AML Programme and Transaction Monitoring Guide

Most anti-money laundering (AML) programmes generate thousands of alerts and a steady flow of suspicious activity reports, yet cannot show that either one matches the risks the firm actually carries. This guide covers the operational core of an AML programme: the business-wide risk assessment, transaction monitoring scenarios and thresholds, alert triage, case management, suspicious activity and suspicious transaction reporting (SAR and STR), and what changes for crypto-asset businesses. It draws on the FATF Recommendations, the EU Anti-Money Laundering Regulation (AMLR) and the new Anti-Money Laundering Authority (AMLA), the US Bank Secrecy Act rules administered by FinCEN, the UK Money Laundering Regulations 2017 and Proceeds of Crime Act 2002, and the Wolfsberg Group's statements on effective monitoring. It is for financial crime operations leads, MLRO teams, engineers who run the monitoring stack, and auditors. Customer due diligence, politically exposed persons and sanctions screening are covered only where they feed monitoring.

Key takeaways

The risk assessment drives the rules. UK regulation 18 names five risk factors (customers, geography, products or services, transactions, delivery channels); every monitoring scenario should trace back to a risk in that written assessment, and every material risk should have coverage.
Deadlines are short and start at detection. A US bank must file a SAR within 30 calendar days of initial detection (60 at most where no suspect is identified), and a UK defence request starts a 7 working day notice period, so slow triage queues create regulatory breaches.
Alert volume is not effectiveness. The Wolfsberg Group warns that coverage counts, alert volumes and alert-to-SAR ratios measure quantity, and recommends below-the-line testing, segmentation and feedback from authorities instead.
Case files are evidence, not notes. Rationale for closing or escalating an alert must be written so an examiner can follow it years later; US SAR records are kept five years from filing and UK records five years from the end of the relationship.
Crypto changes the data, not the duties. Virtual asset service providers carry the same programme obligations, plus travel rule data and on-chain exposure signals that need their own scenarios and screening.

The regulatory frame in one view

The FATF Recommendations set the international standard (adopted 16 February 2012, most recently amended June 2026, according to the FATF). National law turns them into obligations. The February 2025 revision of Recommendation 1 and its interpretive notes, together with INR.10 and INR.15, emphasised proportionality and simplified measures in lower risk areas, which supports tuning monitoring to risk rather than running every scenario everywhere.

Regime	Programme and risk assessment	Monitoring duty	Reporting	Records
FATF	R.1 risk-based approach; R.18 internal controls (INR.18 revised November 2017 for group information sharing)	R.10 ongoing due diligence	R.20 suspicious transaction reporting to the FIU; R.21 tipping-off	R.11 record keeping
EU AMLR, Regulation (EU) 2024/1624	Business-wide risk assessment and internal policies, supervised by national authorities and, for selected entities, AMLA	Ongoing monitoring of business relationships	Recital 136: all suspicious transactions, including attempted ones, reported regardless of amount	Retention rules in the regulation; check the operative text
US Bank Secrecy Act (banks)	31 CFR 1020.210: internal controls, independent testing, designated compliance individual(s), training, risk-based customer due diligence	1020.210: monitoring to identify and report suspicious transactions and update customer information	31 CFR 1020.320: SAR at $5,000 or more, 30 calendar days	SAR and supporting documentation five years from filing
UK MLRs 2017 and POCA 2002	Reg 18 risk assessment; reg 19 policies, controls and procedures; reg 21 internal controls	Reg 28(11) ongoing monitoring	SAR to the NCA under POCA Part 7; tipping off offence s.333A	Reg 40: five years, transaction records capped at 10 years

