The recast Funds Transfer Regulation: building travel rule compliance into crypto asset transfers

This article is for informational purposes only and does not constitute legal advice. Consult a qualified legal professional for advice specific to your situation.

The travel rule and why applying it to crypto required a separate instrument

The travel rule in financial services originates from FATF Recommendation 16, which requires financial institutions to transmit information about the originator and beneficiary of wire transfers and to make that information available to the receiving institution. The rule was designed to ensure that the identity information collected at the point of customer due diligence travels with the funds, so that any institution in the payment chain can identify the parties to the transaction.

The EU implemented the travel rule for wire transfers through successive versions of the Transfer of Funds Regulation. The original instrument under Regulation (EU) 2015/847 covered wire transfers between payment service providers. Crypto-asset transfers were not in scope, because the regulatory framework for crypto-asset service providers did not yet exist at EU level and the peer-to-peer architecture of most crypto networks did not map cleanly onto the correspondent banking model the travel rule was designed for.

The recast Funds Transfer Regulation, Regulation (EU) 2023/1113, repeals and replaces the 2015 version and extends the travel rule to crypto-asset transfers for the first time. The extension applies to CASPs as defined under MiCA, and it entered into force on 30 December 2024 alongside the broader MiCA CASP authorisation provisions.

The legal architecture matters for understanding the compliance obligations. The recast FTR is an AML instrument. Its legal basis is the EU's anti-money laundering and counter-terrorist financing framework. MiCA is a markets and consumer protection instrument. A CASP that reads only its MiCA authorisation conditions without separately reading the recast FTR is missing a substantive regulatory layer that applies to its core product, the transmission of crypto-assets between parties.

The scope of the obligation: what transfers are covered

The recast FTR applies to crypto-asset transfers where at least one of the CASPs involved in the transfer is established in the EU. For the purpose of the regulation, a CASP processes a crypto-asset transfer when it executes the movement of crypto-assets from one distributed ledger address or account to another, on behalf of a customer.

The scope includes:

Transfers between two CASPs, including transfers where the originator's CASP and the beneficiary's CASP are the same entity (internal transfers between accounts held by different customers at the same CASP).

Transfers from a CASP to a self-hosted wallet, and transfers from a self-hosted wallet to a CASP, where the transfer amount equals or exceeds EUR 1,000 or the equivalent in another currency.

The scope excludes transfers that are purely technical in nature and do not result in a change of beneficial ownership, including transfers executed for settlement netting, certain intragroup transfers, and the technical movement of crypto-assets that does not represent a customer instruction.

The distinction between a self-hosted wallet and a hosted wallet at another CASP is operationally significant because the obligations it generates differ. A transfer to a wallet hosted at a regulated CASP in a FATF-equivalent jurisdiction generates travel rule exchange obligations between two regulated entities. A transfer to a self-hosted wallet generates an enhanced due diligence obligation under the regulation's self-hosted wallet provisions, regardless of the transfer amount when the amount is EUR 1,000 or above.

The data payload: what must be transmitted

The information required to accompany a crypto-asset transfer under the recast FTR is set out in the regulation text and detailed in the EBA guidelines on the technical standards for information accompanying transfers of funds and certain crypto-assets, developed under Article 36 of the regulation.

The required information differentiates by transfer type, transfer size, and counterparty type.

Transfers between CASPs

For all transfers between CASPs, the originator's CASP must transmit to the beneficiary's CASP the full information set specified in Article 14 of the regulation. Unlike the wire transfer provisions of the recast FTR, the crypto-asset travel rule does not establish a reduced-information regime below a EUR 1,000 threshold: Article 14 applies the same information requirements to all crypto-asset transfers between CASPs regardless of amount.

Originator information required in the transfer message:

The originator's full legal name, their distributed ledger address for the transaction, and their account number at the originator CASP (which may be the same as the distributed ledger address or a separate internal account identifier). For natural persons, the full name means given name and family name in full. For legal entities, it means the full legal entity name without abbreviation.

