The Travel Rule explained for teams launching crypto transfers
The Travel Rule requires the sending VASP to collect originator and beneficiary information, pass it to the receiving VASP immediately and securely, and make it available to authorities. The hard parts are finding the counterparty, handling self-hosted wallets and jurisdictions that disagree.
Charles Archibong, Co-founder
· 6 min read
Key takeaways
- Under INR.15, the originating VASP must obtain, hold and submit originator and beneficiary information immediately and securely.
- FATF allows a de minimis threshold of no more than USD/EUR 1,000; the EU applies its crypto rules regardless of amount.
- The EU transfer of funds regulation (EU) 2023/1113 has applied since 30 December 2024.
- The hardest parts are counterparty discovery, self-hosted wallets and differing national rules.
The Travel Rule means a crypto transfer between two regulated providers must carry information about who is sending it and who is receiving it. Under the FATF Standards, the sending virtual asset service provider (VASP) collects originator and beneficiary information, sends it to the receiving VASP "immediately and securely", and makes it available to authorities on request. The receiving VASP holds it too. The information does not have to sit on the blockchain; it travels alongside the transfer.
What makes it hard is not the list of fields. It is finding out who the other provider is and how to reach them, dealing with self-hosted wallets that have no provider at all, and operating across countries that have written the rule differently or not enforced it yet.
Where does the Travel Rule come from?
It is FATF Recommendation 16, on payment transparency, applied to crypto. The FATF itself describes Recommendation 16 as "also referred to as the 'Travel Rule' in the context of virtual assets" (FATF, 18 June 2025 (opens in a new tab)).
The link is made in the Interpretive Note to Recommendation 15, paragraph 7(b), in the FATF Recommendations (updated October 2025) (opens in a new tab):
The originating VASP must obtain and hold "required and accurate originator information and required beneficiary information", submit it to the beneficiary VASP or financial institution "immediately and securely", and make it available to authorities on request.
The beneficiary VASP must obtain and hold "required originator information and required and accurate beneficiary information".
The same obligations apply to banks and other financial institutions sending or receiving virtual asset transfers for customers.
A footnote adds that the information "can be submitted either directly or indirectly" and need not be attached to the transfer itself. That is why Travel Rule messages run over separate protocols rather than on-chain.
Notice the asymmetry in the word "accurate". The sender vouches for its own customer's details; it passes on the beneficiary details it was given. The receiver vouches for its own customer. Each side verifies the person it knows.
What information has to travel?
The FATF text points to paragraph 9 of the Interpretive Note to Recommendation 16 for the data set. As published in the October 2025 text, which already reflects the revision agreed in June 2025, a cross-border transfer above the applicable threshold carries:
Field | Originator | Beneficiary |
|---|---|---|
Name | Required | Required |
Account number, or unique transaction reference | Required | Required |
Address | Full address (country and town if no standardised address) | Country and town |
Date of birth (natural persons) | Required, year of birth if the full date is unavailable | Not required |
BIC, LEI or official identifier (legal persons) | Where it exists | Where it exists |
For virtual assets, the "account number" is the wallet address or the provider's account identifier. The revised Recommendation 16 is expected to be in force everywhere by the end of 2030, so national rules in force today may still ask for a slightly different set. Check your own regulator's list.
Is there a threshold?
The FATF lets countries adopt a de minimis threshold of "no higher than USD/EUR 1 000" for cross-border transfers. Below it, only names and account numbers (or a unique reference) are needed, and they need not be verified unless there is suspicion. INR.15 separately sets the threshold above which VASPs must carry out due diligence on occasional transactions at USD/EUR 1,000.
The European Union chose not to use a crypto threshold. Regulation (EU) 2023/1113 (opens in a new tab), which has applied since 30 December 2024, says transfers of crypto-assets "should be subject to the same requirements regardless of their amount and of whether they are domestic or cross-border transfers" (recital 30). Its Article 14 asks for the originator's name, distributed ledger address, and either address plus official document and customer numbers or, alternatively, date and place of birth. A firm serving both EU and non-EU customers therefore needs to know which rule set applies to each transfer.
Why is it hard to run?
Knowing who the counterparty is
Before a VASP can send anything, it has to know whether the receiving address belongs to another VASP, and which one. A wallet address says nothing about its owner. Teams use a mix of customer declarations ("I am sending to my account at Exchange X"), address attribution data and directories of participating providers. Every one of these can be wrong.
Reaching the counterparty
Even when you know the counterparty, you need a secure channel to it and agreement on the message format. Providers use different Travel Rule protocols, and a message sent in one is not automatically readable in another. Before sending personal data you also need confidence that the counterparty can protect it; the EU text requires transmission "in a secure manner" and in line with the GDPR (Article 14(4)).
Self-hosted wallets
When the other side is a self-hosted wallet, there is no counterparty VASP to send to. The EU rule still requires you to obtain and hold the information, and for transfers above EUR 1,000 to or from a self-hosted address, to "take adequate measures to assess whether that address is owned or controlled" by your customer (Articles 14(5) and 16(2)). In practice that means methods such as a signed message from the wallet or a small verified transfer.
The sunrise problem
Rules only work when both sides follow them. The FATF's seventh targeted update (opens in a new tab) (16 July 2026) reports that 83% of surveyed jurisdictions (91 of 109) have passed Travel Rule legislation, and that 55 of those 91 had not yet taken any supervisory or enforcement action on it. A provider in a fully implemented jurisdiction will regularly send to providers in places where the rule is not yet enforced, and has to decide what to do when no reply comes.
Timing
The EU requires the information to be submitted "in advance of, or simultaneously or concurrently with" the transfer. Blockchain transfers settle quickly and are hard to reverse, so a receiving VASP that gets funds before the data must decide whether to credit, hold or return them.
A worked example
An illustrative exchange with customers in Lagos and Lisbon processes three withdrawals.
Lagos customer to an account at a known exchange in another country. The exchange identifies the counterparty, sends name, wallet address, address and date of birth over a shared protocol, and releases the transfer once the counterparty acknowledges. Standard path.
Lisbon customer, EUR 300 to another EU provider. Under the EU regulation there is no threshold, so the full data set is still required. A threshold configured for another jurisdiction must not suppress this.
Lisbon customer, EUR 5,000 to a new self-hosted address. No counterparty to message. The exchange records the beneficiary information the customer gives, and because the amount exceeds EUR 1,000, asks the customer to prove control of the address before release.
The rules differ between these three because the jurisdictions and counterparties differ. Requirements vary by country, and this article is general information, not legal advice.
What should you have in place before launching transfers?
A per-jurisdiction table: threshold, required fields, what "accurate" means, and the self-hosted wallet rule.
Verified customer data that can fill the originator fields: full name, address, and date of birth taken from the identity check rather than typed free text.
A way to decide whether a destination is a VASP or self-hosted, with the method recorded.
A policy for counterparties that cannot receive data: hold, return, or proceed with enhanced review.
Sanctions screening of the counterparty and the addresses involved, not only your own customer.
Record keeping that lets you produce what was sent and received for any transfer.
Myaza Trust covers some of the inputs today. Identity Verification checks customers against the government record in our five government-database markets, which gives you a verified name and date of birth to send, and Watchlist Screening can screen wallet addresses attached to a customer against sanctioned-wallet data. The Travel Rule exchange itself is a separate problem. Our Crypto & Travel Rule workspace is where we are working on it; if you are planning a launch, talk to us about your corridors and requirements.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
