Structuring Below the Threshold: What the Pattern Actually Looks Like
Fourteen transfers of 9,990. Nothing crosses the line, everything rhymes. A walkthrough of the structuring typology with a real case file behind it.
Structuring — smurfing, in the older literature — is the practice of breaking a movement of money into pieces small enough to stay under a reporting threshold. It is one of the oldest typologies in AML, and one of the most frequently missed by systems that screen names but never read transaction streams.
The case file
Customer Salem Al Farsi, a UAE national, ran a modest trading account. Over six days, the account made fourteen outgoing transfers. Every single one was for USD 9,990 or less. The reporting threshold was 10,000. Nothing crossed the line. Nothing tripped a rule.
Read as a stream, though, the pattern is unmistakable — and it is made of five inspectable signals:
| Signal | Observation | Weight in composite |
|---|---|---|
| Threshold proximity | 14 transfers, max 9,990, threshold 10,000 | +10 |
| Round-value bias | 9,950 / 9,980 / 9,990 — all near-round | +6 |
| Temporal compression | 6 days, bursts at 09:41–09:58 | +8 |
| Counterparty concentration | 12 of 14 to a single beneficiary | +8 |
| Profile inconsistency | Median transfer before: 1,200. Now: 9,900 | +12 |
Individually, each signal is explainable. Collectively, they are the typology. That is the design principle: no single signal files an alert; the combination does — and the combination is spelled out, factor by factor, in the trace.
Why exact thresholds miss it
Rule engines built on the threshold itself are structurally blind here: 9,990 is below 10,000, so the rule fires never. The fix is not to lower the threshold (that drowns everyone in noise); it is to model proximity and rhythm:
- proximity: repeated values within a band of the threshold (0–5% below is the default band);
- rhythm: temporal clustering — bursts of activity compressed into days, with consistent values;
- concentration: one counterparty absorbing an outsized share;
- deviation: volume inconsistent with the account's declared and historical profile.
What the trace says
When the investigation agent read this file, the reasoning trace wrote itself in the usual plain language:
mizan.agent SIGNAL threshold_proximity · 14 of 14 transfers ≤ 9,990 (band 0–5% of 10,000)
mizan.agent SIGNAL temporal_compression · 6-day window, 09:41–09:58 bursts
mizan.agent SIGNAL counterparty_concentration · 12/14 to single beneficiary
mizan.agent SIGNAL profile_deviation · median 1,200 → 9,900
mizan.agent RISK_SCORED · composite 87 → CRITICAL
mizan.agent DISPOSITION_RECOMMENDED · freeze funds and file STRThe agent recommends. The analyst reviews. The MLRO approves. The STR is filed with the narrative drafted from these exact lines — so the filing and the file can never disagree. (If you want to see the console the MLRO reviews these in, we shipped one: the MLRO Console.)
The takeaway
Name screening tells you who; behavioural detection tells you what they did. The Salem Al Farsi file shows why you need both: the name matched a watchlist alias at 0.94 — but even without the list hit, the transaction stream alone carried enough evidence to warrant a filing. In four years, no single rule would have caught it. Five signals, read together, caught it in a morning.