Declined-but-pending auth reversal reconciliationCards & Interchange

Task prompt

CX just flagged this in #bugs_in_the_mainframe: customers were seeing their card transactions decline, but the money still showed up as a pending hold on their account. Word is the card processor went back and reversed a batch of those auths to clear the holds. I need to know how bad this was and whether it's actually resolved. Eng has a ticket on file about issuer-timeout card declines — the mechanism where the processor is slow, the auth times out so the customer sees a decline, but a hold still posts. Track that ticket down so we cite the real root cause, not just the symptom. For calendar year 2023 only (this was a 2023 incident — not later outages and not the all-time history of the same pattern), reconstruct the population of initial authorization requests that timed out yet still linked to a ledger hold. Do not fold in ordinary NSF / denied incremental top-ups that legitimately attach to a parent auth, and do not count routine auth-reversal volume. Sum the dollars that were actually held from the auth/hold amount (not the zero-dollar release entries). Then reconcile cleanup: how many of those holds were later reversed/released versus still pending, and roughly how long they stayed stuck. When you've got it, post an incident reconciliation summary back to the #bugs_in_the_mainframe channel so CX and eng see it, and reply to me with the headline numbers — affected authorizations, affected accounts, total dollars held, how many were reversed vs. still pending, and whether we can call this fully cleaned up.