Institutional digital-asset businesses operating across borders face a compliance obligation that is simultaneously universal and fragmented: the Travel Rule (the requirement under FATF Recommendation 15 to pass originator and beneficiary data with every qualifying virtual-asset transfer). Every significant regulatory regime – MiCA/ESMA in the European Union, VARA in Dubai, the Payment Services Act under MAS in Singapore, the FCA's anti-money-laundering regime in the United Kingdom, and the VASP frameworks in the BVI, Cayman Islands and beyond – has now embedded a version of the Travel Rule into its supervisory expectations. Getting the program wrong is not a technicality; it is a direct path to enforcement, account closures and loss of operating licences. This page sets out how a properly constructed Travel Rule compliance program works, where institutions most often fail, and how OBOLUS builds the cross-border architecture that regulators in the leading hubs now demand.
What the Travel Rule Actually Requires From a VASP
The Travel Rule requires a VASP (virtual asset service provider) to collect, verify and transmit originator and beneficiary data alongside every qualifying virtual-asset transfer – and to screen that data against sanctions lists before the transfer is executed. The obligation derives from the FATF Recommendations, specifically Recommendation 15 and its interpretive note, which defines the data fields required and the threshold above which the rule applies. Each jurisdiction translates that standard into domestic law differently: the precise threshold, the data fields mandated and the treatment of unhosted wallets vary from regime to regime, which means a multi-jurisdictional operator is not running one Travel Rule program but several overlapping ones.
Under MiCA and the EU's transfer-of-funds regulation, the obligation applies to transfers of any amount, with no de-minimis floor – a position stricter than FATF's baseline guidance. Under the VARA rulebooks in Dubai, the Travel Rule sits within a broader AML/CFT framework that requires transaction screening at the point of transfer. MAS in Singapore and the SFC in Hong Kong each publish guidance that maps the data transmission obligation onto their existing payment-service and VASP licensing conditions. In the United Kingdom, the FCA's Money Laundering Regulations incorporate the Travel Rule requirement as part of the broader AML registration conditions. The practical effect is that an institution with licensing relationships across these jurisdictions must maintain data transmission protocols that satisfy each regime simultaneously.
Compliance requires more than a vendor subscription. The institution must have a documented policy, a technology integration that actually transmits data between counterparty VASPs, a process for handling transfers to or from unhosted wallets, and a named MLRO (money laundering reporting officer) who can demonstrate ownership of the program to a regulator on demand. In our practice, we see institutions underestimate every one of those four requirements.
For a first assessment of your current Travel Rule gap, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity structure, the user base geography and the banking relationships – change the analysis materially.
What an Institutional-Grade Travel Rule Program Contains
A well-constructed Travel Rule compliance program for an institutional operator has six core components, each of which must be documented, tested and maintained as a living instrument rather than a one-time deliverable.
First, a jurisdictional mapping exercise. Before any policy is drafted, the institution must identify every regime in which it holds a licence, every regime in which its counterparties are regulated, and every regime whose rules may be triggered by the geographic profile of its users. The data-transmission obligation in one jurisdiction may be more demanding than in another; the program must satisfy the strictest applicable standard on each transfer.
Second, a KYC framework (the structured process for collecting and verifying customer identity) must be integrated with the Travel Rule data layer. The Travel Rule does not operate in isolation; it depends on the institution already holding accurate originator data. A KYC program that collects the right fields at onboarding is the prerequisite for Travel Rule compliance in operation. Institutions that treat KYC and Travel Rule as separate workstreams consistently fail both.
Third, a counterparty VASP due-diligence process. When transferring to another VASP, the transmitting institution must have reasonable assurance that the receiving institution is itself regulated and capable of receiving Travel Rule data. Most of the leading protocols – including the IVMS 101 messaging standard that underlies the majority of interoperable Travel Rule solutions – require a bilateral recognition step. Absent that step, data is transmitted into a void and the obligation is not met.
Fourth, an unhosted-wallet policy. Regulators across the major hubs now expect institutions to apply enhanced due diligence when a transfer involves a wallet that is not held at a regulated VASP. The policy must set out the threshold for enhanced due diligence, the evidence required from the customer and the conditions under which the institution declines a transfer.
Fifth, a transaction monitoring program calibrated to the institution's risk appetite. Transaction monitoring for Travel Rule purposes extends beyond screening the data fields; it includes behavioral analytics, velocity checks and sanctions screening at the point of transmission. The program must be tuned to the actual transaction profile of the institution, not to a generic template.
Sixth, an MLRO governance structure. The MLRO must have documented authority, adequate resources and a direct reporting line to the board or senior management. Regulators in the leading hubs – including VARA, the FCA and MAS – have each, in recent supervisory communications, signaled that the personal accountability of the MLRO is a live examination point.
How Cross-Border Operations Multiply Travel Rule Risk
Cross-border institutional operations create Travel Rule risk that is qualitatively different from single-jurisdiction exposure. The institution is not managing one regulatory relationship; it is managing a matrix of data-transmission obligations, each with its own threshold, data fields and enforcement posture, across entities and counterparties in multiple financial centers.
Consider a common structure: a holding company in one jurisdiction, an exchange entity holding a CASP authorisation under MiCA in the EU, a custody entity operating under the FSRA within ADGM in Abu Dhabi, and a payments rail running through Singapore under the Payment Services Act. Each entity is independently regulated. Each faces its own Travel Rule obligations. A transfer that crosses two of those entities is subject to two sets of rules simultaneously – and the data that satisfies the MAS standard may not satisfy the ESMA/NCA standard without supplementation.
The cross-border dimension also creates a counterparty risk that is easy to underestimate. When the receiving VASP is in a jurisdiction with a weaker or recently introduced Travel Rule regime, the transmitting institution may be required by its own regulator to treat the transfer as higher-risk and apply enhanced due diligence. FATF's mutual evaluation process increasingly flags jurisdictions where Travel Rule implementation is incomplete; institutions in well-supervised hubs are expected to know their counterparties' regulatory standing.
In our cross-border practice, we regularly advise institutions on the sequencing problem: which entity onboards the customer, which entity holds the Travel Rule data, and which entity has the obligation to transmit. Getting that sequencing wrong in the structure phase creates a compliance gap that is expensive to retrofit.
Where Institutional Travel Rule Programs Fail: The Four Common Mistakes
Institutions that arrive at OBOLUS with a pre-existing Travel Rule program almost always share one or more of four structural failures. Each of them is avoidable with proper architecture; each of them has produced enforcement consequences in at least one major jurisdiction.
The first failure is treating the Travel Rule as a technology problem rather than a legal and governance one. Deploying a Travel Rule vendor solution is necessary but not sufficient. The vendor transmits data; it does not draft the policy, train the staff, appoint the MLRO or map the jurisdictional matrix. Regulators conduct on-site and desktop reviews that go well beyond asking for a vendor certificate. The governance layer must be in place and demonstrable.
The second failure is failing to update the program as the regulatory environment changes. MiCA's transfer-of-funds rules, VARA's AML rulebook updates and MAS's evolving DPT guidance have all changed the operative requirements within the past few years. An institution that built its program to the 2021 FATF standard and has not reviewed it since is likely operating out of compliance in at least one jurisdiction where it holds a licence.
The third failure is the unhosted-wallet gap. Many institutions have a Travel Rule policy that addresses VASP-to-VASP transfers competently but says little about unhosted wallets. Regulators across the EU, UK, Singapore and Dubai have each signaled that the unhosted-wallet question is a supervisory priority. An institution without a documented, risk-calibrated unhosted-wallet policy is exposed.
The fourth failure is the absence of a counterparty VASP registry. Knowing to whom you are transmitting data, whether they are regulated, and whether they are capable of receiving IVMS 101 formatted data are foundational questions. Operators we advise routinely discover that their counterparty lists have never been audited against current regulatory status. A counterparty that was regulated when the relationship was established may have lost its licence, changed its jurisdiction or been placed on an FATF-flagged list.
What a Program Review Actually Looks Like in Practice
In a recent engagement, a mid-sized institutional exchange held licences in two EU member states under the prior VASP regime and was preparing for MiCA CASP authorisation. Its Travel Rule program had been built for one jurisdiction and had never been extended to the second. The counterparty VASP registry was a spreadsheet last updated some eighteen months earlier. We conducted a gap analysis across both entities, mapped the MiCA transfer-of-funds obligations against the existing policy, identified eleven counterparties whose regulatory status had lapsed or changed, and drafted a revised unhosted-wallet policy calibrated to the institution's actual transaction profile. The revised program was submitted as part of the MiCA authorisation file; the relevant national competent authority confirmed no further AML/Travel Rule queries during the review. The matter was completed over a single quarter.
Decision Matrix: Which Profile Needs Which Travel Rule Instrument
Not every institutional client needs the same Travel Rule intervention. The right instrument depends on the operator's current licensing position, the volume and geography of its transfers, and the maturity of its existing AML infrastructure.
Profile A: A newly licensed CASP or VASP building its first Travel Rule program. The institution needs a full-scope program build: jurisdictional mapping, policy drafting, KYC-to-Travel-Rule integration design, MLRO governance structure and counterparty VASP due-diligence framework. The timeline is typically several weeks for a focused engagement. The key risk at this stage is building to one jurisdiction's standard and leaving gaps in the others where a licence or user base triggers additional obligations.
Profile B: An institution with an existing program preparing for a regulatory review or licence renewal. The institution needs a gap analysis against current regulatory expectations in each relevant jurisdiction, a report suitable for submission to the regulator or inclusion in a licence file, and targeted remediation on the gaps identified. This is a shorter-scope engagement. The key risk is that a program built under a prior regime – MiCA's predecessors in Europe, for example, or the pre-VARA Dubai framework – will not satisfy the current supervisory standard without material revision.
Profile C: A multi-entity institutional group with operations across multiple hubs. The institution needs a group-level Travel Rule architecture review: which entity carries the primary obligation in each transfer type, how data flows between entities without creating a compliance gap, and how the group's MLRO governance structure demonstrates ownership to multiple regulators simultaneously. The timeline varies by complexity. The key risk is the sequencing problem described above – a structure designed for tax or operational efficiency that creates a Travel Rule gap at the inter-entity transfer level.
Profile D: An institution that has received a regulatory inquiry or enforcement notice relating to AML or Travel Rule. The institution needs immediate triage: an assessment of the inquiry's scope, an honest analysis of the program's current state against the regulator's stated concerns, and a remediation roadmap that can be presented to the regulator as evidence of good faith. The timeline is dictated by the regulatory clock, not by the institution's convenience. The key risk is under-responding to the inquiry – submitting a partial fix rather than a systematic remediation that closes the structural gap.
If a regulatory clock is running, reach the OBOLUS compliance desk now at info@oboluslaw.com. If a prior program has already been reviewed and flagged, a second read frequently surfaces the structural reason and the route to remediation.
Addressing the Offshore-Licence Assumption
A common assumption among institutional operators – particularly those who structured early in the digital-asset cycle – is that a single offshore licence provides adequate regulatory cover for a multi-jurisdictional user base. It does not, and the Travel Rule makes this especially clear.
The Travel Rule obligation is triggered by the activity, not solely by the licence. An institution licensed in the BVI or the Cayman Islands that is actively serving institutional clients in the EU, the UK, or Singapore is likely subject to the Travel Rule obligations of those jurisdictions as well – and to their AML supervision, their data-transmission standards and their enforcement authority. The FCA, ESMA's national competent authorities and MAS have each articulated, in supervisory statements and enforcement actions, that the geographic reach of their AML regimes extends to the activity, not only to the entity's country of incorporation.
The practical consequence for an institution in this position is that it is operating with a licence stack that does not match its actual regulatory exposure. The Travel Rule program must be designed to the standard of every jurisdiction where the institution is actively present – whether through users, counterparties or banking relationships. We map the licence stack across operating, custody and payment layers before any client commits to a structure, precisely because the gap between the offshore licence and the actual regulatory perimeter is where enforcement risk accumulates.
This is not an argument against offshore licensing. Structures in the BVI, Cayman or ADGM free zone can be entirely appropriate for specific institutional profiles. The argument is that the licence and the compliance program must be designed together, to the same multi-jurisdictional reality.
Self-Assessment: Is Your Travel Rule Program Institutionally Adequate?
Before engaging external counsel, an institution's senior compliance officer or MLRO should be able to answer the following questions affirmatively. Each negative answer represents a gap that a regulator conducting a desktop review or on-site examination is likely to identify.
Does the institution have a written Travel Rule policy that identifies, by jurisdiction, the data-transmission obligations that apply to each entity and each transfer type? Does the policy address unhosted wallets with risk-calibrated thresholds and enhanced-due-diligence procedures? Has the policy been reviewed and updated to reflect MiCA's transfer-of-funds requirements, VARA's current rulebook, and any changes to the MAS or SFC guidance in the past twelve months?
Is there a named MLRO with documented authority, adequate resources and a board-level reporting line? Has the MLRO completed documented training specific to Travel Rule obligations in the last year? Does the institution maintain a counterparty VASP registry that records each counterparty's current regulatory status, jurisdiction and Travel Rule capability?
Is the transaction monitoring program calibrated to the institution's actual transaction profile – not a generic template – and reviewed at least annually? Has the institution tested its Travel Rule data-transmission protocol against a live transfer and confirmed that the receiving VASP received and acknowledged the data correctly?
If the answer to any of these questions is no, or if the honest answer is "we are not sure," the program has a gap that warrants professional review before a regulator finds it first.
Related at OBOLUS
- AML and Travel Rule for Digital-Asset Businesses – our full practice overview covering the regulated basis for AML/Travel Rule obligations across jurisdictions.
- KYC for Crypto: A Legal Guide – a detailed reference on Know Your Customer requirements for digital-asset operators, including onboarding and verification standards.
- Travel Rule Compliance for Early-Stage Founders – a focused service page for pre-licence operators building their first AML program from the ground up.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to collect originator and beneficiary data – names, account identifiers and, in most regimes, address information – and to transmit that data to the receiving VASP before or alongside a qualifying transfer. The obligation derives from FATF Recommendation 15 and is implemented domestically in each jurisdiction. The precise data fields and threshold vary: the EU's transfer-of-funds regime applies from the first euro equivalent, while other jurisdictions apply a de-minimis threshold. Screening against sanctions lists at the point of transfer is a concurrent obligation in all major regimes.
Who must act as MLRO for a crypto firm?
A money laundering reporting officer must be a named individual with documented authority over the firm's AML program, including its Travel Rule compliance. Most major regulators – including the FCA, VARA and MAS – require the MLRO to be approved or notified as part of the licensing or registration process. The MLRO must have adequate seniority, resources and independence to escalate concerns to the board. In a multi-entity group, each regulated entity typically requires its own MLRO, creating a governance coordination requirement across the group.
How do regulators audit crypto AML programs?
Regulators audit AML programs through a combination of desktop reviews, on-site examinations and, increasingly, transaction-level data requests. A desktop review typically covers the written policy, the MLRO appointment, the counterparty VASP registry and evidence of staff training. An on-site examination goes further: regulators test whether the policy matches operational reality by reviewing transaction samples, screening logs and escalation records. Travel Rule compliance is assessed not only by confirming that a vendor solution is in place but by verifying that data was actually transmitted correctly on a representative sample of transfers.
About OBOLUS
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and institutional funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the AML, Travel Rule and KYC compliance that sits around every operating structure. Digital assets are the entirety of our practice, and we act only for businesses – not retail clients. We map the licence, compliance and banking stack across operating, custody and payment layers before our clients commit to a structure. To discuss your Travel Rule compliance program, contact info@oboluslaw.com or reach us via t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialist in AML program design and Travel Rule implementation for multi-jurisdictional digital-asset operators.
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.