EU Travel Rule (TFR) for Casps: Practical, Lawyer‑led Compliance Guide

The crypto travel rule EU framework anchored in Regulation (EU) 2023/1113 (the “Transfer of Funds Regulation” or TFR) imposes binding obligations on crypto-asset service providers (CASPs) to collect, verify and transmit originator and beneficiary information whenever crypto-asset transfers take place. For compliance officers, in-house counsel, CTOs and founders operating across the European Union, understanding these obligations is no longer optional: it is a condition of licensing, ongoing supervision and market access under the broader MiCA ecosystem.

This guide provides a lawyer-led, practical walkthrough of TFR compliance for CASPs from legal-framework mapping and data-field cataloguing to self-hosted wallet risk controls, thresholds and a ready-to-use implementation checklist.

Who this guide is for

This article is designed for compliance officers at licensed or licence-applicant CASPs, in-house legal teams advising on EU crypto operations, CTOs and founders building travel-rule-compliant infrastructure, and external compliance consultants scoping advisory engagements.

What this guide covers and what it does not

The guide addresses TFR obligations under Regulation (EU) 2023/1113, the mapping of FATF Travel Rule principles into EU law, MiCA interaction, required data fields and verification steps, self-hosted wallet checks, thresholds and exemptions, and a step-by-step implementation checklist. It does not constitute jurisdiction-specific legal advice for any single EU member state, nor does it cover third-country equivalence assessments in detail.

Key takeaways at a glance:

• Binding EU obligation: The TFR applies directly to all CASPs operating in the EU no national transposition is required.
• No de minimis for crypto: Unlike traditional wire transfers, the TFR eliminates the EUR 1 000 de minimis threshold for crypto-asset transfers.
• MiCA overlay: MiCA licensing and conduct rules do not replace TFR obligations but add governance, consumer-protection and supervisory-reporting requirements on top.
• Self-hosted wallet risk: Transfers involving unhosted addresses attract enhanced due-diligence requirements and on-chain verification expectations.
• Supervisory readiness: National competent authorities are actively inspecting CASPs’ travel-rule evidence trails as part of licence reviews and ongoing supervision.

Background and Legal Framework: From FATF to TFR to MiCA

The FATF Travel Rule core principle

The Financial Action Task Force (FATF) first extended its “Travel Rule” (Recommendation 16) to virtual-asset service providers (VASPs) through its Guidance for a Risk-Based Approach to Virtual Assets and VASPs. The core principle requires that originator and beneficiary information “travel” alongside or immediately before a transaction, enabling intermediaries and law enforcement to trace funds and identify parties. FATF guidance contemplates risk-based approaches (RBA) allowing supervisors and VASPs some flexibility in applying checks to lower-value or lower-risk transfers.

Regulation (EU) 2023/1113 (TFR) where it sits in EU law

The Transfer of Funds Regulation transposes the FATF Travel Rule into directly applicable EU law. Published in the Official Journal in June 2023, the TFR applies to “transfers of funds” and critically to “transfers of crypto-assets.” It defines key concepts including “originator,” “beneficiary,” “payment service provider” and “crypto-asset service provider,” and it imposes mandatory data-transmission and verification obligations on CASPs regardless of transaction value. Notably, the Regulation removes any de minimis exemption for crypto-asset transfers, a stricter position than the FATF baseline, which permits risk-based flexibility for low-value transfers.

MiCA interaction licensing and conduct overlay

The Markets in Crypto-Assets Regulation (MiCA) establishes the licensing, governance and consumer-protection framework for CASPs across the EU. While MiCA does not duplicate travel-rule transmission obligations, it creates the supervisory infrastructure within which TFR compliance is monitored. A CASP that fails to demonstrate adequate TFR compliance may face licence refusal or conditions, and MiCA’s ongoing-supervision and record-keeping requirements reinforce the TFR’s audit-trail expectations. The practical effect is that MiCA compliance for CASPs and TFR compliance are operationally inseparable.

Supervisory developments 2026 guidance

