EU Travel Rule for Crypto: TFR 2023/1113 and Self-Hosted Wallet Rules

What the Travel Rule actually requires

Regulation (EU) 2023/1113 — the Transfer of Funds Regulation, or TFR — is the EU’s implementation of FATF Recommendation 16, requiring originator and beneficiary information to accompany transfers of funds and crypto-assets. The Regulation entered into force on 29 June 2023 and became applicable to CASPs from 30 December 2024 — the same date Title V of MiCA started applying.

The TFR rebuilds the prior Funds Transfer Regulation (Regulation (EU) 2015/847) to cover crypto-assets and extends information obligations to CASPs that act as either originator or beneficiary in a crypto-asset transfer. The EBA published implementing guidelines (EBA/GL/2024/11) on 4 July 2024 detailing how CASPs should operationalise the rule.

The headline message for CASPs: the Travel Rule is binary on CASP-to-CASP transfers (zero threshold) and introduces a €1,000 threshold for self-hosted-wallet ownership verification. Both are operational from 30 December 2024.

What information must accompany a transfer?

TFR’s originator-information rule of the TFR sets out the originator CASP’s obligation. Every transfer of crypto-assets must include:

About the originator (TFR’s originator-information rule (paragraphs 1-2)):

• Name
• Distributed ledger address (where the transfer is registered on a DLT) or account number
• Plus additional originator information — address, official personal document number, customer identification number, OR (alternatively) date and place of birth

About the beneficiary (TFR’s originator-information rule (paragraph 1)):

• Name
• Distributed ledger address (where the transfer is registered on a DLT) or account number

The originator CASP must transmit this information to the beneficiary CASP using a secure messaging channel. The Regulation does not prescribe a specific protocol — the market has converged on Notabene, Sumsub Travel Rule, the TRP (Travel Rule Protocol) and a small number of point-to-point bilateral arrangements. The EBA guidelines accept any protocol that meets the security and integrity requirements.

What does the beneficiary CASP do with incoming transfers?

TFR’s intermediary-CASP rule sets out the beneficiary CASP’s obligation. The beneficiary CASP must:

1. Detect transfers arriving with missing or incomplete originator/beneficiary information
2. Apply effective risk-based procedures to determine how to handle them
3. Take the appropriate follow-up action under TFR’s incomplete-transfer handling rule

TFR’s incomplete-transfer handling rule specifies the four follow-up actions:

• Execute — proceed with the transfer if the risk assessment allows
• Reject — decline to make the transferred crypto-assets available to the beneficiary
• Return — return the crypto-assets to the originator CASP
• Suspend — temporarily hold the transfer while requesting the missing information

The choice among these is risk-driven, not discretionary. A high-risk gap (e.g. originator name absent on a large transfer from a higher-risk jurisdiction) typically requires reject or suspend; a lower-risk gap might support execute with documented rationale. Supervisors expect a documented decision-making framework for these calls.

How does the self-hosted wallet rule work?

Self-hosted wallets — wallets where the user holds the private keys directly, not at a CASP — receive specific treatment under the TFR. The rule has two layers:

Below €1,000: The CASP collects originator and beneficiary information for transfers to/from self-hosted wallets, but is not required to use technical means (chain analytics, signed-message proof, micro-transfer verification) to verify that the customer actually owns or controls the self-hosted address. Information collection only.

Above €1,000: The CASP must take additional steps to verify whether its customer owns or controls the self-hosted address involved in the transfer. The Regulation does not prescribe the verification method; in practice the market options are:

• Signed-message proof — the customer signs a message from the self-hosted wallet that proves control
• Micro-transfer verification — the customer sends a small (sub-threshold) test transfer that confirms control
• Chain-analytics-driven heuristics — pattern analysis suggesting customer ownership

Each option has trade-offs in user experience, technical reliability, and supervisory acceptance. The EBA guidelines accept any verification method that delivers reliable evidence of customer control.

The €1,000 threshold is one of very few quantitative figures in the TFR. CASPs whose customer profile skews toward high-net-worth users with self-hosted wallets effectively operate above the threshold most of the time, making the verification workflow part of routine onboarding rather than an exception path.

What’s out of scope?

The Travel Rule does not cover:

• Peer-to-peer transfers between two self-hosted wallets without CASP involvement on either side
• Transfers within the same CASP’s customer base (intra-CASP), since both originator and beneficiary information is held by the single CASP — though internal AML monitoring still applies
• Transfers below €1,000 to/from self-hosted wallets for the verification step (information collection still applies)

The first carve-out is what enables genuine peer-to-peer crypto-asset use to continue without CASP intermediation. The TFR is a CASP-focused regulation, not a general crypto-asset rule.

How does the Travel Rule interact with CASP outsourcing?

Many CASPs outsource Travel Rule compliance to specialist providers (Notabene, Sumsub, TRM Labs, etc.). The arrangement is permitted under MiCA’s outsourcing rules but subject to the standard outsourcing discipline:

• The outsourcing must be set out in writing
• The CASP retains responsibility for Travel Rule compliance — the outsourcing does not delegate liability
• The outsourcing arrangement is recorded in the CASP’s outsourcing register and (where the provider is an ICT third party) the DORA register of information
• Material outsourcing arrangements are notifiable to the home competent authority

The practical effect: outsource the technical implementation; retain the supervisory accountability and the internal capacity to oversee what is outsourced.

Working with counsel and compliance vendors on TFR architecture

The diagnostic for counsel and compliance vendors is whether they can describe the specific risk-based decision framework their architecture supports for TFR’s incomplete-transfer handling rule follow-up actions, and how they handle the self-hosted-wallet €1,000 threshold operationally. Generic answers about “Travel Rule compliance” mask a significant gap between vendors that have built the compliance workflow and those that ship the messaging layer alone.

The firms in our index with relevant TFR-implementation experience are listed below.