The EU Travel Rule — Transfer of Funds Regulation, Regulation (EU) 2023/1113 — became applicable on 30 December 2024. It is the EU transposition of FATF Recommendation 16 for virtual asset transfers, with thresholds and self-hosted wallet rules that are tighter than the FATF baseline. This article reads TFR from a CASP operator's perspective: which transfers carry which data, how to verify self-hosted wallets, how the sunrise problem is solved in practice, and how TFR compares with Turkey's MASAK framework and the UK MLR 2017.
What TFR Regulates
TFR is the recast of Regulation (EU) 2015/847 (traditional fund transfer Travel Rule). It covers two areas:
- Traditional payment transfers (bank wires, SEPA) — replacing the 2015/847 regime.
- Crypto-asset transfers — including CASPs and self-hosted wallets.
This article focuses on the crypto side. The traditional payment side is mostly an established flow already (SWIFT MT103/MX, SEPA pacs.008).
Core Rules
CASP-to-CASP Transfers: €0 Threshold
Every crypto transfer between two CASPs, at any amount (including €0), must carry:
Originator data:
- Name
- Address (at least city + country)
- Account / wallet number
- Official identification number (passport, national ID, etc.) or date and place of birth
Beneficiary data:
- Name
- Account / wallet number
This data is transmitted to the receiving CASP "in the messaging accompanying the transfer." The industry standard for that message is IVMS 101 (Interoperable Virtual Assets Messaging System).
Self-Hosted Wallet Transfers: €1,000 Verification Threshold
A self-hosted wallet is one that is not managed by a CASP — i.e. the user holds their own private key (MetaMask, Ledger, etc.). TFR Article 14:
- €0-€1,000: the CASP must establish that the self-hosted wallet belongs to its own customer — user declaration is sufficient, no technical proof required.
- Above €1,000: the CASP must technically verify wallet ownership. Two common methods:
- Message signing (Satoshi Test): the user signs a defined message with the self-hosted wallet's private key; the CASP verifies the signature.
- Micro-deposit: the CASP sends a tiny amount to the self-hosted wallet; the user returns it to the CASP account, proving control.
The threshold is fiat-equivalent (transfer value computed in €, using the crypto-fiat rate at transfer time).
High-Risk Third Country CASPs
The Commission maintains a "high-risk third country" list. For transfers involving CASPs in those jurisdictions, EU CASPs must perform Enhanced Due Diligence (EDD) and may restrict or refuse transfers. As of May 2026 the list runs parallel to but is independent from the FATF grey/blacklist.
TFR Message Flow (IVMS 101 Example)
Simplified IVMS 101 payload for a CASP-to-CASP transfer:
{
"originator": {
"originatorPersons": [{
"naturalPerson": {
"name": [{"primaryIdentifier": "Yilmaz", "secondaryIdentifier": "Ahmet"}],
"geographicAddress": [{"addressType": "HOME", "townName": "Istanbul", "country": "TR"}],
"nationalIdentification": {"nationalIdentifier": "12345678901", "nationalIdentifierType": "CCPT"},
"dateAndPlaceOfBirth": {"dateOfBirth": "1985-04-12", "placeOfBirth": "Istanbul"}
}
}],
"accountNumber": ["bc1q...originator_wallet..."]
},
"beneficiary": {
"beneficiaryPersons": [{
"naturalPerson": {
"name": [{"primaryIdentifier": "Mueller", "secondaryIdentifier": "Anna"}]
}
}],
"accountNumber": ["bc1q...beneficiary_wallet..."]
}
}
In production CASPs transmit this payload over a Travel Rule network using IVMS 101: TRP (Travel Rule Protocol), Sygna, TRISA, Notabene, Veriscope. In the EU TRP and Sygna are most widely adopted.
The Sunrise Problem and EU-Side Solutions
Sunrise problem: a CASP produces TFR-compliant messages, but its counterparty CASP either does not have compliance infrastructure yet or uses a different network. Three practical EU-side approaches:
- Multi-network membership. The CASP joins more than one Travel Rule network (TRP + Sygna + TRISA, etc.). Whichever network the counterparty uses, the message is routed.
- Counterparty due diligence + fallback. Counterparty CASP licence status (EU CASP list, FATF VASP list) is checked. If not TFR-compliant: risk-based decision — high risk = block, low risk = manual flow + extra monitoring.
- Self-hosted treatment. If the counterparty CASP does not transmit TFR-compliant messages, the EU CASP may treat the transfer as a self-hosted wallet transfer under TFR Article 14 — i.e. requiring technical verification above €1,000.
For a deeper analysis of sunrise problem strategies see our Travel Rule sunrise problem article.
TR, EU and UK Travel Rule Side-by-Side
| Topic | Turkey | EU (TFR) | UK |
|---|---|---|---|
| Legislation | MASAK communiqué | Regulation 2023/1113 | MLR 2017 (2022 amendment) + JMLSG |
| Effective | 2024 | 30 December 2024 | September 2023 |
| VASP-VASP threshold | TRY/USD 1,000 equivalent | €0 | £1,000 |
| Self-hosted threshold | TRY 1,000 equivalent | Above €1,000 — technical verification | Above £1,000 — technical verification |
| Originator data | Name + address + ID | Name + address + ID | Name + address + ID |
| Beneficiary data | Name + wallet number | Name + wallet number | Name + wallet number |
| Message format | Open (IVMS 101 recommended) | IVMS 101 (de facto) | IVMS 101 (de facto) |
For deeper TR and UK coverage see our Travel Rule by jurisdiction article. For the broader FATF Travel Rule framework see our FATF Travel Rule guide.
Implementation Roadmap for a CASP
- TFR and MiCA planned together. TFR compliance is part of a MiCA CASP application — the application package must evidence Travel Rule infrastructure.
- IVMS 101 message production and validation. Production side is relatively straightforward; validation of incoming messages (content validation) is more complex.
- Travel Rule network integration. At minimum one network (TRP or Sygna for the EU), ideally two — to widen counterparty coverage.
- Self-hosted verification flow. Message signing or micro-deposit, integrated into a customer-friendly UX.
- Counterparty due diligence process. On the first transfer with a new counterparty CASP: automatic DD — licence list query, network compliance status, jurisdiction risk.
- Monitoring + reporting. TFR breach reporting to the national FIU (e.g. FIU Germany in Germany, FCIS in Lithuania). STR on suspicious patterns.
Frequently Asked Questions
Does the €1,000 self-hosted wallet threshold include exactly €1,000?
Article 14 uses "€1,000 or above" — exactly €1,000 and above is included. €999.99 is below threshold and does not trigger technical verification. Some CASPs therefore apply a buffer (e.g. €900 or €800) to stay on the safe side.
Does TFR apply only to BTC and ETH?
No — TFR applies to all "crypto-asset" transfers. The definition matches MiCA: utility token, ART, EMT, NFT (if criteria met). In practice CASPs must implement TFR messaging for all supported chains.
How does a CASP verify that the counterparty is TFR-compliant?
Official method: query the EU CASP register (published by ESMA, listing MiCA-authorised CASPs) + national registers. Industry practice: query Travel Rule network directories (TRP directory, Sygna list). The counterparty CASP's message signing key is obtained from the network and used to verify incoming message signatures.
Are TFR and MiCA applied for in a single authorisation process?
They must be planned together. A MiCA CASP application must evidence Travel Rule infrastructure (TFR compliance) in the application package. National competent authorities (NCAs) typically request the Travel Rule integration agreement, a sample IVMS 101 message and the sunrise problem policy document.
Does TFR apply when a Turkish exchange sends to an EU CASP?
Yes, this is the EU side's rule — the EU CASP expects TFR-compliant originator data in the incoming message. Turkish exchanges' Travel Rule data collected under the MASAK framework largely meets what the EU CASP expects (structure is similar, but data quality and message format alignment are critical). In practice Turkish exchanges deploy IVMS 101 messaging; TR-EU cross-border transfers work without friction.
How Legichain Helps with TFR Compliance
TFR compliance in practice requires two things: correct message production (originator + beneficiary data, IVMS 101 format) and a practical sunrise problem solution. The Legichain Travel Rule module provides IVMS 101 messaging through a single API; with TRP, Sygna and TRISA network integrations, EU-side counterparty coverage exceeds 90%. The self-hosted wallet verification flow (message signing + micro-deposit) is calibrated to both EU and UK thresholds. Our crypto exchange solution covers the MiCA + TFR combined compliance architecture; for exchanges expanding from TR into the EU, TR-EU cross-border Travel Rule flow is a standard configuration.
