After a reconciliation incident reaches customers or your partner bank
After a reconciliation incident, freeze the affected money flows, rebuild transaction status from the ledger and bank and processor statements, find the root cause, correct balances with reversing entries, add regression tests for the failing path, and package evidence for the partner bank or regulator. The result is a corrected ledger, a break inventory, and dated test evidence.
When a reconciliation break has left the reconciliation team
The trigger is a break seen outside engineering. The daily comparison shows the ledger total for a for-benefit-of (FBO) or safeguarding account above the bank balance. Customers report balances that differ from their statements, finance cannot close the month because processor payouts do not match captures, or a partner bank asks for a written explanation of a shortfall.
The people in the room are the CTO or head of engineering, the finance operations lead, and the compliance officer of a neobank, a Banking-as-a-Service (BaaS) programme, a remittance product, or a business banking platform. Reconciliation discrepancies at this stage usually trace to one of these defects:
- a retried webhook with the same event ID that posted a second journal;
- ACH (Automated Clearing House) returns received after the cut-off that never reversed the original payout;
- a pending camt.054 entry posted as final and posted again when the camt.053 statement booked it;
- an auto-match tolerance that closed one-cent FX rounding residues as matches for months;
- a data migration that carried balances across but dropped reversal links.
What happens when the break is handled without preparation
These rules start their clocks at a customer's notice or at discovery of the incident, whatever the state of the fix.
- US consumer accounts. Regulation E treats an incorrect electronic fund transfer and a computational or bookkeeping error relating to a transfer as errors (12 CFR 1005.11(a)(1)(ii) and (iv)). The financial institution determines whether an error occurred within 10 business days after the notice (1005.11(c)(1)), with longer limits only under the provisional credit and account type conditions in 1005.11(c)(2) and (c)(3). Without a reconstructed transaction history, those dates pass one customer at a time; the Regulation E testing requirements list every timer.
- Partner bank records. The Consumer Financial Protection Bureau (CFPB) alleged that Synapse Financial Technologies violated the Consumer Financial Protection Act by failing to keep adequate records of the location of consumers' funds and to ensure those records matched its partner banks' records. Per the CFPB enforcement action page (complaint filed 21 August 2025, order entered 12 September 2025, checked on 2026-09-16), the partner banks determined a shortfall of between $60 million and $90 million, and consumers had no access to their funds for weeks or months while the banks reconciled records.
- Canada. Under the Retail Payment Activities Act (RPAA) and its Regulations (RPAR), a payment service provider holding end-user funds identifies, as soon as feasible, any instance where those funds would not have been payable to end users on an insolvency event listed in RPAR 14(3), and immediately investigates its root cause (RPAR 16(1) and 16(2)). An incident with a material impact on end users requires notice to them and to the Bank of Canada without delay (RPAA 18(1)), and the incident record includes the status of all transactions and how data integrity issues were corrected (RPAR 5(1)(i)(viii)(D)). See the RPAA safeguarding and incident requirements.
- EU. The Digital Operational Resilience Act (DORA) applies to credit institutions, payment institutions, and electronic money institutions, among others (Article 2(1)). When recovering from an information and communication technology (ICT)-related incident, the entity performs checks, including reconciliations, also when it rebuilds data from external stakeholders (Regulation (EU) 2022/2554 Article 12(7), checked on 2026-09-16). A major ICT-related incident, or a major operational or security payment-related incident at those entities (Article 23), is reported to the competent authority (Article 19(1)), and clients whose financial interests are affected are informed without undue delay (Article 19(3)). See the DORA testing requirements.
An unprepared response adds engineering failures:
- A correction that rewrites history. A backfill script updates posted ledger rows, so today's balance looks right and the original entries a partner bank or auditor samples are gone.
- The same break returns. A hotfix ships without a test that replays the failing statement, and the next cycle reopens the break.
- Double correction. Finance adjusts from a spreadsheet while engineering runs a script, the adjustment posts twice, and a shortfall becomes an overpayment to claw back from customers.
Recovery sequence after a reconciliation incident
- Contain. Pause the payout batch, auto-match rule, or posting job that creates new breaks, or route it to manual approval. Output: a containment record with the pause time per flow and the list of affected accounts.
- Build the break inventory. Rematch the affected window against bank statements (camt.053, BAI2), processor settlement files, and scheme reports, and give each break one class. Output: a break inventory per account, business date, class, and amount.
- Reconstruct transaction status. Mark each affected transfer as initiated, sent, booked, returned, or unknown, citing the external record that proves the status. Output: a transaction status reconstruction log.
- Find the root cause across ledger and external records. Reproduce the break in staging with synthetic statement and settlement files. Keep production account data out of staging. Output: a root cause statement and a failing test that reproduces the break.
- Correct and backfill. Post reversing and adjusting entries; posted rows stay unchanged. Run the backfill first in staging and compare recomputed balances per account. Output: a correction journal with before and after balances, and a customer remediation list for refunds and fee reversals.
- Verify the correction. Rerun reconciliation for the whole affected window. Output: a post-correction reconciliation report with every remaining break explained, and a balance drift and rounding report.
- Add regression tests for the failing path. Each break class found gets an injected-file test in CI that fails on the defect. Output: merged regression tests linked to the incident ticket.
- Close the detection gap. Test the daily comparison of ledger totals with safeguarding or FBO account balances, including weekends and holidays, with injected shortfalls. Output: detection check results per injected case.
- Package the evidence. Assemble the timeline, inventory, root cause, correction journal, test results, and correction audit trail. Output: an incident evidence pack for the partner bank review or the regulator's request.
Timeline and scope of reconciliation incident recovery
Durations are typical engineering estimates for one ledger and one or two external counterparties, not company statistics.
| Phase | Duration (estimate) | Roles | Output |
|---|---|---|---|
| Containment | Hours to 2 days | Engineering lead, finance operations | Containment record, affected account list |
| Break inventory and status reconstruction | 3 to 7 days | QA engineer, finance operations, data engineer | Break inventory, transaction status reconstruction log |
| Root cause | 3 to 10 days | Backend engineer, QA engineer | Root cause statement, reproducing test |
| Correction and backfill | 1 to 3 weeks | Backend engineer, QA engineer, finance approver | Correction journal, remediation list, post-correction report |
| Regression tests and detection | 1 to 3 weeks, in parallel with correction | QA automation engineer | Merged regression tests, detection check results |
| Evidence pack | 3 to 5 days | QA lead, compliance officer | Incident evidence pack |
Regulatory clocks run separately: each Regulation E notice starts its own error resolution clock. Scope grows with the number of banks and processors, the file formats involved, the length of the affected window, the jurisdictions with affected customers, and whether overpaid money needs recovery. A break caused by cut-off or return handling adds rail-specific cases from bank transfers and payment rails testing.
How we help after a reconciliation incident
We test ledgers and reconciliation for neobanks, BaaS programmes, remittance products, and business banking platforms, and join at step 2 or step 4.
- Steps 2, 4, and 6. Ledger and reconciliation testing delivers "Reconciliation test scenarios against bank, processor, and scheme files", and the "Balance drift and rounding report" before and after the correction.
- Steps 5 and 9. The same service's "Audit trail completeness checks" confirm that each correction records the actor, time, reason, and original entry. After a migration, data migration testing adds the "Balance and transaction history comparison report".
- Steps 7 and 8. Test automation delivers the "Regression suite for critical money flows" and "CI pipeline integration with release gates", so a posting change that reintroduces the defect fails the build.
- Step 9. Audit and certification test evidence delivers the "Requirement-to-test traceability matrix" and "Retest evidence after remediation", mapped to the requests from your partner bank or regulator.
Your team keeps production access, customer remediation decisions, and notices to regulators and customers. Our evidence is input to the partner bank's or regulator's review.
Related
Services
Standards
Guides
- How to test ledger reconciliation against settlement files and bank statements
- How to reconcile camt.053 statements: format, batch entries, reversals, and MT940 mapping
- How to test Same Day ACH cutoff times and settlement timing across time zones
- How to test payment idempotency
- How to test banker's rounding in payment and ledger code
Questions
What are reconciliation discrepancies?
Reconciliation discrepancies are differences between a company's internal ledger and an external record of the same money movement, such as a bank statement, a processor settlement file, or a card scheme report. Common classes of reconciliation discrepancies are timing differences, duplicate entries, entries missing on one side, amount mismatches, and reversals that do not link to their original entry.
How to identify reconciliation discrepancies?
Reconciliation discrepancies are identified by matching every ledger entry to a line in the bank statement, processor settlement file, or card scheme report by reference, amount, and value date, and then comparing closing balances per account and business date. Each unmatched item becomes a break with one class, and a break older than its expected settlement window needs an investigation.
How to resolve reconciliation discrepancies?
Reconciliation discrepancies are resolved by tracing each break to its source event, deciding which record is wrong, and correcting that record: a reversing ledger entry for an internal error, or a request to the bank or processor for an external error. Each resolution records the actor, time, reason, and original entry, and a regression test covers the defect that caused the break.
Scope your reconciliation incident recovery
Send the break list you have so far, your ledger model, and the statement and settlement file formats involved, and we return a recovery test scope with the evidence each step produces.