Payments Reconciliation at a Gulf Bank — 96% Auto-Match on 4.2M Daily Transactions

MindMap deployed Bank Reconciliation (Br) as the new primary reconciliation engine, Anomaly Detector (Ad) as the exception-pattern-detection layer, Multi-Agent Orchestrator (Mo) for the cross-rail orchestration and Financial Close (Fc) for the cycle-management workflow.

Phase one was the matching-model rebuild. The legacy engine's matching logic was rule-based — match by transaction reference, by amount-and-counterparty, by amount-and-date-within-tolerance — with each rule applied sequentially and the transaction routed to manual investigation if no rule matched. The new engine replaces the sequential rule application with a probabilistic matching model that considers all candidate matches across all match dimensions simultaneously and emits the most-likely match with a confidence score.

Phase two was the cross-rail integration. The bank's payments flow across SWIFT, the regional payment rails and the card networks each generates a different transaction-record format, with different identifiers and different settlement timing. The new engine ingests all rails in parallel and matches across rails where the transaction's lifecycle spans rails (e.g. an inbound SWIFT settlement against an outbound regional payment rail).

Phase three was the exception-investigation workflow. For the transactions that the matching model cannot auto-match with high confidence, the investigation queue is prioritised (high-value, customer-impacting, regulatory-deadline-driven items first) and the investigator's workspace surfaces the candidate matches the model considered, the reasons each was rejected, and the recommended next investigation step.

The platform runs on the bank's private cloud tenant inside its primary data centre, with high-availability failover to the secondary site. The payments data — meaningful PII exposure given the transaction-narrative content — stays inside the bank's perimeter.

The matching engine uses a gradient-boosted-tree ensemble trained on three years of historical match outcomes (the labels). Features include the standard match dimensions (reference, amount, counterparty, date) plus derived features (counterparty-relationship recency, amount-pattern matching, free-text narrative similarity using embedding-based semantic match). The model produces a top-N candidate-match list per unmatched transaction with confidence scores.

The cross-rail orchestration layer is built on Multi-Agent Orchestrator. For transactions whose lifecycle spans rails, the orchestrator tracks the transaction state across rails and surfaces the unified lifecycle view to the investigator. The cross-rail tracking has been the largest single contributor to the auto-match rate improvement — many of the legacy engine's unmatched items were cross-rail transactions whose lifecycle the legacy engine did not understand.

The Anomaly Detector layer runs in parallel with the matching engine. It identifies patterns in the unmatched transactions that suggest systemic issues (e.g. a sudden rise in unmatched transactions from a specific counterparty, suggesting a counterparty-side reference-formatting change). These pattern-level insights drive the operations team's process-improvement work and have caught several counterparty-integration issues that were generating recurring exception volume.

Integration with the bank's payments infrastructure is read-only — the platform consumes the transaction feeds from each rail without writing back to the rails themselves. Reconciliation outcomes are written to the bank's GL platform and to the bank's customer-correspondence engine for downstream notification.