During 2025 and 2026, the European Banking Authority (EBA) and national competent authorities including Germany’s BaFin have sharpened expectations around travel-rule evidence standards, verification timelines for counterparty CASPs, and the treatment of self-hosted wallets. Industry observers expect further harmonisation as supervisory convergence tools under MiCA mature. Compliance teams should monitor EBA opinions and national authority publications for updates on enforcement priorities and inspection methodologies.

Step-by-Step Implementation for CASPs: The Crypto Travel Rule EU Process

The following ten operational steps provide CASPs with a structured path from regulatory mapping to supervisory readiness. Each step corresponds to obligations under the TFR and practical expectations from national supervisors.

Step 1 Governance and Legal Mapping

Begin by mapping every service your CASP offers custody, exchange, transfer, off-ramp against the definitions in Regulation (EU) 2023/1113 and MiCA. Identify which transfer flows are captured by the TFR (all crypto-asset transfers where at least one CASP is involved). Assign a named senior officer with documented responsibility for TFR compliance, and embed travel-rule governance into your existing AML/CFT framework and board-level reporting.

Step 2 Data-Field Catalogue and Wire Mapping

Create a canonical internal schema defining every originator and beneficiary data field required under the TFR (see the detailed field list in the next section). Decide on transmission formats JSON, XML or proprietary protocol and define API endpoints for inter-CASP communication. Standardise field names, encoding and validation rules to ensure interoperability. Document the schema version and change-management process so that updates triggered by regulatory guidance can be tracked and audited.

Step 3 Source Verification and KYC Linkage

Every transmitted data field must be linked to an underlying KYC record. Verify the source of originator and beneficiary information against your customer due-diligence files. Establish procedures for flagging mismatches for instance, where an on-chain wallet address does not correspond to any verified customer. Build audit trails that demonstrate, for any given transfer, the evidentiary chain from transmitted data to KYC documentation. Retain these records in accordance with the retention periods specified in both the TFR and applicable national AML legislation.

Step 4 Counterparty Discovery and Endpoint Routing

Before transmitting data, determine whether the counterparty is a regulated CASP, an unregulated entity, or a self-hosted wallet. Use available registries (e.g., national CASP registers, ESMA registers under MiCA), VASP discovery protocols and internal screening workflows. Where the counterparty is a licensed CASP, establish a secure messaging endpoint. Where the recipient address cannot be attributed to a regulated provider, classify the transfer as involving a self-hosted wallet and route it through your enhanced due-diligence workflow.

Step 5 Transmission Mechanics and Secure Messaging

Transmit originator and beneficiary data to the counterparty CASP using an encrypted, authenticated channel. Ensure replay protection, delivery receipts and error-handling procedures are in place. Where transmission fails or is rejected, log the error, apply risk-based hold procedures and escalate as necessary. Record round-trip proofs (RTPs) timestamps, message hashes and delivery confirmations as supervisory evidence. Consider interoperability with industry messaging standards (e.g., IVMS101, OpenVASP or proprietary protocols) while ensuring compliance with the specific field requirements of the TFR.

Step 6 Thresholds, Exemptions and Decision Logic

Implement a rules engine that applies the TFR’s threshold and exemption logic to each transfer. Under Regulation (EU) 2023/1113, there is no de minimis threshold for crypto-asset transfers all transfers involving a CASP must carry originator and beneficiary data. However, internal transfers (within the same CASP) and certain payment-service-provider flows may benefit from reduced requirements. Document the rationale for every exemption decision and log the rule-engine output for supervisory inspection.

Step 7 Self-Hosted Wallet Risk Controls and Enhanced Due Diligence

When a transfer involves a self-hosted (unhosted) wallet, apply enhanced risk controls. Run on-chain heuristics address clustering, provenance tracing, interaction history with known regulated CASPs to assess risk. Where the risk score exceeds your internal threshold, request supplementary information from your customer (e.g., proof of ownership of the receiving address). Establish clear escalation paths: where adequate information cannot be obtained, consider suspending the transfer and filing a suspicious-transaction report.

Step 8 Testing, Monitoring and Supervisory Evidence

