Travel Rule compliance: how VASPs exchange sender data under FATF rules

Among all the obligations that FATF standards impose on the crypto industry, one has proven the hardest to operationalize: the travel rule. The requirement itself is borrowed directly from traditional banking, where wire transfers have carried originator and beneficiary information for decades. Transplanting it onto blockchain rails, where a transaction is a broadcast message signed by a private key, turned out to be anything but mechanical. A bank receiving a wire can read the sender’s name on the payment message; a VASP receiving on-chain funds receives only a deposit address — and must somehow reconstruct who sent it.

That reconstruction problem defines the entire compliance landscape of 2026. By now, the travel rule has moved from recommendation to enforced law across the major jurisdictions: the EU’s MiCA and transfer-of-funds regulation, the US FinCEN expectations, the UK’s FCA rules, and implementations across Asia and the Gulf have each given it binding force, with the EU’s MiCA framework now in full application for crypto-asset service providers. This piece walks through what the rule actually requires, how the data exchange between institutions technically works, what happens with self-custody wallets, and where the system still has unresolved friction — because travel rule compliance is the part of the AML stack where technology, law and industry coordination meet most directly.

What the travel rule actually requires

The rule’s logic is deceptively simple: when value moves between entities, the information about who sent it and who receives it must travel too. FATF Recommendation 16, extended to virtual assets in 2019, established the baseline that national laws have since implemented with local variations. The core requirements, as they operate in practice:

1. Originator data accompanies the transfer. The ordering institution must transmit, with the transfer, the originator’s name, account/wallet identifier, and physical address, national identity number, customer ID or date and place of birth — the standard demands one of the latter identifiers, and most implementations collect more.
2. Beneficiary data travels with it. The beneficiary’s name and account identifier must accompany the transfer and be available to the receiving institution before funds are made available to the customer.
3. Receiving institutions must verify. The beneficiary VASP must check that the received information matches its own customer records; mismatches trigger review, delay or rejection.
4. The obligation applies VASP-to-VASP. Transfers to and from self-custody addresses follow separate rules per jurisdiction — but transfers between regulated entities must carry full data regardless of amount, in the strictest reading, or above jurisdictional thresholds in the more lenient ones.

The threshold question is the most confusing practical detail. FATF sets a threshold of 1,000 USD/EUR for applying the full data requirements to transfers between VASPs, but leaves countries free to set lower thresholds or none at all. The United States applies its rules broadly below the de minimis amount; the EU’s regulation applies the data requirements to all transfers between service providers, with simplified measures for low-value transfers to self-custody wallets under defined conditions. A VASP operating across jurisdictions must therefore implement the strictest applicable rule — which, in practice, has pushed most institutional messaging systems toward treating every VASP-to-VASP transfer as fully in scope.

How the data actually moves: the messaging problem

Blockchains carry no customer names, so the travel rule lives entirely off-chain — in a parallel messaging layer that must connect every regulated institution to every other one. Solving this required an industry-wide coordination exercise without precedent in the AML world. The technical landscape that emerged:

Protocol	Governance	Model	Notable traits
TRP (Travel Rule Protocol)	Open, working-group driven	Peer-to-peer information exchange	Flexible exchanges over a common request-response framework; the earliest broad protocol
IVMS 101/102	InterVASP working group	Data standard (not transport)	The standardized message vocabulary most protocols and solutions adopt; defines the exact fields exchanged
TRISA	Open-source, interoperability-focused	Peer-to-peer with public key infrastructure	Cryptographically signed messages; designed for decentralized discovery
Sygna Bridge	Commercial solution	Hub-based	A central relay connecting participating VASPs; widely adopted in Asian markets
Notabene, Sumsub and similar commercial networks	Commercial SaaS	Hub/network hybrid	Counterparty discovery, compliance workflows and integration tooling under one interface

The split between peer-to-peer protocols and hub-based networks is the structural choice of the field. Peer-to-peer models preserve decentralization but demand that each VASP discover, authenticate and connect to every counterparty individually. Hub-based networks solve discovery instantly — send once to the hub and it routes to any member — but concentrate the messaging layer in commercial intermediaries, recreating a faint echo of the correspondent-banking world. In 2026, the practical answer is convergence: most VASPs operate through commercial networks for reach while the underlying message data converges on IVMS standards, and the peer-to-peer protocols function as the interoperability floor rather than as competing silos.

The complete workflow of a compliant transfer

Tracing one transfer end to end shows where every obligation sits and why the system is more intricate than a single handshake. The sequence in a VASP-to-VASP transfer:

1. Counterparty discovery. Before the data can be sent, the sending VASP must establish which entity controls the destination address. This is the unsung hard problem: attribution from a raw blockchain address to an operating VASP, solved through directory services, address indexing databases and counterparty self-identification.
2. Data collection from the customer. The originator VASP gathers the required identity fields from the sending customer, in many cases alongside a declaration of the destination’s nature.
3. Secure transmission. The originator transmits the IVMS-formatted message to the beneficiary VASP through the connected protocol or network, typically before or simultaneously with the on-chain transfer.
4. Receipt and verification. The beneficiary VASP confirms the message authenticity, matches the originator data against its expectations, and verifies the beneficiary is its own customer.
5. Acceptance, hold or return. On a successful match, funds are credited. On missing or mismatched data, the receiving institution may hold the transfer pending cure, request resubmission, or return the funds — and each jurisdiction’s rules define what must be reported if resolution fails.
6. Recordkeeping. Both institutions retain the exchanged data for the statutory retention period, generally five years, and make it available to supervisors on request.