At least one of the following: the originator's national identification number, customer identification number used by the originator CASP, date and place of birth, or, for legal entities, the registered address and registration number. The choice of which identifier is transmitted is determined by what the originator's CASP has collected during KYC, but the identifier must be one that allows the beneficiary's CASP to perform a meaningful check.

Beneficiary information required in the transfer message:

The beneficiary's full legal name and their distributed ledger address or account number at the beneficiary CASP.

The beneficiary information must be transmitted in the same message as the originator information; it cannot follow the transfer execution. The recast FTR does not permit a model where the transfer executes and the travel rule information is transmitted separately.

Transfers involving self-hosted wallets

The self-hosted wallet provisions in the recast FTR are the area where the compliance obligation most significantly diverges from the correspondent CASP model.

Where a customer instructs a transfer from their CASP account to a self-hosted wallet, and the amount is EUR 1,000 or above, the CASP must:

Collect from the customer the name of the person who owns or controls the self-hosted wallet. Where the wallet is the customer's own, the customer attests this. Where the wallet belongs to a third party, the CASP must collect the third party's name and the customer's explanation of their relationship with that third party.

For transfers above EUR 1,000 to self-hosted wallets where the CASP assesses that the transfer presents a higher risk, apply enhanced measures. The EBA guidelines specify risk indicators for self-hosted wallet transfers that trigger the enhanced measures obligation, including the use of privacy-enhancing technologies in the wallet's transaction history, transfer patterns inconsistent with the customer's stated purpose, and address characteristics associated with mixing or tumbling services.

The obligation for inbound transfers from self-hosted wallets follows a symmetric structure: the CASP receiving the transfer must collect information about the originating wallet and apply the same risk assessment framework.

The cross-border matching problem

The travel rule's fundamental operational challenge is that it requires two regulated entities to exchange structured data in real time around an underlying crypto-asset transfer. In the correspondent banking context, SWIFT messaging protocols provide the infrastructure for this exchange. In crypto-asset transfers, there is no single messaging protocol that all CASPs use, and the global travel rule framework is implemented through a combination of technical solutions built by Travel Rule protocol vendors, bilateral agreements, and industry association frameworks.

When both the originator's CASP and the beneficiary's CASP are EU-regulated entities, the compliance framework is symmetric: both are subject to the recast FTR, both understand the data fields required, and the exchange can take place through whichever Travel Rule messaging solution both support.

When the beneficiary's CASP is established in a third country, the symmetry breaks.

FATF-equivalent third countries. Where the beneficiary's CASP is established in a jurisdiction that FATF has assessed as having implemented Recommendation 16 to an equivalent standard, the EU CASP can treat the exchange as a peer-to-peer travel rule interaction. The data fields expected by the third-country CASP may differ from the recast FTR's schema, and the EU CASP's outbound message may need to be adapted to the receiving jurisdiction's requirements. In practice, this means the EU CASP's Travel Rule messaging solution needs to support schema translation between the recast FTR format and the formats used by major third-country jurisdictions, including VASP versions of the FATF standard implemented in Singapore, the UK, Switzerland, and the United States.

Non-equivalent third countries. Where the beneficiary's CASP is established in a jurisdiction without an equivalent travel rule framework, the recast FTR's missing information procedure applies. The EU originator's CASP must transmit the travel rule information to the extent possible, and if it cannot receive confirmation that the beneficiary's CASP has received and retained the information, it must consider whether the transfer presents an elevated AML risk and whether it should proceed.

The missing information procedure is not a compliance exception; it is a set of additional obligations that apply when the normal peer-to-peer exchange fails. For EU CASPs with significant customer activity involving jurisdictions without equivalent travel rule frameworks, the missing information procedure can generate a material volume of escalations that must be handled through the compliance function rather than automated through the data pipeline.

The EBA guidelines: field-level specifications

