AML transaction monitoring rules: 25 examples and thresholds

US law draws one line in cash. A financial institution "shall file a report of each deposit, withdrawal, exchange of currency or other payment or transfer ... which involves a transaction in currency of more than $10,000" (eCFR text current to 6 October 2026, 31 CFR 1010.311).

The line created its own workaround, and the regulation names it. Structuring "for the purpose of evading" the report is prohibited (31 CFR 1010.314). The definition at 31 CFR 1010.100(xx) gives the regulator's own example: "the breaking down of a single sum of currency exceeding $10,000 into smaller sums, including sums at or below $10,000". And the transactions "need not exceed the $10,000 reporting threshold at any single financial institution on any single day in order to constitute structuring".

That is why rule 1 in the table below watches cash just under the line. The other 24 follow the same pattern, a method of laundering turned into a test, and together they form the rules library behind the transaction monitoring guide.

What is a transaction monitoring rule made of?

A transaction monitoring rule is a condition the system checks against transactions or customers, written so precisely that two analysts would flag the same activity. Every AML monitoring rule has five parts.

1. Trigger: the event that starts the check, such as a cash deposit or a new beneficiary.
2. Threshold: an amount, a count, or a multiple of the customer's own average.
3. Window: the period the rule adds up over, such as one business day or 30 days.
4. Scope: who the rule covers and who it excludes.
5. Action: an alert to triage, a score added to the customer, or a payment held.

Read rule 1 aloud and every part is audible: "When a retail personal account makes three or more cash deposits in five days, each between 2,000 and 9,999 dollars and together above 15,000 dollars, send an alert to triage, unless the account is a cash intensive merchant."

A rule that cannot be said in one sentence is not finished.

The window is the firm's choice, not the law's. The statute treats multiple cash transactions as one only when they total more than 10,000 dollars "during any one business day" (31 CFR 1010.313(b)).

At what level should a rule add up: transaction, account, customer or linked entity?

Scope also sets the level a rule adds up at. The FCA's Financial Crime Guide lists monitoring at transaction, account, customer and linked entity level as good practice (FCA FCG 3.2.5A, last updated 29 November 2024). Picture a customer who deposits 4,000 dollars in cash into each of four accounts over three days. Account level sees four small deposits and stays quiet. Customer level sees 16,000 dollars, and rule 1 fires. Linked entity level also sees the spouse's business account. Rule 1 belongs at customer level at least.

Which transaction monitoring rules does a program run?

Seven families, 25 rules: structuring (1 to 4), velocity (5 to 8), geography (9 to 11), counterparty (12 to 15), crypto (16 to 19), cash (20 to 22) and dormant account (23 to 25). Every threshold in the table is illustrative, an opening value your own data must confirm or move, except rule 19's US funds transfer line and the FATF ceiling beside it. The statutory lines sit in the last column.

No statute sets how many rules a program runs. The FCA describes good practice as a firm that "tailors the monitoring system rules to its business, risk and relevant typologies" (FCG 3.2.5A). A crypto exchange needs rules 16 to 19; a bank with no crypto customers does not.

Structuring (1 to 4). The CTR line is statutory; the bands, floors and windows around it are not. Rule 4's 10,000 dollar line is illustrative, while the SAR floors beside it apply whatever the split: 5,000 dollars for a bank (31 CFR 1020.320) and 2,000 dollars for a money services business (31 CFR 1022.320). The difference between smurfing and structuring sets the scope: when several people make the deposits, rule 1 must run at linked entity level.

Velocity (5 to 8). Speed and spread, measured against the account's own history. This family catches accounts that move money straight through, and it misfires on accounts built to do exactly that for honest reasons: sweep accounts, payroll floats, marketplaces, charities. The false positive column names them so the scope can exclude them before the first alert.

Geography (9 to 11). Where the money goes, read against where the customer said it would go. Rule 9's list is the firm's own, built from its risk assessment, with the FATF high risk country lists as one input; the free AML country risk index scores each country as a place to start. Rule 11 is the money services pattern of one sender spreading value across receivers in one corridor. Family remittances look the same, so calibrate per corridor.

Counterparty (12 to 15). Rule 13 is the odd one in this family, because it needs ownership data that transaction records do not carry, the kind collected in KYB and UBO verification. It also reads screening results, so the quality of PEP screening and adverse media screening decides how noisy it is. In Complead, formerly Sanction Scanner, the connections graph searches the network around a customer for paths to sanctioned, PEP or adverse media entities, up to six hops by default and configurable, so the table's three hops is an illustrative setting.

