Travel Rule Crypto Data Fields: All 14 Required Fields

The EU Transfer of Funds Regulation (TFR) requires crypto-asset service providers to collect and transmit specific information alongside every transfer. The regulation sets out 14 mandatory data fields across originator and beneficiary categories, with varying requirements depending on transfer value and whether the counterparty is another regulated CASP or an unhosted wallet.

Data fields for the originator

Every transfer must carry information about the party sending the crypto-asset. The originator data set comprises seven fields:

The name and account number fields apply to every transfer regardless of value. For transfers below 1,000 EUR, a CASP may omit the address and birth data but must still collect and transmit name, account identifier, and customer identification number.

The TFR defines account number broadly: an IBAN for traditional payment accounts, an LEI where assigned to the legal person, the wallet address itself, or any unique identifier that permits tracing the transaction back to the originator. A CASP may use its own internal customer reference as the account number if that reference is unique and allows the receiving CASP or authority to request further information.

For natural persons, the customer identification number is the national identity number, passport number, or a unique identifier assigned by the CASP upon customer onboarding. For legal persons, the LEI satisfies this requirement where one has been assigned; where no LEI exists, the CASP must assign and record a unique customer identification number.

Data fields for the beneficiary

The beneficiary data set mirrors the originator structure. A CASP sending a transfer must collect and transmit seven fields about the recipient:

The threshold structure is identical to the originator side: name and account number for all transfers, address and birth data only above 1,000 EUR. The customer identification number requirement applies where the beneficiary CASP holds the receiving customer — a sending CASP transmitting to another CASP does not invent a customer identification number for the recipient; the receiving CASP verifies and records its own customer's details.

The date-of-first-use field was introduced specifically for unhosted wallets. Where a transfer involves a self-hosted wallet rather than a CASP-controlled address, both the sending and receiving CASP must record the date that wallet address was first used by the originator or beneficiary. This field does not apply to CASP-to-CASP transfers where both parties are regulated entities.

Unhosted wallet threshold and self-declaration

Article 14 TFR imposes an additional obligation for transfers to or from unhosted wallets valued at 1,000 EUR or more. Before executing the transfer, the CASP must collect a self-declaration from its customer stating whether the customer owns the unhosted wallet or, if not, the identity of the wallet owner.

The self-declaration must include:

• Confirmation that the customer owns and controls the unhosted wallet, or
• If the customer does not own the wallet, the name and address of the third party who does.

The CASP must verify the beneficiary wallet address before execution. For transfers below 1,000 EUR, the self-declaration is not required, but the CASP must still collect the date of first use and verify the wallet address where practicable.

This threshold creates an operational branch: a customer sending 950 EUR to their own hardware wallet completes the transfer with name, account number, customer identification number, and date of first use. The same customer sending 1,050 EUR must first provide a signed or electronically submitted declaration that they own the destination wallet, which the CASP must retain for five years.

Transmission and verification requirements

Collecting the data is the first step; the TFR also specifies when and how a CASP must transmit it. Article 8 requires immediate and secure transmission of complete originator and beneficiary information alongside the transfer itself. The data must accompany the transfer of funds, not follow in a separate message.

Where the transfer occurs on-chain, the CASP must embed the required information in the transaction metadata or transmit it through a secure off-chain channel that cryptographically links the data to the on-chain transaction. The TFR does not mandate a single technical standard; CASPs may use the InterVASP Messaging Standard, TRP, Notabene, or another protocol that satisfies the security and immediacy requirements.

The receiving CASP must verify beneficiary information against its own customer records. Article 9 requires the beneficiary CASP to detect missing or incomplete information and, where any required field is absent, to reject the transfer or request the missing data from the sending CASP within three business days. A CASP that repeatedly accepts incomplete transfers commits an infringement and may face supervisory measures.

Retention and availability for authorities

Article 16 TFR requires CASPs to retain all collected information for five years from the date of the transfer. The retention obligation applies equally to successful transfers, rejected transfers, and transfers where the CASP detected a compliance issue and filed a suspicious transaction report.

The retained data set must be available to the CASP's home competent authority and to financial intelligence units on request. The TFR does not require CASPs to submit batch reports of all transfers; instead, authorities may request the full data set for a specific transaction, customer, or period during supervision or investigation.

CASPs operating across multiple member states must ensure the data is accessible to each relevant authority. A CASP passporting from Germany into France under MiCA must make transfer records available to both BaFin and the Autorité des marchés financiers on request, depending on which authority is examining which part of the business.

Divergence from traditional TFR for payment service providers

The crypto-asset annex to the TFR (Annex I) introduces two fields that do not exist in the traditional payments regime: date of first use for unhosted wallets and the explicit requirement to collect an LEI where assigned. Payment service providers under the original TFR need not record when a customer first used a particular bank account, because the account is by definition opened with the PSP. The unhosted wallet date-of-first-use field reflects the self-custody reality of crypto-assets.

