A compliance rule that sounds simple until you try to build it
The Travel Rule sounds like paperwork. Send a transaction, attach the sender and receiver's details, done. In practice it is one of the harder engineering problems in crypto compliance right now, and most virtual asset service providers are still working out how to solve it properly.
That was the subject of a recent conversation on the Fintech Garden Podcast (episode 176), where host Igor Tomych sat down with Emeka Mgbenu from Sumsub to break down what the Travel Rule actually requires and why self hosted wallets remain the industry's hardest open question. The episode is worth fifteen minutes of anyone's time if you work anywhere near crypto compliance, but the underlying problem it describes applies well beyond crypto. It is the same identity and risk architecture question every regulated fintech eventually has to answer: how do you prove who is on the other end of a transaction, and how much proof is actually enough.
The core tension is this: banks have SWIFT and decades of correspondent banking relationships to confirm who they are paying. Crypto does not have an equivalent lookup system, so VASPs have to build attribution logic from scratch, transaction by transaction.
Why this is harder than standard AML
Traditional AML and KYC work against a known set of identifiers. A bank account has a holder, a routing number, a jurisdiction. A crypto wallet has none of that by default. When a VASP receives funds, it often has no reliable way to confirm who actually controls the sending wallet, whether the name attached to it is accurate, or whether it is even a wallet subject to Travel Rule obligations at all.
The episode walks through the practical layers of this problem: what data has to travel with a transaction (names, dates of birth, identification details, with different thresholds for local versus international transfers), how VASPs attempt to attribute wallet ownership without anything resembling a SWIFT style directory, and what happens operationally when a name on an incoming transaction does not match the name on file. None of these are edge cases. They are the default condition of running a compliant crypto business today.
Self hosted wallets push the problem further. Anyone can generate one in seconds, with no registration and no custodian standing behind it. Verifying that the person claiming to control a self hosted wallet actually does is still a mix of signature challenges, ownership proofs, and self declaration, none of which carry the certainty a regulator would prefer. Add hierarchical deterministic wallets, which can generate a near unlimited number of addresses from a single seed, and the attribution puzzle multiplies again.
The same problem, a more familiar shape
Strip away the crypto specific vocabulary and this is a risk based customer due diligence problem, the kind every regulated fintech already lives with under FATF Recommendation 10, which requires that the intensity of due diligence scale with the assessed money laundering and terrorist financing risk of the relationship, not apply a single uniform process to everyone. A VASP deciding how hard to push on wallet attribution is making the same call a bank makes when deciding how deep to go on a new corporate account: match the scrutiny to the risk, and be able to show your work.
FATF's own guidance on digital identity, published in March 2020, is explicit that any digital identity system used to satisfy due diligence obligations needs its assurance level formally assessed before being treated as a reliable, independent source. NIST SP 800 63A gives the technical vocabulary for that assessment, with identity assurance levels running from IAL1 to IAL3 depending on the strength of evidence behind a claimed identity. Most crypto wallet attribution today, even at sophisticated VASPs, is operating well below what either framework would consider a high assurance identification method. That gap is exactly why a risk based decision engine, rather than a single pass or fail check, keeps coming up as the only workable answer.
There is a parallel worth drawing for any fintech running automated or remote onboarding, not just crypto firms. EBA guidelines on customer due diligence already treat non face to face and automated onboarding as a delivery channel risk factor in its own right, something that must be explicitly assessed and mitigated rather than assumed safe because the technology is modern. A Travel Rule compliant VASP and a digital bank running instant onboarding are solving structurally the same problem: proving identity and intent without a human in the room, at a speed the business model demands.
What the practical build looks like
The episode lays out a sequence that generalizes well beyond crypto: start with the foundational steps any VASP needs before anything else, then move from a compliance heavy manual launch toward automated screening once the risk patterns are understood. That ordering matters. Teams that try to automate first and understand their risk profile second tend to build systems that either block too much legitimate activity or miss too much illegitimate activity, and both failures are expensive to unwind later.
For regulated fintechs watching this space, whether or not crypto is part of the roadmap, the lesson is architectural. Build a decision engine that treats identity assurance as a graded input, not a binary gate. Document the risk based logic behind every threshold, because when a regulator asks why a transaction cleared, "the system flagged it as low risk based on these specific factors" is a defensible answer and "it passed the check" is not. And treat self hosted, non custodial, or otherwise unverifiable endpoints as what they are: a known category of higher risk that needs its own handling path, not an exception that gets waved through because verifying it properly is hard.
The Travel Rule will keep getting more specific as regulators close gaps. The firms in the best position are the ones that already built their due diligence architecture to flex with changing requirements instead of hardcoding today's rule into tomorrow's system.