EU timing: the AMLR is dated 31 May 2024 and was published in the Official Journal on 19 June 2024; EUR-Lex lists 10 July 2027 as the date its rules take effect, so obliged entities should plan for 2027 as the switch from national transpositions to a single rulebook and confirm any staggered dates in the regulation's final provisions. AMLA has existed legally since 26 June 2024, is seated in Frankfurt, selects 40 obliged entities for direct supervision in 2027 and plans to start direct supervision in 2028, according to AMLA.
UK status: legislation.gov.uk shows amendments from S.I. 2026/621 to the MLRs not yet applied to the consolidated text (as of 25 October 2026). Read the amending instrument before relying on the wording of regs 18 or 40.
FCA expectations: authorised firms must appoint a Money Laundering Reporting Officer, give overall responsibility for AML systems and controls to a director or senior manager, and use the Financial Crime Guide and JMLSG guidance as benchmarks. Some firms also file the annual financial crime return (REP-CRIM).

For the wider regulatory picture across fraud and cyber see the Financial Services Cyber Regulation Map and the Online Fraud Regulation Map.

Programme design: the components that examiners test

Every regime asks for the same building blocks. Design them as one system: stale customer risk ratings silently degrade thresholds keyed to them.

Governance: a named senior manager accountable for the programme, an MLRO or BSA officer with authority to file without business approval, and a board or committee that receives the risk assessment and monitoring effectiveness reports.
Business-wide risk assessment: a written assessment that scores inherent risk by customer type, geography, product, transaction type and channel, then the controls that mitigate each, then residual risk. UK reg 18 requires the record to be kept up to date and provided to the supervisor on request.
Customer risk rating: the customer level score from onboarding and periodic review. Monitoring segments and thresholds should read it, so its refresh cycle matters. See the Identity Proofing and KYC Guide.
Monitoring: automated scenarios, screening, and human referrals (front line staff, fraud teams, law enforcement requests) into one case queue.
Investigation and reporting: triage, case management, decision to file, filing, and post-filing actions such as exit or enhanced review.
Independent testing and model validation: 31 CFR 1020.210 requires independent testing by staff or an outside party; for monitoring this means testing scenario logic, data feeds and threshold rationale, not only sampling cases.
Training: role-specific red flags and documentation standards.
Records: retention and deletion schedules aligned to each regime, including the UK reg 40(5) requirement to delete personal data once the retention period ends unless an exception applies.

From risk assessment to monitoring scenarios

A defensible rule set is a coverage map: each material risk in the assessment maps to one or more scenarios, and each scenario states the typology it detects, the population it runs on, its parameters and the evidence behind them. The Wolfsberg Group's 2024 statement asks firms to point resources at "crystallised risk", meaning risk observed in the firm's own cases and authorities' priorities, rather than theoretical coverage.

Scenario family	Typology it targets	Typical data inputs	Tuning levers
Structuring and threshold avoidance	Cash or transfers kept below reporting or due diligence thresholds; the US SAR rule names transactions designed to evade BSA requirements	Cash deposits, ATM, branch, transfer amounts by day and week	Look-back window, band below threshold, aggregation across linked accounts
Rapid movement of funds	Pass-through accounts, mule activity, layering	Inbound and outbound value and timing per account	In-out ratio, dwell time, minimum value by customer segment
Profile deviation	Activity inconsistent with the stated business or expected activity (UK reg 28(11), US "no apparent lawful purpose")	Declared turnover and occupation, peer group statistics	Segment definitions, standard deviation or percentile limits
High-risk geography	Flows to or from jurisdictions in the risk assessment	Counterparty country, IP and device country, correspondent route	Country list version, value floor, first-time counterparty flag
Network and counterparty	Many-to-one funnels, shared devices or identifiers, circular flows	Counterparty graph, device and address identifiers	Entity resolution rules, degree thresholds
Trade and correspondent	Trade-based laundering, nested relationships	Payment messages, invoice data, respondent information	Message field completeness, unusual routing
Crypto exposure	Deposits from or withdrawals to illicit or high-risk addresses, rapid conversion between assets	Blockchain analytics risk scores, wallet attribution, travel rule data	Exposure hops, direct vs indirect exposure, value floor

