TFR Art. 14(5): verifying self-hosted wallets under the Crypto Travel Rule

The Crypto Travel Rule in the Transfer of Funds Regulation — Regulation (EU) 2023/1113 (TFR) — has two entirely different rules around the number EUR 1,000 that, in practice, almost always get muddled. Conflating them means you build either too little, or the wrong thing ^[1].

First: for transmitting the Travel Rule data (name, wallet address, identifier of originator and beneficiary), crypto-asset transfers have no de-minimis threshold. Recital 30 of the regulation states explicitly that crypto-asset transfers are subject to the same requirements “regardless of their amount”. The much-cited EUR 1,000 simplification in Arts. 5–6 applies only to conventional funds transfers, not to crypto ^[1].

Second: for transfers to or from a self-hosted address above EUR 1,000, Art. 14(5) (and Art. 16(2) on the beneficiary side) imposes an additional duty — verification of wallet ownership. So this EUR 1,000 threshold does not decide whether Travel Rule data must be sent (that applies from the first cent); it decides whether the provider must additionally check who owns the unhosted address ^[1].

The wording is terse: for a transfer of more than EUR 1,000 to a self-hosted address, the originator’s crypto-asset service provider (CASP) must take “adequate measures” to assess whether that address is owned or controlled by the originator. Art. 16(2) mirrors the duty for the beneficiary’s CASP where it receives more than EUR 1,000 from a self-hosted address ^[1].

What matters is what the provision does not say: it does not ban transfers to self-hosted wallets, and it does not require verifying third-party wallets. The only thing assessed is whether the counterpart address belongs to the CASP’s own customer. If it belongs to a third party, the general due-diligence and risk-assessment duties apply instead.

The most common implementation error: you let the customer tick a box saying “this address is mine” and treat the duty as discharged. The EBA Travel Rule Guidelines (EBA/GL/2024/11), applicable since 30 December 2024, make clear, however, that a mere customer self-declaration alone does not satisfy the “adequate measures” standard — additional, verifiable evidence is expected ^[2][3].

The guidelines do not prescribe a single technique; they require risk-based evidence proportionate to the risk of the customer and the transaction. This is where the real project work sits: a documented procedure that triggers weaker or stronger verification depending on risk — and that holds up in a supervisory inspection.

The industry has converged on a few methods that go beyond self-declaration. Cryptographic proof (signature test): the customer signs a CASP-specified message with the address’s private key; a valid signature proves control of the address. Micro-transaction (Satoshi test): the customer sends a CASP-specified tiny amount from the address to be verified, which likewise proves control. Both are stronger evidence than a bare statement.

Which method suffices is a risk decision: for low-risk customers one method may be enough; for higher-risk ones you combine several and document the rationale. What matters for auditability is not the choice of technique but that the procedure is defined, applied and traceable in the audit trail.

Beyond the self-hosted question, the guidelines require risk-based procedures to detect missing or incomplete originator/beneficiary data. On a deficiency, the CASP decides on a risk basis whether to execute, reject, return or suspend the transfer — there is no automatic rejection duty, but the decision and its rationale must be documented ^[3].

Compounding this is the sunrise problem: as long as Travel Rule regimes come into force at different times around the world, EU CASPs transact with foreign providers that are not yet (or not technically) Travel-Rule-capable. The data exchange breaks, and sanctions screening runs empty without counterparty data. Repeatedly non-compliant counterparty CASPs are a risk — and potentially a reporting — matter in their own right.

Operationally, Art. 14(5) breaks into three building blocks: a threshold trigger (above EUR 1,000 to/from self-hosted), a verification procedure (stronger than self-declaration, risk-tiered), and an audit trail capturing the trigger, the method chosen and the outcome. These are exactly the three points a supervisory inspection tests.

And because the TFR does not stand alone — it interlocks with MiCA, with the new AMLR (Regulation (EU) 2024/1624) and with sanctions screening — every new EBA clarification or national supervisory position potentially lands in several workflows at once. Implement Art. 14(5) cleanly but fail to track the follow-on Q&As, and you are behind again in twelve months. That is exactly what horizon scanning is for: detect changes at the source, classify them, and route them to the team that implements them.