Transfer of Funds Regulation (EU) 2023/1113 (TFR): Funds and Crypto-Asset Transfers

The full name of the regulation says almost everything: Regulation (EU) 2023/1113 of the European Parliament and of the Council of May 31, 2023 on information accompanying transfers of funds and certain crypto-assets and amending Directive (EU) 2015/849. In the industry it is called the TFR, short for Transfer of Funds Regulation, and the obligation it imposes is known as the travel rule: information on who orders and who receives the transfer must travel together with it.

The anti-money laundering logic is simple. If a transfer arrives without identifying who ordered it, the recipient cannot assess the risk, the authorities cannot reconstruct the chain and the trail is lost. That is why the EU has had an information regime for transfers of funds for years. What Regulation 2023/1113 does is recast that regime and extend it to crypto-assets, closing the gap that allowed the same value to move with traceability as a bank transfer and without it as a crypto-asset transfer.

The structure of the regulation mirrors exactly that dual nature. After Chapter I on subject matter, scope and definitions, Chapter II sets out the obligations of payment service providers and Chapter III those of crypto-asset service providers. They are two parallel regimes, with similar but not identical requirements, and the most important difference between them—the thresholds—is precisely the one that causes the most mistakes.

As a regulation, the TFR is directly applicable: it requires no transposition and applies in Spain without any domestic law reproducing it. It coexists with Law 10/2010 and its implementing regulation, which remain the general framework for AML/CFT obligations, and it works alongside the EU package that includes the new AML Regulation and AMLA.

The practical consequence of this structure is that many entities fall under both chapters at once. A crypto-asset service provider that also offers transfer services for e-money tokens may need a payment services authorization, and must then comply with both regimes for different activities. The first task in any TFR compliance project is therefore to map which activity falls under which chapter, because the thresholds and obligations do not match.

Two clarifications on how this works in practice. The first concerns timing: the originator and beneficiary information must be submitted immediately and securely, and for batch file transfers the regulation requires that submission to take place before or at the moment the transaction is completed. Sending it afterward does not work: it is called the travel rule precisely because the data travels with the movement of value.

The second concerns the channel. The regulation does not impose any specific transmission technology. It requires the information to be transmitted immediately and securely, which in practice has led the industry to adopt specialized travel rule messaging protocols and providers. Choosing that infrastructure is a compliance decision, not just a technical one: if your counterparty uses a protocol you do not support, the transfer cannot be completed properly.

This is by far the most widespread confusion. Many projects simply import the €1,000 threshold from the funds regime and apply it to crypto-asset activity, leaving every transfer below that figure outside the information flow. It is a design error with direct consequences: a substantial part of the activity moves without the information the regulation requires.

The €1,000 threshold does appear in the crypto world, but for something else: to trigger the enhanced obligation regarding self-hosted addresses. They are two different rules that share a figure, and confusing them produces the worst possible outcome: under-complying where there is no threshold while believing you are compliant.

A self-hosted address is one that the user controls directly, without a crypto-asset service provider involved. There is no supervised counterparty to ask for the beneficiary’s data or to send the originator’s data to. The regulation resolves this asymmetry by shifting the burden to the provider that is supervised.

The mechanism has two parts. The first is verification of ownership or control: when a transfer to or from a self-hosted address exceeds €1,000, the provider must verify whether that address is owned by its customer or under the customer’s effective control. The second, set out in Article 14(5), is the individual identification of crypto-asset transfers to self-hosted addresses. Article 16(2) covers the reverse direction: transfers from self-hosted addresses.

In practice, ownership verification is carried out through proof-of-control techniques—signing a message with the private key, a verification micro-transaction or other equivalent methods—whose suitability must be documented. What does not work is a bare customer statement: the regulation speaks of verifying, not of collecting a declaration.

It is also worth anticipating that this area is still evolving. The regulation itself provided for the Commission to assess the need for additional measures on transfers involving self-hosted addresses. Any policy designed today must be open to review, and the internal procedure should allow controls to be tightened without rebuilding the system.

The third phase is the most neglected and the one with the greatest consequences. Detecting and rejecting are operational acts that a well-configured system performs on its own. Assessing a counterparty’s repeated failures is something else: it requires building up a history, applying your own criterion for when a pattern stops being an incident and becomes a problem, and acting accordingly—from stepping up controls to ceasing to do business with that counterparty. Without that log, the entity cannot prove it has done what the regulation requires, even if it is in fact rejecting transfers every day.

The TFR applies from the date of application of Regulation (EU) 2023/1114, MiCA, as the regulation expressly provides—recital 64 justifies this “in order to ensure consistency” between the two. MiCA, in turn, has applied since December 30, 2024, with the transitional regime under Article 143(3) for providers that were already operating before that date.

And here is the key point for any Spanish provider: Spain did not shorten that transitional period, unlike other Member States, so grandfathering ran until July 1, 2026 or until authorization was granted or refused, whichever came first. That deadline has now passed. As a result, every crypto-asset service provider operating in Spain today must be authorized and is therefore fully subject to the transfer information regime.

As for the authority, the CNMV is the competent authority for crypto-asset service providers in Spain, while the Bank of Spain retains competence over payment services authorization under PSD2—which is relevant when the provider offers transfer services for e-money tokens. This dual gateway explains why so many crypto projects end up needing a perimeter analysis covering both sets of rules: see MiCA license and payment institution license.

Also bear in mind that the text of the regulation was subject to a corrigendum published in the Official Journal on December 3, 2025, which affected, among other provisions, the definition of crypto-asset service provider in Article 3(15), Article 14(5) (individual identification of transfers to self-hosted addresses), Article 16(2) (transfers from self-hosted addresses) and Article 28(2) on penalties. If your manual quotes the original text, check that the wording you are working with is the one currently in force.