For a virtual asset service provider (VASP) – an exchange, custodian, broker or payment facilitator dealing in digital assets – the Travel Rule (the obligation under FATF Recommendation 15 to pass originator and beneficiary data with every qualifying virtual-asset transfer) is the single most operationally disruptive compliance requirement of the current cycle. Unlike traditional wire-transfer obligations that banks have managed for decades, the Travel Rule arrived in a market built on pseudonymous addresses, fragmented counterparty networks and no universal messaging protocol. The result is a patchwork of inconsistent national implementations, bilateral data-sharing failures and growing regulatory scrutiny. This analysis maps where the obligations stand, where they break down, and what a cross-border VASP must do to operate without exposing its rails to regulatory action.
What Does the Travel Rule Actually Require from a VASP?
The Travel Rule requires a VASP to collect, verify and transmit specified originator and beneficiary data alongside every virtual-asset transfer that meets or exceeds the applicable threshold – and to apply enhanced scrutiny when that data cannot be confirmed. FATF Recommendation 15, updated in 2019 and elaborated through subsequent FATF guidance, extended the wire-transfer Travel Rule to virtual-asset transfers, treating VASPs as functional equivalents of financial institutions for this purpose. The core data set – originator name, account or wallet identifier, and physical address or national identification – must travel with the transaction so that the receiving institution can screen it.
In our cross-border practice, the first thing we explain to clients is that the Travel Rule is not one rule. It is a baseline principle that each jurisdiction has implemented differently: different thresholds, different data fields, different grace periods and different enforcement postures. FATF's Recommendation 15 sets the floor; the ceiling is built locally. A VASP moving assets between Singapore and the EU, or between the UAE and Lithuania, operates under at least two distinct Travel Rule regimes simultaneously – and must satisfy both.
The compliance obligation attaches in two directions. The originating VASP must collect and transmit data before or alongside the transfer. The beneficiary VASP must receive and screen that data, flag discrepancies and – under most implementations – reject or hold transactions where required data is missing or unverifiable. Neither institution can outsource that obligation to the other.
The process above describes the standard path. Your facts – the entity structure, the user base, the technology stack – change the analysis considerably. For a scoped assessment of how the Travel Rule applies to your specific business model and jurisdictional footprint, contact OBOLUS at info@oboluslaw.com.
Where National Implementations Diverge Most Sharply
Jurisdictional divergence in Travel Rule implementation creates the core operational problem: a VASP that is fully compliant in its home jurisdiction may still be transmitting non-compliant data packets to a counterparty regulated elsewhere. The divergences cluster around four axes: threshold amounts, required data fields, treatment of unhosted wallets and sunrise-period status.
Under the MiCA regime and the EU's Transfer of Funds Regulation (TFR) as it applies to crypto-assets, the threshold for full data transmission obligations sits at a level that captures the overwhelming majority of retail and institutional transfers – and there is no de-minimis exemption comparable to what some non-EU jurisdictions apply. Every transfer between two VASPs requires the full data set, regardless of size. Singapore's MAS regime under the Payment Services Act sets a threshold that differs from the EU's, meaning a Singapore-based exchange sending to an EU counterpart must satisfy the stricter standard.
The treatment of unhosted wallets (wallets not held by a regulated VASP – self-custody addresses, hardware wallets, protocol-level addresses) is where implementation diverges most dramatically. Some jurisdictions require the VASP to collect and verify information about the beneficial owner of an unhosted wallet before processing a transfer to or from it. Others apply a risk-based approach, requiring enhanced due diligence above a threshold. Still others have not yet issued definitive guidance. A VASP advising its compliance team that "unhosted wallets are low-risk" based on its domestic regulator's silence is exposed the moment it processes a transfer from a counterparty regulated in a jurisdiction with a stricter standard.
The sunrise problem – the period during which one jurisdiction has implemented the Travel Rule and a counterparty jurisdiction has not – is nominally closing as more regimes come into force. But in practice, the operational burden has shifted. VASPs now face the VASP counterparty identification problem: before transmitting data, the originating VASP must establish whether the receiving address belongs to a regulated VASP, an unhosted wallet or an unknown entity. No global registry resolves this automatically. Solutions are commercial and proprietary – and interoperability between them is incomplete.
Why the Technical Architecture Creates Legal Risk
The technical infrastructure gap is a legal risk, not merely an engineering inconvenience. When Travel Rule data fails to transmit – because two counterparty VASPs use incompatible messaging protocols, because one does not participate in any Travel Rule solution, or because a blockchain-native transfer bypasses the VASP layer entirely – the originating VASP faces a compliance failure it may be unable to prevent through contract alone.
Several Travel Rule messaging solutions operate in the market, each with a different network of participating VASPs. No single solution has achieved universal adoption. A VASP connecting to one solution may be able to exchange data with half its counterparty universe and is structurally unable to reach the other half through that channel. The legal consequence is that the VASP must either maintain memberships in multiple solutions, halt transfers to non-participating counterparties, or document a risk-based workaround that will withstand regulatory scrutiny.
In our practice, we regularly advise clients that documenting the workaround is as important as the workaround itself. A VASP that has made genuine, auditable efforts to obtain Travel Rule data – attempted outreach, rejection of non-responsive counterparties above the threshold, escalated due diligence – is in a materially stronger position before a regulator than one that processed transfers silently and claimed the technical gap as an excuse. The FCA, MAS and VARA have each signalled that good-faith procedural compliance, properly documented, will be a factor in enforcement discretion. That signal is not a safe harbour.
The DeFi dimension adds a further layer. Where a VASP's users interact with decentralized protocols directly, the VASP may be the last regulated touchpoint in a transaction chain. Whether the VASP's obligation extends to transfers originating or terminating at protocol-level addresses is a live question that regulators in several leading jurisdictions have not definitively answered. The prudent approach is to treat any transfer to or from an address associated with a DeFi protocol with the same enhanced diligence applied to unhosted wallets, until the regulatory position crystallises.
The Cross-border Data Conflict: Privacy Law vs. AML Obligation
A VASP operating across multiple jurisdictions faces a structural conflict between its Travel Rule data-transmission obligation and applicable data-protection law. Transmitting originator and beneficiary personal data internationally – name, identifier, address – engages data-protection requirements in every jurisdiction touched by the transfer. In the EU, the GDPR applies to transfers of personal data outside the EEA and imposes conditions on lawfulness, purpose limitation and cross-border transfer mechanisms. A VASP transmitting Travel Rule data from an EU-regulated entity to a non-EEA VASP is simultaneously obliged to transmit by the MiCA TFR regime and constrained in how it transmits by the GDPR.
This is not a theoretical tension. Regulators in the major hubs increasingly expect VASPs to have analysed and resolved this conflict in their compliance documentation – not to have noticed it and deferred resolution. The legal basis for processing and transmitting Travel Rule data must be identified, documented and embedded in the privacy notice and the data-retention policy. Where the counterparty jurisdiction has no adequate data-protection framework recognised by the EU, the VASP must rely on an approved transfer mechanism or a derogation.
We have seen this issue arise acutely for clients structured with an EU-licensed entity and a non-EU operational hub. The EU entity is bound by the GDPR; the data must travel to the non-EU hub for screening and onward transmission; and the receiving hub may sit in a jurisdiction with no adequacy decision and no standard contractual clause arrangement in place. The fix is structural, not cosmetic – it requires either a data-processing agreement with appropriate transfer safeguards, a restructured data flow, or a reassignment of processing responsibilities across the group. Each option has different cost and timeline implications.
Which Travel Rule Architecture Fits Your Business Profile?
The right Travel Rule compliance architecture depends on the VASP's business model, counterparty universe and regulatory footprint. A single solution does not fit all profiles. The analysis below maps four common operator types to the compliance architecture that best manages their risk exposure.
Profile A – Institutional OTC broker with a known, recurring counterparty set. This operator transacts in large size with a limited number of regulated counterparties, most of whom participate in at least one Travel Rule messaging network. The appropriate architecture is a single Travel Rule solution with direct onboarding of key counterparties, supplemented by a policy requiring confirmed VASP status before any new counterparty is activated. The primary risk is the unhosted-wallet edge case where a counterparty settles to a proprietary custody address. Timeline for implementation: typically measured in weeks once the solution is selected and counterparty agreements are in place.
Profile B – Retail exchange with a broad, anonymous user base across multiple jurisdictions. This operator faces high volume, frequent unhosted-wallet interactions and a counterparty universe that is partially outside regulated Travel Rule networks. The appropriate architecture combines a multi-solution Travel Rule connector, a VASP counterparty identification tool (to distinguish regulated from unhosted addresses at scale), and an automated hold-and-review queue for transfers where data cannot be confirmed. Regulators in the leading hubs – the FCA, MAS and ESMA-supervised NCAs – expect this profile to demonstrate systemic controls, not ad hoc review. Timeline: longer; the integration with the exchange's transaction-monitoring infrastructure determines the critical path.
Profile C – Custodian receiving transfers on behalf of institutional clients. The custodian sits at the beneficiary end of the Travel Rule obligation. Its primary obligation is to receive, screen and retain data – and to raise a suspicious transaction report when data is missing, inconsistent or linked to a flagged counterparty. The risk here is beneficiary-side liability for transfers it accepts without adequate incoming data. The architecture is a Travel Rule inbox, integrated with the transaction-monitoring system and with a clear escalation protocol for incomplete data packets. A documented "reject-and-notify" policy for non-compliant inbound transfers is essential before the regulator asks for it.
Profile D – Cross-border payment facilitator routing stablecoin transfers. This operator is the most exposed profile. It processes high volumes, operates across multiple regulatory perimeters, and may be touching transfers that engage both the Travel Rule and wire-transfer regulations in the same corridor. The architecture requires legal opinions on the applicable regime in each corridor, a Travel Rule solution capable of cross-border data transmission, and a documented analysis of how GDPR or equivalent data-protection law applies to each data flow. The compliance build is the most complex; the regulatory exposure for gaps is the highest.
How Regulators Are Auditing Travel Rule Compliance
Regulatory audit of Travel Rule compliance has moved from a paper-review exercise to a technical examination. Supervisors in the leading hubs increasingly review transaction data directly, looking for patterns that indicate systematic non-collection or non-transmission of required information. A VASP that has a Travel Rule policy but has not operationalized it – where the policy document exists but the system does not enforce it – will not survive a technical audit.
The FCA has been explicit that it expects cryptoasset businesses registered under the Money Laundering Regulations to have Travel Rule-compliant systems operational, not merely planned. The MAS under the Payment Services Act regime has similarly signalled that Travel Rule obligations are a key focus of supervisory review for licensed digital payment token service providers. VARA in Dubai has embedded Travel Rule requirements directly into its activity-specific rulebooks, and its supervisory framework includes on-site and off-site review mechanisms.
In our practice, we have observed a consistent regulatory expectation across the major hubs: regulators want to see a documented risk assessment of the VASP's Travel Rule exposure, a technical solution that is operationally live, a testing record showing it functions as intended, and a policy for handling the edge cases – missing data, unhosted wallets, non-participating counterparties. The absence of any one of these four elements is, in our experience, a finding that triggers remediation timelines and, in repeat or aggravated cases, enforcement action.
A micro-matter from our recent practice illustrates the pattern. In a recent engagement, a payments company licensed in an EU member state had onboarded a Travel Rule solution and trained its compliance team. A supervisory review revealed that the solution had not been integrated with the firm's transaction-processing layer: Travel Rule data was collected but not transmitted automatically, requiring manual steps that were frequently skipped under volume pressure. We assisted the client in mapping the integration gap, restructuring the data flow and producing a remediation report for the regulator. The firm avoided formal enforcement, but the timeline for remediation – and the management attention it consumed – was substantial. The lesson: a Travel Rule solution in procurement is not a Travel Rule solution in compliance.
If a prior compliance build stalled or a regulator has raised questions about your Travel Rule architecture, a structural review can surface the gap and the route to remediation. Write to OBOLUS at info@oboluslaw.com to discuss a scoped assessment.
Who Bears Personal Responsibility: The MLRO's Travel Rule Exposure
The MLRO (Money Laundering Reporting Officer) is personally accountable for the effectiveness of the firm's AML/CFT controls, including Travel Rule compliance, in every jurisdiction that requires the role. That personal accountability is not discharged by approving a policy document. It requires active oversight of the system that implements the policy – and a record demonstrating that oversight was exercised.
For a VASP operating across multiple regulatory perimeters, the MLRO question is complicated by structure. A group with entities in the EU, the UAE and Singapore may have an MLRO in each jurisdiction, each accountable to a different regulator, each applying a different standard. The MFSA, VARA and MAS each prescribe fitness-and-propriety standards for the MLRO role, and each expects the individual to be genuinely senior – capable of challenging the business and escalating without interference.
The cross-border reality is that the MLRO in one jurisdiction does not have supervisory authority over the AML program in another. But regulators increasingly look at group-level AML governance and ask whether the MLRO in their jurisdiction is receiving the information and resources necessary to be effective. A VASP that assigns MLRO responsibilities to a junior compliance officer as a cost-saving measure – or that structures its group so that the local MLRO has no authority over the Travel Rule system operated by the parent – is creating a governance gap that a regulator will find.
We regularly advise clients on MLRO mandate design: the scope of authority, the reporting line, the information rights and the documentation standards that demonstrate genuine independence. The design of that mandate across a multi-jurisdictional group is a legal question, not merely an HR question.
A Common Assumption Worth Examining: The "Single Offshore Licence" Myth
A common assumption among founders and CFOs structuring a new digital-asset business is that a single licence in a favourable offshore jurisdiction is sufficient to operate globally. That assumption is incorrect in almost every case where the business has substantive users, banking relationships or operational staff in jurisdictions with their own regulatory perimeters. The Travel Rule makes this particularly clear: even if a VASP is licensed only in the BVI under the VASP Act 2022, if it sends transfers to or from users or counterparties in the EU, it is interacting with parties subject to the MiCA TFR regime, and its data packets must conform to that standard on the receiving end.
The offshore-licence structure can serve legitimate purposes – holding company efficiency, banking access, investor preference for a recognised jurisdiction. But it does not insulate the business from the AML and Travel Rule obligations of every jurisdiction in which its transfers land. Regulators in the leading hubs have demonstrated a consistent willingness to reach beyond the formal place of incorporation and apply their standards to the substance of the business activity directed at their markets.
The practical consequence is a licence stack – multiple regulated entities or registrations, each satisfying the requirements of the relevant jurisdiction. Designing that stack correctly requires analysis of where the users are, where the banking is, where the custody is held and where the Travel Rule obligations attach. A structure built on a single offshore licence, without that analysis, is a structure built on a compliance assumption that is unlikely to hold.
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – our full-service compliance practice across the major VASP regimes
- Transaction monitoring setup in Estonia – practical guidance on establishing a compliant monitoring infrastructure in an EU licensing jurisdiction
- De-risking and account closure defence – what recent enforcement trends reveal about managing banking relationships under AML pressure
FAQ
What does the Travel Rule require from a VASP?
Under FATF Recommendation 15, a VASP must collect, verify and transmit specified originator and beneficiary information – including name, wallet or account identifier and physical address or national identification number – alongside every qualifying virtual-asset transfer at or above the applicable threshold. The beneficiary VASP must receive and screen that data. Implementation details, including thresholds and required data fields, vary by jurisdiction: the EU's TFR under MiCA, Singapore's Payment Services Act regime and VARA's rulebooks each apply their own standards, and a VASP operating cross-border must satisfy the strictest applicable standard across the transaction corridor.
Who must act as MLRO for a crypto firm?
Most regulated jurisdictions require a VASP to appoint a nominated Money Laundering Reporting Officer who bears personal accountability for the firm's AML and CFT controls. The individual must satisfy fitness-and-propriety standards set by the relevant regulator – the MFSA, VARA, MAS and FCA each prescribe their own criteria – and must be sufficiently senior to challenge the business and escalate concerns without impediment. In a multi-entity group, each regulated entity typically requires its own MLRO accountable to the local regulator, with group-level governance coordinating across the structure. Assigning the role to a junior officer or limiting its authority is a governance gap regulators actively look for.
How do regulators audit crypto AML programs?
Supervisors in the leading hubs – including the FCA, MAS and VARA – have moved beyond paper-based policy reviews to technical examination of transaction data and system architecture. A regulatory audit will typically assess whether the firm's Travel Rule solution is operationally integrated with its transaction-processing layer, whether the transaction-monitoring system generates alerts calibrated to the firm's risk profile, whether suspicious activity reports are filed accurately and promptly, and whether the MLRO can demonstrate active oversight rather than nominal appointment. Gaps between policy documentation and operational reality are a consistent audit finding and a predictor of enforcement action.
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 AML, Travel Rule and compliance architecture that sits around them. Digital assets are the whole of our practice. We map the licence and compliance stack across operating, custody and payment layers before you commit – and we act only for businesses, never for retail claimants. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in cross-border VASP compliance architecture, AML program design and Travel Rule implementation across EU, Gulf and Asia-Pacific regulatory regimes.
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.