Money laundering doesn't hide in one payment. It hides in the shape of many. This monitor re-derives the laundering typologies straight from the raw flow, with parameters you can interrogate, cites the exact transactions, and routes every alert to a human. It never files a report on its own, and it's honest about what it can't yet catch.
Origin Pay moves thousands of payments a day. A launderer never trips a single-transaction limit. They structure (break a sum into many top-ups each just under the reporting threshold) or layer (push value in and straight back out to break the trail). Legacy rules engines "solve" this by alerting on everything that looks vaguely off, which is why real AML teams drown in 90%+ false positives and still miss the structured case buried in the noise. The job is not more alerts. It is the right alerts, with the evidence attached.
So this monitor aggregates near-threshold top-ups per account over a window (structuring), and matches large inflows to outflows (layering). I am explicit below about where that is solid and where it needs the graph to go further.
The detection is deterministic. It clusters top-ups in the band [S$2,000, S$2,500) with a count ≥ 3 per account (structuring), and matches an inflow ≥ S$5,000 to an outflow within 10% over ≤ 3 days (layering). The model is read-only. It drafts the case narrative for the MLRO, citing the transaction IDs. The agent never files the suspicious-transaction report. It escalates with the evidence and a person decides.
Account W00008 made eight top-ups between S$2,400 and S$2,490 over a few days. None was individually reportable, but together they are a textbook smurf. The monitor aggregates them, prices the total, and escalates with the eight transaction IDs.
| Account | Typology | Why | Total | Evidence | Result |
|---|---|---|---|---|---|
| W00008 | Structuring | 8 top-ups of S$2,000–2,500, one account, days apart | S$19,641 | T-…-S01 … S08 | escalate → MLRO |
| W00020 | Layering | S$9,800 in, S$9,750 out within 1 day | S$9,800 | T-…-948 · 949 | escalate → MLRO |
| W00137 | · | 2 near-threshold top-ups (below the ≥3 count); a card merchant | · | · | correctly not flagged |
Read those numbers honestly. The 2/0 precision is on a synthetic flow where I seeded the typologies. It proves the detection logic fires on the right shapes and ignores near-misses. It does not prove it would hold a real bank's false-positive rate down, because real AML runs at 90–95% false positives. The dial is the count and band. Raise the count from 3 to 5 and you trade recall for a quieter queue; add account history and type to cut the merchant false positives. And the honest limit: the layering test here matches an inflow to a single near-equal outflow, and a sophisticated launderer beats that by splitting the outflow across accounts. Catching that needs the windowed inflow-vs-Σ-outflow match and following hops through the entity graph, which is exactly what the Knowledge Graph demo is built to do. I would rather name that gap than pretend the 1:1 match is sufficient.
seq : 47 agent : AML Monitor action : escalate_aml subject : W00008 amount : S$19,641 tier : high decision : escalate → MLRO policy : POL-GOV-HITL evidence : [T-…-S01, …, T-…-S07] typology : structuring prev_hash : 2c4d…91fa hash : a6b8…7e02
I move detection from per-transaction alarms to pattern-level evidence, with the parameters in the open so a regulator can interrogate them. And I am deliberate about where the AI stops. It is strong at finding the shape in the noise. It has no business deciding to file a regulatory report, so it triages and escalates and the MLRO decides. Most of all, I will name the limitation, the 1:1 layering gap and the false-positive reality both, because pretending a synthetic precision is a production one is exactly how AI loses a regulated client's trust.
The alerts above are real output from the monitor over Origin Pay's flow. The full console, with the derived alerts, the cited transactions, and the governed ledger, runs as a working application.