The EU Crypto Travel Rule Has Entered Its Enforcement Era

MiCAR Is Not the TFR, And the TFR Is Not MiCAR

For much of the discussion around EU crypto regulation, MiCA has become shorthand for Europe’s regulatory framework for digital assets. That is understandable. MiCA introduced the authorisation regime around which much of the market has organised its compliance efforts, covering prudential safeguards, governance arrangements, conduct obligations and broader requirements for regulated crypto-asset services.

But MiCA was never the only framework reshaping how crypto intermediaries operate in Europe.

Running alongside it is the Transfer of Funds Regulation, the EU’s Travel Rule regime, which is often discussed in the same breath as MiCA, despite serving a different legal function and following a different implementation path. That distinction has sometimes been blurred in market discussions, where Travel Rule compliance is still occasionally framed as part of a broader “MiCA readiness” exercise, rather than recognised as a standalone set of obligations with its own supervisory trajectory.

The distinction matters because the two frameworks regulate different things.

MiCA establishes the broader prudential and conduct framework for crypto-asset service providers and stablecoin issuers. The TFR addresses transfer controls, including information requirements accompanying transfers and specific obligations linked to transfers involving self-hosted addresses.

They also became applicable through different timelines.

The recast TFR has applied to CASPs since 30 December 2024, while the EBA’s Travel Rule Guidelines contemplated only a narrow accommodation period through 31 July 2025 for circumstances involving objective technical limitations. That was not a delay of the regime itself, nor a general grace period for implementation. It reflected limited recognition that certain technical constraints might temporarily affect compliance with aspects of an already operative framework.

That point is worth emphasising because this is often confused with a separate and unrelated feature of MiCA: the optional national transitional arrangements available in some Member States for pre-existing CASPs. Those transitional periods, some of which remain in effect but approach fixed end dates this year, concern continued operation pending MiCA authorisation or, failing authorisation, exit from the market.

They are not Travel Rule transition periods and that distinction is often overlooked. The fact that some firms may still be operating during a MiCA grandfathering period does not mean Travel Rule obligations remain in some parallel implementation window. Those obligations are already part of the applicable compliance framework and, in many cases, form part of what competent authorities are assessing in MiCA authorisation reviews themselves.

In that sense, Travel Rule controls sit not outside MiCA authorisation, waiting for licensing to conclude, but increasingly as part of the control environment firms are expected to evidence when seeking authorisation and maintain once authorised. That is why it can be misleading to treat Travel Rule implementation as somehow deferred while MiCA transitions run their course.

Legally and operationally, the Travel Rule is already part of the compliance stack. And once obligations move into ordinary operations, the questions supervisors ask tend to change. The focus begins to move away from whether frameworks have been built, and toward whether those frameworks operate effectively in practice.

The EU Travel Rule Is About More Than Messaging Requirements

Part of what has contributed to confusion around the Travel Rule is the tendency to frame it primarily as a messaging obligation, focused on transmission of required information between intermediaries. That framing captures an important part of the regime, but it can obscure how much of the framework concerns controls associated with transfers themselves, particularly where heightened risks arise.

That is especially visible in the provisions and guidance surrounding transfers involving self-hosted addresses. Requirements concerning assessment of ownership or control, verification methods, risk-mitigating measures and escalation where concerns arise are difficult to understand purely as disclosure mechanics. They sit much closer to transfer controls, and in some cases can bear directly on whether a transfer should proceed.

That feature has broader significance than is often acknowledged.

In many areas of financial crime compliance, controls operate around payment activity or monitor transactions after execution. The Travel Rule, at least in part, sits earlier in the transaction chain. It can introduce controls relevant before value moves, particularly where compliance conditions affect whether a transfer may be initiated, suspended or subject to additional verification. That is one reason the Travel Rule has often been associated not simply with information sharing, but with forms of pre-transfer trust and authorisation.

That point also helps explain why the Travel Rule has growing relevance in discussions around consumer safeguards, particularly in relation to fraud. Properly implemented controls around counterparty information, self-hosted wallet verification and escalation can operate as safeguards precisely because they sit close to the point where transfers occur. The framework was never designed solely around completing data fields: it also addresses how risks associated with transfers are managed.

That becomes particularly important once scrutiny begins to focus not simply on whether information is collected or exchanged, but on whether those controls operate as intended.

ASF 062/2025: The First Public Test of Crypto Travel Rule 

That signal emerged in ASF 062/2025 (KJ v Foris DAX MT Limited) before the Maltese Office of the Arbiter for Financial Services.

The case concerned two transfers of USDT made after the TFR had become applicable to CASPs. On 1 January 2025, the customer transferred USDT 13,945 to an external wallet. On 16 January 2025, he transferred a further USDT 16,035. Together, the two transfers were funded by fiat deposits of €13,800 and €16,300, amounting to €30,100.

The destination wallet was treated as a self-hosted address. Before the disputed transfers, the customer had also made smaller transfers to external wallets in December 2024, but the complaint focused on the two transfers made after the provider’s communication on Travel Rule compliance and after the TFR became applicable to CASPs.

