Travel Rule

Where the rule comes from, and what it is properly called

The Travel Rule is not a crypto rule that was later applied to payments. It is a payments rule that was later applied to crypto. FATF Recommendation 16 governs payment transparency, and FATF describes the changes to it as the standard "also referred to as the 'Travel Rule' in the context of virtual assets."¹

The crypto extension arrived in two steps. At its October 2018 plenary FATF revised Recommendation 15 and added the definitions of "virtual asset" and "virtual asset service provider" to its glossary, "in order to clarify how AML/CFT requirements apply in the context of virtual assets." In June 2019 it added an interpretive note to Recommendation 15 "that sets out the application of the FATF Standards to virtual asset activities and service providers."⁴ So the crypto Travel Rule is the interpretive note to Recommendation 15 combined with the payment-transparency requirement in Recommendation 16, which is why practitioners cite two recommendation numbers for one obligation. Commercially the lineage matters, because it puts your token inside a payments compliance regime your distribution partners already run rather than a new one built for crypto.

The fields that have to travel

The EU regulation names the parties precisely. An originator is a person holding a crypto-asset account, a distributed ledger address or a storage device who allows a transfer from it, or where there is no such account, the person who orders or initiates the transfer. A beneficiary is "the intended recipient of the transfer of crypto-assets."²

Article 14 then sets the payload. The originator's service provider must ensure every transfer is accompanied by the originator's name, distributed ledger address or crypto-asset account number, and address, official personal document number, customer identification number or date and place of birth, plus the legal entity identifier where available. The same class of information is required on the beneficiary.²

Note what the EU did not do here. There is no de minimis threshold for the data obligation between service providers; the duty attaches to the transfer, not to its size. FATF's own updated Recommendation 16 sets a standardised requirement of name, address and date of birth for peer-to-peer cross-border payments above USD or EUR 1,000, which is a different threshold answering a different question.¹ Confusing the two is a common source of under-scoped compliance work.

The provider-to-provider problem

The obligation is bilateral and the infrastructure is not. Article 16 requires the beneficiary's service provider to implement procedures to detect whether originator and beneficiary information is missing or incomplete, and to act when it is.² But a blockchain transfer carries no envelope for that data, so the two providers have to exchange it over some other channel, agreed between them, in a format they both accept, at a moment that lines up with settlement.

That is why the practical failure modes are all operational. The receiving provider does not support the sender's messaging protocol. The counterparty cannot be identified as a regulated provider at all. The data arrives after the transfer has already confirmed onchain. FATF acknowledged the problem by devoting part of its 2021 virtual-asset guidance to "additional guidance for the public and private sectors on the implementation of the 'travel rule'" alongside licensing, stablecoins and peer-to-peer risk.³

FATF also clarified where responsibility starts in a payment chain: "the payment chain is considered to start with the financial institution which receives an instruction from the customer."¹ The provider taking the customer's order owns the first obligation. It does not pass to whoever settles.

Self-hosted addresses and the 1,000 euro line

For transfers to or from a wallet the customer controls themselves, the EU keeps the data obligation and adds a verification duty above a threshold. The originator's service provider must obtain and hold the same information, and "in the case of a transfer of an amount exceeding EUR 1 000 to a self-hosted address, the crypto-asset service provider of the originator shall take adequate measures to assess whether that address is owned or controlled by the originator."² The beneficiary's provider carries the matching duty on receipt.

The amending provisions push the same expectation into anti-money-laundering law generally, inserting a requirement that providers identify and mitigate risk on transfers to and from self-hosted addresses, including "taking risk-based measures to identify, and verify the identity of, the originator or beneficiary."² Address ownership proof therefore becomes a product feature, and a friction point, in any EU-facing withdrawal flow above the threshold.

What is settled and what is scheduled

Settled: the EU regulation has applied since 30 December 2024, aligned with MiCA, and its obligations are live.² Also settled: the crypto extension of the FATF standards dates from 2018 and 2019 and is long since adopted.⁴

Not settled: the June 2025 revision of Recommendation 16 is agreed but has a long runway. FATF states that "the changes will come into effect by the end of 2030," with guidance and private-sector engagement in the meantime.¹ Treating those revised requirements as current obligations overstates them, and treating them as speculative understates them; they are agreed standards on a slow clock.

Also not settled: the EU self-hosted-address regime is subject to its own review. The regulation required the Commission, after consulting the EBA, to report by 1 July 2026 on the risks of transfers to or from self-hosted addresses and entities outside the Union, and to propose amendments if appropriate.² In our view a founder should build the 1,000 euro address-ownership check as a configurable control rather than a hard-coded one, because the threshold and the method behind it are under active review.

What this changes in a token design

Three consequences worth planning for. Your regulated counterparties will not accept transfers they cannot document, so listing, custody and payment partnerships come with data-exchange requirements attached, and those conversations start earlier than most teams expect. Withdrawal flows to self-hosted wallets need an address-ownership step above the threshold, which is a real conversion cost. And record retention runs on both legs of every transfer, which is a data-governance question as much as a compliance one.

None of this is enforced by the token contract, and that is the point worth internalising. The Travel Rule binds the regulated entities around your token, so it shapes distribution rather than mechanism. Design the mechanism for the business, then check which of your intended distribution partners can actually carry the data obligation.

One caution. Which travel rule obligations apply to a specific business, in a specific jurisdiction, at a specific threshold is fact-specific, and implementation differs materially between the EU, the US and other FATF members. That call belongs to your counsel and compliance function. This page is reference material for design work. It is not legal advice, and it is not a recommendation to buy, sell or hold any asset.