The Travel Rule for crypto turns seven this year. In theory, every regulated VASP on the planet now exchanges identifying information on customer transfers, no different from a SWIFT wire.
In practice? It's still a mess. Different thresholds by jurisdiction. Three competing technical protocols. Self-hosted wallets handled four different ways depending on which lawyer you ask. And a "sunrise issue" that quietly broke compliance for years and still hasn't fully closed.
This piece is the operator-and-compliance view of where the Travel Rule actually stands in 2026 — what's required, what works, and where it's still genuinely broken.
(If you want the basic explainer of what the Travel Rule is in the first place, I covered that here. This article assumes you already know what FATF Recommendation 16 is.)
The Travel Rule is fully in force in the EU, UK, Singapore, Switzerland, UAE, Hong Kong and most major regulated markets. It's enforced inconsistently in others. The protocol layer is dominated by TRP, IVMS101 and Sygna's network. Self-hosted wallets are still the single hardest operational problem. And smaller VASPs are still missing data 30%+ of the time.
Where the Travel Rule Stands by Jurisdiction
The biggest mistake operators make is treating "the Travel Rule" as one thing. It isn't. Every major regulator has implemented FATF Recommendation 16 differently, and the differences matter.
| Jurisdiction | Threshold | Self-Hosted Wallet Rule | Status |
|---|---|---|---|
| EU (TFR) | EUR 0 — applies to every transfer | Mandatory verification of self-hosted wallet ownership for transfers above EUR 1,000 | Fully in force since Dec 2024 |
| UK (FCA) | GBP 1,000 (domestic) / GBP 0 cross-border | Risk-based — proportionate to transaction risk | In force since Sep 2023 |
| US (FinCEN) | USD 3,000 | Proposed rule never finalised — guidance only | Patchy — exchange-by-exchange |
| Singapore (MAS) | SGD 1,500 | Required where counterparty is unhosted | In force |
| Switzerland (FINMA) | CHF 0 | Proof of ownership required for self-hosted wallets | In force since 2020 — strictest in Europe |
| UAE (VARA / SCA) | AED 3,500 | Counterparty due diligence required | In force |
| Hong Kong (SFC) | HKD 8,000 | Risk-based with verification for higher-value | In force since 2023 |
| Japan (FSA) | JPY 0 | Permitted only with specific licensing | In force |
The EU's Transfer of Funds Regulation (TFR) is the strictest meaningful regime — every transfer, no threshold, identifying data on both sides, and self-hosted wallet ownership verification above EUR 1,000. If you operate in the EU, you operate to the EU standard, full stop.
The US is the outlier most people don't realise. FinCEN's 2020 proposed rule on unhosted wallets and reporting was never finalised. Travel Rule expectations exist via existing BSA guidance, but enforcement is uneven and largely depends on the licensing regime of the specific VASP. This is one reason US-EU corridors remain operationally painful.
Picking the lowest-common-denominator threshold across your operating jurisdictions and applying it everywhere. This works for compliance (you're always above the highest bar) but it's terrible for product — you're collecting and transmitting more data than necessary, expanding GDPR exposure, and slowing every transaction. Smart operators stratify by corridor.
The Sunrise Problem (Still)
The sunrise issue is the polite name for the years between the FATF setting Recommendation 16 in 2019 and every jurisdiction actually enforcing it. Some VASPs adopted Travel Rule infrastructure early. Others didn't — either because their regulator hadn't required it yet, or because they were unregulated entirely.
The result: a regulated VASP sending a transfer to a counterparty VASP in a non-implementing jurisdiction had nowhere to send the data. The receiving VASP had no infrastructure to receive it, no obligation to acknowledge it, and often no interest in setting it up.
In 2026, the sunrise is mostly over for major regulated markets. But meaningful gaps remain:
| Gap | Where It Still Bites | What It Means Operationally |
|---|---|---|
| Non-implementing jurisdictions | Parts of LATAM, Africa, Southeast Asia | You can't transmit Travel Rule data because the counterparty has no system to receive it |
| Unregulated VASPs | Smaller exchanges, OTC desks | Even when you can transmit data, the counterparty has no obligation to act on it |
| DeFi protocols | All of them | DeFi is not a VASP — there is no entity to receive Travel Rule data |
| Self-hosted wallets | Globally | No counterparty institution exists by definition |
| Newly licensed jurisdictions | Markets just turning on TR | Implementation is real but data quality is initially poor |
Self-Hosted Wallets: The Hardest Operational Problem
This is the part of Travel Rule compliance that keeps operators up at night.
A "self-hosted" or "unhosted" wallet is any wallet not controlled by a regulated institution — your MetaMask, your Ledger, your Phantom. There is no counterparty VASP to send Travel Rule data to. There is no compliance department on the other end. It's just a wallet address.
Different jurisdictions have settled on different approaches:
| Approach | Used By | What It Requires |
|---|---|---|
| Verification of ownership | EU (above EUR 1,000), Switzerland | The customer must prove they control the receiving address — typically a microdeposit, signed message, or attestation through a connected wallet |
| Risk-based collection | UK, Hong Kong | Identifying information collected for higher-value or higher-risk self-hosted transfers |
| Counterparty due diligence | UAE, Singapore | Operator must perform additional checks on the counterparty wallet, often through blockchain analytics |
| Outright prohibition | Some banking-licensed VASPs | Withdrawals to self-hosted wallets banned entirely |
| No specific rule | Many smaller jurisdictions | Treated under general AML rules, not Travel Rule specifically |
The EU's verification requirement is the most operationally demanding and the one most likely to spread. Three methods are commonly used:
- Microdeposit + return — the customer sends a small amount from the self-hosted wallet to the VASP, proving control of the private keys
- Signed message — the customer signs a specific message with the wallet's private key, demonstrating ownership without moving funds
- Connected wallet attestation — third-party services (like KYT providers) attest to the wallet's ownership through verified wallet connection flows
Each has trade-offs: microdeposit is universal but adds friction and a fee; signed messages don't work for every wallet type; connected wallet attestations rely on third parties and don't always cover hardware wallets cleanly.
Most operators end up offering two or three methods and letting the customer choose. The verification flow is one of the highest-friction parts of crypto compliance — and it's where most of the customer-experience battle is fought. Operators who solve this well retain customers; operators who don't, lose them.
The Three Protocol Stacks
The Travel Rule isn't just legal text — it requires actual technical infrastructure for VASPs to exchange data securely. In 2026, the market has consolidated around three main approaches:
| Protocol | Strengths | Weaknesses | Common Use |
|---|---|---|---|
| TRP (Travel Rule Protocol) | Open, simple, REST-based | Lower built-in counterparty discovery | Bilateral exchanges between known counterparties |
| IVMS101 | The data standard — adopted across most protocols | Just a data format, not a transmission method | Underlying schema for nearly every Travel Rule message |
| Sygna / Notabene / Veriscope networks | Counterparty discovery built in, broad VASP coverage | Network effects — value depends on which VASPs are on which network | Most used by mid-to-large VASPs |
| In-house bilateral | Total control | Doesn't scale beyond a handful of counterparties | Used by very large VASPs with high-volume corridors |
In practice, most regulated VASPs sit on at least two networks plus a fallback bilateral arrangement for the largest counterparties. The fragmentation is real and is one of the reasons Travel Rule infrastructure has been a meaningful operational cost line for compliance teams.
Data Quality: The Quiet Failure
Even when Travel Rule data is successfully transmitted, the data itself is often incomplete, inconsistent, or wrong.
The most common data quality failures we see:
| Failure Mode | What Happens | Why It Matters |
|---|---|---|
| Missing originator address | Address field left blank or filled with 'unknown' | Triggers AML alerts on receipt — and is technically non-compliance with most regimes |
| Inconsistent name formats | 'Smith, John' vs 'John Smith' vs 'JOHN SMITH' | Sanctions screening false positives or, worse, false negatives |
| Wrong date of birth | Format mismatches, regional date conventions | Identity matching fails — manual review required |
| Counterparty wallet address mismatches | Address transmitted doesn't match address actually credited | Reconciliation failure — the most common operational issue |
| Late transmission | Data arrives after the transfer has settled | Defeats the purpose — you can't act on data you don't have when the transaction lands |
Internal estimates from major operators put data quality failure rates between 15% and 35% on cross-VASP transfers, depending on the corridor. That's not a Travel Rule problem — it's an industry-wide data hygiene problem that the Travel Rule has exposed.
What Good Travel Rule Compliance Looks Like in 2026
After working with multiple operators on TR programmes, this is what mature compliance looks like:
Flor's Take
The Travel Rule was never going to be clean. It was retrofitted onto a financial system that was built specifically to operate without intermediaries — and you can feel that retrofit every time a self-hosted wallet hits a regulated VASP.
That said, the 2024 implementation of the EU TFR was the moment the Travel Rule stopped being theoretical. We now have a clear, strict, enforced regime in the largest regulated crypto market in the world, and other jurisdictions are converging on it. The sunrise is mostly over. The operational pain is mostly known. The protocols are mostly mature.
What hasn't been solved — and won't be solved soon — is DeFi. The Travel Rule applies to VASPs. DeFi protocols are not VASPs by any honest reading of the FATF definitions. Until that question is regulated (and the EU's MiCA II discussions in 2025-26 are circling it), there's a structural gap where regulated capital can flow to and from DeFi without Travel Rule coverage at all. Some operators block it. Some price the risk. Nobody has solved it.
The Travel Rule in 2026 is real, enforced and operationally manageable for compliant VASPs in major markets. It's still imperfect — and the imperfections (sunrise gaps, self-hosted wallets, DeFi) are exactly where compliance teams need to focus their judgement. The teams that handle TR well treat it as a multi-control programme, not a data-transmission problem. The ones that don't are the ones the next round of enforcement will catch.
For operators: invest in counterparty network coverage and self-hosted wallet UX. For compliance teams: treat data quality as a KPI. For users: understand that the Travel Rule is now a permanent feature of regulated crypto — and that the more you transact through compliant VASPs, the more your data is being shared. That's the trade-off.
Working through a specific Travel Rule scenario? Drop me a message.
This article is educational content only and does not constitute legal, regulatory, or compliance advice. Travel Rule requirements vary materially by jurisdiction and licence type. Always consult qualified counsel for specific compliance decisions.