Crypto (16 to 19). The FCA lists as poor practice a cryptoasset business that "assumes that blockchain analysis is all that is required to monitor transactions" (FCG 3.2.5A). The chain rules therefore run beside the account rules. For a single address, the free crypto wallet risk check shows the kind of exposure rule 17 reads. Rule 19 has no single international line. FATF lets a country adopt a de minimis threshold for cross border transfers "no higher than USD/EUR 1 000" (Interpretive Note to Recommendation 16, paragraph 8), and its note to Recommendation 15, paragraph 7(b), applies the other requirements of Recommendation 16 to virtual asset transfers on the same basis (FATF Recommendations, as amended June 2026, read 9 October 2026). The US line for transmittals of funds is 3,000 dollars (31 CFR 1010.410). Which line each market sets is compared in cryptocurrency regulations by country, and where Recommendations 15 and 16 sit among the 40 is set out in the FATF Recommendations guide.

Cash (20 to 22). Above 10,000 dollars a currency transaction report is filed whatever the rules say; rule 20 is a monitoring line set per segment. Rule 22 is the direct test of UK regulation 28(11)(a): transactions "consistent with the relevant person's knowledge of the customer, the customer's business and risk profile". It reads the expected activity recorded in the customer risk assessment and KYC at onboarding, so a stale declaration makes it misfire.

Dormant account (23 to 25). An account that wakes up, a new account that fills and empties in a week, and a takeover signature built from device and beneficiary changes all point to an account someone else now controls. Rule 25 needs device signals; without them it collapses into rule 23. Takeover sits where AML meets fraud, and the fraud side is covered in fraud detection and prevention.

How do rules combine into transaction monitoring scenarios?

Picture an illustrative account at a payments firm, opened 70 days ago and almost silent since. Over six days, seven different people send it 12,600 dollars. Within 40 hours, 11,900 dollars leaves in two transfers to an exchange account.

Run the table one rule at a time. Rule 7 wants eight senders and sees seven. Rule 23 wants 180 days of dormancy from a 70 day old account. Both stay quiet. Rule 6 fires, because 94 percent left within 48 hours, but rule 6 also fires on every payroll float in the book. Alone, it gives an analyst little reason to escalate.

The mule scenario joins four conditions with AND: an account under 120 days old, a quiet period followed by a burst, five or more distinct sources in seven days, and most of the money out within 48 hours. Each condition is looser than its rule, and the combination is tighter than any rule alone. This account meets all four, and the alert arrives with the story assembled. The quiet period is read against the account's own short history, not rule 23's 180 days.

A transaction monitoring scenario, then, is a set of rules joined by logic so that it describes one laundering method. Detection scenarios are built four ways.

1. AND for precision. Each added condition removes noise, so thresholds inside the scenario can sit lower than they would alone.
2. OR for the safety net. A structuring scenario that fires on rule 1, 2 or 4 catches the method by any route, at the price of volume.
3. Chaining. One rule's event opens another's window: a new beneficiary under rule 25 starts a 24 hour watch for rule 6.
4. One case per customer. When rules 6, 7 and the mule scenario fire on one account in one week, the analyst gets one case.

Each scenario is written from a typology, a described method of laundering money; the methods themselves are covered in money laundering typologies.

How do you set and tune a transaction monitoring threshold?

A threshold is a decision the firm must be able to explain. Under regulation 28(12)(a) of the UK Money Laundering Regulations 2017, the extent of monitoring "must reflect" the firm's risk assessment and the level of risk "arising in any particular case". One threshold for the whole book cannot do that, so tuning starts with segments.

1. Segment. Split customers by type, industry, product, geography, risk score and channel.
2. Baseline. Measure normal by mean plus standard deviations, percentiles, a peer group, or the customer's own history.
3. Set the line. Convert the baseline with a z score, a percentile, or a deviation from peers.
4. Pick the operating point. Backtest several lines and choose where fewer alerts start costing caught cases.

A worked calculation with illustrative numbers, for rule 20 in an SME segment: 20,000 cash deposits a month, mean 12,000 dollars, standard deviation 11,000 dollars. A z score of 2 puts the line at 12,000 + 2 × 11,000 = 34,000 dollars. A z score of 3 puts it at 45,000. Under a normal distribution, about 2.3 percent of deposits would sit above the first line (about 460 a month) and about 0.13 percent above the second (about 27).

Cash deposits have a long right tail. The real history shows 610 deposits a month above 34,000 dollars and 140 above 45,000, several times the normal prediction. A percentile reads the data as it is: the 99th percentile, the top 200 deposits, sits at 43,000 dollars. The backtest runs over 12 months against the 18 past cases in this segment that ended in a filing:

From 34,000 to 43,000 dollars, alerts fall by two thirds and no case is lost. From 43,000 to 45,000, 60 fewer alerts cost one case. Past 45,000, detection falls fast: that is the knee of the curve. The firm picks 45,000 only because the backtest shows rule 22 caught the one case that 45,000 misses. That reason goes into the record with the date of the data.