The LEI requirement appears in both regimes but is operationally more significant for crypto CASPs, because MiCA-authorized firms serving corporate clients are more likely to encounter legal persons with assigned LEIs. A CASP that does not request and record an assigned LEI at onboarding will discover the gap when the first transfer above 1,000 EUR occurs and the required field is missing.

Sanctions screening and PEP checks layered on top

The TFR data fields are anti-money-laundering infrastructure, not the entirety of AML obligations. A CASP that collects all 14 fields and transmits them in the required format has satisfied the travel rule but not necessarily its broader AML duties under the Anti-Money Laundering Regulation (AMLR) or the national implementation of the Sixth Anti-Money Laundering Directive.

Before executing a transfer, the CASP must screen the originator and beneficiary against sanctions lists, verify that the customer is not a politically exposed person subject to enhanced due diligence, and assess the transaction against the risk profile built during onboarding. The TFR does not replace these checks; it adds a layer of structured data that must move with the transfer regardless of whether any sanctions or PEP flags exist.

CASPs using /verify to confirm a counterparty's authorization status should layer that check into the same workflow that verifies TFR data completeness. A transfer rejected for missing beneficiary address is a compliance failure; a transfer accepted from an unauthorized firm is a supervisory breach and potentially a criminal-law issue if the counterparty is operating without the required MiCA authorization.

What happens when a field is genuinely unavailable

The regulation anticipates that certain fields may not exist for every beneficiary. Where a natural-person beneficiary has no national identity number (for example, a refugee or stateless person), the CASP may use a passport number or an internally assigned unique identifier. The requirement is that the field contains a value that permits re-identification, not that every customer has a government-issued ID number.

For unhosted wallets, the date of first use may be unknown if the customer cannot or will not provide it. In that case, the CASP must record the date the customer disclosed the wallet address to the CASP, and note in its records that the actual first-use date could not be verified. A CASP that encounters this situation repeatedly for a single customer or wallet may conclude that the customer's explanation is implausible and file a suspicious transaction report.

Supervision and enforcement of TFR compliance

The TFR is directly applicable EU law and does not require national transposition. Member state competent authorities supervise compliance as part of MiCA authorization and ongoing supervision. A CASP licensed under MiCA is automatically subject to TFR; there is no separate travel-rule registration.

Authorities may test TFR compliance by requesting transaction records during on-site inspections or through off-site data calls. BaFin, the AMF, and the Dutch Authority for the Financial Markets have each conducted thematic reviews of travel-rule data quality among authorized CASPs, and each has issued administrative fines where the data set was incomplete or where the CASP could not demonstrate that beneficiary information was verified.

The pattern emerging from early enforcement is that supervisors treat TFR compliance as table-stakes. A CASP that cannot produce complete originator and beneficiary records on request will not pass authorization, and a CASP that operated under transitional registration without implementing TFR by 30 December 2024 forfeited the ability to apply for full MiCA authorization.

How the travel rule applies to cross-border transfers

The TFR binds all CASPs established in the EU and all transfers where the originator or beneficiary CASP is in the EU. A CASP authorized in Germany must apply the full data set to a transfer sent to a non-EU exchange, and must collect and verify the same fields when receiving a transfer from a non-EU counterparty.

Where the non-EU CASP operates under a compatible travel-rule regime (for example, FATF-compliant jurisdictions like the United Kingdom, Singapore, or Switzerland), the data fields largely overlap and both CASPs can satisfy their respective obligations by exchanging the same structured message. Where the non-EU jurisdiction has no travel rule or a divergent standard, the EU CASP must still collect and retain the required fields for its own records, even if the counterparty does not reciprocate.

A CASP using /reverse-check to determine whether a non-EU firm may serve EU clients under reverse solicitation should treat TFR compliance as a separate question. A non-EU exchange that may lawfully accept EU customers under passive marketing rules is not exempt from transmitting travel-rule data when the transfer involves an EU CASP.

Technical standards and message formats

The TFR does not prescribe a single message format. Article 15 requires the European Banking Authority and ESMA to draft regulatory technical standards specifying the procedures and arrangements for transmitting the information, but until those RTS enter into force, CASPs may use any protocol that satisfies the security, immediacy, and completeness requirements.

In practice, most EU CASPs have adopted one of three approaches: the InterVASP Messaging Standard (IVMS 101), the Travel Rule Protocol (TRP), or a proprietary API that exchanges JSON payloads matching the TFR field list. The choice of protocol is operationally significant only where the sending and receiving CASP use incompatible systems; supervisors care that the data was transmitted securely and verifiably, not which standard was used.

The draft RTS published by EBA in 2025 propose a standardized JSON schema and a requirement that CASPs either implement a messaging protocol that other CASPs can connect to or use a third-party travel-rule service provider. The final RTS are expected in 2026, with a six-month implementation period.