Before going live, conduct staging tests with counterparty CASPs to validate end-to-end data transmission, receipt handling and error recovery. Execute sample transmissions using synthetic data and retain test logs. After deployment, implement continuous monitoring alert on transmission failures, data-field validation errors and latency anomalies. Compile a supervisory evidence pack comprising test reports, sample payloads (redacted) and third-party attestation reports where available.

Step 9 Contracts, Information-Sharing Agreements and MOUs

Formalise data-sharing arrangements with counterparty CASPs through bilateral agreements or memoranda of understanding. Specify SLAs for transmission response times, data-field completeness and error resolution. Address data-protection obligations conduct a Data Protection Impact Assessment (DPIA) covering the personal data transmitted and retained and align contractual terms with GDPR requirements.

Step 10 Training, Policy Updates and Continuous Improvement

Roll out targeted training for compliance, operations and engineering staff on TFR obligations, transmission workflows and escalation procedures. Update internal policies at least annually and whenever EBA or national competent authority guidance materially changes. Map training records and policy versions to MiCA licence conditions to demonstrate ongoing compliance.

Required Data Fields and Verification Steps

Authorised canonical field list originator and beneficiary

Under the TFR, the originator’s CASP must ensure that the following information accompanies or is made available in connection with each crypto-asset transfer:

Originator fields:

• Full name: The legal name of the originator (natural or legal person).
• Account number / on-chain address: The crypto-asset account or distributed-ledger address from which the transfer is initiated.
• Originator’s address, official personal document number, customer identification number, or date and place of birth: At least one additional identifier as specified by the TFR.
• Originator institution identity: The identity of the originator’s CASP (including LEI or equivalent identifier where available).

Beneficiary fields:

• Full name: The legal name of the beneficiary.
• Account number / on-chain address: The crypto-asset account or distributed-ledger address of the beneficiary.
• Beneficiary institution identity: The identity of the beneficiary’s CASP (if applicable).

Additional fields transaction identifier, transaction value, currency and timestamp are operationally essential for matching, reconciliation and supervisory review, even where not all are explicitly enumerated as “required” data in the TFR text.

Data format examples illustrative JSON mapping

The following is a simplified, non-sensitive illustration of how a CASP might structure travel-rule data in JSON format, aligned with IVMS101 naming conventions:

{
 "originator": {
 "naturalPerson": {
 "name": "Jane Müller",
 "accountNumber": "0x1a2b3c...originator",
 "dateOfBirth": "1990-05-12",
 "countryOfResidence": "DE"
 }
 },
 "beneficiary": {
 "naturalPerson": {
 "name": "Marco Rossi",
 "accountNumber": "0x4d5e6f...beneficiary"
 }
 },
 "originatorCASP": {
 "name": "CASPAlpha GmbH",
 "lei": "5299001ABC..."
 },
 "beneficiaryCASP": {
 "name": "CASPBeta SRL",
 "lei": "5299002DEF..."
 },
 "transactionId": "txn-uuid-12345",
 "amount": "1500.00",
 "currency": "USDC",
 "timestamp": "2026-08-10T14:32:00Z"
}

This schema is illustrative only. CASPs should adopt whichever interoperability protocol their counterparties support, while ensuring all TFR-mandatory fields are populated.

Verification steps KYC linking and evidence

For transfers between CASPs, the receiving CASP must verify that the incoming data set is complete and internally consistent. Verification may include certificate-of-licence checks (confirming the sending CASP is authorised under MiCA or a comparable regime), domain or institution-identifier validation, and cryptographic assertions (e.g., signed JWT tokens) confirming institutional identity. For self-hosted addresses, the sending CASP must apply risk-based checks transaction-history review, clustering heuristics and, where the risk threshold is exceeded, a request for additional information from the customer.

Recordkeeping and retention audit-ready trails

CASPs must retain transmitted payloads, verification evidence and KYC-linkage logs for a minimum period consistent with EU AML legislation typically five years from the date of the transfer. Hashing transmitted payloads (e.g., SHA-256) preserves integrity for supervisory review without requiring the storage of duplicated plaintext data. Logs should include transmission timestamps, counterparty acknowledgements, error records and any escalation decisions.

