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.
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 most 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.
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. Deliberately staying below a threshold is itself an offence in many jurisdictions.
Offsetting play. Bets on opposing outcomes of the same market, within an account or across linked accounts, producing near-zero net exposure.
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 requirement in this domain rather than a nicety.
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 extremely rare, because most reports never produce a confirmed outcome the operator learns about. 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.
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 almost nobody produces 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 standard 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.
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, which exists in some markets and not most.
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, it is a data engineering problem rather than a regulatory one, and it is unresolved at more operators than anybody would like to admit.