The Travel Rule (the obligation to pass originator and beneficiary data with every qualifying virtual-asset transfer) has moved from a FATF policy recommendation to a live, audited compliance requirement across the flagship licensing jurisdictions. A virtual-asset service provider that operates without a documented Travel Rule compliance program faces enforcement action, correspondent-banking termination and, in the most aggressive regulatory environments, licence revocation. This analysis maps the legal lines regulators and supervisors are drawing, the structural choices operators face across multiple jurisdictions, and the internal governance architecture that a defensible program requires.
What Does the Travel Rule Actually Require from a VASP?
The Travel Rule obliges a VASP (virtual asset service provider) to collect, verify and transmit originator and beneficiary information alongside every qualifying virtual-asset transfer – mirroring the wire-transfer rules that banks have carried for decades under FATF Recommendation 15. The obligation runs in both directions: the originating VASP must send the data; the beneficiary VASP must receive, validate and retain it. Failure on either side creates a compliance gap that supervisors can and do act on.
The specific data fields required – name, account identifier, physical address or national identity number, date of birth – follow the FATF standard, but each implementing jurisdiction layers its own threshold and de-minimis rules on top. Under MiCA and the EU Transfer of Funds Regulation, no de-minimis applies to crypto-asset transfers between CASPs, meaning the obligation activates from the first euro of value. Singapore's Payment Services Act regime and the MAS Travel Rule guidance take a broadly comparable position. Other hubs set a threshold above which the full data set is mandatory and below which a reduced data set suffices; that threshold varies and operators serving multiple markets must apply the most conservative standard that applies to each transfer leg.
Cross-border complexity is the rule, not the exception. A Singapore-licensed VASP routing a transfer to a counterpart VASP in Dubai – supervised by VARA – must satisfy the Travel Rule requirements of both sides. Where the receiving VASP operates in a jurisdiction that has not yet enacted Travel Rule obligations, the originating VASP's home supervisor may still require it to conduct enhanced due diligence on the unhosted-wallet risk that the gap creates. Regulators in the leading hubs increasingly expect operators to document how they manage exactly this asymmetry.
The process above describes the standard path. Your facts – the jurisdictions in which you hold licences, your user geography and your counterpart-VASP relationships – change the analysis materially. For a scoped assessment of your Travel Rule exposure, contact OBOLUS at info@oboluslaw.com.
Where Are the Legal Lines Drawn Across the Major Hubs?
The legal lines differ by regulator, and the divergences are operationally significant for any business running a multi-jurisdiction footprint. The following is not an exhaustive survey; it is a practitioner's map of the fault lines operators most frequently encounter in our practice.
European Union – ESMA and the MiCA/TFR stack. The EU Transfer of Funds Regulation, extended to crypto-asset transfers under MiCA, requires CASPs to transmit originator and beneficiary data on all transfers regardless of value. ESMA and national competent authorities are the supervisory layer. Passporting under MiCA means that a CASP authorised in one member state may serve the entire EU/EEA – but the Travel Rule obligation travels with the passport. A CASP that obtains a Lithuanian or Maltese MFSA authorisation and then routes transfers to non-EU counterparts must still satisfy the full TFR data standard on the outbound leg.
UAE – VARA and the Dubai Rulebooks. VARA's activity-based licensing regime covers transfer and settlement as a discrete licensed activity. The VARA AML/CFT rulebook incorporates FATF Recommendation 15 and requires licensed VASPs to implement Travel Rule procedures as a condition of continued authorisation. VARA has demonstrated a willingness to issue detailed compliance notices, and supervisory attention to Travel Rule program quality – not merely Travel Rule policy existence – is increasing.
Singapore – MAS and the Payment Services Act. MAS published explicit Travel Rule guidance applicable to Digital Payment Token service providers. The guidance addresses the sunrise-issue problem directly: where a counterpart VASP in another jurisdiction cannot technically receive structured Travel Rule data, the originating VASP must retain the data and apply compensating controls. MAS has signalled that "we tried but the counterpart couldn't receive it" is not a complete defence; the compensating-control framework must be documented and applied consistently.
UK – FCA and the MLR framework. Cryptoasset businesses registered under the Money Laundering Regulations must implement Travel Rule obligations as part of their AML/CFT framework. The FCA has published expectations for Travel Rule implementation and has noted in supervisory communications that program maturity – not just policy adoption – is the standard it applies. A firm that has a Travel Rule policy but cannot demonstrate operational transmission of data, counterpart due diligence records and a sunrise-issue response procedure is not compliant.
Hong Kong – SFC VASP licensing regime. The SFC's VATP licensing framework incorporates AML/CFT requirements aligned to the FATF standard. Travel Rule compliance is a licence condition, and the SFC's inspection approach assesses operational effectiveness, not merely the existence of written policies.
How Does the Sunrise Issue Change Your Compliance Exposure?
The "sunrise issue" – the compliance gap that arises when a VASP in a Travel-Rule-compliant jurisdiction sends a transfer to a counterpart in a jurisdiction that has not yet implemented the obligation – is one of the most practically consequential problems in Travel Rule compliance program design. It is not hypothetical: a significant portion of global virtual-asset transfer volume still flows to or from counterparts operating in jurisdictions with incomplete or no Travel Rule implementation.
Regulators that have addressed the sunrise issue directly – including MAS in Singapore and ESMA at the EU level – take the position that the originating VASP's obligation to collect and transmit data does not disappear because the receiving side cannot accept it. The required response is a risk-based compensating-control framework: the originating VASP must assess the risk profile of the counterpart, document the technical barrier, apply enhanced transaction monitoring to the transfer and, in higher-risk situations, decline the transfer or apply manual review before execution.
In our cross-border practice, we see operators underestimate this obligation regularly. A common structural mistake is treating the sunrise issue as a "technical gap to be resolved by the solution vendor" rather than a legal-compliance decision that requires documented risk-based reasoning at the transaction level. The vendor may enable the transmission; the legal obligation to apply compensating controls where transmission is not possible belongs to the VASP's compliance function, not to the software.
Unhosted wallets introduce a related but distinct compliance question. Where a VASP's customer sends a transfer to or receives one from a wallet that is not held at another regulated VASP – a self-custodied wallet – the Travel Rule data-transmission mechanism does not apply in the same way. Most major hubs require the VASP to conduct enhanced due diligence on the unhosted-wallet counterpart: confirming, at minimum, that the wallet is controlled by the customer claiming it, and applying transaction monitoring calibrated to the risk that the wallet is controlled by a third party. The VARA rulebooks, MAS guidance and the FCA's expectations all address unhosted-wallet risk as a standalone compliance topic within the AML/CFT framework.
What Does a Defensible Travel Rule Compliance Program Look Like?
A defensible Travel Rule compliance program is not a single policy document – it is a governance architecture that integrates legal obligations, operational procedures, technology and documented decision-making. Regulators auditing program quality look at all four layers; a gap in any one undermines the whole.
The first layer is the legal mapping exercise: a current, jurisdiction-by-jurisdiction analysis of the threshold, data fields, counterpart-due-diligence expectations and unhosted-wallet treatment that apply to every licence the operator holds and every market it serves. This is not a one-time exercise. MiCA's TFR extension, VARA rulebook updates and MAS guidance iterations have all changed the legal standard within recent supervisory cycles. A program built on a mapping that is more than twelve months old is likely stale in at least one material respect.
The second layer is counterpart VASP due diligence. Before a VASP transmits Travel Rule data to – or receives it from – a counterpart, it should have assessed whether that counterpart is itself subject to equivalent AML/CFT obligations, whether its Travel Rule implementation is technically and operationally functional, and what compensating controls apply if it is not. This assessment should be documented and updated on a risk-triggered schedule. Regulators expect to see it.
The third layer is transaction-level operational procedure: the workflow by which a transfer is screened, the data is assembled, transmitted or retained (with the reason for retention documented), and the outcome is recorded. This layer is where many programs break down in practice. A policy that says "we will transmit data" is not the same as a procedure that specifies who assembles the data, what system transmits it, what happens if the transmission fails, and who has authority to release a held transfer.
The fourth layer is governance and MLRO accountability. A MLRO (Money Laundering Reporting Officer) with clear mandate over the Travel Rule program, an escalation path for sunrise-issue decisions, a testing and audit cycle, and documented senior-management oversight is the governance standard that most flagship regulators apply. Where an operator has multiple group entities across different jurisdictions, the governance map must address which MLRO has authority over which transfer leg and how group policy interacts with local-law obligations.
Does Your Travel Rule Solution Vendor Manage the Legal Risk?
Technology solutions for Travel Rule data exchange – the interoperable messaging protocols that allow two VASPs to exchange originator and beneficiary data in a structured format before a transfer settles – are a necessary component of any operational program. They are not a sufficient one. The legal risk sits with the VASP, not with the vendor.
This distinction matters for three practical reasons. First, the vendor's system can only transmit what the VASP's own KYC process has collected and verified. If the underlying KYC (know your customer) data is incomplete or unverified, the transmitted data is legally deficient regardless of the protocol used. Second, most vendor solutions address the transmission mechanism; they do not automatically implement the risk-based compensating-control decisions that sunrise-issue and unhosted-wallet scenarios require. Those decisions require legal judgment, documented at the transaction level by the VASP's compliance function. Third, regulators audit the VASP – not the vendor – and the VASP cannot delegate the compliance obligation contractually.
Operators we advise routinely discover, on a compliance review, that their solution-vendor integration is incomplete in one of two ways: the vendor supports Travel Rule data exchange between registered counterparts but has no documented workflow for unregistered or sunrise-issue counterparts; or the vendor's solution covers only transfers above the platform's own threshold setting, which may not match the regulatory threshold in every jurisdiction the operator serves. Both gaps are legal compliance failures, not technical ones.
A further dimension: where an operator uses a third-party custodian or a sub-custody arrangement, the question of which entity bears the Travel Rule originator or beneficiary VASP obligation on a given transfer must be resolved contractually and operationally before the architecture goes live. We have seen custody and exchange agreements that are silent on this allocation, creating an unresolved gap that a regulator examining a specific transfer could characterise as a systemic program failure.
How Do Multi-Jurisdiction Operators Manage Conflicting Travel Rule Standards?
A multi-jurisdiction operator – a business holding, for example, a MiCA CASP authorisation in an EU member state, a VARA licence in Dubai and an SFC VATP licence in Hong Kong – faces a compliance matrix in which the legal standard for any given transfer is determined by the most demanding of the applicable rules. Managing that matrix requires more than a single group Travel Rule policy; it requires a jurisdiction-specific annex structure and a transfer-routing decision tree that compliance staff can apply at transaction time.
The EU/MiCA standard – no threshold, full data set on all CASP-to-VASP transfers – is currently among the most demanding in terms of scope. An operator subject to MiCA cannot rely on a higher threshold in a counterpart's home jurisdiction as a basis for reducing the data it transmits on the outbound leg. The MiCA obligation runs on the originating CASP's side, unconditionally.
VARA's framework aligns closely to the FATF standard. Where VARA-licensed and MiCA-licensed entities in the same group exchange transfers, the group must be able to demonstrate that data is being transmitted at the MiCA standard (since that is the more demanding), and that the VARA entity's receipt and retention of data satisfies the VARA rulebook on the inbound side. In our practice, we have seen group structures where this was not mapped before go-live, resulting in a compliance gap that required a retrospective remediation program.
Banking relationships add a further constraint. Correspondent banks that provide fiat-clearing services to crypto businesses increasingly conduct their own AML program reviews of VASP clients. A VASP that cannot demonstrate a mature, operational Travel Rule compliance program – including documented counterpart due diligence and a sunrise-issue procedure – is at elevated risk of having its banking relationship declined or terminated on AML grounds. The connection between Travel Rule program quality and banking access is direct and, in our experience advising businesses across multiple hubs, underappreciated at the board level.
If a prior application stalled or a banking relationship was lost on AML grounds, a structured review can surface the program gap and the route back. Write to OBOLUS at info@oboluslaw.com to initiate a confidential assessment.
Which Compliance Architecture Fits Your Operator Profile?
The right Travel Rule compliance architecture depends on the operator's licence footprint, transfer volume, counterpart network and custody model. No single template fits all profiles. The following matrix describes the principal decision branches we work through with clients in practice.
Profile A – Single-jurisdiction licensed exchange, homogeneous user base, institutional counterparts only. This operator's Travel Rule exposure is relatively contained. The legal mapping covers one regulator's requirements; the counterpart VASP universe is small and predominantly regulated; sunrise-issue frequency is low. The defensible program here centres on a clean legal mapping document, a vendor integration that covers the full counterpart universe, and a governance structure in which the MLRO has direct visibility over Travel Rule transmissions and exceptions. The primary risk is complacency: a program that works well for institutional counterparts may break when the operator onboards a retail segment or a new jurisdictional corridor.
Profile B – Multi-jurisdiction licensed operator, retail and institutional, broad counterpart network. This is the operator for whom the compliance matrix is most complex. The program requires a jurisdiction-specific annex for each regulator, a transfer-routing decision tree, documented sunrise-issue compensating controls, and a group-governance structure that resolves MLRO authority across entities. The vendor solution must be stress-tested against the most demanding standard in the footprint – typically the EU/MiCA TFR standard. Banking relationships should be supported by a compliance summary that documents program maturity, not just policy existence.
Profile C – DeFi-adjacent operator with unhosted-wallet volume. Where a significant proportion of transfer volume involves unhosted wallets, the program must go beyond standard VASP-to-VASP Travel Rule procedures and build a documented unhosted-wallet due diligence framework. This framework must address: wallet-ownership verification, transaction monitoring calibrated to the unhosted-wallet risk tier, and escalation procedures for transfers that exceed risk thresholds. VARA, MAS and the FCA all have published expectations for this profile. The legal mapping exercise for this operator is more complex and must be updated more frequently as regulatory guidance evolves.
Profile D – Token issuer or custodian not operating an exchange. A business that issues tokens and uses a third-party exchange for distribution, or that provides custody without itself executing transfers, must resolve whether it falls within the VASP definition under the applicable regime for Travel Rule purposes. In most MiCA and FATF-aligned regimes, certain custody activities trigger VASP status and therefore Travel Rule obligations, even without an exchange function. The legal mapping exercise is the first step; the program architecture follows from that determination.
Where Does MLRO Accountability Begin and End?
The MLRO – or, in some jurisdictions, the AML compliance officer – is the individual accountable to the regulator for the adequacy of the AML/CFT program, including the Travel Rule component. That accountability is personal, not merely institutional. Regulators in the UK, the EU member states and the VARA regime all have authority to take enforcement action against individual compliance officers where a program failure is attributable to inadequate oversight or wilful neglect.
In our practice, we regularly see three structural weaknesses in MLRO governance that create personal and institutional exposure. First: an MLRO who has formal accountability but no operational line of sight into Travel Rule transmissions and exceptions. If the MLRO cannot, at any given moment, produce a report showing which transfers in the last audit period had Travel Rule data transmitted, which had data retained under sunrise-issue procedures and why, and which triggered escalation, the governance structure is not functioning. Second: an MLRO whose mandate covers only the registered entity and not the group's full transfer activity. Where a group routes certain transfers through an unregulated or lightly regulated affiliate, the MLRO of the regulated entity may nonetheless face scrutiny if the transfer is connected to the regulated entity's clients. Third: an MLRO who is also the chief executive or chief financial officer. Regulatory concentration of the compliance oversight function in the same individual responsible for commercial decisions is a governance red flag that regulators in all major hubs have specifically commented on.
In a recent compliance review matter, a payments business operating under a MiCA-transitional authorisation had a documented Travel Rule policy but no operational mechanism for the MLRO to monitor exception cases – transfers where data had been retained rather than transmitted. When the national competent authority conducted a targeted review, the gap was treated not as a technical deficiency but as a governance failure at the MLRO level. We assisted in designing a remediation framework that addressed both the operational gap and the governance accountability structure, including a reporting cadence and escalation protocol that satisfied the supervisor's requirements. The outcome was a structured compliance undertaking rather than a formal enforcement action.
What Are the Most Consequential Mistakes in Travel Rule Program Design?
A common assumption is that Travel Rule compliance is primarily a technology procurement question – select a recognised protocol solution, integrate it with the core platform and the obligation is met. That assumption is incorrect, and acting on it is the single most consequential mistake we encounter in program reviews.
The technology layer enables data transmission. It does not constitute a compliance program. The legal obligation includes: a current legal mapping across every jurisdiction the operator is subject to; a counterpart VASP due-diligence procedure; a documented compensating-control framework for sunrise-issue and unhosted-wallet scenarios; a transaction monitoring calibration specific to Travel Rule risk; a governance structure with MLRO accountability; and a testing and audit cycle that verifies operational effectiveness, not just policy existence.
A second consequential mistake is treating the Travel Rule obligation as static. The regulatory standard is evolving: ESMA has published updated CASP guidance; VARA has issued rulebook amendments; MAS has updated its Travel Rule guidance. An operator whose program was designed to meet the standard as it stood at licensing but has not been reviewed since is likely non-compliant in at least one material respect today.
A third mistake – specific to multi-entity group structures – is failing to resolve, at the contract and operational level, which entity bears the originating VASP obligation and which bears the beneficiary VASP obligation on intergroup transfers. Where a group routes transfers through multiple licensed entities before they reach an external counterpart, the compliance obligation attaches at each VASP-to-VASP leg. Gaps in this intergroup mapping are a recurring finding in supervisory reviews of larger group structures.
A fourth mistake is underestimating the interaction between the Travel Rule program and the broader AML/KYC framework. Travel Rule data quality depends on the integrity of the upstream KYC process. A VASP that has a Travel Rule transmission mechanism but a weak or inconsistent KYC process is transmitting unreliable data – which is itself a compliance failure under most implementing regimes. Transaction monitoring calibrated to Travel Rule risk is a distinct layer on top of standard AML transaction monitoring; it needs to be designed, documented and tested separately.
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – how OBOLUS structures end-to-end AML and Travel Rule programs for VASPs across jurisdictions
- Sanctions screening for crypto businesses in Jersey – the intersection of sanctions compliance and AML obligations for crypto operators in Jersey
- Crypto exchange licensing – practical lessons for boards – strategic licensing decisions and the compliance obligations that attach to each licence category
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to collect, verify and transmit originator and beneficiary identifying information alongside every qualifying virtual-asset transfer. The originating VASP must send the data; the beneficiary VASP must receive, validate and retain it. The specific data fields, applicable threshold and compensating-control expectations for transfers to non-compliant counterparts vary by jurisdiction and must be assessed for each regulatory regime the operator is subject to.
Who must act as MLRO for a crypto firm?
Most flagship licensing regimes – including the MiCA/ESMA framework, VARA in Dubai, MAS in Singapore and the FCA in the UK – require a designated MLRO (Money Laundering Reporting Officer) or equivalent AML compliance officer who holds personal accountability for the adequacy of the AML/CFT program. That individual must have operational oversight of the Travel Rule program, a clear escalation mandate and direct access to senior management. Combining the MLRO role with executive commercial responsibility is a governance structure that regulators across the major hubs have specifically flagged as inadequate.
How do regulators audit crypto AML programs?
Regulators in the leading hubs – ESMA's network of national competent authorities, VARA, MAS and the FCA – audit AML programs by assessing operational effectiveness, not merely the existence of written policies. Typical audit lines include: evidence of Travel Rule data transmission and exception records; counterpart VASP due diligence documentation; transaction monitoring calibration and testing records; governance structure and MLRO reporting lines; and documented compensating-control decisions for sunrise-issue and unhosted-wallet scenarios. A program that exists on paper but cannot be evidenced operationally will not satisfy a supervisory review.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance obligations – including Travel Rule program design – that sit around them. We map the licence stack across operating, custody and payment layers before you commit, and we advise on the AML architecture that regulators in the major hubs expect to see. Digital assets are the whole of our practice. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Roman Levitt, Technology & DeFi Counsel – specialising in the legal architecture of Travel Rule compliance programs, protocol-layer obligations and multi-jurisdiction VASP governance structures.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.