A Tier-1 commercial bank in Pakistan (name withheld under NDA)
CoreBanking AML Suite — an internal delivery codename, not a commercial product name.
The problem
The bank had three separate systems that each believed they held the authoritative customer record. Screening ran against one of them. The consequence was structural rather than occasional: a customer could be screened under one spelling of their name and transact under another, and nothing in the architecture would notice.
The reporting pipeline had been written against a sample goAML XML file rather than against the published schema, so schema rejections were discovered after submission to the Financial Monitoring Unit rather than before it.
Constraints we had to design within
- The existing core banking system could not be replaced or taken offline.
- Transaction data was mutable in place, with no event history, so historical alerts could not be reproduced.
- Regulatory examination was scheduled during the delivery window.
- Analyst headcount was fixed — any increase in alert volume had to come with a corresponding increase in alert quality.
Approach
Entity resolution before anything else
We resolved the customer record first, because screening built on ambiguous identity is unfixable downstream. Records were matched across the three source systems using CNIC as the strong identifier where present, and phonetic plus edit-distance name matching where it was not, with every automated merge above a confidence threshold routed to human review rather than applied silently.
This stage produced no visible feature and consumed a substantial share of the timeline. It was also the reason everything after it worked.
An append-only event stream beside the core
Rather than modify the core banking system, we captured its transaction events into an append-only store. That store became the substrate for monitoring and for reporting, and it is what made alert reproduction possible — a requirement that only becomes visible during an examination, at which point it is too late to add.
Deterministic rules with model-assisted prioritisation
Alerts of record are produced by a deterministic rule engine, so every alert carries an auditable reason. A model runs alongside to order the analyst queue by likely materiality. The regulatory critical path stays explainable; the analysts get their day back.
goAML validation moved before submission
We built XSD validation against the published goAML schema into the pipeline, running in the bank's own environment. Report generation also enforces narrative quality rules, because the reason-for-suspicion text is read by a human analyst at FMU and its quality reflects on the whole programme.
Engineering notes
Why an immutable event stream rather than mutable state
The decisive constraint in AML work is not detection quality, it is reconstruction. An examiner does not ask what the system believes today; they ask what it knew on the day a decision was taken, and expect the answer to be evidenced rather than asserted.
A conventional mutable schema cannot answer that. Once a customer risk rating is updated in place, the rating that actually drove a decision six months ago is gone. Storing an append-only stream of events, with derived state projected from it, means any historical position can be rebuilt exactly — including the configuration that produced it.
The cost is real and worth stating: projections add operational complexity, and engineers unfamiliar with the pattern find the indirection uncomfortable at first. In a regulated context that cost is straightforwardly worth paying, because the alternative is an audit answer of "we cannot reconstruct that".
Screening thresholds as governed configuration
Name matching against sanctions and proscribed-persons lists is a tuning problem, not a correctness problem. Set the threshold too tight and real matches are missed; too loose and the alert queue becomes noise an analyst learns to dismiss reflexively — which is the more dangerous failure, because it degrades quietly.
Thresholds were therefore treated as governed parameters rather than deployment settings: versioned, change-controlled, and recorded with the testing that justified each value and the person who approved it. When an examiner asks why a threshold sits where it does, "that is what the vendor shipped" is not an answer that survives the follow-up question.
Transliteration from Urdu makes this materially harder than in Latin-script markets. The same person legitimately appears under several Roman spellings, so exact matching under-detects and naive fuzzy matching over-alerts. Matching is tuned per list rather than globally, because the lists have different risk profiles and different tolerance for false negatives.
Keeping the model off the decision path
There was commercial appetite for machine learning in the monitoring layer. The design keeps deterministic rules as the alerts of record and uses a model only to order the review queue.
This is not conservatism about the technique. It is that explainability is a regulatory obligation here, and an alert whose only justification is a score cannot be defended in an examination. Ordering a queue is a decision that being wrong about is recoverable; deciding whether to file is not.
Outcome
Screening now runs against a single authoritative customer record. Alert reproduction for historical dates is possible and has been exercised. Schema rejections are caught internally rather than after filing.
The threshold-tuning decisions are versioned and logged with their false-negative testing and approver, which turned the examination question "why is this threshold set here?" from a research exercise into a document lookup.
Figures above are drawn from delivery records held under NDA and are pending independent confirmation. Where a figure cannot be evidenced it will be removed rather than qualified.