AML Transaction Monitoring at an Indian Public-Sector Bank — 71% Alert Volume Reduction, RBI-Audit Clean

MindMap proposed an augmentation strategy rather than a replacement. The legacy AML engine would continue to generate the primary alert stream, but every alert would pass through a new triage layer — built on Compliance Monitor (Cm) and Anomaly Detector (Ad) — that would score the alert for likely true-positive probability and either auto-close clear false positives, surface the high-confidence suspicious cases with rich context for analyst review, or route the borderline cases for standard investigation.

Phase one was the labelled-data build. We ingested four years of historical alerts, four years of investigation outcomes (the analyst's final disposition), and the full set of filed STRs. Approximately 14 million labelled alert records were used to train the triage model. We also ingested the bank's customer KYC data, transaction history, RFI (Request for Information) responses to correspondent banks, and the open-source sanctions and PEP datasets the bank already subscribed to.

Phase two built the triage model. It is a stacked ensemble: a gradient-boosted tree for the structured features (alert type, amount, frequency, customer risk band, account age, channel mix), a graph neural network for the transaction-network features (counterparty risk, fund-flow pattern, network distance to known high-risk entities), and an LLM-based reasoning layer (Llama 3.1 70B fine-tuned on the bank's STR narrative corpus) that generates the structured case narrative for analyst review.

Phase three was the analyst-workflow rebuild. The legacy AML engine's alert queue was replaced by a new case-management UI that surfaces the model's confidence, the narrative explanation, the relevant transaction network visualisation, and a checklist of the standard investigation steps. Analysts can confirm, escalate or dismiss each case with one click, with the model's prediction logged as a feature for continuous retraining.

The entire stack runs on the bank's private cloud inside its primary data centre in Mumbai, with active-active failover to a secondary site in Hyderabad. The bank's RBI-mandated data-residency posture is preserved: no transaction data, no customer PII, no model artefact leaves the country.

The legacy AML engine continues to operate unchanged — it consumes the same transaction feed it always has, applies its rule library, and emits alerts to a Kafka topic. The triage layer consumes that Kafka topic, enriches each alert with the additional features (customer history, network position, related cases), runs the ensemble scoring, and emits a triage outcome to a downstream queue that drives the analyst workflow.

The LLM serving layer runs Llama 3.1 70B-Instruct fine-tuned on the bank's STR corpus — approximately 280,000 historical STR narratives, redacted of PII for the training process. The model is served via vLLM on a cluster of sixteen H100 GPUs, sized to handle the daily alert volume peak (approximately 1,400 model calls per minute at peak). Inference is constrained to the structured JSON schema the case-management UI expects, with hallucination guardrails preventing the model from inventing facts not present in the input transaction data.

The graph features are precomputed on a 15-minute cadence using a Spark-based pipeline that maintains the bank's transaction graph (approximately 8.4 billion edges) in Neo4j. Graph features for the alerts in the current queue are updated continuously; less time-sensitive graph features (community-detection clusters, long-window centrality scores) are recomputed on a daily cadence.

All model decisions, inputs and outputs are logged to a compliance audit store with the full RBI-required retention. The bank's internal audit team has direct query access and the inspection trail that the bank's external auditors and the RBI inspectors require.