Setting and documenting thresholds

Segment first: run scenarios on populations that behave alike (retail, small business, corporate, private banking, crypto retail). A single threshold for all customers either floods the queue with retail noise or misses corporate abuse. Wolfsberg Part I recommends dynamic segmentation to reduce false positives.
Above and below the line: set initial parameters from data analysis, then sample alerts just below the threshold to test whether productive cases are being missed. Record the sample size, findings and decision in a tuning log.
Tie to outcomes: feed case outcomes (closed, escalated, filed, law enforcement feedback) back into scenario reviews at a fixed cadence, quarterly for high-volume scenarios.
Change control: treat scenario logic and parameters as production code with versioning, approval by the MLRO function, and a record of what changed and why. A silent threshold change is a common examination finding.

Rules, models and explainability

Rules are transparent but brittle; machine learning models catch combinations rules miss but need validation and explanation. Wolfsberg Part I supports machine learning as booster models (re-ranking or suppressing rule alerts) or as primary detection, with clear documentation, and treats generative AI as early-stage. Part II (27 August 2025) adds three pillars for the transition: transition and validation, balancing model risk with financial crime risk, and explainability that shows coverage and effectiveness.

Approach	Use when	Main risk	Evidence to keep
Rules only	Small firm, low volume, clear typologies, limited data science capacity	High false positives, easy to game once thresholds are known	Threshold rationale, below-the-line tests
Rules plus ML alert scoring	High alert volumes, mature case data with outcomes	Model suppresses true positives without anyone noticing	Validation report, suppression sampling, drift monitoring
ML or graph as primary detection	Large firm with strong data, model risk management and supervisor engagement	Explainability gaps in SAR narratives and examinations	Feature documentation, reason codes per alert, parallel or back-testing results

The fraud side of monitoring (strong customer authentication transaction monitoring and behavioural signals) is covered in the Transaction Monitoring and Behavioural Biometrics Guide. Run fraud and AML monitoring on shared data and entity resolution, but keep separate decision logic: fraud stops a payment in real time, AML usually investigates after the fact and reports.

Alert triage that holds up

Triage decides whether an alert becomes a case, and is where most backlog arises.

Prioritise by risk, not by age alone: score alerts using scenario productivity, customer risk rating and value, and route the top band to experienced analysts.
Group by entity: consolidate all open alerts for the same customer or network into one review, so analysts see the whole pattern and do not close the same behaviour five times.
Use a fixed review checklist: customer profile and expected activity, recent due diligence changes, counterparties, prior alerts and cases, adverse media and screening hits, and any explanation already on file.
Write the rationale: a closure note states what was reviewed, why the activity is explained, and by what evidence. "Activity in line with profile" alone is not a rationale.
Quality assurance: sample closed alerts weekly per analyst, with a higher rate for new staff and for scenarios with low productivity, and track rework.

Case management and the decision to report

A case collects the alerts, documents, analysis and decision for one subject or network. The case system is also the audit trail, so it needs immutable history, role-based access and a clean separation between investigators and the person who decides to file.

Reporting deadlines and confidentiality

Item	United States (banks, 31 CFR 1020.320)	United Kingdom (POCA 2002, MLRs 2017)
What triggers a report	Transaction of at least $5,000 where the bank knows, suspects or has reason to suspect illegal funds, BSA evasion, or no apparent lawful purpose with no reasonable explanation	Knowledge or suspicion of money laundering or terrorist financing, reported to the NCA under POCA Part 7
Deadline	30 calendar days from initial detection; a further 30 days to identify a suspect, never more than 60 days in total	As soon as practicable through the nominated officer; where consent (a defence) is needed, a 7 working day notice period applies (s.335)
Urgent cases	Telephone law enforcement for ongoing violations, as well as filing	If consent is refused, a 31 day moratorium runs, extendable by court order (ss.336A, 336C)
Confidentiality	SAR and any information revealing it are confidential; subpoenas for SARs are declined and FinCEN notified	Tipping off in the regulated sector (s.333A): up to two years' imprisonment on indictment
Retention	Five years from filing, with supporting documentation	Five years (reg 40), from the end of the relationship or completion of an occasional transaction

