The Travel Rule and MiCA: what must travel with every transfer
The crypto Travel Rule is a simple idea with an awkward implementation: identifying data about both ends of a transfer has to travel with the transfer. Blockchains were not built to carry it, so an entire messaging layer had to be bolted on beside them.
- The rule is FATF Recommendation 16, written for wire transfers and extended to virtual assets. It is not a crypto-specific invention.
- Data moves off-chain, provider to provider. Nothing goes in the transaction itself.
- In the EU the transfer-of-funds regulation applies with no de minimis threshold — unlike the $1,000 FATF suggests and the US applies.
- Unhosted wallets have no counterparty to message, so the duty becomes proving your customer controls the address.
- The unsolved part is still the sunrise problem: your counterparty may not be subject to the rule yet.
What the Travel Rule actually requires
When a regulated provider sends a transfer to another regulated provider, it must transmit identifying information about the originator, and receive it about the beneficiary. The receiving provider must check that what arrived is complete and act on what is missing.
| Party | Data required |
|---|---|
| Originator | Name; account or wallet reference used for the transfer; address, national ID number, customer identification number, or place and date of birth |
| Beneficiary | Name; account or wallet reference receiving the transfer |
Two details trip firms up. The data must be accurate, not merely present — sending "Customer 41772" as a name satisfies a field and fails the rule. And the transmission must be immediate and secure, which in practice means a dedicated protocol between providers rather than email, spreadsheets or a support ticket.
Where the data travels
None of this goes on-chain. A blockchain transaction carries an amount, addresses and perhaps a memo field — putting customer names in a public memo would be a data-protection incident, not a compliance control. Instead the information moves through a parallel messaging network, and providers must agree on the protocol before value moves.
That creates a discovery problem that has nothing to do with cryptography: before you can send Travel Rule data, you have to know which provider controls the receiving address, and whether they speak a protocol you also speak. Address attribution — the same capability behind wallet screening — is what turns a destination address into a counterparty you can actually message.
Thresholds differ by jurisdiction
| Regime | Threshold | Note |
|---|---|---|
| FATF recommendation | USD/EUR 1,000 | A floor countries may lower, and many have |
| European Union | None | Applies to every transfer regardless of value |
| United States | USD 3,000 (funds transfer rule) | Long-standing; proposals to lower it have circulated for years |
If you operate across regions, build for the strictest regime rather than maintaining threshold logic per corridor. Firms that implemented per-jurisdiction thresholds first have generally rewritten that logic later, because a single transfer can touch several regimes and the cheapest posture is to send full data every time.
MiCA sits alongside, not on top
MiCA is a separate instrument and it is worth being precise, because the two get conflated constantly. MiCA governs authorisation and conduct — who may provide crypto-asset services in the EU, what they must disclose, how they must safeguard client assets, and the rules for stablecoin issuance. The Travel Rule obligation sits in the EU's transfer-of-funds regulation, which travels with the AML framework.
The practical consequence is that a firm holding a MiCA authorisation is not thereby Travel Rule compliant, and vice versa. They are separate examinations with separate evidence. Where they converge is expectation: by 2026 digital-asset service providers are held to the same financial-grade AML and KYC standards as banks, with full transaction monitoring, Travel Rule adherence and comprehensive sanctions screening treated as unremarkable baseline.
Unhosted wallets
When your customer sends to a wallet nobody custodies, there is no provider at the other end to receive Travel Rule data. The obligation does not vanish; it transforms. You must establish that your customer controls the destination address, and apply risk-based measures to the transfer.
The workable verification methods in production today are:
- Signed message. The customer signs a nonce you supply with the address's private key. Cryptographic, cheap, and the strongest evidence available.
- Micro-transfer. A small transfer out and back from the address. Slower and costs gas, but works where signing is awkward.
- Attested declaration plus screening. Weakest. Acceptable only for low-value, low-risk transfers, and only alongside address screening.
Whichever you use, screen the address regardless. Self-custody says nothing about exposure — an unhosted wallet two hops from a mixer is a higher risk than a custodial account at a well-regulated exchange.
The sunrise problem
Jurisdictions adopted the Travel Rule on different timetables and implemented it with different thresholds and protocols. So a compliant provider routinely faces a counterparty that either has no obligation yet, or has one it satisfies differently.
You still carry your obligation. The defensible posture has three parts: record that you attempted transmission and what the counterparty's status was; apply enhanced measures to the transfer, because a counterparty outside the regime is a risk factor in itself; and set a policy threshold above which you simply decline rather than proceed on a hope. Firms that documented the attempt and the reasoning have fared considerably better in examination than firms that quietly sent anyway.
Sunrise is not a technical gap you can close from your side. It is a risk you document, price and sometimes decline.
Implementation checklist
- Counterparty attribution resolves destination addresses to a provider before send.
- Protocol coverage mapped against your actual corridor volumes, not a vendor's total.
- Full originator and beneficiary data sent on every transfer; no per-jurisdiction thresholds.
- Inbound completeness checks, with a defined action when data is missing.
- Unhosted-wallet control verification, preferring signed messages.
- Sunrise policy written down, with a decline threshold.
- Screening runs independently of Travel Rule status — they answer different questions.
- Retention aligned to your AML record-keeping period.
Frequently asked questions
What is the crypto Travel Rule?
A requirement that identifying information about the originator and beneficiary travels with a transfer between providers. It derives from FATF Recommendation 16, written for wire transfers and extended to virtual assets.
Does the Travel Rule apply to unhosted wallets?
There is no counterparty provider to message, so the duty shifts to verifying that your customer controls the address and applying risk-based measures. In the EU that verification duty starts at a low threshold.
What is the sunrise problem?
Jurisdictions adopted the rule at different times, so a compliant provider often transacts with a counterparty not yet subject to it. The compliant firm still carries the obligation and must document its attempt and its reasoning.
Is MiCA the same as the Travel Rule?
No. MiCA governs authorisation, conduct, disclosure and stablecoin issuance. The Travel Rule obligation sits in the EU transfer-of-funds regulation. They are separate examinations with separate evidence.