Anti-money-laundering transaction monitoring

Banks, payment institutions, e-money issuers, crypto providers and other obliged entities must monitor customer transactions and report suspicion to the financial intelligence unit (in Germany: the FIU, via goAML). Classic rule scenarios ("more than X EUR in cash per week") generate mostly false alerts that analysts close by hand. ML adds risk scoring, network analytics and anomaly detection on top of rules; LLMs help analysts summarise cases and draft reports. The decision to file a report stays with a qualified human (AML officer / MLRO).

Problem & value

• Today: rule-based scenarios with thresholds, run in batch against customer segments. Large volumes of alerts, a high share of false positives, and analysts re-collecting the same context (KYC file, past transactions, counterparties) for every case. Regulators expect documented, risk-based, back-tested monitoring, and also criticise missed suspicious activity.
• AI value: (1) prioritise alerts by learned risk so analysts see the likeliest true positives first; (2) detect patterns rules miss (structuring across accounts, funnel and mule networks, rapid pass-through); (3) auto-summarise alerts and draft narratives, cutting handling time; (4) tune thresholds with evidence instead of guesswork.
• Scale of the problem: a widely quoted UN estimate puts annual laundering at 2–5 % of global GDP; ground-truth labels are scarce because most laundering is never detected, which is why public AML benchmarks are synthetic [3]. Vendor-claimed reductions in false positives vary strongly by institution and are not generalisable; measure on your own back-test (see KPIs).
• Regulatory driver: the EU AML Regulation (EU) 2024/1624 applies from 10 July 2027; the new EU authority AMLA (Frankfurt) is to start direct supervision of selected high-risk cross-border institutions in 2028, with about 40 entities selected during 2027 [1][2]. Expect harmonised rules and more supervisory scrutiny of model governance.

Variants

• Retail and corporate banking: the core case (account-based monitoring, correspondent banking, trade-based laundering indicators).
• Payment institutions, e-money, neobanks, marketplaces: high-velocity instant payments; real-time or near-real-time scoring; closely related to mule detection ANOM-022 and fraud ANOM-001.
• Crypto-asset service providers: on-chain analytics and travel-rule data, covered in ANOM-023.
• Capital markets / wealth / insurance: monitoring of securities flows, premium refunds, single-premium products; market abuse is separate (ANOM-012).
• Non-financial obliged entities (SMB): real estate agents, notaries, dealers in high-value goods, auditors, tax advisers: usually risk assessment, customer due diligence checklists and unusual-transaction flags rather than full monitoring engines; vendors for this segment are mostly KYC-portal tools.
• Public sector (FIU): analysis of incoming reports and network triage on the authority side. This is law-enforcement-adjacent; see the limits in the regulation section.
• Private use: none; this is not an end-consumer use case.
• Related, but separate: sanctions/PEP screening (ANOM-016), onboarding identity checks (ANOM-014), fake documents (ANOM-017).

How it works

1. core banking / payments / cards
2. event stream + data lake
3. data prep (customer 360, counterparty resolution, entity resolution)
4. detection layer a) rule scenarios (regulatory baseline, explainable) b) supervised models (gradient boosting on labelled alert outcomes) c) unsupervised / anomaly models (peer-group deviation, new behaviour) d) graph analytics (shared devices/addresses, funnel, circular flows, GNN)
5. alert generation + deduplication into cases
6. alert prioritisation (risk score + reason codes)
7. LLM assistant: case summary, evidence collection, draft narrative
8. analyst review (four-eyes)
9. escalate / close with rationale
10. MLRO decision
11. SAR/STR filing (goAML) + feedback loop to models

• Rules stay. Regulators expect a documented, scenario-based baseline. ML typically sits as a second layer: it re-ranks or suppresses rule alerts and adds extra alerts, with documented thresholds and back-testing (below-the-line testing).
• Supervised models need labels from past alert outcomes; labels are noisy and biased towards what rules already flagged. Mitigate with sampling of unalerted activity and periodic random reviews.
• Graph methods: entity resolution and transaction graphs surface organised structures that single-account views miss. GNNs (e.g. via PyTorch Geometric) show strong results on synthetic benchmarks [3]; in production, explainable graph features fed into boosted trees are common.
• LLMs: summarise a case, extract facts from KYC documents, propose a disposition with cited evidence, draft the SAR narrative in the regulator's structure. They never decide to close or file on their own.
• Human-in-the-loop: analyst disposition, MLRO filing decision, model risk committee approval of changes.

