For an EU crypto business, Travel Rule compliance is no longer a future implementation project.
Regulation (EU) 2023/1113 has applied since 30 December 2024 and requires crypto-asset service providers, or CASPs, to make specified originator and beneficiary information travel with crypto-asset transfers. The rules sit alongside MiCA and form part of the wider EU anti-money laundering and counter-terrorist financing framework. (EUR-Lex)
The difficult part is not understanding the principle. It is turning it into a working transaction process.
A CASP needs to know what information to collect, when to transmit it, what to do when another provider sends incomplete data, how to handle self-hosted wallets and how to integrate all of this with AML, sanctions, GDPR and transaction monitoring.
This guide explains what the EU crypto Travel Rule requires and what a compliant implementation should look like in practice.
What is the crypto travel rule?
The Travel Rule is an AML/CFT measure designed to preserve information about the people sending and receiving assets as those assets move between financial service providers.
Internationally, the concept comes from the Financial Action Task Force, or FATF. FATF extended its payment transparency requirements to virtual assets and VASPs, requiring providers to obtain, hold and transmit specified originator and beneficiary information when processing virtual-asset transfers. FATF updated Recommendation 16 again in 2025 as part of a broader revision of payment-transparency standards. (FATF)
In the EU, the operative rules for crypto transfers are contained in Regulation (EU) 2023/1113 on EUR-Lex, commonly referred to as the Transfer of Funds Regulation or TFR.
There is an important terminology distinction. FATF generally uses VASP, or virtual asset service provider. EU law now uses CASP, or crypto-asset service provider, following the terminology introduced by MiCA.
The commercial effect is straightforward: a crypto transfer can no longer be treated as only a blockchain transaction. When a CASP is involved, regulated identity information has to travel through the compliance layer as well.
What information must accompany a crypto transfer?
The originator’s CASP must ensure that the transfer is accompanied by prescribed information about both the originator and beneficiary.
For the originator, this can include:
• name;
• distributed ledger address where applicable;
• crypto-asset account number where applicable;
• address and country;
• official personal document and customer identification information, or alternatively date and place of birth;
• LEI or another equivalent official identifier where applicable.
For the beneficiary, the required information includes the name, relevant distributed ledger address or crypto-asset account number, and certain official identifiers where applicable. (EUR-Lex)
The data must be transmitted before, simultaneously with or concurrently with the crypto transfer, through a secure mechanism compliant with applicable data-protection requirements.
Crucially, the personal information does not have to be written onto the blockchain or directly embedded into the crypto transaction. (EUR-Lex)
That distinction matters. Travel Rule compliance requires an information-exchange layer around the transfer, not publication of customer identity data on a public ledger.
The €1,000 threshold does not mean what many CASPs think
One of the most important implementation points is the threshold.
The EU crypto Travel Rule generally applies to covered crypto transfers where a CASP is involved. There is no general €1,000 exemption below which CASPs can ignore the Travel Rule.
The €1,000 threshold becomes particularly relevant when dealing with self-hosted addresses.
Where a customer sends more than €1,000 to a self-hosted address, the originator’s CASP must take adequate measures to assess whether that address is owned or controlled by the originator. Corresponding requirements apply to the beneficiary’s CASP for transfers exceeding €1,000 coming from a self-hosted address. (EUR-Lex)
This distinction should be built directly into transaction rules.
A system that simply applies the Travel Rule only above €1,000 is therefore implementing the EU framework incorrectly.
What CASPs must implement in practice
Buying a Travel Rule software solution is not the same as implementing Travel Rule compliance.
The regulation affects the complete transaction workflow, from customer onboarding to transfer execution and post-transaction monitoring.
1. Determine the Type of Counterparty
Before processing a transfer, the CASP needs to determine whether the destination or source involves:
• another CASP;
• an intermediary CASP;
• a self-hosted address;
• or a transaction that falls outside the scope of the TFR.
That classification determines how the required information is obtained and exchanged.
2. Collect and Validate the Required Data
Customer onboarding and transaction systems must capture the information required by the TFR.
This should not be treated as a one-time KYC exercise. Transaction systems need to identify whether the relevant data is present and sufficiently complete for the specific transfer.
3. Transmit the Information Securely
CASPs need a mechanism for exchanging Travel Rule information with counterparties.
The TFR does not require this information to be placed directly onto the blockchain. Data should instead be exchanged securely and in a way that respects GDPR requirements. FATF itself remains technology-neutral and does not prescribe one specific technical solution. (EUR-Lex)
The practical question is therefore not simply which vendor to buy. It is whether the selected infrastructure works with the CASP's counterparties, transaction architecture and internal controls.
4. Detect Missing or Incomplete Information
Receiving CASPs must have effective procedures for identifying transfers where required originator or beneficiary information is missing or incomplete.
That means controls cannot operate only on outgoing transactions.
Inbound transfers require monitoring as well. (EUR-Lex)
5. Build an Escalation Process
Where information is missing, the beneficiary or intermediary CASP needs risk-based procedures for determining whether to execute, reject, return or suspend the transfer, or request the missing information.
Repeated failures by another CASP may require warnings, restrictions, rejection of future transfers or termination of the relationship, as well as reporting to the relevant competent authority. (EUR-Lex)
This is why the Travel Rule cannot sit entirely inside an API. Someone has to define what happens when the API identifies a problem.
How does the travel rule apply under EU law?
The Travel Rule is often described as a MiCA requirement, but that is not technically precise.
MiCA, Regulation (EU) 2023/1114, establishes the EU regulatory and authorisation framework for CASPs. The Travel Rule obligations themselves primarily come from Regulation (EU) 2023/1113.
The two frameworks operate together.
The TFR applies to crypto-asset transfers, including transfers through crypto ATMs, where the CASP or intermediary CASP of either the originator or beneficiary has its registered office in the EU. (EUR-Lex)
There are specific exclusions. For example, the TFR does not apply where both the originator and beneficiary are CASPs acting on their own behalf. It also does not apply to genuine person-to-person transfers carried out without the involvement of a CASP. (EUR-Lex)
For businesses, this means Travel Rule analysis should follow the actual transaction architecture.
The relevant questions are who is transferring the crypto-assets, on whose behalf the transfer takes place, which regulated entities are involved, where those entities are established and whether the transaction involves a self-hosted address.
It is one layer of the compliance framework, not a substitute for MiCA authorisation, AML/CFT controls, sanctions screening or other regulatory obligations.
The most common Travel Rule implementation mistake
One of the most common mistakes is treating Travel Rule compliance primarily as a software integration project. Connecting a Travel Rule solution may solve the technical exchange of originator and beneficiary data, but it does not by itself create a compliant operating model.
The more difficult questions arise when a transaction does not follow the expected path. A CASP still needs clear procedures for situations where required information is incomplete, a counterparty CASP repeatedly fails to provide it, a self-hosted wallet is involved, or the transfer raises AML, sanctions or other risk concerns. Those decisions cannot be delegated entirely to an API or a technology provider.
As Dr. Peter Merc, founder of Lemur Legal, explains:
“The technology can exchange data, but it cannot decide what happens when that data is incomplete, when a self-hosted wallet is involved, or when a transaction raises AML or sanctions concerns. Those decisions need to be defined in the CASP’s policies, risk framework and escalation procedures. In practice, the real test of a Travel Rule setup is not whether the API works when everything is straightforward, but whether the organisation knows what to do when the transaction does not follow the expected path.”
For that reason, Travel Rule implementation should be designed as an end-to-end legal, operational and technical process. The software is one component. The compliance framework around it determines how the CASP actually responds when exceptions, higher-risk transactions or incomplete information arise.
How should CASPs handle self-hosted wallets?
A self-hosted wallet is not automatically prohibited or suspicious.
But the fact that there is no second CASP on the other side of the transfer changes how the information must be obtained.
Where a transfer goes to or comes from a self-hosted address, the CASP generally obtains the relevant originator and beneficiary information from its own customer and must ensure that the transfer can be individually identified. (EUR-Lex)
For transfers exceeding €1,000, the CASP must take adequate measures to assess whether the relevant self-hosted address is actually owned or controlled by its customer. (EUR-Lex)
Risk still matters below and above that amount.
Where information appears inaccurate, transaction patterns are unusual, or higher AML/CFT risks are present, the regulation contemplates enhanced risk mitigation. Blockchain analytics and transaction-monitoring tools can therefore support the process, but they do not replace the required customer and transfer information. (EUR-Lex)
The right implementation is not “ban self-hosted wallets.” It is to establish a defensible process for identifying, assessing and documenting the risk.
Common crypto travel rule compliance mistakes
Several implementation errors are particularly avoidable.
Treating €1,000 as a General Travel Rule Threshold
It is not. The threshold is particularly relevant to ownership or control checks for self-hosted addresses. Covered CASP-to-CASP transfers are not generally exempt simply because their value is lower.
Assuming a wallet address is enough
Blockchain addresses provide transaction traceability, but the Travel Rule requires prescribed originator and beneficiary information. A wallet address does not replace identity information.
Sending personal data on-chain
The TFR specifically allows required information to travel separately from the crypto transfer. Publishing personal information on a public blockchain would also create obvious data-protection concerns. (EUR-Lex)
Implementing only outgoing controls
A beneficiary CASP must also detect missing information in incoming transfers and determine the appropriate response.
Relying entirely on a travel rule vendor
Technology can transmit data. It cannot decide the firm's legal scope, risk appetite, escalation criteria, self-hosted wallet procedures, sanctions response or FIU reporting framework.
The policy and the technical architecture have to match.
Travel rule, GDPR and sanctions must work together
Travel Rule implementation involves sensitive personal data.
The TFR expressly subjects processing to GDPR and limits the use of personal data collected under the regulation to AML/CFT purposes. Processing that information for incompatible commercial purposes is prohibited. CASPs must also provide customers with appropriate information about this processing. (EUR-Lex)
At the same time, CASPs must maintain internal policies, procedures and controls for implementing applicable EU and national restrictive measures when transferring crypto-assets. (EUR-Lex)
This creates an operational challenge.
A transfer process must simultaneously handle identity data, sanctions screening, transaction risk, privacy, self-hosted wallets and incomplete counterparty information.
Treating each framework as a separate compliance document usually produces gaps between them.
What should a CASP have ready?
A CASP building or reviewing its crypto Travel Rule compliance framework should be able to demonstrate more than the existence of a vendor contract.
At minimum, the operating model should cover:
• scope analysis for relevant transfer types;
• required originator and beneficiary data fields;
• customer-data validation;
• counterparty CASP identification;
• secure information transmission;
• self-hosted wallet procedures;
• ownership or control verification where required;
• inbound and outbound transfer monitoring;
• missing-data escalation rules;
• handling of repeatedly non-compliant counterparties;
• AML/CFT and sanctions escalation;
• FIU and competent-authority reporting procedures;
• GDPR and data-retention controls;
• audit trails showing how decisions were made.
The EBA's Travel Rule Guidelines are particularly important for translating the TFR into operational procedures. They have applied since 30 December 2024 and address how CASPs should detect and manage transfers with missing or incomplete information. (Evropska agencija za železniški promet)
Lemur Legal's work on crypto regulatory compliance approaches these requirements as part of the wider CASP compliance architecture rather than as an isolated technology exercise.
Build the travel rule into the transaction flow
The EU crypto Travel Rule is fundamentally a traceability requirement, but compliant implementation reaches much further than adding customer names to a transfer message.
CASPs need to know who is sending and receiving the assets, exchange the required information securely, identify missing data, handle self-hosted addresses, make risk-based transaction decisions and retain a defensible record of what happened.
The strongest implementation is therefore built into the transaction architecture from the start.
For a CASP preparing for authorisation, expanding into the EU or reviewing an existing compliance framework, the key question is not whether a Travel Rule solution has been installed.
It is whether the legal, technical and operational controls still work when a real transfer does not follow the ideal path.