EU firms report to their national FIU under current national law until the AMLR applies; recital 136 of the AMLR confirms that attempted transactions are in scope and there is no minimum amount.

Writing a useful report

Answer who, what, when, where, why and how: subjects and identifiers, accounts and amounts, dates and channels, and why the activity is suspicious against the customer's profile.
Use the regime's codes: the FCA tells firms to apply the correct UKFIU glossary codes to SARs, which help the FIU route them.
Avoid defensive filing: Wolfsberg Part I criticises filing to leave "no SAR behind" and says direct feedback from authorities is the best measure of report quality.
Decide post-filing actions: continuing activity review cadence, enhanced due diligence, exit, and how to exit without tipping off.

Many cases begin as fraud victim reports and end as mule investigations. See the Money Mule Detection Guide for mule typologies and the Authorised Push Payment (APP) Fraud Guide for the victim side.

Crypto and VASP monitoring

FATF Recommendation 15 brought virtual asset service providers (VASPs) into scope, and FATF's 2022 targeted update found that only 29 of the 98 jurisdictions that answered its March 2022 survey had passed travel rule laws, so cross-border coverage remains uneven. In the US, FinCEN's guidance FIN-2019-G001 (9 May 2019) explains how its money transmitter rules apply to convertible virtual currency business models. In the UK, cryptoasset exchange providers and custodian wallet providers are within the MLRs (reg 14A), must deal with the FCA on registration (regs 56A and 56B), and must send and check information with inter-cryptoasset business transfers (Part 7A, reg 64C).

Exposure scenarios: alert on direct and indirect exposure to sanctioned, stolen-fund, mixer, darknet market or scam addresses using blockchain analytics, with a value floor and hop limit set from the risk assessment. See the Blockchain Analytics and On-Chain Monitoring Guide.
Published attacker addresses: after major thefts, authorities publish addresses. In the Bybit hack of 2025 the FBI attributed the theft to North Korea's TraderTraitor, reported that the funds were being converted and spread across thousands of addresses on several blockchains, and published addresses it linked to the actors. Load such lists into screening within hours, not at the next weekly refresh.
Travel rule data quality: treat missing or mismatched originator and beneficiary information as a monitoring signal, not only a compliance exception. See the Crypto Travel Rule Compliance Guide.
Fiat edges: correlate on-chain signals with bank, card and payment data for the same customer at fiat off-ramps.

Where security and identity fit

A monitoring system is a high-value target and a source of sensitive data. Scenario parameters tell a criminal exactly how to stay below the line, and case files hold suspicion that must not leak.

Restrict and log parameter access: limit read and write access to scenario logic, and review the change history (NIST SP 800-53 AU-6, audit record review).
Protect data pipelines: monitoring is only as good as its feeds. The service accounts and API keys that move transaction data into the monitoring platform need owners, rotation and alerts on failure, because a stopped feed means no alerts. See the Payment API keys beyond Stripe guide.

Detection and measurement

Measure effectiveness, timeliness and quality; volume is context only.

Metric	What it shows	Watch for
Scenario productivity (share of alerts escalated to case or report, per scenario)	Which rules earn their cost	Scenarios with near-zero productivity over two review cycles
Below-the-line hit rate	Whether thresholds hide true positives	Productive cases found in samples below threshold
Days from detection to filing	Exposure to the US 30 and 60 day limits	Any case past 25 days without a decision
Alert and case backlog age	Operational capacity	Growing backlog after a new scenario or product launch
QA error rate on closed alerts	Quality of rationale	Rates above the agreed tolerance for any analyst or scenario
Authority feedback and production orders linked to filings	Value of reports to law enforcement, the Wolfsberg measure	No feedback mechanism at all
Data feed completeness	Monitoring coverage	Missing days or fields in source systems