Self-Hosted Wallet Checks and KYT Integration

When an address is “self‑hosted” vs CASP‑controlled

An address is self-hosted (or “unhosted”) when it is not controlled by or attributed to a regulated CASP. In practice, CASPs determine hosting status through counterparty-discovery protocols: if an address cannot be matched to a registered CASP in available registries, it is treated as self-hosted. This classification triggers enhanced obligations under the TFR.

Practical checks on-chain heuristics and provenance

CASPs should deploy Know-Your-Transaction (KYT) tools to assess address risk. Practical checks include address clustering (identifying address groups controlled by a single entity), provenance tracing (the chain of prior transactions), interaction history with known regulated CASPs and interaction with sanctioned or darknet-associated addresses. These heuristics inform the risk score assigned to each self-hosted-wallet transfer.

Escalation and EDD when interacting with self-hosted wallets

When risk scoring exceeds the CASP’s internal threshold, enhanced due diligence (EDD) must be applied. This may include requesting the customer to prove ownership of the self-hosted address (e.g., through a signed message), obtaining a declaration of the purpose of the transfer, or in the most elevated cases suspending the transaction and filing a suspicious-transaction report with the relevant Financial Intelligence Unit.

Thresholds, Exemptions and Comparative Table

EU-specific thresholds

The TFR notably eliminates the EUR 1 000 simplified-due-diligence threshold for crypto-asset transfers that applies to traditional fund transfers. All crypto-asset transfers involving at least one CASP require the transmission of originator and beneficiary data, regardless of value. National competent authorities may, however, provide additional guidance on the practical application of risk-based verification intensity for lower-value transfers.

Decision-logic examples

Key Requirements, Eligibility and Supervisory Expectations

Minimum governance, technical and operational controls

Supervisors expect CASPs to demonstrate documented policies and procedures, an assigned compliance officer with TFR responsibility, a tested technical transmission system, recorded verification workflows and an evidence-retention framework. During inspections, sample payloads, KYC-linkage logs, test-transmission records and staff training certifications are commonly requested.

Licensing considerations under MiCA

Travel-rule compliance is a practical prerequisite for MiCA licensing. Applicants should expect competent authorities to assess the adequacy of their TFR controls as part of the licence-application review. Post-authorisation, ongoing supervisory reporting and inspection frameworks treat travel-rule compliance as a core operational metric.

Penalties and enforcement trends

MiCA empowers national competent authorities to impose administrative penalties and remedial measures on CASPs that fail to comply with TFR obligations. While penalty regimes vary across member states, the direction of travel is clearly toward escalating enforcement. BaFin and other national supervisors have signalled that travel-rule deficiencies will be treated as material compliance failures.

Comparison Table TFR vs FATF Travel Rule vs MiCA Obligations

Implementation Checklist

The following checklist is designed for in-house compliance and legal teams preparing for TFR readiness. It can be adapted to any EU jurisdiction.

Editorial Notes Next Steps with GLE Legal Partners

Global Law Experts works with specialist legal partners across EU jurisdictions who advise CASPs on scoped TFR advisory engagements, jurisdictional legal opinions, supervisory-defence preparation and MiCA licence applications. When engaging counsel through GLE, CASPs should expect to provide a current system-architecture diagram, sample transfer-flow documentation, existing KYC/AML policies, MiCA licence status or application timeline, and details of any prior supervisory correspondence. These materials enable efficient scoping and ensure advisory output is tailored to the CASP’s specific operational and regulatory position.

Sources

• Regulation (EU) 2023/1113 Transfer of Funds Regulation (TFR), Official Journal of the European Union
• FATF Guidance for a Risk-Based Approach to Virtual Assets and VASPs (2021), Financial Action Task Force
• European Banking Authority (EBA) Opinions, FAQs and Supervisory Guidance
• European Commission Markets in Crypto-Assets (MiCA) Framework
• BaFin Crypto Assets Supervisory Guidance, German Federal Financial Supervisory Authority