AML Transaction Monitoring: What Banks Actually Need to Get Right

AML transaction monitoring is the control that checks what customers do with their accounts against what a firm knows about them, and sends anything that doesn't fit to a person who can decide whether it is suspicious. In 2026 many programs run it as three layers: rules that test single conditions, scenarios that combine rules to find a typology, and models that score or rank what the rules produce. This guide explains what the law asks for, how the three layers fit, and what examiners expect to see. It also includes a library of 20 scenarios mapped to the FATF Recommendations.

What AML transaction monitoring is, and what the law asks for

The international standard comes from FATF Recommendation 10. It asks for "scrutiny of transactions undertaken throughout the course of that relationship to ensure that the transactions being conducted are consistent with the institution's knowledge of the customer, their business and risk profile".

The interpretive note goes further. Firms "should examine, as far as reasonably possible, the background and purpose of all complex, unusual large transactions, and all unusual patterns of transactions, which have no apparent economic or lawful purpose."

Where risk is higher, they should "increase the degree and nature of monitoring of the business relationship".

A customer rated low risk at onboarding isn't automatically low risk for monitoring. FATF says lower risk for identification purposes "does not automatically mean that the same customer is lower risk for all types of CDD measures, in particular for ongoing monitoring of transactions."

Monitoring ends in a report. Under Recommendation 20, a firm that suspects funds are criminal proceeds or linked to terrorist financing should be required by law "to report promptly its suspicions to the financial intelligence unit (FIU)."

National rules turn this into specific duties:

In the US, a bank's AML program must include "Conducting ongoing monitoring to identify and report suspicious transactions and, on a risk basis, to maintain and update customer information."

The same rule requires "Independent testing for compliance to be conducted by bank personnel or by an outside party", so monitoring is tested along with the rest of the program.

In the EU, Article 26 of the AML Regulation requires monitoring "to ensure that those transactions are consistent with the obliged entity's knowledge of the customer, the customer's business activity and risk profile".

The regulation "shall apply from 10 July 2027", so national laws based on the directives govern until then.

In the UK, the FCA's Financial Crime Guide says ongoing monitoring "means scrutinising transactions to ensure that they are consistent with what the firm knows about the customer".

The same section adds that firms "must carry out enhanced ongoing monitoring of the business relationship" where risk is higher.

Monitoring depends on good customer data. If onboarding never recorded what a customer is expected to do, "activity inconsistent with profile" has nothing to compare against. That's why monitoring and customer onboarding and KYC have to be designed together. For a plain definition of the term, see our transaction monitoring glossary entry.

Rules, scenarios and models: how the three layers fit

People use these words loosely, so here is how this page uses them.

The FCA describes the starting point most large firms share. Many have used systems that work "on a transaction-by-transaction or unusual transaction basis, or combination of the two, flagging fund movements that exceed rule-driven thresholds for human scrutiny."

It also names the newer layer: "machine learning tools or tools based on artificial intelligence to detect suspicious activity or triage existing alerts."

The guide treats triage as its own question. If a firm uses "scorecards overlaid on existing systems or other systems to prioritise which alerts receive manual attention", it asks whether that can be "justified within the context of the firm's overall approach to monitoring?"

In practice the layers stack. Rules and scenarios decide what becomes an alert. Models either add detection (finding behaviour no rule describes) or sit on top of the alert queue to decide what an analyst sees first. Both uses need their own testing, because a triage model that buries a true alert does as much damage as a scenario that never fires.

The FCA also expects monitoring at more than one level. It lists the transaction level, the account level, the customer level and the "linked-entity level (i.e. across a group of linked customers by relationship managers)."

A rule set that only looks at single transactions will miss layering that spreads activity across accounts and related parties. Our guide to transaction monitoring scenarios with examples walks through common scenario designs in more detail.

Is a rule a "model"? The US answer changed in 2026

On 17 April 2026 the OCC, the Federal Reserve and the FDIC issued revised model risk guidance. OCC Bulletin 2026-13 rescinds OCC Bulletin 2011-12 and OCC Bulletin 2021-19, the 2021 interagency statement on model risk management for BSA/AML systems.

The new definition of "model" "excludes simple arithmetic calculations, such as those found within spreadsheets, as well as deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use."

So a pure threshold rule falls outside the US model risk guidance, while a machine learning scoring model falls inside it. The agencies also say "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance."

