The FATF Travel Rule fits in a sentence: when a transfer above a threshold moves between regulated providers, the originator's and beneficiary's information has to travel with it. Like most one-sentence rules, it turns into months of edge cases the moment you implement it.
Where literal text and practice diverge
The most expensive bugs are not in the code; they are in the gap between what the rule says and how it is enforced. Two divergences show up reliably:
- What counts as a "transfer." The rule was drafted against on-chain settlement between providers. In practice, enforcement has been read to include internal book transfers between custodial users of the same provider — transfers that never touch a chain. A literal implementation misses these entirely.
- How the threshold applies. The text reads per-transaction. Enforcement frequently applies it as a 24-hour aggregate per counterparty, to stop structuring. Build per-transaction and you pass the text and fail the audit.
Model the divergence, don't bury it
The pattern that keeps this maintainable: capture each clause as {statutory_rule, enforcement_overlay, divergence_note}. The overlay is the binding behaviour the detector uses; the statutory rule stays as a citation; the divergence is documented. When an auditor asks why the system aggregates over 24 hours, the answer has a paper trail instead of a shrug.
The transmission problem
Beyond detection, there is the actual moving of data between providers:
- Counterparty discovery — is the receiving address controlled by a regulated provider, an unregulated one, or a self-hosted wallet? The obligation differs in each case.
- Interoperability — a shared data model (IVMS101) and a protocol both sides speak, so the originator/beneficiary payload is understood at the other end.
- Self-hosted wallets — when the counterparty is not a provider at all, the rule bends, and your system needs an explicit branch for it.
Edge cases that bite
Aggregation windows, batched withdrawals, currency conversion right at the threshold boundary, retries and idempotency of transmission, and — easy to forget — the intersection with GDPR, because you are transmitting personal data across providers and borders. Each of these is a place to be precise.
Build for the audit
The throughline is the same as any serious compliance system: log every decision, keep the divergence between text and practice auditable, and make the reasoning reconstructable after the fact. The Travel Rule is not hard because the sentence is long. It is hard because the sentence and the enforcement are two different things, and only one of them is what you are actually graded on.
I build AML and compliance transmission layers that hold up to scrutiny — reconciling the literal rule with how it's actually enforced. If you are implementing the Travel Rule or similar, let's talk.