What breaks when AML programmes rely mainly on transaction thresholds?

Why threshold-only AML monitoring fails

Thresholds are useful as a coarse filter, but they are a poor proxy for laundering behaviour. A single payment can look harmless while the wider pattern is deliberately fragmented to avoid detection. When teams optimise only for large-value events, they protect themselves against obvious spikes and leave the slow, distributed pattern of placement and layering largely invisible.

That is why threshold-only design tends to overrate amount and underrate sequence, frequency, and counterpart relationships. The monitoring logic becomes event-centric instead of behaviour-centric, so it can miss the very activity it was meant to surface.

The practical limitation is that amount thresholds do not explain intent. A legitimate customer can breach a threshold once, while a structured scheme can stay below it hundreds of times. Effective AML monitoring therefore has to interpret movement across time, channels, branches, accounts, and linked parties, not just compare a payment to a fixed amount.

What structuring exploits in the control design

Structuring works because it turns one suspicious act into many ordinary-looking acts. Each deposit, transfer, or cash movement may remain below the rule set’s trigger point, but the combined pattern reveals an effort to break the causal chain that investigators need. The control failure is not the absence of data, it is the absence of correlation.

That correlation usually requires joins across behavioural signals: repeated small deposits, short spacing between events, use of multiple branches or channels, reuse of the same beneficiary or funding source, and identity overlap across accounts. Without those joins, an AML engine sees noise, not a coordinated laundering path.

Threshold logic also creates a false sense of coverage. Teams may believe they have a rule for suspicious cash activity when they actually have a rule for only one narrow symptom of it. In practice, the control needs contextual scoring, scenario chaining, and entity resolution to convert raw transactions into a meaningful risk view.

How to redesign monitoring around behaviour, not amounts

Transaction thresholds should still exist, but as one input among several, not as the primary detection model. The better design is layered: thresholds for obvious outliers, scenario rules for known typologies, and behavioural analytics for patterns that unfold over time. That mix is what makes suspicious activity more observable without forcing investigators to review every small payment.

For AML teams, the operational question is whether the monitoring stack can reconstruct linked behaviour fast enough to support investigation. If the answer is no, then the programme is underpowered even if alert volume looks healthy. Useful signals include repeated near-threshold activity, bursty payment patterns, shared identifiers across accounts, and sudden changes in channel or geography.

Behavioural joins also reduce the risk of relying on one narrow typology. Criminals adapt quickly once they know the threshold, so the model should be able to learn from relationship patterns and historic sequences. That is the difference between a static rulebook and a detection programme that can still work when the adversary changes tactics.

Risk and Threat Considerations

Threshold-centric monitoring creates a blind spot that adversaries can exploit with minimal sophistication. The main risk is false reassurance: the programme continues to generate alerts, but not the right ones, because the suspicious behaviour is intentionally dispersed below the rule boundary.

Failure mechanism: Small deposits, transfers, or cash movements are split across time, accounts, branches, or counterparties so that each event appears ordinary unless the system correlates them into a single behavioural pattern.

Impact: Structuring and layering can progress with reduced detection probability, increasing the chance of missed suspicious activity reports, delayed investigations, and weak typology coverage across the AML programme.

Practitioner Guidance

What to prioritise: Treat entity and relationship correlation as a core control requirement, not an enhancement. If your monitoring cannot connect transactions by customer, beneficial owner, device, counterparty, channel, or branch, it will stay vulnerable to simple structuring.

What to verify: Test whether alert scenarios can detect a pattern only when activity is spread across multiple smaller events. A good challenge case is a sequence of deposits that never crosses the amount threshold individually but clearly does so in aggregate.

Common mistake: Escalating threshold tuning as if it were the main AML improvement. Lowering a threshold may increase volume, but it does not solve the underlying problem if the system cannot recognise distributed behaviour.

Practitioner takeaway: Effective AML monitoring is less about catching big transactions and more about rebuilding the intent behind many small ones, so the programme should be judged on correlation quality, not alert count.

Related resources from NHI Mgmt Group

• What breaks when transaction monitoring and suspicious activity reporting are too weak in AML programmes?
• What breaks when organisations rely only on transaction volume thresholds to detect crypto laundering networks?
• What breaks when banks rely on SMS OTP as the only transaction authentication method?
• What breaks when identity teams rely on static login thresholds?