The workflow makes visible the dependency that regulators underestimated in the early years: the system’s integrity depends on the weakest participant. An originator VASP in one jurisdiction transmitting sloppy data creates compliance burdens for every counterparty downstream — which is why supervisory attention has increasingly focused not just on whether messages are sent, but on their quality.

Self-custody wallets: the rule’s hardest edge

Transfers between a VASP and an unhosted wallet sit outside the clean VASP-to-VASP pathway, and each regulator resolved the edge differently. The patchwork that governs these transfers:

• Risk-based collection. Most regimes require the VASP to obtain and verify originator or beneficiary information for self-custody transfers above defined thresholds, with the intensity scaling to risk — a small occasional withdrawal faces lighter treatment than repeated large outflows.
• Ownership verification. Several jurisdictions expect VASPs to establish that the customer actually controls the destination wallet, commonly satisfied through a signed message challenge, a micro-transfer test or a verified wallet registry. The demand for proof-of-control has become a routine onboarding step rather than an edge case.
• The EU’s approach. The bloc’s transfer regulation applies travel-rule data requirements to transfers to and from self-custody addresses above 1,000 EUR when the VASP can identify the counterparty — and imposes enhanced scrutiny regardless, requiring VASPs to verify the identity of the wallet holder in defined circumstances.
• Prohibited or constrained jurisdictions. Some regimes restrict unhosted wallet interaction more aggressively, and a few jurisdictions’ rules effectively channel users toward hosted wallets by making self-custody transfers administratively heavy.

For users, the practical meaning is that self-custody is not exempt from visibility — it is merely visible through a different mechanism: instead of counterparty VASPs exchanging messages, the customer’s own VASP applies risk assessment, verification and, in many frameworks, occasional information requests. The friction that was once an exchange’s problem is now partially the user’s paperwork.

The unsolved frictions of 2026

Despite several years of implementation, the travel rule regime still carries structural friction points that every compliance officer recognizes. The outstanding problems:

1. Counterparty attribution at scale. Address-to-institution mapping remains imperfect, especially for smaller VASPs, decentralized services and multi-signature structures; misattributed or undiscoverable counterparties generate false-positive holds that annoy legitimate users.
2. Sunrise problem. Jurisdictions implemented at different times and depths, and transfers crossing into non-implementing or lightly implementing jurisdictions leave VASPs choosing between delaying transfers and accepting incomplete compliance — with documentable risk decisions expected in either case.
3. Data quality asymmetry. The volume of exchanged messages grew far faster than their accuracy; incomplete originator data, placeholder names and unresponsive counterparties remain the daily texture of compliance operations.
4. Privacy tension. The rule’s data requirements collide with data protection frameworks in jurisdictions like the EU, where transmitting personal identity data across borders must satisfy both AML and privacy law simultaneously — a legal tightrope that keeps compliance teams consulting counsel.
5. Decentralized and emerging services. DEX aggregators, cross-chain bridges and non-custodial services resist the VASP classification on which the messaging system depends; the perimeter of «who must exchange data» is a moving frontier.

None of these frictions is fatal, and each has workarounds that the industry employs daily. But together they explain why travel rule compliance is consistently the highest-cost, highest-friction component of VASP operations — and why the systems built for it are converging on shared infrastructure rather than staying fragmented.

What this means for users

For the customer sending or receiving funds, the travel rule manifests as predictable friction rather than visible machinery. Names may be requested for transfers the user considers trivial; withdrawals to unfamiliar exchanges may pause pending counterparty confirmation; wallet-control proofs may be demanded before a first self-custody withdrawal. None of these steps signals suspicion — they are the routine operation of a regime that now treats every cross-institution transfer as a documented event.

The habits that minimize friction mirror the ones that minimize AML friction generally: transacting between established, regulated services wherever possible; keeping account identity data current so originator messages transmit cleanly; responding promptly to verification requests; and avoiding chains of services with uncertain regulatory status, where the counterparty-discovery machinery breaks down and holds become the default rather than the exception.

Conclusion

The travel rule in 2026 is the compliance layer that turned anonymous blockchain transfers between institutions into documented, attributable events. Its requirements — originator and beneficiary data accompanying every VASP-to-VASP transfer, verification on receipt, and retention for supervisors — are now enforced across the major jurisdictions, with the strictest applicable rule effectively defining global practice. The technical answer to the messaging problem matured from fragmented experiments into a working ecosystem: IVMS data standards as the common vocabulary, peer-to-peer protocols as the interoperable floor, and commercial networks as the operational layer where most institutions actually live.

The regime’s remaining frictions — counterparty discovery, the sunrise problem, data quality, the self-custody edge — are real, but they are the frictions of a system that exists and functions, not one still being imagined. For VASPs, the message of the current era is that data exchange is no longer a differentiator but a baseline, and operational excellence now lies in message quality, counterparty reach and workflow speed. For users, the rule is simply the reason their transfers carry names even when the blockchain itself carries none — an invisible layer that, working as designed, passes entirely unnoticed.