Crypto Travel Rule Explained: FATF R.16 and EU TFR
The crypto Travel Rule requires virtual asset service providers (VASPs) to send identifying information about the originator and beneficiary along with a crypto transfer, and to receive and check that information on incoming transfers. It comes from FATF Recommendation 16, which sets a USD/EUR 1,000 threshold, and in the EU it is implemented by the Transfer of Funds Regulation (EU) 2023/1113, which has applied to crypto-asset transfers since 30 December 2024 with no threshold between providers.
Below is what that means in daily operations for an exchange, OTC desk or crypto payment company: what data moves, when, what to do about unhosted wallets, and how to handle a counterparty that never answers.
Where the rule comes from
FATF extended Recommendation 16, originally written for bank wire transfers, to virtual assets in 2019. The interpretive note to Recommendation 15 tells countries to apply the wire transfer rules to VASPs. FATF standards are not law by themselves: each jurisdiction writes its own rules, so thresholds, data fields and deadlines vary.
The EU went further than the FATF minimum. The recast Transfer of Funds Regulation (TFR) applies to crypto-asset service providers (CASPs) under MiCA and covers every crypto-asset transfer between CASPs, whatever the amount. It is a regulation, so it applies directly in every member state without national transposition.
What data travels
The exact fields depend on the jurisdiction. The table below summarises the core set under the FATF standard and the EU TFR.
| Party | FATF R.16 (at or above threshold) | EU TFR (CASP to CASP, any amount) |
|---|---|---|
| Originator | Name; account number (e.g. wallet address); plus physical address, national ID number, customer ID or date and place of birth | Name; distributed ledger address and crypto-asset account number where used; address including country, official personal document number, customer ID, or date and place of birth; LEI or equivalent where available |
| Beneficiary | Name; account number (e.g. wallet address) | Name; distributed ledger address and crypto-asset account number where used; LEI or equivalent where available |
Under FATF, transfers below the threshold still carry the names of both parties and their wallet or account identifiers, but the information does not have to be verified unless there is a suspicion of money laundering or terrorist financing.
Two practical points for the originator side:
- The originating VASP verifies its own customer's data. This is information you already hold from KYC. If your onboarding is weak, your Travel Rule data will be weak too.
- The beneficiary data comes from your customer. They type in a name. You cannot verify it yourself, which is why the receiving VASP compares it with its own records.
Thresholds: FATF vs EU
FATF allows countries to apply a de minimis threshold of USD/EUR 1,000. Many jurisdictions use it. The EU does not between CASPs: a EUR 5 transfer from one CASP to another carries the full data set.
If you operate in several regions, the simplest policy is often to send full data on every transfer and decide on the receiving side which rules apply. Splitting logic by threshold and destination country adds edge cases, and an amount near the threshold in one currency can cross it after conversion.
Unhosted wallets and ownership proof
An unhosted (self-hosted) wallet has no VASP on the other side, so there is nobody to exchange data with. The rules shift from data exchange to knowing your own customer's relationship with that address.
Under the EU TFR, a CASP must collect originator and beneficiary information for transfers to or from a self-hosted address. For transfers above EUR 1,000, it must also take adequate measures to assess whether the address is owned or controlled by its own customer. Common ways to prove ownership:
- Message signing. The customer signs a message with the wallet's private key.
- Satoshi test. The customer sends a small, specific amount from the wallet.
- Other evidence your regulator accepts for wallets that cannot sign messages, documented in your procedures.
Doing this on every transfer frustrates customers. A better pattern is to verify ownership once, store the proof, and treat later transfers to the same address as already verified. That is how Cryptic AI's Travel Rule module handles it: the client confirms once that the wallet is theirs, and later transfers do not get stuck.
Ownership proof does not replace risk screening. A verified customer wallet can still have exposure to illicit sources, so screen it like any other address.
Interoperability between protocols
There is no single Travel Rule network. Several messaging protocols exist, and VASPs choose different ones. If you only support one, you will find counterparties you cannot reach.
Interoperability problems show up as:
- Discovery failures. You cannot tell which VASP controls the destination address, or which protocol it uses.
- Field mismatches. Names split differently into first and last name, transliteration differences, missing address fields.
- The sunrise issue. The counterparty sits in a country that has not yet implemented the Travel Rule, so it may not be obliged to respond.
Supporting more than one protocol reduces unreachable counterparties. Name matching needs tolerance: an exact string compare will reject a correct beneficiary whose name was written in a different order or alphabet. How strict to be is a policy choice you should make and document.
When the counterparty does not respond
This is the hardest operational question. Under the EU TFR, the beneficiary CASP must have risk-based procedures to decide whether to execute, reject, return or suspend a transfer that arrives with missing or incomplete information. A CASP that repeatedly fails to provide required data should be subject to escalating measures, which can include restricting or ending the relationship, and must be reported to the competent authority.
A workable policy usually answers four questions:
- How long do we wait? A fixed window per risk level, for example a short wait for low amounts and a longer one for high ones.
- What happens when time runs out? Release, return, or escalate to review.
- Do we hold the funds meanwhile? For outgoing transfers, holding until the counterparty confirms is the safest option. For incoming, funds may already be on-chain, so the decision is whether to credit.
- Who decides the exceptions? A named reviewer with a deadline, not an inbox nobody owns.
In Cryptic AI these are configurable rules: the amount that triggers the Travel Rule, how strict name matching is, how long to wait, and what to do on no reply. Transfers can optionally be held until the counterparty answers. Cases that need a person land in a review queue with countdown deadlines, and the reviewer can launch a KYT investigation of the beneficiary wallet from the transfer card with one click.
Integration
Travel Rule checks sit in the same flow as your withdrawal and deposit processing. A typical integration calls the API when a withdrawal is requested, holds or releases based on the rule outcome, and listens on webhooks or a real-time status stream for counterparty replies and reviewer decisions. Keep the full exchange (what was sent, what came back, when, and who approved) attached to the transaction for audits.
FAQ
Does the Travel Rule apply to transfers below EUR 1,000 in the EU?
Yes, for transfers between CASPs. The EU TFR has no de minimis threshold for crypto-asset transfers between providers. The EUR 1,000 figure matters for transfers involving self-hosted addresses, where ownership must be assessed above that amount.
What if the beneficiary VASP is in a country without Travel Rule laws?
You still have to meet your own obligations. Send the required data where possible, assess the counterparty's risk, and decide case by case whether to proceed, using your documented policy for unresponsive or non-compliant counterparties.
Do I need to verify ownership of every unhosted wallet?
Under the EU TFR, ownership must be assessed for transfers above EUR 1,000 to or from a self-hosted address. Verifying once and reusing the proof for the same address keeps this from blocking regular customers.
Is Travel Rule data the same as KYC?
No, but it depends on it. The originator data you send comes from your KYC records, so gaps there become Travel Rule failures. See our KYC module for how identity data is collected and checked.
Travel Rule compliance comes down to sending complete data, reaching as many counterparties as possible, and having a clear answer for when they do not respond. If you want to set those rules once and let the system enforce them, see how the Cryptic AI Travel Rule module works.