Recalibration runs on a calendar, commonly a full review at least once a year, and on triggers: a new product, a new segment, a geopolitical change that shifts payment corridors, a new typology, or an alert volume swing nobody can explain. A rule is retired when its backtests show another rule catches everything it catches, and the retirement goes into the record.

How do you test a rule before it goes live?

A backtest replays the rule against past transactions and shows the alerts it would have raised and the known cases it would have caught. A simulation runs the current and proposed versions side by side on the same history. Shadow mode runs the new version on live traffic for a set period, recording its alerts without sending them to analysts.

In Complead, the rules engine backtests a rule against real history in 30, 60 or 90 day windows, showing alert volume, clearance rate and true positives. Every rule and every change is versioned, with a one click rollback and a record of who changed what, when and why. The decision to ship stays with the AML compliance officer or the rule owner; the backtest supplies the numbers.

What happens when a transaction monitoring rule fires?

When a transaction monitoring rule fires, it creates an alert: a record naming the rule, its version, the threshold, the window and the matched transactions, queued for an analyst. Alerts on one customer are grouped into one case. Triage closes it with a written reason or escalates it. Investigation ends in a decision to file or not, with the rationale kept either way.

Filing has a floor and a clock. A US bank reports a transaction of at least 5,000 dollars, alone or in aggregate, when it "knows, suspects, or has reason to suspect" (31 CFR 1020.320(a)(2)). A money services business reports from 2,000 dollars (31 CFR 1022.320(a)(2)). Under 31 CFR 1020.320(b)(3), the bank's filing is due "no later than 30 calendar days" after initial detection, or up to 60 days when no suspect is identified. Paragraph (d) has the bank keep the report and its supporting documentation for five years after filing (eCFR current to 6 October 2026). The narrative and the form are covered in how to file a SAR.

Picture rule 4 firing on an illustrative business customer: transfers of 4,800, 4,900 and 4,700 dollars to one beneficiary in one afternoon. The alert shows rule 4, the version live that day, the threshold and the three transfers. The analyst finds three matching supplier invoices on file, closes the alert with that reason and attaches them. If the rule changes next month, the record still shows which version fired and why the alert closed.

Some alerts end in a screening question: when rule 13 fires, is the counterparty itself a listed party? Sanction Scanner, the screening product, is part of Complead, and its transaction screening checks the sender and the receiver of a payment through the API while the transfer is processed. Moka United, a fintech as a service platform, runs AML screening and transaction monitoring through the API, with case management and safelists in one place (Moka United case study).

What does an examiner ask about each rule?

These five questions come from practice in exams and audits rather than from one manual.

1. Why this threshold? The segment, the baseline method and the operating point, with the date of the data.
2. Why this scope? Every exclusion is a population the rule cannot see.
3. When was it last reviewed? A rule never reviewed reads as a rule nobody needs.
4. Is the data complete? A rule that reads an empty field as zero never fires.
5. Who approved it? The name, the date and the live version, so each change traces to a decision.

The UK regulator asks the same in its own words. FCG 3.2.5A's self assessment questions read: "Do you frequently review the monitoring system rules and typologies for effectiveness? Do you understand the threshold and rule rationales?" Its good practice list includes "records of decision making and rationales for thresholds" that "are documented and accessible". Its poor practice list describes a rule based system that is "poorly calibrated and the firm struggles to articulate the rationale for particular rules and scenarios" (FCA FCG 3.2.5A, last updated 29 November 2024).

In the EU, Article 26(1) of Regulation (EU) 2024/1624 gives a supervisor the test: transactions "consistent with the obliged entity's knowledge of the customer, the customer's business activity and risk profile" (text read in a browser on 9 October 2026). Under Article 90 the Regulation applies from 10 July 2027, with exceptions for some obliged entities named there.

The record has five parts: methodology, baseline data, decision rationale, change log and validation results. Six mistakes undo it: round convenience numbers, tuning for volume without measuring detection, no retest after a change, thresholds inherited from another institution, ignoring data quality, and tuning once and forgetting.

Rules catch the typologies someone has described; behavioral models score how far a customer moves from their own baseline. In Complead's transaction monitoring software, the rules engine lets a team build, test and ship detection rules without code, setting conditions, thresholds and score effects, and scope each rule per product, segment or jurisdiction. Onboarding, screening, monitoring, fraud and investigation run on one engine, Complead Fusion, so a customer carries one customer risk score instead of a separate score in every tool. On the screening side, Moldcell, a telecom operator with 1.5 million users, screened about 100,000 transactions and surfaced about 10,000 for review (case study, July 2026; what Moldcell did).

What to do this week

1. Pull the rule register and write each rule as one sentence with its five parts; any rule that cannot be said aloud goes on the fix list.
2. Check every threshold against the five examiner questions and mark the ones with no written rationale.
3. Backtest the two rules that raise the most alerts against 90 days of history, and record the result whatever it shows.