The guidance "is expected to be most relevant to banking organizations with over $30 billion in total assets."

It "does not set forth enforceable standards or prescriptive requirements."

Being outside the guidance doesn't mean being outside scrutiny. Rules still need a documented rationale under the program rule and the FCA's expectations, and AI agents still need the controls described later on this page. Older articles that cite SR 11-7 or the 2021 statement as current guidance are out of date.

A scenario library: 20 scenarios mapped to FATF typologies

This is the library our team uses as a starting point. Each entry gives what the scenario looks for and the first question for the analyst, and links it to the FATF Recommendation or designated offence category it supports. The mapping is our reading of the FATF text, not a FATF list. No institution should run all 20 as written: pick the ones your risk assessment supports, set thresholds from your own data, and record why.

1. Cash just under the reporting line (R.10, R.20; structuring). Repeated cash deposits just below the currency reporting threshold. Ask: Is there a business reason for cash in these amounts, and is the pattern new?
2. Multi-location cash (R.10). Cash deposits at several branches or ATMs in a short window. Ask: Do the locations fit where the customer lives and works?
3. Rapid in and out (R.10; fraud). Funds credited and moved out within days, leaving a low balance. Ask: Is the account being used as a pass-through, perhaps by a money mule?
4. Many to one (Fraud; organised crime). Many unrelated senders pay one account, which then sweeps funds out. Ask: Who are the senders, and do they know each other?
5. One to many (R.10; layering). One account pays many new beneficiaries soon after a large credit. Ask: Did the customer explain the purpose, and does it fit the profile?
6. Dormant account wakes up (Fraud). An account silent for months suddenly moves a large sum. Ask: Did contact details, devices or signatories change recently?
7. Activity above expected profile (R.10 (c) and (d)). Monthly volume or value well above what onboarding recorded. Ask: Is the profile out of date, or is the activity unexplained?
8. Higher-risk jurisdictions (R.19). Payments to or from countries the FATF calls for enhanced due diligence on. Ask: Is there a documented reason for the corridor?
9. Incomplete wire information (R.16). Wires missing required originator or beneficiary information. Ask: Can the missing information be obtained, and has this sender done it before?
10. Repeated round amounts (R.10; layering). Identical round-sum payments to the same set of counterparties. Ask: Do invoices or contracts support the payments?
11. Trade payments that don't match (Smuggling and customs offences; trade-based laundering). Payment amounts, parties or goods that don't match trade documents. Ask: Do price, quantity and route make commercial sense?
12. Nested correspondent activity (R.13). A respondent bank's own customers transacting through the relationship. Ask: Does the respondent's due diligence cover these customers?
13. Unlicensed money transfer pattern (R.14). A personal or small business account behaving like a remittance business. Ask: Is the customer providing money transfer services without a licence?
14. Virtual asset on and off ramps (R.15). Frequent transfers to or from virtual asset service providers. Ask: Does this activity fit the customer's stated source of funds?
15. PEP activity beyond source of wealth (R.12; corruption and bribery). Inflows to a politically exposed person's account above the recorded source of wealth. Ask: Has enhanced due diligence covered this source?
16. Links to sanctions screening hits (R.6, R.7). Payments involving parties that matched, or nearly matched, a sanctions list. Ask: Has the screening alert been resolved before the payment moved?
17. Non-profit funds forwarded abroad (R.8; terrorist financing). Donations collected and quickly forwarded to higher-risk areas. Ask: Does the organisation's stated purpose explain the destinations?
18. Shell company flows (R.24). A newly formed company moving large sums with no visible operating costs. Ask: Who are the beneficial owners, and what does the company do?
19. Signs of exploitation (Trafficking in human beings and migrant smuggling). Frequent payments for short-stay lodging, online ads and transport, funded by many small deposits. Ask: Does the spending fit the customer's stated life or business?
20. Loan repaid by third parties (R.10; fraud). A loan repaid early, in cash or by unrelated third parties. Ask: Who paid, and why would they repay this customer's debt?

The FATF list of designated offence categories includes "fraud", "corruption and bribery" and "trafficking in human beings and migrant smuggling", which is why those appear as typologies above.

Two of the scenarios rest on specific rules. In the US a currency transaction report is due for cash "of more than $10,000", which is the line scenario 1 watches.

Being near that line isn't enough on its own. The 2025 FinCEN FAQs say that "The mere presence of a transaction or series of transactions by or on behalf of the same person at or near the $10,000 CTR threshold is not information sufficient to require the filing of a SAR."