How to implement

Rebuild the risk assessment: update the business-wide assessment using the five reg 18 factors (or local equivalent), current national risk assessments and your own case history.
Map coverage: list every material risk against existing scenarios, screening and referral routes, and mark gaps and duplicates.
Fix data first: confirm every source system feeds the monitoring platform with complete customer, account, counterparty and channel fields, and add feed-failure alerting.
Tune in a test environment: run new or changed scenarios against historical data and compare alert output to known cases before switching on.
Pilot in parallel: run a new scenario or model alongside the old one for a defined period on one segment, with analysts working both outputs, then compare productivity and missed cases.
Cut over with rollback: keep the previous version deployable, record the approval, and set a review date. If backlog or missed-case indicators breach agreed limits, revert and investigate.
Validate independently: have internal audit or an external party test logic, data and tuning annually and after major changes.

Small vs large organisations

Small firms: a short list of well documented rules, manual review of all alerts, and an outsourced annual independent test are proportionate. FATF's 2025 revision supports simplified measures where risk is lower.
Large firms: segment-level tuning, model risk management for any machine learning, entity resolution across business lines, and group information sharing within the limits that INR.18 and tipping-off rules allow.

Framework mapping

Programme activity	AML sources	Security framework anchor
Risk assessment and objectives	FATF R.1; UK MLRs reg 18; AMLR business-wide risk assessment	NIST CSF 2.0 GV.RM-01
Alert analysis and triage	FATF R.10; UK reg 28(11); 31 CFR 1020.210	NIST CSF 2.0 DE.AE-02
Escalation to reporting officer	FATF R.20; POCA Part 7; 31 CFR 1020.320	NIST CSF 2.0 DE.AE-06
Monitoring system integrity	Independent testing, 31 CFR 1020.210	NIST SP 800-53 SI-4, AU-6
Records	FATF R.11; UK reg 40; 1020.320(d)	Retention and deletion schedule

Common failure patterns

Rules with no lineage: scenarios inherited from a vendor default with no link to the firm's risk assessment, so nobody can explain why a threshold is set where it is.
Silent data gaps: a product or new payment rail never connected to monitoring, discovered only when an examiner asks for alerts on it.
Backlogs that break deadlines: alert queues growing after a product launch until detection-to-filing times exceed the 30 day US limit.
Template closures: copy-and-paste rationale that does not mention what was reviewed, which fails QA and examination sampling.
Tuning by volume: raising thresholds to cut workload without below-the-line testing, which hides the cases that matter.
Slow list updates: waiting for vendor refreshes after a public theft, as laundering through thousands of addresses after the Bybit hack showed how fast funds move.

Practitioner checklist

Business-wide risk assessment is written, current, approved and mapped to monitoring coverage.
Every scenario has a documented typology, population, parameters, owner and last tuning date.
Below-the-line testing runs at least annually for each production scenario.
Source data feeds are inventoried and alert on failure or missing fields.
Alert closures carry a specific written rationale and are QA sampled weekly.
Detection-to-filing time is tracked against each regime's deadline, with escalation before it is breached.
SAR confidentiality and tipping-off controls cover case access, exits and customer communications.
Crypto exposure, travel rule data and published attacker addresses feed monitoring and screening.
Scenario and model changes go through versioned change control with rollback.
Independent testing covers logic, data and tuning, not only case samples.

Standards and references

Related NHI Mgmt Group resources: Money Mule Detection Guide · Transaction Monitoring and Behavioural Biometrics Guide · Crypto Travel Rule Compliance Guide · Fraud Prevention Guide for Digital Businesses. This guide summarises AML programme and transaction monitoring obligations under FATF, EU, US and UK rules and is not legal advice.

AML programme and transaction monitoring: design rules, triage alerts and file sound reports