MiCA Travel Rule: the Funds Transfer Regulation for crypto
Every crypto-asset transfer between EU CASPs now carries originator and beneficiary information, regardless of value. The recast Regulation (EU) 2023/1113 on transfers of funds and certain crypto-assets — the EU’s transposition of the FATF Travel Rule — applies in parallel with MiCA and obliges every Crypto-Asset Service Provider to attach defined data to every outgoing transfer and to verify defined data on every incoming one. This piece walks through what data must travel, how unhosted wallets are handled, and the operational checks that need to sit in production.
1. What the Funds Transfer Regulation does
The Regulation extends to crypto-assets the long-established Travel Rule that already applies to wire transfers under Regulation (EU) 2015/847. The recast version repeals the 2015 instrument and combines fiat-transfer and crypto-transfer rules into one consolidated text. For crypto, it requires:
- The originator’s CASP (the firm sending the crypto on behalf of its customer) to attach defined identifying information to the transfer.
- The beneficiary’s CASP (the firm receiving on behalf of its customer) to verify that the data is present and properly formed before crediting the customer.
- Both CASPs to retain the records and make them available to authorities on request.
The Regulation took effect alongside MiCA in 2024 and is in operation across the EU.
2. Who is in scope
Every Crypto-Asset Service Provider authorised under MiCA — exchanges, custodial wallets, brokers, transfer service providers — is subject to the Travel Rule. The obligation hits the CASP, not the underlying customer.
The Regulation also captures credit institutions and financial institutions when they execute transfers of crypto-assets, even if their primary licence is not MiCA-CASP. Banks and EMIs holding customer crypto-assets fall within scope when they transfer them.
3. The data that must travel
For every crypto-asset transfer, the originator’s CASP must transmit:
Originator information
- Name of the originator
- Distributed-ledger address from which the transfer is initiated (or a transaction identifier where there is no on-chain address)
- Originator’s account number with the CASP, where one exists
- Originator’s address, official personal-document number, customer-identification number, or date and place of birth — at least one of these
Beneficiary information
- Name of the beneficiary
- Distributed-ledger address to which the transfer is sent (or a transaction identifier where applicable)
- Beneficiary’s account number with the receiving CASP, where one exists
4. What the beneficiary’s CASP must verify
On receipt, the beneficiary’s CASP must:
- Verify that all required originator information has accompanied the transfer.
- Verify the beneficiary information against its own customer records.
- Where information is missing or evidently incomplete, take risk-based action — request the missing data, hold the credit, return the transfer, or, in serious cases, report to the FIU and consider terminating the relationship.
- Retain the data for at least five years.
The “evidently incomplete” check is operational: the receiving CASP runs structured-data validation (is the originator-name field non-empty? is the address-or-DOB-or-ID present?). Pure free-text disputes do not need to block credits, but missing mandatory fields do.
5. Transfers to and from self-hosted wallets
The biggest operational nuance. Where one side of the transfer is a self-hosted wallet (an address controlled by the customer directly, not a CASP), there is no counterparty CASP to send data to. The Regulation handles this:
- Above EUR 1,000 per transfer, the CASP on the regulated side must verify whether the self-hosted wallet is owned or controlled by its own customer — typically through technical proof such as a signed message from the wallet, or via a satoshi-test transaction.
- Below the threshold, no counterparty-CASP exchange is required, but the originator’s identity still travels with the transfer where the regulated side is sending.
- The customer’s response to the verification request can be a refusal — in which case the CASP applies enhanced due diligence and may decline the transaction.
This is operationally heavier than the bank-to-bank wire-transfer model. Most CASPs implement a wallet-attestation flow built around message-signing or a small test transaction.
6. The technical channel
The Regulation does not mandate a specific protocol. In practice, the CASP-to-CASP exchange runs over one of several Travel-Rule-compliant industry protocols supported by the major regulated venues. The Regulation requires the data to travel “with the transfer” — directly bound to it through a corresponding identifier — but accepts that the transmission channel can be off-chain. Match-then-settle workflows are common: the data exchange happens in seconds, the on-chain settlement follows.
7. Overlap with MiCA, AML and sanctions
The Travel Rule sits alongside three other regimes:
- MiCA — the prudential and conduct framework for CASPs. The Travel Rule is a separate AML instrument; MiCA does not displace it.
- Sixth EU AML Directive (and EU AML Regulation 2024/1624) — the substantive AML framework. Customer-due-diligence obligations align between the two; the Travel Rule adds the per-transfer information-attachment layer.
- EU sanctions — see our sanctions-screening piece. The Travel Rule data (originator and beneficiary) feeds the sanctions screen on the regulated side.
For tax: the parallel DAC8 regime captures crypto-asset transactions for tax-information exchange. The two have different reporting cycles and different recipients but share underlying customer-data layers.
8. What to build
- A structured customer-data layer with the Travel-Rule-required fields per individual and entity customer (name, ID number or DOB, address, account number).
- An outgoing-transfer hook that attaches the data block to every transfer to another CASP.
- An incoming-transfer hook that validates the data block before crediting.
- A self-hosted-wallet attestation flow with message-signing or test-transaction verification.
- A logging layer that retains the data for at least five years and is accessible to the AML representative.
- A risk-based action engine for missing-data scenarios — hold, return, request, escalate.
9. FAQ
Does the Travel Rule apply to transfers between two wallets at the same CASP?
Internal book transfers within the same CASP do not invoke the Travel Rule because there is no counterparty CASP. They remain subject to ordinary AML monitoring.
Is there a de-minimis threshold for crypto Travel Rule?
No. Unlike the fiat side, crypto Travel Rule applies regardless of value. A small-value transfer carries the same data obligations as a large one.
How does the EUR 1,000 threshold for self-hosted wallets work?
It triggers an additional CASP-side verification step (proving the wallet is controlled by the customer). Below the threshold, the verification is not required, but the data still travels where the CASP is on the sending side.
What if a counterparty CASP doesn’t support our Travel Rule protocol?
Industry protocols are interoperable in practice. Where direct exchange is not possible, the regulated CASP must take risk-based action — typically holding the credit, requesting the data through a fallback channel, or returning the transfer to the originator’s CASP.
How does this interact with sanctions screening?
The Travel Rule data is screened against EU sanctions lists at the receiving side. A sanctions match triggers a freeze regardless of Travel Rule data quality. The two checks are independent and run in parallel.
What is the retention period?
At least five years from the date of the transfer. Some member states impose longer retention through national AML rules; check the local regime.
10. What to do, today
- Audit your current customer-data layer against the Travel-Rule field list. Close gaps.
- Pick a Travel-Rule protocol and confirm interoperability with your major counterparty CASPs.
- Build the self-hosted wallet attestation flow now — it is the single most-asked-for operational improvement from supervisors mid-cycle.
- Coordinate with your AML representative on the missing-data escalation rules.
- Plan retention against five years minimum and align with DAC8 retention so customer-data lifecycle is consistent.
Related: MiCA white paper drafting · DAC8 — EU crypto reporting · Sanctions screening at instant-payment speed
