Duplicate card auth holds never releasedCards & Interchange

Task prompt

CX escalated a customer and I'd like you to size the problem behind it. Her card declined at the till, but the account still got authorized three times for the same amount and two of those holds are still sitting against her balance. It's card 49370 on account 11887, $16.75 at 'RED HAWK SPORTS BAR' on 2023-12-24: three approved auths inside about twenty minutes, nothing ever captured, and only one of the three ever came back off. Same shape as ENG-252 and ENG-2376 — read both of those first, ENG-2376 in particular for how a release ties back to the authorization. Then work out how widespread this is across the whole recorded history. Everything you need is in the card authorization event log: the approvals, the captures/settlements and the releases are all events in there, so reconstruct it from those (the hold fields on the transaction ledger won't give you the right picture, and the disbursements table is transfer-scoped, not a card clearing source). So we're both measuring the same thing, use this definition: - A hold is an `auth-request` or `incremental-auth-request` with status `approved` and a non-zero amount. Denied auths never placed a hold, and zero-amount card verifications tie up no money, so leave both out. - One purchase attempt = approved holds on the same card, merchant and amount, each within 72 hours of the previous one. - An attempt qualifies if it has two or more holds and was never settled — meaning no `auth-capture` or `force-capture` with status `received`, and no `auth-clear-request` with status `approved`, for that same card + merchant + amount from the attempt's first hold onward. Note this is a question about the attempt, not about any single authorization. - In a qualifying attempt the earliest hold is the legitimate one; every later hold is a duplicate that shouldn't be there. - A duplicate was released if the log holds an `auth-reversal` carrying that duplicate's own trace id on the same card — that's the linkage ENG-2376 turns on. Don't put a time condition on it: a couple of thousand reversals in this log were written a fraction of a second before their own authorization, and those are genuine releases. Released duplicates are context only. - A duplicate with no such reversal is still stranded. That's the population I want audited. - For anything time-based, treat "now" as the latest `created_at` in the event log rather than today's date. Please work out and report: - Scope: qualifying attempts carrying at least one still-stranded hold, affected cards, affected accounts, total still-stranded holds, and the date window (earliest to latest still-stranded hold). - Dollar impact: total dollars currently stranded (still-stranded holds only), the released dollars for context, and total dollar-hours the money was held (dollars x hours from the hold until it was released, or until the "now" cutoff if it never was), split still-stranded vs released. - Overdraw risk: of the accounts with a still-stranded hold, how many were at overdraw risk — the running total of that account's still-stranded holds exceeded its available balance, taken from the most recent balance snapshot at or before each hold — versus those that never breached. - Remediation: the exact number of still-stranded holds Ops needs to release (keeping the one legitimate hold per attempt), and be ready to hand over the line-item list (card, account, amount, auth time). - Recommendation: root cause and a concrete control change, with the tradeoff called out. When you're done: open a Slack channel 'duplicate-auth-holds-never-released-audit', post the summary (scope, tied-up funds, overdraw-risk cohort) and pin it; file a Card Operations Jira ticket titled 'Duplicate card auth holds never released audit' referencing ENG-252 / ENG-2376; and reply with the headline numbers and your recommendation.