Data preparation

Data needed: transactions, account and customer master data (KYC), beneficial owners, sanctions and PEP lists, prior alerts and case outcomes. They live in the core banking system, payment platform, CRM, KYC tool, and often in scanned onboarding documents and mail. Typical gaps: inconsistent customer identifiers across systems, duplicated parties, poor-quality names and addresses, unlabelled historical alerts (false positive vs. SAR filed), scanned identity papers and missing audit trail of analyst decisions.

Preparation steps: build a customer and counterparty golden record (PREP-005, PREP-011), harvest labels from closed cases and filed suspicious activity reports (PREP-020), define alert categories (PREP-019), digitise paper KYC files with OCR (PREP-006) and build a test set with compliance experts (PREP-018). Clarify purpose and legal basis (PREP-025); pseudonymise for model development (PREP-022). See also DATA-003 and DATA-008.

Rough share of effort: 50-60 percent of the project; data quality dominates model choice.

Implementation paths

Which path for whom

• Enterprise: Path B, because large institutions run own data platforms and need tuned scenarios and explainable models on top of core banking data, with vendor engines where needed.
• Developer: Path C, because open-source graph and anomaly libraries on HW1/HW2 let you build and audit monitoring logic without sending customer data out.
• SMB: Path A, because small obliged entities (payment institutions, brokers, dealers) need a certified, regulator-accepted product with updates for sanctions and typologies.
• Public: Path C, because authorities and public-sector institutions favour sovereign, auditable hosting in Germany over foreign SaaS.

Path A — Buy (recommended for most obliged entities)

• AML/FIU platforms with ML: Hawk (Hawk AI, Munich; EU/German), Lucinity (Iceland/EU), Feedzai, NICE Actimize, SAS Anti-Money Laundering, Oracle Financial Crime and Compliance Management, Quantexa (entity resolution and network analytics), Napier AI, ComplyAdvantage, Tookitaki, Unit21, Sardine, Silent Eight (alert adjudication), Fiserv/FIS/Temenos built-in modules. Also check regional core-banking and savings-/co-operative-bank (Sparkassen, Volksbanken) service providers, which often bundle AML monitoring for their member institutions.
• Check before buying: EU data residency, BaFin/EBA outsourcing and DORA third-party requirements, model transparency (reason codes, back-testing tooling), goAML export, ability to run your own scenarios, tuning without vendor tickets, and references from institutions of your size.
• Choose A when: you are a regulated bank, payment or e-money institution. Building a full engine in-house is rarely worth it below large-bank scale. Vendor facts above should be re-verified in a procurement round; product names change through acquisitions.

Path B — Build on cloud APIs

• Data and ML: warehouse/lakehouse in an EU region (Azure, AWS Frankfurt, Google Cloud EU, or EU providers such as STACKIT, OVHcloud, IONOS), streaming with Kafka/Flink, gradient boosting (XGBoost, LightGBM) and graph database (Neo4j, Memgraph, Amazon Neptune).
• LLM layer: Mistral (EU), or Claude, Gemini, GPT via EU regions/EU data boundaries and zero-retention terms for case summarisation and SAR drafting. Use structured output and citations to transaction IDs.
• Choose B when: you already have a data platform and need a bespoke layer, e.g. an alert-triage and narrative-drafting copilot over a vendor engine. Check DORA (ICT third-party register, exit plans) and that personal data and tipping-off-sensitive case data are covered by contract. Case content about suspected crime is highly sensitive; many institutions will keep SAR content off public LLM APIs.

Path C — Self-host (open source)

