Where standard AML training runs out
Most AML training programmes were built for a world of names, accounts, and correspondent banking relationships. That training isn't wrong, the underlying skill, recognising a pattern inconsistent with a stated profile, still applies. But a genuinely crypto-touching case exposes gaps that standard training simply doesn't cover, and an analyst who's never had those gaps named tends to discover them under pressure, mid-investigation, rather than beforehand.
Fiat training assumes a bank in the middle
Traditional AML training is built around the assumption that value moves through regulated intermediaries, banks, payment processors, that are typically capable of holding, delaying, or refusing a transaction before it settles. Part 4 already covered the structural consequence of this assumption breaking down in crypto: a firm often can't simply decline an incoming on-chain transaction the way a bank can decline to open an account. An analyst trained purely on "when in doubt, block the transaction" hits a genuine procedural wall the first time they're looking at value that's already landed in a wallet the firm controls, with no equivalent "return to sender" option available.
Identity and ownership don't map the way KYC training assumes
Standard KYC training teaches verifying who a customer is. Crypto adds a second, separate question standard training rarely addresses with any depth: whose wallet is this, actually. A customer can pass every identity check and still control multiple wallets under different guises, or conversely, a wallet address alone tells you nothing about who controls it without additional attribution work, clustering, exchange deposit tagging, or off-chain intelligence. An analyst trained to think "identity verified, case closed" misses that wallet-level attribution is a distinct, ongoing task, not something settled once at onboarding.
"Clean history" means something different on-chain
In fiat AML, a clean transaction history over time is genuinely reassuring. On-chain, a wallet's history can look clean simply because the tooling in use doesn't have visibility into activity on other chains, or because funds arrived via a bridge or mixer that weakened or broke the traceable link to their origin, how completely depends on the specific protocol, not because the funds are actually clean. An analyst applying fiat intuition, "nothing's flagged, therefore it's fine", is applying a standard that doesn't transfer.
The pace is faster than the review cycle
A suspicious fiat transaction typically allows some window for review before it settles irreversibly. On-chain finality is commonly near-immediate, though the exact timing varies by chain and consensus mechanism. This changes what "acting quickly" actually means in practice, and it's a big part of why OFSI specifically flagged retrospective discovery, catching a sanctioned transaction only after better analytics tools became available, as a recurring, reportable failure pattern among UK crypto firms, covered in Part 4. Standard training rarely prepares an analyst for a case where the review window has already closed before the review even starts.
Standard training doesn't teach you to read a wallet graph
This is the most concrete, learnable skill gap, and arguably the easiest one to actually close. Reading a cluster of connected wallets, spotting a peel chain, recognising a tightly-knit group of addresses trading only with each other, none of this is something we've seen covered in the AML certification curricula we're familiar with, and all of it is a genuinely learnable, practical skill once someone's shown what to look for. Part 3 of this series covered the underlying typologies directly.
Worked example: the wallet that looked clean
A customer at a mid-sized VASP requests withdrawal of 40,000 USDT to an external wallet. The wallet has no direct hits against sanctions lists, no mixer exposure, and a six-month on-chain history showing only routine peer-to-peer transfers. KYC on the customer is complete: identity document verified, address confirmed, source of funds declared as "trading profits." Nothing in the file looks wrong, because the file only asks a name-and-address question.
What it misses is on-chain: the receiving wallet took in funds from four other wallets over the prior 72 hours, each deposit sitting just under the exchange's standard reporting threshold, and each of those four funding wallets was itself funded from a single wallet with no prior on-chain history before that week. That's a layering pattern, structuring below a threshold followed by consolidation, and it doesn't show up in a KYC file because a KYC file was never built to ask a wallet-graph question in the first place.
This is illustrative, not a specific documented case, the pattern is common enough that most VASP investigation teams will recognise a version of it, but it isn't tied to a named counterparty or a public enforcement action. The lesson is the transferable part: a wallet passing every sanctions and PEP screen tells you nothing about layering risk. That's a separate question, and asking it requires looking at the graph, not just the address.
Checklist: reading a wallet graph before you approve
- Funding source count. How many distinct wallets fed the customer's wallet in the review window, and does that match their declared counterparty story?
- Timing clustering. Do multiple small deposits land within a short window relative to a single large withdrawal request?
- Threshold proximity. Are individual inbound amounts sitting just under a reporting or internal monitoring threshold?
- Wallet age. Does the funding wallet have on-chain history predating this transaction pattern, or did it appear only to fund this transfer?
- Declared source-of-funds test. Does the customer's stated explanation for the funds match the actual on-chain funding pattern, not just the total amount received?
None of these five checks require specialist forensics tooling to start with, they're a way of looking at a block explorer with the right questions in mind, which is exactly the practical skill standard AML training tends to leave out.
Closing this gap deliberately, not by accident
None of the five gaps above get closed by reading about them once. They get closed by working through cases that force the decision the way a real one would, which is the entire premise behind Scenario Lab's KYC and Sanctions Investigation module: building an actual ownership tree, screening entities in sequence, and making a disposition call against a case that's specifically designed to test whether a clean surface result gets treated as the end of the analysis or the start of it. If any of the five gaps above sound familiar from your own experience, that's a reasonable place to test the actual skill, not just read another paragraph about it.