A central factual point was that the customer had declared that he owned or controlled the destination wallet. In reality, according to his own account, the wallet belonged to the fraudulent platform to which he was sending funds. The customer therefore made an incorrect declaration, whether knowingly or under the influence of the scam. The Arbiter did not ignore that point, and expressly treated the customer’s conduct as a contributory factor.

But the decision did not stop there.

The Arbiter’s reasoning was that the provider’s obligations did not end with receiving a customer declaration. For transfers above EUR 1,000 to a self-hosted address, Article 14(5) TFR requires the originator’s CASP to take adequate measures to assess whether that address is owned or controlled by the originator. The EBA Travel Rule Guidelines then explain what this assessment may require in practice, including verification methods such as technical checks, wallet-control demonstrations, digital signature methods or other reliable means, depending on risk.

That is why the case is notable. It was triggered by a consumer complaint and involved fraud losses, but the reasoning examined whether Travel Rule controls operated as required before the transfer was executed. The question was not simply whether the customer had clicked the right box or provided the right information. It was whether the CASP had met its own obligation to assess ownership or control of the self-hosted address, particularly where the transfer value was well above the EUR 1,000 threshold.

It would be overstating matters to describe the decision as a classic supervisory enforcement action under the TFR. It was not that. But it would also be too narrow to dismiss it on that basis.

Regulatory obligations often begin to take shape through interpretation before they appear through formal sanctions. They are tested in disputes, supervisory findings and adjudicative decisions that reveal how obligations may be understood when deficiencies are alleged. In that sense, this case may represent an early enforcement signal even if it did not arise through the traditional route market participants might expect.

That is particularly so because the scrutiny in the case did not center on failures in messaging or information transmission. It centered on whether controls surrounding the transfer itself (verification, escalation and risk response) were adequate.

How the Malta Case Tested Self-Hosted Wallet Controls Under TFR

The complaint itself was framed around losses arising from two transfers of USDT to a fraudulent external wallet. The complainant alleged failures to verify ownership of the destination wallet, failures to apply enhanced controls appropriate to the risk profile of the transfers, and failures to suspend or reject a transfer after indicators of potential fraud had emerged.

Those allegations could have been approached primarily through the lens of consumer harm. What makes the decision notable is that it approached them, in substantial part, through the functioning of transfer controls.

That is important because it placed under scrutiny not simply whether a provider had general anti-fraud safeguards or broad duties of care, but whether controls specifically associated with the Travel Rule were operating in a way consistent with the regulatory framework.

In that respect, the case became less about whether a fraud occurred and more about whether the controls expected to apply around the transfers were capable of identifying, escalating or interrupting risks associated with them.

That is a different inquiry. And it goes directly to how the Travel Rule may increasingly be examined. Particularly striking was the focus on transfers involving a self-hosted address and whether the provider had taken adequate measures to assess whether the destination address was genuinely owned or controlled by the customer, as contemplated under Article 14(5) TFR.

That issue often receives attention in implementation discussions as a technical or procedural requirement. In this case, it was treated as a substantive control question.

Why Self-Certification Is Not Enough Under the EU Travel Rule

A central part of the provider’s defence was effectively that it had obtained confirmation from the customer that he controlled the destination wallet and that this should satisfy its obligations.

The Arbiter rejected that reasoning.

In doing so, the decision addressed an issue likely to resonate well beyond the facts of the case, namely whether customer declarations, standing alone, can satisfy obligations where the regulatory framework contemplates verification.

The answer, in this case, was plainly no.

The reasoning placed significant emphasis on the EBA Travel Rule Guidelines, particularly the provisions describing methods that may be used to assess ownership or control of self-hosted addresses, including situations where a combination of methods may be necessary depending on risk.

That analysis rejects a minimalist reading of compliance in this area. The decision did not treat verification as something fulfilled through form completion. It treated verification as requiring controls capable of supporting a genuine assessment. That is a materially different standard.

It also reinforces something implementation discussions have sometimes understated: obligations around self-hosted wallets were not framed around collecting declarations but around assessing whether declarations can be relied upon.

That point is particularly important because verification in self-hosted wallet scenarios is not merely theoretical, nor limited to abstract supervisory expectations. The market has developed technical methods specifically aimed at these scenarios, including wallet-control proofs, cryptographic signature approaches, satoshi tests, address ownership verification workflows and other methods reflected both in supervisory guidance and in industry tooling. Looking at providers such as 21 Analytics, for example, self-hosted wallet verification is treated as a solvable control problem, with methods ranging from signature-based proofs and automated ownership verification to satoshi test mechanisms and evidentiary proof collection designed specifically for Travel Rule scenarios.

That does not mean any particular method is universally required. It does, however, reinforce a broader point reflected in the EBA Guidelines and implicit in the Arbiter’s reasoning: there are available means to move beyond bare customer attestation. That makes it harder to frame self-certification alone as sufficient where obligations require assessment of ownership or control.