• Detection: Apache Kafka/Flink for streams, scikit-learn, XGBoost, LightGBM, PyOD for outliers, PyTorch Geometric / DGL for graph models, NetworkX or Neo4j Community for network analysis. Open-source decision and monitoring engines exist (e.g. Marble, Jube), but verify maturity, support and regulatory fit before relying on them as a primary control.
• LLMs on-prem: open-weight models (Mistral family, Qwen3, Llama, gpt-oss) served with vLLM for case summarisation; VLM or OCR/doc-parse for KYC documents (see DOC-014).
• Hardware: HW2 is enough for boosted trees, graph features and a ~30B quantised LLM for narrative drafting; heavy GNN training on large graphs needs HW3. Operating effort is high: model governance, 24/7 data pipelines and audit trail dominate, not GPUs.

Path D — Custom training

Worth it for large institutions or for consortia: train bank-specific supervised models on investigation outcomes, GNNs on the full payment graph, and fine-tune a small LLM for the house narrative style. Data needed: several years of alerts with final dispositions, SAR outcomes and enrichment data. Privacy-preserving collaboration (federated learning, privacy-enhancing technologies, supervised data-sharing partnerships between banks) is an active area; legal admissibility under GDPR and banking secrecy must be cleared per project. Public benchmarks (synthetic AMLworld/IBM datasets [3]) are useful for method comparison only, not as a proxy for your own performance.

State of the art (2026)

• Layered detection (rules + supervised ML + graph + anomaly) is the industry baseline; regulators in the EU and elsewhere accept ML if validated, explainable and governed, but expect rule-based coverage of mandated scenarios to remain.
• Network and graph analytics are the main source of new detection value, especially for mule networks and layering; entity resolution quality is often the real bottleneck.
• Agentic alert adjudication: LLM agents gather context (KYC, transaction history, adverse media), explain their reasoning and propose Level-1 dispositions; vendors position this as a way to cut analyst time. Treat claims as vendor-reported until proven in your back-test, and keep a human sign-off.
• Synthetic data and benchmarks: the AMLworld generator [3] gave the field comparable datasets with complete labels; real-world data remains unavailable for open research.
• Limits and failure modes: label bias from rule-driven alerting; concept drift as criminals adapt; unexplainable scores that regulators reject; entity-resolution errors that create false links to innocent third parties; LLM hallucinations in narratives (invented transactions); and tipping-off risk if customer-facing systems reveal suspicion.

Shared resources & combinations

• Same building blocks (tabular-ml, graph-ml, anomaly-detection, streaming): ANOM-001 (card/payment fraud, near-identical feature pipeline), ANOM-022 (APP scams and money mules), ANOM-023 (crypto monitoring), ANOM-012 (trade surveillance) and ANOM-006 (ledger anomalies). One feature store and graph database can serve all of them.
• Upstream: ANOM-016 (sanctions/PEP/adverse-media screening produces risk signals and alerts), ANOM-014 (identity verification at onboarding), ANOM-017 (forged payslips and bank statements), DOC-017 (bank-statement parsing) and DOC-014 (document parsing for KYC files).
• Shared LLM server: the narrative-drafting model can be the same on-prem LLM (HW2/HW3) used for other compliance copilots.
• Workflow engine and case management: shared with other investigation queues (fraud, sanctions).

Effort, cost & KPIs

• Path A: 6–18 months for a bank-grade rollout, including data migration, scenario tuning and regulatory validation; licence typically scales with transaction or account volume.
• Path B: 4–12 months for an augmentation layer (triage + narrative copilot); cost drivers are data engineering, integration and model governance rather than API fees.
• Path C/D: a multi-year programme with a dedicated data science and model-risk team.
• KPIs: true-positive rate of alerts (alert-to-SAR conversion), false-positive rate at fixed recall (back-tested), mean time to disposition, backlog age, SAR timeliness, share of SARs with useful follow-up from the FIU, analyst override rate on model proposals, model drift and stability metrics, fairness checks across customer groups.

People & change

Involve management (accountable for the AML framework), the money laundering reporting officer and compliance as process owners, IT and IT security, the DPO, and the analysts who work the alerts from the start; their feedback labels decide model quality. Notify the regulator-facing functions early because model changes need documentation.

