Compliance is an architectural property, not a bolt-on
Most AML remediation work we are asked to do exists because compliance was added to a transaction platform after the platform was designed. The symptoms are consistent: screening runs against a customer record that three services disagree about, alerts cannot be reproduced six months later because the transaction table is mutable, and the reporting pipeline was written against a sample XML file rather than against the schema the Financial Monitoring Unit actually validates.
We build the other way round. The customer record is resolved to one authoritative entity before screening is designed. The transaction stream is append-only, so any alert can be reconstructed exactly as the system saw it at decision time. The reporting pipeline validates against the goAML schema in your own environment before anything is submitted. None of this is exotic — it is just considerably cheaper to decide at design time than to retrofit under examination pressure.
Screening that survives Pakistani name data
Identity screening against the NACTA Proscribed Persons list, UN Security Council Consolidated List and OFAC SDN is straightforward to describe and difficult to tune. Urdu-to-Roman transliteration produces several valid spellings for the same person, honorifics and patronymics appear inconsistently, and the same CNIC frequently sits against differently spelled name records inside a single institution.
Exact matching misses real hits. Untuned fuzzy matching produces alert queues an analyst cannot work honestly — and an analyst dismissing hundreds of alerts a day will eventually dismiss the one that mattered. We tune phonetic and edit-distance matching per list, treat the threshold as a governed, version-controlled parameter, and log every tuning change with its false-negative testing and its approver. That log is what turns "why is your threshold 0.82?" from an awkward question into a two-minute answer.
Monitoring you can explain to an examiner
Transaction monitoring detects behaviour: structuring below CTR thresholds, velocity spikes, dormant-account reactivation, geography inconsistent with a stated customer profile, round-trip flows between related parties.
There is commercial pressure to lead with machine learning. We generally advise against putting a model on the regulatory critical path, because explainability is a requirement rather than a preference — "the model scored it 0.31" is not a defensible answer to an examiner. The pattern we build is layered: a deterministic rule engine produces the alerts of record with an auditable reason attached to every decision, and a model runs alongside to prioritise the analyst queue. You get the efficiency without the unexplainable artefact.
goAML reporting, validated before submission
FMU accepts STRs and CTRs through goAML, which validates every submission against a strict XML schema. A rejected report is a report you did not file, and rejections cluster around a small set of causes: party identifiers placed in the wrong typed field, conditionally-mandatory fields modelled as optional, locale-formatted dates and separators, and narratives that are schema-valid but analytically useless to the human who reads them.
We build the reporting pipeline against the schema from the first iteration, with an XSD validation stage that runs in your environment before submission, and we treat the reason-for-suspicion narrative as a product surface rather than a free-text box — because it is read by an analyst, and its quality is a visible reflection of your programme.
What is included
- Customer entity resolution across onboarding, ledger and CRM systems
- Real-time and batch sanctions, PEP and proscribed-persons screening
- Match-threshold tuning with governed, auditable change control
- Deterministic transaction monitoring rule engine with alert reasoning
- Append-only event storage for reproducible alert reconstruction
- Case management and analyst workflow for alert disposition
- goAML XML generation with pre-submission XSD validation
- STR and CTR automation with narrative quality controls
- Regulatory audit trail and examination evidence packs
- Model-assisted alert prioritisation, kept off the critical path
Technologies and standards
Related case studies
- goAML-Integrated AML Monitoring for a Tier-1 Bank — Screening, monitoring and goAML reporting rebuilt around an immutable transaction event stream, so any alert can be reconstructed exactly as the system saw it.
- RAAST-Enabled Digital Wallet Built for Unreliable Networks — A consumer wallet with RAAST instant payments, where settlement finality and offline conflict resolution were design decisions rather than late discoveries.