The EBA guidelines published under Article 36 of the recast FTR provide the field-level specification that the regulation text alone does not supply. These guidelines function similarly to the RTS under the AML Regulation: the regulation establishes the obligation and the broad information categories, and the technical standards specify how the information must be structured, validated, and transmitted.

The key field-level specifications in the guidelines address:

Name format. The guidelines specify that full legal name must be transmitted without abbreviation and in a format that allows meaningful matching. For the beneficiary's CASP, the name received in the travel rule message must be checked against the name on the beneficiary's account. A name transmitted in an abbreviated or partial form that does not allow this check to be performed is not compliant with the guidelines.

Distributed ledger address format. The address field must contain the distributed ledger address actually used in the transaction, not a wallet label or internal account reference. For transfer architectures that use batch settlement or address aggregation at the technical layer, this means the compliance data pipeline must be able to map the settlement address back to the specific transaction and customer.

Timestamp and transaction reference. The guidelines require the travel rule message to include a timestamp and a unique transaction reference that links the information message to the underlying on-chain transfer. This is the data field that allows the beneficiary's CASP to perform the matching check: receiving the travel rule information for a transaction it has not yet seen on-chain, or receiving it for a transaction that cannot be matched by reference and timestamp, creates a compliance gap.

Missing information escalation format. Where a CASP receives a transfer without the required travel rule information, or with information that fails the matching check, the guidelines specify what the receiving CASP must do: retain the transfer in a pending state, attempt to obtain the missing information from the originator's CASP, and escalate to the compliance function if the information cannot be obtained within the timeframe the CASP's internal procedures define. The escalation must be documented in a structured record that supports subsequent supervisory review.

Where the MiCA and recast FTR obligations interact

The regulatory status of a CASP under MiCA and its travel rule obligations under the recast FTR are governed by different instruments with different supervisory chains. Understanding where they interact and where they run independently is essential for building a compliance architecture that addresses both without conflating them.