Scenario 9 follows Recommendation 16, under which firms should "monitor wire transfers for the purpose of detecting those which lack required originator and/or beneficiary information, and take appropriate measures."

Scenarios 12 to 18 follow FATF Recommendations 13 (correspondent banking), 14 (money or value transfer services), 15 (new technologies), 12 (politically exposed persons), 6 and 7 (targeted financial sanctions), 8 (non-profit organisations) and 24 (beneficial ownership of legal persons).

Scenario 16 is a hand-off between two controls. Sanctions screening decides the match, and monitoring watches the flows around it, so the two teams need to see each other's alerts. For more scenario examples, including data each one needs, see our scenario examples guide. Typology pages such as smurfing and structuring, mule networks and trade-based money laundering explain the behaviour behind several of them.

Thresholds, tuning and the record an examiner asks for

The FCA's self-assessment questions for monitoring are a good checklist. It asks: "Do you frequently review the monitoring system rules and typologies for effectiveness?"

It also asks: "Do you understand the threshold and rule rationales?"

Its examples of good practice include a firm that "tailors the monitoring system rules to its business, risk and relevant typologies."

Another is that "records of decision making and rationales for thresholds are documented and accessible."

The poor practice is the mirror image: a system that is "poorly calibrated" where "the firm struggles to articulate the rationale for particular rules and scenarios."

The FCA lists a data failure too. It flags cases where data "is not migrated smoothly when feeder systems are modified or upgraded or transactions from a specific system have been erroneously omitted from the transaction monitoring system."

The FCA's own HSBC case study shows what happens when these slip. It found that "3 key parts of HSBC's transaction monitoring systems showed serious weaknesses over an extended period of several years."

The bank failed to "consider whether the scenarios used to identify indicators of money laundering or terrorist financing covered relevant risks".

It also failed to check data "being fed into, and contained within, monitoring systems", which left "millions of transactions worth billions of pounds that were either monitored incorrectly or not at all."

The FCA imposed a financial penalty of £63,946,800.

From that, we'd keep five records for every scenario:

• the risk in the risk assessment it covers, with a link to the assessment;
• the threshold, the lookback period and the customer segment, with the analysis that set them;
• a change log showing what changed, why, the alert counts before and after, and who approved it;
• test results for each change, covering what the new threshold still catches and what it would have missed;
• a data completeness check showing which source systems feed it and when that was last confirmed.

Our AML risk assessment guide covers the first record. Our article on tuning transaction monitoring rules covers the testing.

The FCA also expects a firm replacing or switching off a system to justify it. When "decommissioning an existing automated system (or aspects of that system, such as particular rule sets), a firm is able to justify this decision."

Among the factors it lists are "the intelligence-value of alerts and the proportion of 'false positives'."

Where models help, and the guardrails they need

Models earn their place in two jobs. The first is comparing a customer with their own history and their peer group, which no fixed threshold can do. The second is ordering a long alert queue so the riskiest work comes first.

The FCA expects a firm exploring "network analysis or machine learning" to consider "the limitations of these approaches and how any resultant risks can be contained."

It gives a reason: "it will not be clear to operators of more free-form varieties of machine learning why the software has made its recommendations, which can pose ethical and audit challenges."

It also lists two practices. As good practice, "A firm using an automated system keeps records of how the system has been trained."

As poor practice, a firm "lacks an understanding of what the system is detecting and why."

For new approaches, it expects that they "are piloted or subject to evaluation periods, with firms able to demonstrate appropriate testing."

We'd add three guardrails of our own. Run any new model next to the existing process before it changes a single alert. Keep the rules that cover your highest risks in place, so a model can add coverage but never silently remove it. And make sure every score shows the reasons behind it in words an analyst can repeat to an examiner. Our piece on explainable AI in compliance goes deeper on that last point. Faster payment rails make this harder, because the window for review shrinks; see real-time transaction monitoring.

From alert to decision: the part only a person can do

An alert is a question, and the answer belongs to an accountable person. In the US, a bank must report a transaction of "at least $5,000" when it "knows, suspects, or has reason to suspect" one of the listed conditions.

The rule sets the clock. "A bank is required to file a SAR no later than 30 calendar days after the date of initial detection by the bank of facts that may constitute a basis for filing a SAR."

