MiCA Travel Rule: the Funds Transfer Regulation for crypto
Every crypto-asset transfer touching an EU crypto-asset service provider carries originator and beneficiary information, regardless of value. The recast Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets — the EU’s implementation of the FATF Travel Rule — has applied since 30 December 2024 and runs in parallel with MiCA. It obliges the originator’s CASP to attach a defined data set to every outgoing transfer, the beneficiary’s CASP to detect and act on missing data, and both to retain the records for a fixed five years. This walks the Article 14 field list, the self-hosted wallet test, what “missing or incomplete” triggers, and where the build usually goes wrong.
1. What the Regulation does, and to whom
Regulation (EU) 2023/1113 of 31 May 2023 repealed and replaced Regulation (EU) 2015/847, merging the fiat wire-transfer rules and the crypto rules into one text. Article 1 frames it as an AML/CFT instrument and adds a limb that is easy to miss: rules on internal controls to implement restrictive measures.
The territorial hook differs between the halves. For funds, Article 2(1) catches transfers sent or received by a PSP or intermediary PSP established in the Union. For crypto, it catches transfers where the CASP or intermediary CASP of either side has its registered office in the Union, and says expressly that crypto-ATM transfers are included.
One carve-out matters to e-money issuers. Under Article 2(3), the Regulation does not apply to transfers of funds or of electronic money tokens (Article 3(1)(7) of Regulation (EU) 2023/1114) made with a payment card, e-money instrument, mobile phone or similar prepaid or postpaid device, provided the device is used exclusively to pay for goods or services and its number accompanies all transfers from the transaction. The exclusion collapses the moment the instrument is used for person-to-person transfers between consumers outside trade or business.
2. The data that must travel — including the field most builds omit
Article 14(1) requires the originator’s CASP to ensure the transfer is accompanied by: the originator’s name; the distributed ledger address where the transfer is registered on a DLT network, plus the crypto-asset account number where one exists and is used to process the transaction; the account number where the transfer is not DLT-registered; the originator’s address including country name, official personal document number and customer identification number, or alternatively date and place of birth; and — subject to the existence of the necessary field in the message format, and where the originator has provided it — the current LEI or other equivalent official identifier. Article 14(2) requires the beneficiary set on the same pattern, LEI included. Article 14(3) adds a derogation: where a transfer is neither DLT-registered nor made to or from a crypto-asset account, a unique transaction identifier travels instead of the account numbers.
Two structural rules govern how the data moves. Article 14(4) requires the information to be submitted in advance of, or simultaneously or concurrently with, the transfer, securely and in accordance with Regulation (EU) 2016/679 — then states that it need not be attached directly to, or included in, the transfer itself. That is what makes off-chain Travel Rule messaging lawful. Article 14(8) supplies the hard stop: no initiation and no execution before full compliance with Article 14.
Verification is separate from transmission. Article 14(6) requires the originator’s CASP to verify the originator information against documents, data or information from a reliable and independent source before transferring, and Article 14(7) deems that done where identity was verified under Article 13 of Directive (EU) 2015/849 and retained under Article 40 — so a properly evidenced onboarding file discharges it, and a thin one does not.
3. Self-hosted addresses — two obligations, not one
Article 3(20) defines a self-hosted address as a distributed ledger address not linked to a CASP, or to a non-EU entity providing similar services. The obligations split by value, and the lower tier is the one that gets missed. For every transfer to a self-hosted address, whatever the amount, Article 14(5) requires the originator’s CASP to obtain and hold the Article 14(1) and (2) information and to ensure the transfer can be individually identified. Only above EUR 1,000 does the second obligation bite: adequate measures to assess whether the address is owned or controlled by the originator. Article 16(2) mirrors both limbs for transfers from a self-hosted address, without prejudice to Article 19b of Directive (EU) 2015/849.
| Transfer | Any amount | Above EUR 1,000 |
|---|---|---|
| To a self-hosted address (Article 14(5)) | Obtain and hold the Article 14(1)–(2) data set; ensure the transfer is individually identifiable | Assess whether the address is owned or controlled by the originator |
| From a self-hosted address (Article 16(2)) | Same obtain-and-hold and individual-identification duty on the beneficiary’s CASP | Assess whether the address is owned or controlled by the beneficiary |
| CASP to CASP (Articles 14 and 16) | Full data set transmitted; beneficiary CASP detects missing or incomplete information | No additional tier |
Facts: a customer of an EU CASP withdraws the equivalent of EUR 400 to a wallet address they have not previously used. The firm’s rules engine applies its self-hosted logic only above EUR 1,000, so nothing fires.
What the rule says: the EUR 1,000 threshold governs only the ownership-or-control assessment. The obtain-and-hold and individual-identification duties in the first subparagraph of Article 14(5) apply to the EUR 400 withdrawal exactly as to a EUR 40,000 one.
What the practitioner does: splits the control into two rules — value-independent data capture and transfer tagging, and a value-triggered attestation — then re-runs the last twelve months of sub-threshold self-hosted withdrawals to confirm each is individually identifiable. The remediation is usually a tagging gap, not a data gap.
4. The beneficiary side: detect, then decide
Article 16(1) requires the beneficiary’s CASP to implement effective procedures — including, where appropriate, monitoring after or during transfers — to detect whether the Article 14(1) and (2) information is included in, or follows, the transfer. Note “or follows”: detection is not purely a pre-credit gate. Article 16(3) requires verification of the beneficiary information before making the assets available.
Article 17(1) is where the operational policy lives. The beneficiary’s CASP must have effective risk-based procedures for determining whether to execute, reject, return or suspend a transfer lacking complete information. Where it becomes aware information is missing or incomplete it must, on a risk-sensitive basis and without undue delay, either reject the transfer or return the assets to the originator’s crypto-asset account, or request the required information before making the assets available. Those are the only two branches offered at that moment.
Article 17(2) governs the repeat offender. Where a CASP repeatedly fails to provide the required information, the beneficiary’s CASP must either escalate — warnings and deadlines, then rejection, restriction or termination — or move directly to rejecting future transfers and restricting or terminating the relationship. Either way it must report that failure, and the steps taken, to the competent AML/CFT authority: a duty separate from any suspicious-transaction report, and the one most counterparty policies leave out. Article 18 closes the loop — missing or incomplete information is a factor in assessing whether the transfer is suspicious and reportable to the FIU. Intermediary CASPs carry parallel duties under Articles 19 to 22.
5. When the counterparty keeps sending thin data
Facts: a Luxembourg CASP receives transfers from a non-EU venue whose Travel Rule messages carry the originator name and DLT address but never the address, document number, customer identification number or date and place of birth required by Article 14(1)(d). Volumes are commercially significant.
What the rule says: each transfer is “incomplete” for Article 17(1), so each triggers reject-or-return, or request-then-hold. Repetition moves it into Article 17(2): either a documented escalation path or immediate rejection and restriction — and in both cases a report of the failure and the steps taken to the competent AML/CFT authority.
What the practitioner does: stops treating it as a commercial negotiation. The counterparty file gets a warning with a deadline, the incoming flow moves to request-and-hold rather than credit-and-chase, the authority report goes out, and Article 18 applies on top — a persistent structural data gap from one venue is an input to the suspicion assessment, not just a data-quality issue.
6. Retention is a ceiling as well as a floor
Article 26(1) opens with a sentence that reverses the usual instinct: information on the originator and beneficiary shall not be retained for longer than strictly necessary. CASPs of the originator and beneficiary retain records of the information in Articles 14 to 16 for a period of five years, and Article 26(2) requires the personal data to be deleted on expiry unless national law provides otherwise.
Article 25 reinforces it: personal data may be processed only for AML/CFT prevention purposes, commercial processing is prohibited outright, and new clients must receive the Article 13 GDPR information before the relationship begins. Article 24 requires full and prompt responses to national AML/CFT authorities, through the central contact point under Article 45(9) of Directive (EU) 2015/849 where one exists.
7. Restrictive measures, and how this sits next to MiCA and tax
Article 23 is short and frequently overlooked: PSPs and CASPs must have internal policies, procedures and controls to ensure the implementation of Union and national restrictive measures when performing transfers. It is a standing governance obligation, not a per-transfer one. Supervisory expectations sit in the EBA Travel Rule Guidelines (EBA/GL/2024/11), published 4 July 2024 and applicable from 30 December 2024, replacing the earlier joint ESA guidelines — the reference point an authority uses when testing whether procedures are “effective” in the Article 16 and 17 sense. Screening and Travel Rule checks run independently: a sanctions hit freezes the transfer whatever the data quality, and complete Travel Rule data never cures a listed counterparty. See our sanctions screening note for the fiat equivalent.
The Travel Rule is also not part of MiCA. Regulation (EU) 2023/1114 is the prudential and conduct framework for CASPs; Regulation (EU) 2023/1113 is a separate AML instrument applying to the same population, so authorisation under one discharges nothing under the other — see the CASP notes for Luxembourg and Germany. In parallel, DAC8 collects overlapping data for tax purposes on a different cycle, to a different recipient, with a different retention rule. One customer-data layer can serve all three, but only if modelled for the union of the field sets rather than for whichever regime was built first.
9. FAQ
Does the Travel Rule apply to transfers between two accounts at the same CASP?
An internal book transfer has no counterparty CASP and no transmission step, so the Article 14 machinery has nothing to operate on. Ordinary customer due diligence and transaction monitoring under Directive (EU) 2015/849 still apply.
Is there a de-minimis threshold for crypto transfers?
No. The full Article 14 data set travels with every transfer regardless of value. The only EUR 1,000 figure on the crypto side sits in Articles 14(5) and 16(2), triggering the self-hosted wallet ownership assessment — not the data obligation.
What do we do when a counterparty repeatedly sends incomplete data?
Article 17(2) requires either a staged escalation — warnings and deadlines, then rejection, restriction or termination — or immediate rejection of future transfers and restriction or termination of the relationship. In both cases the failure and the steps taken must be reported to the competent AML/CFT authority.
Is the LEI mandatory?
Conditionally. Articles 14(1)(e) and 14(2)(d) require the current LEI or other equivalent official identifier to accompany the transfer where the relevant message format has the field and the originator has provided it to its CASP.
10. What to do, today
- Data layer: audit the customer record against the Article 14(1) and (2) field list, including the conditional LEI — the field most implementations skip because it is qualified rather than absolute.
- Self-hosted logic: separate the value-independent obtain-and-hold and individual-identification duty from the EUR 1,000 ownership assessment. One rule doing both leaves the sub-threshold population exposed.
- Counterparty policy: write the Article 17(2) escalation ladder and the trigger for reporting the failure to the competent AML/CFT authority — mandatory, and separate from an FIU filing.
- Retention: implement a five-year expiry and deletion job under Article 26, not an open-ended archive, and align the lifecycle with DAC8.
- Governance: evidence the Article 23 restrictive-measures policy as a standing control, and test the Article 16 and 17 procedures against the EBA Travel Rule Guidelines before a supervisor does.
Related: MiCA white paper drafting · DAC8 — EU crypto-asset tax reporting · Sanctions screening at instant-payment speed · The MiCA CASP transition after 1 July 2026 · Funds transfer information under Reg 2023/1113 · E-money tokens under MiCA · CARF and how it lines up with DAC8