What the Malta Case Reveals About EU Travel Rule Enforcement

One reason this case deserves attention is that it may signal where scrutiny around Travel Rule compliance is heading.

Much of the industry conversation around implementation has understandably focused on infrastructure for exchanging information. That remains important. But supervisory scrutiny is unlikely to stop there. 

Questions increasingly may center on whether firms can demonstrate the functioning of controls around transfers involving elevated risks, including how self-hosted wallet assessments are conducted, how escalation occurs when fraud indicators emerge, and how decisions to suspend, reject or permit transfers are governed.

Those are not implementation questions in the ordinary sense. They are supervisory questions. And they point toward a broader understanding of the Travel Rule as part of a control framework that competent authorities may increasingly examine through effectiveness rather than formal compliance alone.

That is particularly relevant because many of the most difficult issues in Travel Rule compliance have never been about populating required data fields. They sit in edge cases where control judgment and operational processes become central. Those are precisely the areas where supervisory attention often intensifies as frameworks mature. 

How Travel Rule Deficiencies Could Become a MiCA Governance Issue 

There is another reason the implications may extend beyond the TFR itself.

Travel Rule deficiencies may not remain confined to analysis under transfer-specific obligations alone. They may also increasingly be viewed through MiCA’s expectations around governance, controls and compliance arrangements.

That possibility should not be overlooked.

MiCA does not operate in isolation from other applicable regulatory obligations. Its governance expectations assume firms maintain effective arrangements to comply with legal obligations relevant to their activities. Where controls required under the TFR prove deficient, questions may arise that extend beyond AML compliance into the adequacy of a firm’s broader control environment.

That has relevance both in authorisation contexts and on an ongoing supervisory basis, particularly because compliance with those arrangements is not assessed only at the point a license is granted, but forms part of what regulated status assumes in day-to-day operation.

That point is not merely theoretical in the context of this case.

Although the decision itself was not a supervisory enforcement action under the TFR, the matter was brought before the MFSA, which introduces the possibility that issues raised in the case may have consequences beyond the Arbiter’s findings alone. Whether through direct consideration under the TFR framework, broader supervisory follow-up, or assessment within ongoing prudential supervision, the case may still have a regulatory afterlife.

That is significant because the same regulator responsible for authorising and supervising a CASP may also consider whether deficiencies in controls raised in such a case bear on expectations attached to an already operational license, including the assumption that compliance arrangements are functioning on an ongoing basis.

Viewed in that light, potential consequences may not sit only under transfer-specific obligations. They may also sit within ordinary supervisory review.

And that is where the connection to MiCA becomes relevant. In practice, Travel Rule controls are already becoming part of authorisation assessments, operating model reviews and supervisory examinations. It is not difficult to see why deficiencies in those controls could also be viewed through the lens of governance weaknesses or ineffective internal controls.

That would make Travel Rule compliance not only a transfer regulation issue, but part of broader prudential and conduct supervision.

That gives the case significance beyond the immediate complaint. Because the question raised is no longer only whether a specific transfer control failed, it is whether weaknesses in those controls may become relevant to how a licensed firm’s control environment is assessed more broadly.

Questions CASPs Should Ask About Travel Rule Compliance Now

This case is likely to attract attention beyond its immediate facts.

It suggests firms may want to revisit not simply whether they have Travel Rule controls in place, but whether those controls can be evidenced, defended and shown to operate as intended. For many institutions, that may involve renewed focus on self-hosted wallet verification approaches and, more broadly, how obligations reflected in the EBA Guidelines are operationalised beyond policy statements.

Because one lesson from the case is that having a Travel Rule policy may not be the same as having a Travel Rule control framework capable of withstanding scrutiny.

That may prompt more fundamental questions.

Do firms have policies and procedures that reflect the regulatory requirements in a meaningful way? Are those procedures supported by tooling? Where tooling is in place, does it support compliance with the legal and supervisory expectations applicable in the jurisdictions where the firm operates, including requirements specific to the TFR and EBA Guidelines?

Those questions may become particularly important where firms have treated Travel Rule implementation largely as a vendor integration exercise. Because institutions may increasingly need to ask not only whether they have a Travel Rule solution, but whether that solution supports compliance in the way regulation expects.

That includes questions around whether tooling aligns with core FATF Travel Rule Solution criteria often associated with effectiveness, including timing of information exchange, counterparty coverage, interoperability across providers and secure handling of data. It may also require closer scrutiny of whether those solutions meet data security and data protection expectations appropriate to the sensitivity of the information being exchanged, particularly where solutions rely on third-party infrastructure.

And increasingly, firms may need to ask a more difficult question: whether their tooling is actually capable of supporting the controls contemplated by regulation, rather than only facilitating baseline information exchange. That includes support for requirements around self-hosted wallet verification, ownership or control assessments, escalation triggers, evidence retention and controls capable of supporting decisions to pause or reject transfers where risk conditions warrant it.

Those are not purely technology questions. They are compliance and governance questions. And they may become harder to separate.