If no suspect has been identified, the bank may take another 30 days. "In no case shall reporting be delayed more than 60 calendar days after the date of initial detection of a reportable transaction."

A backlog doesn't stop that clock, so queue age is a compliance measure as well as an operational one.

Records last too. A bank "shall maintain a copy of any SAR filed and the original or business record equivalent of any supporting documentation for a period of five years from the date of filing the SAR."

The US and EU positions on closed alerts differ, and pages that blur them are wrong. The FinCEN FAQs of October 2025 say "There is no requirement or expectation under the BSA or its implementing regulations for a financial institution to document its decision not to file a SAR."

Where a bank chooses to document it, "In most cases, a short, concise statement documenting a financial institution's SAR decision will likely suffice".

The FAQs "do not alter existing BSA legal or regulatory requirements or establish new supervisory expectations."

The EU will require more. From 10 July 2027, firms must keep "a record of the assessment undertaken pursuant to Article 69(2), including the information and circumstances considered and the results of such assessment, whether or not such assessment results in a suspicious transaction report being made to the FIU".

Even where the law doesn't require it, the FCA asks: "How are unusual transactions reviewed?"

It adds that "Many alerts will be false alarms, particularly when generated by automated systems."

A short, honest reason on each closed alert is what lets a firm answer that question and tune its scenarios later.

How to tell if monitoring is working

Alert volume on its own says little. We'd track these, per scenario and per month, and set targets only from your own baseline:

• Alerts per scenario, which shows where the workload comes from.
• The share of each scenario's alerts closed without action. A scenario where nearly every alert closes that way is a tuning candidate, but that doesn't make it safe to switch off.
• Alert to case, and case to SAR, read together, since a low SAR rate can also mean weak investigations.
• The age of the oldest open alert, which in the US measures exposure to the 30-day clock.
• Time from alert to decision, as the median and the slowest tenth rather than the average.
• Data completeness: the share of expected source records that reached the monitoring system.
• How often a second reviewer disagrees with the first decision.

To put a cost on false positives in your own program, try the false positive cost calculator. For the practical side of cutting noise, including customer segmentation and feeding analyst decisions back into scoring, read how to reduce false positives in transaction monitoring. Treat any reduction figure as something to measure on your own alerts, not a promise.

Laundering and fraud monitoring often draw on the same data. Many firms review both from one queue, which is where fraud prevention and monitoring meet.

Where FluxForce fits

FluxForce is an Agentic OS for Regulated Industries. AI agents that investigate AML, sanctions, fraud and KYC alerts and prepare the case. Your analyst makes the call, with evidence an examiner can replay. You decide how much each agent does on its own, and every one has a kill switch.

Our Transaction Monitoring solution works on the alerts your current system already produces. It "Takes alerts from your existing monitoring system, no rip and replace."

For each alert, an agent reads the scenario that fired and "Compares the activity with the customer's own baseline."

It "Pulls counterparties, linked accounts and prior alerts" and "Scores the alert so the riskiest reach your team first."

It also "Links each new alert to similar cases your team already decided" and shows the earlier analyst's reason before anyone starts work.

What reaches the analyst is a case file. Transactions, customer profile and screening results sit in one place, with a plain-language summary of why the alert matters.

Analysts record their decision and reason code in the same file, and escalations pass to reporting without retyping.

The SAR or STR decision stays with your analyst and your MLRO.

For the team that owns scenarios, the solution "Shows which scenarios produce the most closed-without-action alerts" and "Lets you test a rule change on past alerts before going live."

That is the evidence the tuning records above call for, though your team still sets and approves every threshold.

A pilot starts in observation mode. The agents run next to your team and don't clear, block or file anything, so you can compare their view with your analysts' decisions before anything changes. The solution "Runs as SaaS, on-premise or hybrid" and "Every agent has a kill switch you control."

On fit and limits: this works best for a mid-market bank, fintech or payments firm that already has a monitoring system and an alert queue that outgrows its analysts. It doesn't replace your detection engine, your risk assessment or your scenario design, and it can't fix missing source data. We don't publish accuracy numbers from demos.

We'll measure the change on your own alerts during the pilot. Investigators can also work these cases in Case Management and Investigations.

Next steps

Start with the scenario library above. Mark which scenarios your risk assessment supports, which you already run, and which have no documented threshold rationale. Close those gaps first. When you're ready to see how agents prepare a case from one of your scenarios, see Transaction Monitoring at work on an alert queue.