Shared customer identification foundation. The CDD performed under the AML Regulation (which incorporates the recast FTR's customer identification requirements by reference) is the source of the originator and beneficiary information that populates the travel rule message. A gap in CDD produces a gap in the travel rule data. For the originator's CASP, this means the standard and enhanced CDD schema must include all the fields the travel rule message requires as a mandatory population condition.

Divergent supervision. A CASP's MiCA authorisation and ongoing compliance with MiCA conduct obligations are supervised by the NCA in its MiCA capacity, or by ESMA for significant CASPs. The same CASP's travel rule compliance under the recast FTR is supervised by the NCA in its AML/CFT capacity, which may involve a different team, a different examination cycle, and a different enforcement pathway. A CASP that presents separate compliance programmes to the two supervisory functions, with consistent data at the source but separate reporting and escalation structures, is better positioned than one that treats the two frameworks as a single integrated system where a gap in one automatically propagates to the other.

The self-hosted wallet: overlapping obligations from different instruments. The recast FTR's own provisions on self-hosted wallet transfers, set out in Article 14(5) and the new Article 19a inserted into Directive (EU) 2015/849 by Article 38 of Regulation 2023/1113, specify the information collection and transmission requirements for self-hosted wallet transfers. CASPs must implement policies and procedures to identify transfers involving self-hosted wallets and apply appropriate risk-based measures. These obligations arise directly from the recast FTR and its amendments to the 4AMLD framework, and a compliant architecture must address them in full.

The reverse solicitation and geographical scope question. The recast FTR applies when at least one CASP in the transfer chain is EU-established. A CASP established outside the EU that receives a transfer from an EU CASP is not itself subject to the recast FTR, but the EU CASP sending the transfer must comply with the originator obligations regardless of the counterparty's jurisdiction. For non-EU CASPs considering whether they need to establish an EU presence, this creates an asymmetric obligation: receiving transfers from EU CASPs triggers no EU travel rule obligations on the non-EU CASP, but providing services to EU customers in a way that constitutes solicitation brings MiCA and potentially the recast FTR into play. See MiCA's reverse solicitation trap for non-EU CASPs for the scope analysis.

Building a compliant travel rule data pipeline

A compliant travel rule data pipeline has five components that must function together.

CDD-to-travel-rule data bridge. The KYC profile collected during onboarding must map to the specific fields required in the travel rule message without manual extraction. For natural person customers, this means first name, family name, and at least one additional identifier from the permitted set, stored in fields that a travel rule message composer can query directly. For legal entity customers, it means full entity name without abbreviation and the entity's registration number or registered address. Profiles that store name in a single free-text field that cannot be split into given name and family name without parsing create a systematic travel rule data quality problem.

Transfer classification logic. Before a transfer message is composed, the pipeline must classify the transfer: CASP-to-CASP or involving a self-hosted wallet; above or below the EUR 1,000 self-hosted wallet threshold; domestic or cross-border; counterparty in a FATF-equivalent jurisdiction or not. The classification determines which information fields are required and which protocol the outbound message should use.

Travel rule protocol integration. The outbound message must be transmitted through a protocol that the beneficiary's CASP can receive and process. There is no single mandated protocol under the recast FTR, and the major Travel Rule messaging solutions, including TRUST, Notabene, Sygna Bridge, and VerifyVASP, each have different geographic coverage among CASP participants. For EU CASPs with broad cross-border transfer activity, integration with multiple Travel Rule protocols, or with an aggregation layer that abstracts protocol selection, is a practical requirement.

Inbound verification and matching. When a travel rule message is received for an inbound transfer, the pipeline must perform the matching check: does the originator and beneficiary information in the message match the KYC data held for the beneficiary customer? The matching logic must handle name variation, transliteration differences, and the range of permitted identifier types. A matching failure must generate a structured escalation, not a silent discard of the transfer.

Missing information handling and documentation. For transfers that arrive without travel rule information, or where the matching check fails and the information cannot be resolved, the pipeline must generate a documented escalation record that captures what information was received, what check was performed, what was missing, and what action was taken. This record is the supervisory artifact. A missing information escalation that is resolved by proceeding with the transfer without documenting the resolution creates an audit gap.

What to watch in the second half of 2026 and into 2027

The EBA guidelines on the recast FTR are the primary technical reference for travel rule compliance. These guidelines are subject to revision as EBA observes implementation in practice and addresses interpretive questions through its Q&A function.

The self-hosted wallet risk indicator framework in the guidelines is an area where supervisory expectations are likely to develop. As NCA AML examinations of CASP travel rule compliance begin in earnest through 2026 and 2027, the adequacy of CASPs' self-hosted wallet risk assessment procedures will be tested, and findings from those examinations will inform guidance updates.

The international Travel Rule interoperability question, specifically the treatment of transfers involving jurisdictions that have not yet implemented FATF Recommendation 16, is an ongoing regulatory development area. FATF's mutual evaluation cycle continues to generate new assessments, and the EU's own high-risk third country list may intersect with the recast FTR's missing information procedure in ways that need to be addressed as both instruments are applied in practice.

AMLA's supervisory coordination mandate includes AML/CFT supervision of CASPs once the CASP-specific provisions of its mandate are activated. The timeline and scope of AMLA's engagement with CASP AML supervision is an area that compliance teams building travel rule programmes should monitor alongside their MiCA authorisation obligations.

Forseti monitors recast FTR implementation, EBA travel rule guidelines, and AMLA supervisory developments continuously, anchored to verified official sources. Start for free.

For the MiCA authorisation framework within which travel rule obligations sit, see MiCA for crypto asset service providers: what authorisation actually requires. For the AML Regulation customer due diligence schema that feeds the travel rule data pipeline, see structuring KYC profiles for the AMLA single rulebook: Level 2 RTS requirements. For the stablecoin-specific MiCA obligations, see MiCA and stablecoins: what issuers need to know.