Settlement Engine At 99.95% Accuracy: Triple-Match Reconciliation Across 1,400+ Merchants

Rebuilt the settlement and reconciliation engine for a regional acquirer-processor, moved from two-way match (ledger vs scheme file) to triple-match (scheme settlement file + bank statement + internal ledger). Achieved 99.95% sustained reconciliation accuracy across 1,400+ merchants in four markets. Cut break-detection latency from T+3 evening to T+1 morning, reducing daily reconciliation effort by ~65% and merchant-facing settlement delays from ~2% to ~0.04% per month. Established the reconciliation engine as the system of record for both finance reporting and merchant settlement disputes.

The platform's reconciliation engine was two-way: internal ledger matched against scheme settlement file. The bank statement was reconciled manually by the finance team, T+2 to T+3, producing a daily 6+ FTE-hour exercise across four markets. Reconciliation breaks were detected late (T+3 evening or later); merchants who had been credited but where the funds had not arrived from the scheme were experiencing settlement delays at a ~2% monthly rate; the finance team was carrying a backlog of unresolved breaks rolling from week to week. The CFO and the COO had been escalating; the audit team had flagged the manual statement reconciliation as a tier-2 observation. The senior team needed a system that produced T+1 morning break detection, full triple-match, and per-merchant visibility into the reconciliation state.

• Triple-match engine: every settlement record reconciled across three sources, scheme settlement file (Visa BASE II / Mastercard Settlement File), bank statement (MT940 / MT950 / camt.053), internal ledger entry
• Match-key strategy: per-scheme transaction-reference normalisation; per-statement narration parsing; per-ledger reference standardisation; cross-source key generation enabling automated matching across heterogeneous identifiers
• Per-merchant break detection: every break tagged to the affected merchant, the financial impact, the source of the discrepancy, the suggested remediation
• Real-time break dashboard: live state of all open breaks; per-merchant view; per-source view; per-resolution-owner view
• Automated remediation workflows: common break classes (timing mismatch, narration variation, FX rounding) auto-resolved with audit trail; novel break classes routed to finance ops
• Per-merchant reconciliation report: daily report per merchant on their settled, pending, and broken transactions, surfaced in the merchant portal
• Audit-evidence pipeline: every reconciliation decision logged with the matched records, the decision rule, the resolver, the timestamp
• Settlement-state SLAs: defined per merchant tier with auto-escalation when breaks exceed defined ageing

• The triple-match engine is the system of record for settlement state; the internal ledger is one input among three, not the truth
• Match-key generation is per-scheme + per-statement + per-ledger, normalised against a canonical settlement transaction-ID; mismatches are reconciled through configurable rules
• Automated remediation runs as a series of rules; each rule has documented controls; novel break patterns are escalated to finance ops for manual handling and rule-base expansion
• Per-merchant reporting is generated daily; surfaced via merchant portal API; reconciled against the merchant's own books if the merchant operates one
• Audit evidence is keyed on the reconciliation event (not the transaction), every reconciliation decision is one row, queryable per merchant, per market, per resolution rule
• Failure mode: if any of the three sources is missing on a given day, the engine flags the day as partial-reconciliation and surfaces the gap explicitly rather than silently passing

• Daily reconciliation standup (per market, 15 minutes): prior-day breaks, root cause, remediation, evidence
• Weekly per-market reconciliation health review: break rate, resolution time, recurring patterns, rule-base additions
• Monthly finance + merchant-success joint review: merchants experiencing recurring issues, settlement-state SLA misses, remediation outcomes
• Quarterly scheme + bank coordination: cross-source reconciliation issues flagged with scheme / bank counterparties; resolution timelines tracked
• Real-time alerting on breaks above tier-defined thresholds; alerting on missing source files (scheme file missed, statement late)

Owned the settlement engine rebuild end-to-end, triple-match architecture, match-key strategy, automated remediation logic, per-merchant reporting, audit-evidence pipeline, settlement-state SLA design, and the coordination with finance + ops + audit + merchant-success. Direct accountability for reconciliation accuracy KPIs, break-detection latency, daily reconciliation FTE effort, and merchant-facing settlement experience.

• Achieved and sustained 99.95% reconciliation accuracy across 1,400+ merchants in four markets
• Cut daily reconciliation effort by ~65% across the four markets, from ~6 FTE-hours per market to ~2
• Reduced merchant-facing settlement delays from ~2% per month to ~0.04% per month
• Brought break detection from T+3 evening to T+1 morning
• Closed the audit observation on manual statement reconciliation
• Established the triple-match engine as the system of record for both finance reporting and merchant settlement disputes
• Eliminated the rolling weekly backlog of unresolved breaks; reached steady-state same-day resolution on the majority of breaks

• Built triple-match over two-way match, more complex match-key engineering; produced the audit posture and the merchant-facing experience that two-way could not
• Standardised per-source match-key normalisation rather than per-source bespoke logic, required upfront investment in canonical settlement ID; paid back when new scheme settlement-file format variants arrived without code changes
• Built automated remediation as rule-base with documented controls, heavier upfront ops-engineering investment; produced the audit-ready resolution trail and the rapid scaling to additional break patterns
• Insisted on per-merchant daily reporting in the merchant portal, added engineering for the merchant-facing surface; improved the merchant experience and reduced inbound support volume materially

• Two-way reconciliation is structurally insufficient at any meaningful merchant count. The bank statement is a third source of truth; failing to include it means the engine cannot detect the cases where the scheme settled but the bank statement did not credit (or vice versa).
• Match-key normalisation is the actual product. The scheme transaction ID, the bank narration, and the internal reference rarely match by string; the canonical ID layer is what makes triple-match feasible.
• Automated remediation is rule-base + governance. Rules without governance produce silent over-reconciliation (false matches); governance without rule-base scales linearly with FTE. Both together produce sustained accuracy.
• Per-merchant reconciliation reporting is a merchant-experience product, not an internal finance one. The reporting surface in the merchant portal is what convinces merchants the platform is operating well.
• Break-detection latency is the metric that matters more than accuracy. A 99.5% accurate engine that detects breaks on T+3 produces a worse merchant experience than a 99.0% accurate engine that detects on T+1.

Settlement and reconciliation is the part of the acquirer-processor stack that is invisible when it works and existential when it does not. The platforms that ship triple-match cleanly, canonical IDs, automated remediation, per-merchant reporting, sub-T+1 break detection, operate with merchant trust, audit-clean posture, and finance-team efficiency that compounds. The platforms that ship two-way match carry rolling break backlogs, audit observations, manual finance work, and merchant-facing settlement issues that become churn drivers. The cost difference between the two is not engineering, it is the operating model. This is the playbook.