AML transaction monitoring and fraud detection for banks
Rules-based monitoring at the banks below flagged far more than was suspicious: 18,000 AML alerts a day at one, card declines that were over 95% legitimate at another. Scoring each alert and transaction with models trained on the bank's own history closed the clear false positives, gave analysts better cases and caught fraud the rules had missed.
How does AI transaction monitoring for AML and fraud work?
AI transaction monitoring scores every AML alert and card authorisation with models trained on the bank's own history, using amounts, merchants, velocity, customer behaviour and the network of counterparties, devices and cards around each one. Clear false-positive alerts close automatically, each logged with the model's reasoning. The rest reach an analyst with a written case narrative, the transaction network and the investigation steps, and borderline card decisions get a written explanation for customer service.
- An Indian public-sector bank cut the alerts reaching analysts from 18,000 a day to about 5,200, a 71% reduction.
- Its true-positive rate on alerts rose from 2.3% to 9.1%, and filings of suspicious transaction reports rose 38%.
- A GCC bank cut card fraud losses 43% and its false-positive rate from 1.8% of authorisations to 0.86%.
- Average AML investigation time fell from 47 to 14 minutes, and card-decline dispute calls from 8 minutes to 3.
AML and fraud detection, step by step
Score every alert and authorisation
Each alert from the bank's existing AML engine, and each card authorisation, is scored by a model trained on the bank's own history: about 14 million labelled alerts at the Indian bank, and 3 years of authorisations and confirmed fraud at the GCC bank. Card scoring runs inline, at under 50ms p99.
Add the network view
A graph layer adds what a single transaction can't show. For AML it measures counterparty risk, fund-flow patterns and distance to known high-risk entities. For cards it links devices, cards and merchants, which is how the GCC bank caught coordinated card-testing attacks where each transaction looked innocent on its own.
Close, decide or route each case
Clear false positives are closed automatically and each closure is logged with the model's reasoning, so no alert is dropped silently. High-confidence suspicious cases go to analysts with full context, borderline ones to standard investigation. For cards, about 80 fixed rules for regulatory and contractual requirements run first, then the model.
Explain the decision in writing
An open-weights language model on the bank's own servers drafts a case narrative for each alert an analyst reviews, using only facts in the transaction data. For borderline card decisions it writes the reason off the authorisation path, so the explanation is on file before the customer calls.
Log every decision and retrain
Inputs, outputs and explanations go to an audit store kept for the regulator's retention period. Analysts confirm, escalate or dismiss each case in one click, and every decision feeds continuous retraining. The GCC bank retrains nightly, and a new model version goes live only if it is significantly better on held-out data.
AML analysts decide every alert that isn't a clear false positive, and their work is now investigation rather than clearing a queue. At the Indian bank, the freed analyst time went into deeper investigation and proactive case work. At the GCC bank, the fraud-operations team used the graph views to refer 4 organised-fraud cases to law enforcement.
Results from 2 deployments
Every figure below comes from the case study it links to.
Indian Public-Sector Bank
AML Transaction Monitoring
- 4× true-positive rate
- 18K → 5K daily alerts
GCC Tier-1 Bank
Real-Time Card Fraud Detection
- 52% false-positive reduction
- <50ms p99 inline decision latency
- 8M cards covered
The accelerators behind it
Pre-built accelerators do the work, configured to your documents, rules and systems. Delivery took 24 to 28 weeks in the case studies above.
AML and fraud detection: the questions buyers ask
Does cutting AML alerts mean missing suspicious activity?
No. At the Indian public-sector bank, the whole 71% cut came from closing high-confidence false positives, and every closure is logged with the model's reasoning. The true-positive rate on alerts analysts work rose from 2.3% to 9.1%, filings of suspicious transaction reports rose 38%, and the first RBI inspection after go-live cited the improved investigation quality as a positive.
Do we have to replace our transaction monitoring system?
No. The Indian bank's AML engine runs unchanged: it takes the same transaction feed, applies its rules and emits alerts, and the new triage layer scores each one. Replacing the engine would have meant a multi-year programme, because it is wired into core banking, trade finance, the interbank messaging gateway and the cards host.
Is real-time scoring fast enough for card authorisations?
Yes. The GCC bank's fraud scoring runs inline at under 50ms p99, inside the 80ms its authorisation path allows. The core model scores in 6ms p99 on the bank's CPUs, and the language model that writes explanations runs separately, off the authorisation path.
Can analysts and customer service see why a decision was made?
Yes. AML analysts see the model's confidence, a written case narrative, the transaction network and the standard investigation steps in one case view, which cut average investigation time from 47 to 14 minutes. At the GCC bank, the reason for a borderline decline is on file before the customer calls, and dispute calls fell from 8 minutes to 3.
Where does transaction data stay?
Inside the bank. The Indian bank's stack runs in its own data centre, with active-active failover to a second site, and no transaction data, customer PII or model artefact leaves the country. The GCC bank's runs on its own on-premises infrastructure, with a hot standby at its secondary site, and no scoring traffic leaves the country.
How do we know a new model is better before switching over?
Run it in parallel first. At the GCC bank, the new engine shadowed the existing rules for 10 weeks, catching 24% more confirmed fraud while declining 51% fewer legitimate transactions, and the CRO approved cutover at the end of the shadow run. After go-live, a new model version is promoted only when it is significantly better than the current one on held-out data.
How long does a deployment take?
Delivery took 24 weeks at the GCC bank and 28 weeks at the Indian public-sector bank.
Get the MindMap capability deck
The platform, the accelerator library and how an engagement runs, in one deck. Our team emails it within one business day.
More use cases
KYC and account opening →
4 hrs onboarding at a UK challenger bank, down from 5 days
Regulatory reporting and compliance →
7 days regulatory close at an ASEAN bank, down from 28 days
Insurance claims →
80% low-complexity UK motor claims settled straight through
See it running on your own process
A 20-minute walkthrough with the engineers who build these deployments: your documents, your systems, the accelerators running.