What monitoring is actually doing
Transaction monitoring compares what a customer does against what was expected, and surfaces the differences worth a human looking at. The obligation in most frameworks is to conduct ongoing monitoring of the business relationship, including scrutiny of transactions to ensure consistency with the operator's knowledge of the customer. The UK's Money Laundering Regulations 2017 require transactions to be scrutinised to ensure they are consistent with the relevant person's knowledge of the customer, the customer's business and risk profile, and the EU's Fourth Anti-Money Laundering Directive uses almost the same words.
Read that phrasing carefully, because it specifies the comparison. Monitoring is not a search for large transactions. It is a test of consistency against a baseline, and an operator with no baseline is running pattern matching rather than monitoring.
The practical consequence is that the due diligence lesson and this one are the same system. A customer whose expected activity was never established cannot be monitored for inconsistency with it, and the monitoring will fall back on thresholds, which is where most weak systems sit.
Rules, and the honest case for them
Rule-based monitoring encodes typologies as conditions. It remains the backbone of many implementations and there are good reasons for that: rules are explainable to a supervisor, testable, auditable, and can be written the day after a new typology appears.
The rules that earn their place map directly to the typologies from the first lesson.
Deposit and withdrawal with minimal play. Withdrawal requested with turnover below some proportion of deposits within a window. The purest laundering pattern and the first rule to build: the Gambling Commission's guidance for casinos gives money deposited and then withdrawn after very little game play or gambling as an example of activity that should raise suspicion.
Withdrawal to a different instrument. Payout requested to a card, account or wallet other than the one funded from. Strong on its own and stronger combined with low play.
Rapid deposit velocity. Multiple deposits in a short window, particularly of increasing size or from multiple instruments.
Structuring. Repeated transactions sitting just below a reporting or verification threshold. Linked transactions count together: in Britain the casino due diligence threshold, £2,000 since 30 June 2026 (previously €2,000), is applied to single transactions or transactions that appear to be linked. Deliberately staying below a reporting threshold is itself an offence in some jurisdictions: in the United States, structuring transactions to evade a reporting requirement is a federal crime punishable by up to five years' imprisonment, or up to ten in aggravated cases.
Offsetting play. Bets on opposing outcomes of the same market, within an account or across linked accounts, producing near-zero net exposure. The Gambling Commission lists gaming where two or more persons place opposite, equivalent stakes among the products that may pose a money laundering risk for casino operators.
Third-party indicators. Deposits from an instrument whose name does not match the account holder, or shared instruments across accounts.
Dormancy then activity. An account inactive for a long period that suddenly transacts at volume.
Peer-to-peer value transfer. Consistent losses from one account to a small set of counterparties in player-versus-player products.
Geographic inconsistency. Login geolocation, registered address and payment instrument issuance country that do not cohere.
Linked-account clusters. Shared device fingerprints, instruments, addresses or contact details across accounts that present as unrelated.
The weakness of rules is equally real. They are static, they are blunt, and anyone who learns the thresholds can sit beneath them. That is an argument for combining rules with something else, not for abandoning the explainability they provide.
Models, and the question to ask about any of them
Statistical and machine-learned approaches score behaviour against learned patterns, and they are materially better at ranking than a rule stack. They are also harder to explain, and explainability is a regulatory necessity in this domain rather than a nicety: in the UK an operator must be able to demonstrate to its supervisory authority that the extent of its measures is appropriate to the risks, which is hard to do with a model nobody can explain.
The question to ask of any model in financial crime is what it was trained on, and the answer in this field is usually uncomfortable. Confirmed laundering cases are rare in any operator's data, because an operator often does not learn what became of the reports it files. So models are typically trained on filed reports, on internal escalations, or on rule hits, and each of those proxies carries the bias of the process that generated it. A model trained on rule hits reproduces the rule stack. A model trained on filed reports learns what the current team files, including what it habitually misses.
Anomaly detection avoids the label problem by flagging behaviour that is unusual relative to a peer group or to the customer's own history. It is well suited to this domain precisely because it does not need confirmed outcomes, and its weakness is that unusual is not the same as suspicious.
The defensible position is a layered one: rules for the known typologies and for anything that must be demonstrably covered, models or anomaly detection for ranking and for patterns nobody has written down, and human judgement on the output of both. Document the model, its features, its training data, its known biases and its evaluation, before a supervisor asks.
Alert volume and the review that never happens
The arithmetic here is the same as in any low-base-rate detection problem, and the consequence is the same. Tune a system to catch everything and it produces an alert volume the team cannot review, which means alerts are closed superficially, which means the operator has documented in its own records that it detected the pattern and did nothing.
Three disciplines keep this honest.
Tier the response to the signal. A weak single-rule hit warrants an automated check against existing knowledge and a closure with a recorded reason. A strong or combined signal warrants a human review with a documented assessment. A very strong signal warrants immediate restriction pending review, because continuing to process transactions you suspect involve criminal property is the thing the offence provisions are about. In the UK it is an offence to enter into or become concerned in an arrangement you know or suspect facilitates another person's acquisition, retention, use or control of criminal property, unless a defence applies, chiefly an authorised disclosure made with the appropriate consent.
Size the threshold to the capacity, and be explicit that you have. Every operator does this. The ones that survive scrutiny wrote down that they did it, what the trade-off was, and what they are doing about the gap.
Measure closure quality, not closure rate. Sample closed alerts and re-review them independently. The proportion that a second reviewer would have escalated is the single most informative number about a monitoring function, and many monitoring functions do not produce it.
Tuning and testing
A monitoring system that has never been tuned is a system nobody has checked.
Threshold tuning examines the distribution of customer behaviour and sets triggers where they separate normal from unusual for that population, rather than at round numbers. A threshold that fires on 30% of the customer base is not a threshold.
Above-the-line and below-the-line testing is the usual method. Above the line, sample alerts that fired and assess whether they should have. Below the line, sample transactions that did not alert and assess whether they should have. The second is the one that finds the gaps, and it is the one usually skipped because it requires reviewing activity nobody flagged.
Coverage mapping takes the typologies in the risk assessment and asks, for each one, which rule or model would detect it. Gaps in that map are the most defensible finding an internal audit can produce, and they are cheap to produce.
Change control. Every rule change should be recorded with the reason, the expected effect and the observed effect. A framework that cannot show why a threshold moved cannot rebut a suggestion that it moved for commercial reasons. Some regulators write these disciplines into rule: New York's financial services regulator, for banks, money transmitters and cheque cashers licensed under the state's Banking Law rather than gambling operators, requires end-to-end testing of the monitoring programme, documentation of its detection scenarios and thresholds, ongoing analysis of whether they remain relevant, and procedures ensuring changes are defined, managed, controlled, reported and audited.
What monitoring cannot see
Being explicit about the limits is part of operating the system credibly.
Monitoring sees the operator's own accounts. A customer running structured activity across six operators presents an unremarkable pattern at each. Cross-operator visibility requires a data-sharing scheme or a central register, and where neither exists no single operator sees the whole pattern. The Gambling Commission notes that gambling with an almost guaranteed return or very little financial risk sometimes runs across multiple operators.
Monitoring sees transactions, not intent or context. A pattern consistent with laundering is also consistent with an ordinary customer behaving unusually, and the system cannot distinguish them. That is what the human review is for, and it is why a monitoring function staffed too thinly to conduct real reviews is not a monitoring function.
Monitoring within a brand misses the customer operating across brands in the same group. That one is entirely within the operator's own control. The Gambling Commission already says it is important that casino operators are able to reconcile customers' gambling activities across different brands and different accounts, so the obstacle is data engineering rather than regulation, and it is unresolved at more operators than anybody would like to admit.