Inbound-transfer point-in-time false-positive backtestRisk & Fraud

Task prompt

Hey — sanity check on the backtest before tomorrow's ENG-14 Risk review. The draft matched each old pending pull to the funding flags on the account row today. Work from ENG-14 — guardrail, backtest population, risk treatment, sign-off criteria — and follow the ticket it links on handling funding timestamps in a historical review. Rebuild the blocked cohort in the warehouse and give me the false-positive result two ways: the draft's current-row view (the ticket's test against the row as it stands today) and the corrected view (the same test, applied as the linked ticket requires). Use the ticket's definition as written for both — they may differ only in how timestamps are treated, never in which conditions count as funding. Two things I want shown explicitly rather than assumed. First, pending exposure: show me the earlier attempts on blocked accounts that the ticket says must not be counted toward it — how many, their total value, and which accounts they sit on. Second, the margin on the corrected decision: of the accounts that are false positives only under the draft's view, tell me which single one would, on its own, have changed the corrected view's gate outcome if it had been left in, and which of the gate's two limbs it turns on. Create a channel "inbound-transfer-pit-backtest", post the findings and your recommendation, then pin it. File a Bank Operations ticket titled "Inbound transfer limit — point-in-time backtest" with one line per blocked account: id, pending amount, pending created-at date, current-row classification, point-in-time classification, short reason. Link that ticket to ENG-14. Cover the same ground in the channel, the ticket, and your reply here: the blocked count and dollars; each view's false-positive count, account ids, dollars, and rate within the cohort; the accounts and dollars that are false positives only under the draft's view; the excluded-attempt reconciliation; the single account that carries the corrected decision; and the ticket's rollout gate applied to each view, with the thresholds it passes or fails.