Structuring and smurfing — what detection actually needs
Structuring is the typology that exposes whether a monitoring model was designed or merely configured. The behaviour is simple — break an amount into pieces that individually attract less attention — but detecting it requires the model to reason across transactions, accounts, people and time, which most threshold rules do not. EU law anticipates the behaviour directly: several obligations are drafted to catch operations that “appear to be linked” precisely so that splitting does not defeat them.
1. The linked-operations principle
The drafting technique recurs across the AML package. Article 80 of Regulation (EU) 2024/1624 caps cash payments for goods and services at EUR 10 000 whether the transaction is carried out in a single operation or in several operations which appear to be linked. The same construction appears in the obliged-entity perimeter: dealers in cultural goods come into scope where the value of the transaction or linked transactions reaches EUR 10 000, and the real-estate letting limb uses a monthly rent threshold rather than a per-payment one.
2. Why threshold-adjacent detection under-performs
The intuitive rule — flag amounts just below a reporting or approval threshold — is worth having and is not sufficient, for three reasons:
- It assumes the threshold is known to the fraudster. Internal thresholds are not public. Structuring against a threshold the customer cannot see is not what is happening; structuring against a perceived level of scrutiny is.
- It evaluates one axis. Real structuring splits across at least one of: several accounts of the same customer, several related customers, several channels, or several days. A single-transaction rule sees none of that.
- It ignores the aggregate that matters. Whether an aggregate is unusual depends on the customer’s own expected profile, which is the benchmark Article 26 sets for ongoing monitoring in any case.
3. The four axes worth modelling
| Axis | Pattern | What the model needs |
|---|---|---|
| Time | Many small operations in a short window, or a steady drip that aggregates to an unusual total | Rolling windows, not calendar buckets — month-end boundaries are an artefact, not a behaviour |
| Accounts | The same customer using several accounts or instruments in parallel | Aggregation at customer level, and across products in the relationship |
| People | Several apparently unconnected individuals funding one destination | Counterparty-side aggregation — the beneficiary is often the only shared element |
| Channel | Value moved partly by transfer, partly by card, partly by cash | A single view across payment types rather than per-product monitoring |
The third row is where most models are weakest and where the strongest evidence usually lives. Individually, ten inbound transfers of modest size to ten different customers are unremarkable. Aggregated on the destination, they are a single pattern — and Article 26 supports building it, since it requires monitoring to consider information about the origin and destination of funds where necessary.
4. A worked case
Facts: six recently onboarded personal customers, unconnected on file, each receive three or four inbound transfers over two weeks from different senders, and each forwards close to the full balance to the same overseas beneficiary within a day or two of receipt.
What the rules engage: Article 34(2) — the transactions are conducted in an unusual pattern and, for the individual customers, are unusually large relative to profile — which triggers the duty to examine the origin and destination of the funds and their purpose. Article 26 supports aggregating across the six because monitoring is benchmarked against the firm’s knowledge of each customer and, where necessary, information on the origin and destination of the funds.
What the analyst does: works the case on the destination rather than on the six accounts separately. Each account viewed alone produces a weak alert and a plausible explanation; the shared beneficiary and the near-complete, rapid pass-through are the pattern. The recorded assessment covers the group, and the record is retained under Article 77(1)(b) whether or not it results in a report.
FAQ
Is structuring the same as smurfing?
They describe the same technique from different angles — splitting value to avoid scrutiny. “Smurfing” usually emphasises the use of multiple people, which is the axis most detection models handle worst.
Does the law require aggregation?
Several obligations apply to operations that “appear to be linked” rather than to single transactions, and ongoing monitoring is benchmarked against the customer’s profile rather than against a per-transaction threshold. Both point the same way.
What is the single highest-value change to a model?
Aggregating on the counterparty as well as on the customer. Cases that are invisible account by account are often obvious beneficiary by beneficiary.
Related: Cash-intensive businesses · Money mule typologies · Ongoing monitoring
