With the MiCA grandfathering deadline passed, virtual asset service providers in Europe need to get ready for enforcement – which includes Travel Rule implementation. This post explores how CASPs should prepare for Travel Rule audits by their Competent Authorities.
When auditing Travel Rule compliance, the first step is to identify the regulatory requirements and understand how they translate into practical compliance controls.
In the EU, there are two main sources to start with: the Transfer of Funds Regulation (TFR) and the European Banking Authority (EBA) Travel Rule Guidelines.
The TFR sets the legal requirements. It defines what information must accompany a crypto-asset transfer, what the originating CASP is required to send, what the beneficiary CASP is expected to detect, and how missing or incomplete information should be handled.
The EBA Guidelines take these requirements further and provide more detail on how CASPs are expected to implement them in practice, including detecting missing or incomplete information, dealing with transfers where required info
rmation is missing, and determining what action should be taken.
To build a practical audit framework, the TFR and EBA Guidelines first need to be dismantled into individual requirements that can be translated into concrete audit checks.
This means looking at the full lifecycle of a transaction: whether the transfer is in scope, whether the required originator and beneficiary information is complete and accurate, how and when that information is transmitted, how incoming transfers are matched with Travel Rule messages, and how missing or incomplete information is detected and handled. From there, the audit needs to cover self-hosted wallets, counterparty identification, screening, exception handling and decisioning, repeatedly failing counterparties, recordkeeping and, importantly, the systems and protocols used to exchange Travel Rule information.
Once the requirements are viewed this way, the audit becomes less about checking whether a Travel Rule message exists and more about whether the controls around the entire process actually work.
A very practical example comes from everyday operations. Consider a scenario where CASP A has implemented the Travel Rule requirements and transmits the required information. CASP B has done the same and has processes in place to receive and process that information.
In theory, this should result in a compliant Travel Rule flow between the two CASPs.
In practice, CASP A might be using Travel Rule Provider X while CASP B uses Provider Y. If those providers operate on different networks and there is no interoperability between them, the crypto transfer can arrive while the corresponding Travel Rule message does not.
It is therefore possible for two CASPs that have implemented their respective Travel Rule obligations to still end up with no automatically received Travel Rule message.
And this is where auditing the Travel Rule becomes more interesting than simply checking whether a message was received.
Importantly, a missing Travel Rule message does not determine the outcome on its own. It triggers a process. The beneficiary CASP needs to detect the missing information, assess the circumstances and apply its risk-based procedures to determine what happens next. The EBA Guidelines also make clear that missing information per se does not give rise to suspicion of ML/TF.
From an audit perspective, the focus therefore shifts from the missing message itself to how the CASP identifies, investigates and manages the exception:
- Can the beneficiary CASP identify the originating CASP?
- Can it determine whether Travel Rule information was required for the transfer?
- Can it reconcile the blockchain transaction with the corresponding Travel Rule message?
- If the information is missing, is there a process for requesting it from the originating CASP?
- And is there a documented, risk-based approach for deciding whether to execute, suspend, reject or return the transfer?
The important part is not simply that an exception occurred, but whether the CASP can demonstrate how it was identified, assessed and resolved.
This is also where the EBA Guidelines leave some room for interpretation. They set expectations for detecting and managing missing information, but how those requirements are translated into operational controls is ultimately left to the CASP. At the same time, they do not solve the underlying technical problem: different Travel Rule networks may still be unable to communicate with each other.
Until there is stronger interoperability between providers, different networks are pushed or required to connect to each other, or another industry-wide solution emerges, we will continue to see this gap. Today, a CASP could even connect to multiple providers, yet still face the same challenge if the underlying networks remain fragmented.
At the end of the day, having a Travel Rule solution and the right controls in place, even with connectivity to multiple Travel Rule networks, does not necessarily mean that the required information will successfully reach the intended counterparty CASP.
From an audit perspective, the real test is not whether every incoming transfer has a corresponding message, but whether the CASP can demonstrate how each exception was handled. If an incoming message is missing, can the CASP demonstrate that it was detected, what happened next, what information was requested, which risk factors were considered, and why the transfer was ultimately executed, suspended, rejected or returned?
A risk-based approach gives CASPs flexibility, but that also means that how each transfer is handled needs to be explainable, consistent and documented.
There is also a broader layer to this that goes beyond the EU framework. FATF Recommendation 16 provides the international foundation for the Travel Rule, yet jurisdictions have implemented it at different speeds and, in some cases, with different thresholds and requirements. FATF’s 2026 update shows that 83% of responding jurisdictions have passed Travel Rule legislation, meaning the regulatory environment on the other side of a transfer may look very different from the one under which the CASP operates. This raises another set of audit questions: what happens when the counterparty is subject to a different threshold, different requirements, or operates in a jurisdiction where the Travel Rule has not yet been implemented? That probably deserves an article of its own.
So perhaps the most useful question for a CASP to ask before an auditor does is: are its crypto-asset transfers actually auditable?