Last reviewed · Version 1.0.0 · Evidence cutoff
The Travel Rule is usually bought as a messaging problem. That is the wrong architecture.
For a MiCA-authorised CASP, a payment institution bridging fiat and crypto rails, or a bank operating crypto-asset services during the MiCA transition, the hard question is not whether a Travel Rule message can be sent. The hard question is whether the firm can prove why a transfer was allowed, paused, returned, rejected, escalated or reported when identity, wallet, counterparty, sanctions and transaction-monitoring evidence did not line up cleanly.
That is an identity routing problem.
The EU Transfer of Funds Regulation creates the information-accompanying-transfer duties for crypto-asset transfers. For this radar, the corrected legal map is simple: Article 14 is the core information-accompanying-transfer model for crypto-asset transfers, Article 15 is the batch-file transfer provision, Article 16 is beneficiary-side missing-information detection, and Article 17 is the beneficiary-side procedure for missing or incomplete information. MiCA sits beside that framework. The transfer-services provision is MiCA Article 82, which is why the MiCA overlay belongs in the architecture discussion but should not be confused with the TFR Travel Rule itself.
FATF terminology matters for the same reason. Recommendation 16 is now framed as Payment transparency. Crypto-asset service-provider expectations come through Recommendation 15 and its virtual-asset interpretive material. A CASP that describes Recommendation 16 as if it were only a crypto Travel Rule source is signalling that its policy architecture is probably being copied from vendor copy rather than from the rulebook.
The failure mode
The typical failed design has four silos.
The KYC system knows the customer. The blockchain-intelligence system knows the wallet or exposure risk. The Travel Rule network knows whether a counterparty message has been exchanged. The case-management system knows that an analyst overrode, rejected or escalated something. In a clean demo, those systems appear connected. In a real transfer, they often are not.
The failure only becomes visible when a beneficiary CASP receives incomplete information, when an originator CASP cannot resolve the counterparty, when a self-hosted address triggers an ownership-or-control assessment, when a sanctions hit appears after a message exchange, or when the same counterparty repeatedly fails to provide required information. At that point the question is no longer “did we integrate a Travel Rule provider?” The question is: “Can we reconstruct the evidence that existed before the transfer decision?”
If the answer is no, the implementation is not audit-ready. It may be able to send messages, but it cannot prove controlled transfer decisioning.
What the radar maps
This radar separates the stack into legal instruments, supervisory guidance, control layers, vendors and product artefacts.
The legal core is Regulation (EU) 2023/1113. The MiCA transfer-services overlay is Regulation (EU) 2023/1114 Article 82. The broader perimeter is the AML package: AMLR, AMLD6 and the AMLA Regulation. AMLA is included as a watch item because direct supervision is a future activation point, not a current replacement for NCA supervision.
The guidance layer is deliberately conservative. It includes the EBA Travel Rule Guidelines, the EBA final report, ESMA transfer-services guidance under MiCA Article 82, ESMA’s CASP authorisation supervisory briefing, FATF material, and concrete NCA examples from AMF and CySEC. AMF DOC-2024-08 and CySEC Circular C675 are sufficient to show how NCAs can turn EBA guidance into implementation expectations. They are not a basis for saying that every NCA has published the same document or uses the same operational language.
The control layer is where most buyer diligence should focus. A serious Travel Rule architecture needs counterparty resolution, customer and wallet linkage, route policy, protocol-agnostic transport, exception evidence, repeated-failure handling, management information, sanctions screening, transaction monitoring, case management and pre-transfer evidence reconstruction. These controls are more important than the logo of the messaging network.
The EUR 1,000 trap
The EUR 1,000 point is often misdescribed.
It should not be treated as a general Travel Rule de minimis threshold. In this architecture, it is a threshold relevant to ownership-or-control assessment for self-hosted addresses. That is a narrower and more operationally demanding statement. It means the firm needs evidence that can link a customer, an address, a transfer instruction and the transfer decision. A static wallet-screening result is not enough.
A CASP that cannot explain how self-hosted address evidence is captured, refreshed, challenged, escalated and retained is not ready for serious supervisory questioning. The weakness is not legal interpretation alone. It is data lineage.
Protocols are not convergence
TRP, IVMS-101 and Notabene-supported messaging are useful artefacts. They are not proof that the market has solved Travel Rule interoperability.
TRP is OpenVASP Association-developed. IVMS-101 is a data standard. Notabene SafeTransact and the Notabene Network are product and network capabilities. These artefacts can support information exchange, but this radar does not claim protocol-bridge convergence because a vendor blog is not enough evidence for that claim. The bar would be an EBA, NCA or equivalent primary-source acknowledgement that such convergence has become a supervisory expectation or accepted operating model.
Until that exists, the prudent architecture is protocol-agnostic. The CASP should be able to route evidence through supported channels, document why that route was selected, and still make a controlled transfer decision when a counterparty or channel fails.
Vendor diligence: what to ask
The wrong diligence question is: “Which Travel Rule vendor do you use?”
The better questions are:
- Can the platform resolve the counterparty before route selection?
- Can it bind customer identity, wallet evidence and transfer instruction evidence?
- Can it distinguish Article 14 information duties from Article 15 batch-file handling?
- Can the beneficiary side detect missing or incomplete information under Article 16?
- Can Article 17 handling be evidenced, not merely configured?
- Can self-hosted address ownership-or-control evidence be reconstructed?
- Can sanctions and transaction-monitoring outcomes change the route decision?
- Can repeated failures be identified, escalated and reported?
- Can the MLRO see management information across counterparties, assets, corridors and exception types?
- Can internal audit reconstruct the pre-transfer decision without asking engineering to rebuild the data path?
If a vendor cannot answer those questions with evidence, its product may still be useful, but it should not be treated as the Travel Rule architecture.
What this means for authorisation and vendor due diligence
This radar does not claim that a stronger Travel Rule architecture automatically makes a MiCA application faster. That would be the wrong evidential claim. The better claim is narrower: weak evidence architecture creates avoidable friction during vendor due diligence, authorisation preparation and supervisory review.
A pre-application team should assume that the reviewer will not be impressed by a diagram showing a Travel Rule provider connected to a blockchain-intelligence provider. The reviewer will ask for procedures, decision logic, controls, evidence retention, exception handling and management oversight. A buyer that waits until after vendor selection to design those layers has already lost leverage.
This is why the graph includes vendors but does not rank them. Vendor ranking belongs in a separate buyer-guide surface. This radar is about architecture. A CASP may use one vendor for counterparty messaging, another for blockchain intelligence, another for identity verification, another for sanctions screening and a platform layer for workflow and evidence reconstruction. The risk is not that multiple systems exist. The risk is that no system owns the decision record.
Disclosure: XZiel is built and operated by Finray Technologies Ltd, the publisher of this radar. XZiel is recused from any qualitative ranking. It appears only to keep the buyer-guide vendor universe complete under the editorial methodology at /intelligence/methodology/.
How to read this alongside other Finray radars
Read this radar with the MiCA CASP compliance buyer guide at /intelligence/casp-mica-compliance/, the authorised-CASP register radar at /intelligence/mica-casp-licensing-success/, the authorisation-withdrawals radar at /intelligence/mica-casp-authorisation-withdrawals/, the AMLR and AMLA implementation tracker at /intelligence/amlr-amla-implementation-tracker/, and the Swiss FINMA GRC and ICS radar at /intelligence/swiss-finma-grc-ics/.
Those radars answer different questions. The CASP buyer guide maps the vendor universe. The licensing-success radar maps authorised CASP population evidence. The withdrawals radar maps named regulatory outcomes, without converting those outcomes into unsupported Travel Rule failure stories. The AMLR and AMLA tracker maps the wider AML perimeter. The Swiss GRC and ICS radar provides a useful control-governance comparator for firms operating across EU and Swiss supervisory expectations.
The deeper point is simple: the Travel Rule is not an isolated crypto compliance task. It is a transfer-decision evidence problem. If the architecture cannot route identity, counterparty, wallet, sanctions, monitoring and exception evidence into one defensible decision record, the firm has not solved the problem. It has only installed another message rail.