Works council: yes in practice. Alert queues, case tools and analyst performance reporting are technical systems suited to monitor behaviour (§87(1) no. 6 BetrVG), and §90(1) no. 3 plus §80(3) (external expert) apply; in public bodies the staff council under BPersVG or state law is involved.

Data protection: large-scale profiling of customers makes a DPIA likely (Art. 35 GDPR); statutory AML duties provide the legal basis, but retention and purpose limits still apply; AVV with every vendor. AI literacy: support analysts in reading model explanations and limits (Art. 4 AI Act). Pilot in parallel with the existing rules, compare hit rates and false positives, then switch scenario by scenario. Typical concerns: "will the model replace my judgement" and regulatory accountability; address by keeping humans in the filing decision and documenting every override. See GUIDE-004, GUIDE-005 and GUIDE-011.

Risks, regulation & compliance

• Anti-money-laundering law: EU AMLR (EU) 2024/1624 (applies from 10 July 2027), the AMLD framework, and Germany's Geldwäschegesetz (GwG) with BaFin guidance and FIU reporting via goAML [1][4]. FATF recommendations set the global standard. Obligations include risk-based ongoing monitoring, record-keeping and timely suspicion reporting; tipping-off is prohibited.
• EU AI Act: classification depends. Annex III point 5(b) classifies AI for creditworthiness evaluation or credit scoring of natural persons as high-risk but expressly excludes AI systems used to detect financial fraud [5]. Pure AML transaction monitoring is generally not listed as high-risk, but the line is not a bright one: an AML system whose scores feed credit, account-opening or account-closure decisions about individuals, or any use by law enforcement or an FIU in profiling individuals, can fall under Annex III (credit scoring, essential services, law enforcement). Individual risk assessments of natural persons that are based solely on profiling to predict criminal offences are prohibited under Art. 5(1)(d); a monitoring system must therefore support, not replace, human assessment of objective, verifiable facts. Seek legal classification per deployment.
• GDPR: processing is based on legal obligation (Art. 6(1)(c)), but profiling and automated decisions need care (Art. 22: account termination or freezing must not rest solely on automated scoring); data protection impact assessment, data minimisation, retention limits and strict access control to case data are required.
• Sector rules: DORA (ICT risk and third-party), EBA guidelines on ML and outsourcing, BaFin expectations on model risk (MaRisk), supervisory model-validation standards, de-risking and financial-exclusion concerns (EBA).
• Typical risks and mitigations: discriminatory proxies (nationality, postcode) → fairness testing; over-reliance on LLM drafts → mandatory source citation and analyst verification; model drift → monitoring and periodic re-validation; vendor lock-in → exportable rules and data.
• Sensitive-domain note: this page describes defensive compliance monitoring only. It does not give guidance on evading detection.

Getting started

1. Inventory current scenarios, alert volumes, closure rates and SAR conversion by scenario; define a measurable baseline.
2. Build the data foundation: unified customer and counterparty entities, and a clean history of alert outcomes as labels.
3. Run a back-test (below-the-line) of an ML prioritisation layer on your own historic alerts before changing production thresholds.
4. Pilot an LLM case-summary and narrative-drafting assistant for Level-1 analysts with citation of source transactions and mandatory human sign-off.
5. Set up model governance now (documentation, validation, explainability, DPIA, AI Act classification) so it holds when AMLR applies in July 2027.

Sources

1. EU Anti-Money Laundering Regulation (EU) 2024/1624 (EUR-Lex) — https://eur-lex.europa.eu/eli/reg/2024/1624/oj
2. AMLA, Authority for Anti-Money Laundering and Countering the Financing of Terrorism — About AMLA (timeline: direct supervision from 2028) — https://www.amla.europa.eu/about-amla_en
3. Altman et al., "Realistic Synthetic Financial Transactions for Anti-Money Laundering Models" (AMLworld) — https://arxiv.org/abs/2306.16424
4. Geldwäschegesetz (GwG) — https://www.gesetze-im-internet.de/gwg_2017/
5. AI Act Annex III (high-risk systems; point 5(b) fraud-detection exclusion) — https://artificialintelligenceact.eu/annex/3/
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj