The Travel Rule (the obligation to pass originator and beneficiary data alongside every qualifying virtual-asset transfer) has moved from a FATF recommendation to an enforced compliance standard in every leading licensing jurisdiction. For boards of exchanges, custodians and payment operators, failure to run a credible Travel Rule compliance program now triggers the same consequences as a broken AML framework: regulatory enforcement, account freezes and the permanent loss of banking relationships. This analysis draws on cross-border practice to identify the structural decisions that determine whether a program holds under regulatory scrutiny.
Why the Travel Rule Is a Board-Level Issue
The Travel Rule is not an IT checkbox. It is a governance question that sits on the board agenda because the liability pathway runs directly to senior management. Under FATF Recommendation 15 and its implementing rules across MiCA/ESMA, the MAS Payment Services Act regime, the FCA's AML/CTF framework and VARA's rulebooks, the obligation to transmit originator and beneficiary information falls on the VASP (virtual asset service provider) as a legal entity – and regulators hold boards accountable for systemic failures.
In our cross-border practice, the enforcement pattern is consistent. A firm builds a sound KYC framework at onboarding, invests in transaction monitoring, and then treats inter-VASP data transmission as an operational afterthought. That gap is precisely where supervisory reviews focus. The reason is structural: the Travel Rule is the interface between two regulated parties. One firm's failure to transmit data is another firm's AML gap. Regulators increasingly follow the data chain to its weakest link.
The cross-border reality sharpens this further. A VASP licensed under MiCA and passporting across the EU/EEA sends transfers to a counterpart in Singapore, the UAE or Hong Kong. Each jurisdiction has implemented the Travel Rule with different thresholds, different technical protocols and different enforcement postures. A program built for one regime will not satisfy all three. Boards that understand this build for the most demanding environment, then verify that their program meets the specifics of every jurisdiction they touch.
A common board misconception is that Travel Rule compliance is a vendor decision, not a governance decision. Vendors execute the mechanics. The board sets the risk appetite, approves the policy, ensures the MLRO has authority and resources, and monitors the program's output. Those are governance acts. They are also the acts regulators examine first.
The process starts with identifying which transfers are in scope under each applicable regime, not with selecting a protocol. Many programs fail before the first message is sent because the scope analysis was incomplete.
To discuss how your governance structure maps against the Travel Rule obligations in your key jurisdictions, contact OBOLUS at Map your options.
What the Travel Rule Actually Requires: Scope, Data and Counterparty Verification
A Travel Rule compliance program must address three distinct technical obligations: identifying in-scope transfers, transmitting the required data, and verifying that the receiving VASP is itself regulated and able to receive compliant data.
The scope question turns on two variables: the nature of the transfer and the threshold. FATF's baseline sets a threshold above which the rule applies, but individual jurisdictions have the discretion to set lower thresholds or to apply the rule to all transfers regardless of size. Under MiCA and the ESMA technical standards, the EU has made its position on scope explicit. MAS has done the same under its Payment Services Act implementing rules. VARA applies its own threshold under the Dubai framework. A program that uses a single threshold across all transfer corridors is non-compliant in at least one jurisdiction it serves. The correct approach is a corridor-by-corridor threshold map, updated as regulation evolves.
The data payload itself is prescribed. For the originator: full name, account number or wallet identifier, physical address, national identity number or date and place of birth, and, where available, a legal entity identifier. For the beneficiary: name and account number. The precise fields, the required format and the acceptable substitute identifiers vary by jurisdiction – but the minimum is consistent with FATF Recommendation 16.
Counterparty verification is where many programs break down. Sending compliant data to an unregulated entity does not satisfy the Travel Rule; it creates a new risk. A program must include a process for verifying that the receiving VASP is registered or licensed in its own jurisdiction, maintaining a current counterparty registry, and applying a default-block or enhanced-due-diligence rule for transfers to counterparties that cannot be verified. This is not a one-time exercise. Regulatory statuses change. A counterparty that was regulated last quarter may not be regulated today.
We regularly advise operators who have deployed a protocol solution without building the governance layer around it. The protocol moves the data. The governance layer decides what data is acceptable, what counterparties are permissible, and what happens when a transfer fails a check. Without the governance layer, the protocol is a wire with no insulation.
How Does Protocol Fragmentation Affect Program Design?
Protocol fragmentation is the single most underestimated operational challenge in Travel Rule compliance, and it requires a deliberate architectural decision by the MLRO and the CTO working together.
The major interoperability protocols – broadly categorized as sunrise-period solutions, messaging-layer solutions and on-chain attestation approaches – are not universally adopted. A counterparty VASP may operate on a different protocol, or on no protocol at all. This creates a sunrise problem: a compliant sender cannot transmit to a non-compliant receiver without a bilateral workaround or a default policy.
Programs designed with a single-protocol assumption collapse when they encounter a counterparty outside that protocol's network. The resilient architecture connects to at least two interoperability solutions, maintains a bilateral messaging fallback for known counterparties, and documents the default policy for unresolvable mismatches – typically a hold-and-review or reject posture, applied consistently and recorded in the compliance log.
The cross-border dimension is acute here. A VASP licensed under the VARA regime in Dubai operates in a market where counterparties may include entities in jurisdictions with no Travel Rule implementation at all. The VARA rulebooks set expectations for how licensed entities manage those corridors. Under the MAS framework in Singapore, the approach to non-implemented jurisdictions is similarly addressed at the policy level. The FCA in the UK expects firms to document how they handle transfers to and from jurisdictions outside the Travel Rule perimeter.
The board-level lesson: protocol selection is a compliance decision, not a procurement decision. It requires the MLRO to sign off, and it requires a documented rationale that can be produced to a regulator.
How Does a Board Structure MLRO Accountability for the Travel Rule?
The MLRO (Money Laundering Reporting Officer) owns the Travel Rule compliance program operationally, but the board owns the conditions under which the MLRO can succeed. This distinction matters enormously when a regulator conducts a supervisory review.
Effective board oversight of Travel Rule compliance requires four structural elements. First, the MLRO must have a direct reporting line to the board or its audit/risk committee – not through a business line that has a commercial interest in reducing compliance friction. Second, the MLRO must be given a documented mandate: the Travel Rule policy, the counterparty risk framework, the protocol architecture and the escalation procedure must all be board-approved. Third, the board must receive periodic compliance reporting that includes Travel Rule-specific metrics: volume of in-scope transfers, transmission success rate, counterparty verification failures, and the number and resolution of exceptions. Fourth, the MLRO must have a budget that is not contingent on business performance.
Regulators across the major hubs – ESMA and the NCAs under MiCA, MAS, VARA, the FCA – have moved toward individual accountability frameworks. A board that cannot demonstrate that it received, considered and acted on MLRO reporting has a governance deficit that is independent of whether the underlying transactions were compliant.
We have seen enforcement outcomes shaped almost entirely by the quality of board-level documentation, not by the number of transactions that were processed correctly. A regulator that finds a well-documented program with a small number of resolved failures treats it differently from one that finds an undocumented program with a high success rate and no paper trail.
The micro-matter below illustrates this dynamic from a recent engagement.
In a recent supervisory review matter, a mid-sized exchange had processed the large majority of its inter-VASP transfers correctly under its protocol solution, but had no board-level documentation of its Travel Rule policy and no MLRO reporting to the board in the twelve months before the review. The regulator's concern was not the transactions themselves; it was the absence of demonstrable governance. We assisted the firm in reconstructing the governance record, drafting a board-approved Travel Rule policy and presenting a remediation roadmap. The review was resolved without a formal sanction. The cost of remediation substantially exceeded what a governance framework built from the outset would have required.
The Cross-Border Compliance Gap: Where Programs Fail
Cross-border Travel Rule compliance fails at three identifiable pressure points: jurisdictional threshold mismatches, counterparty status divergence and data-field incompatibility.
Threshold mismatches arise because the jurisdictions a VASP serves have not harmonized their thresholds. A transfer that is below the threshold in the sending jurisdiction may be above it in the receiving jurisdiction. The program must apply the higher of the two thresholds – or the threshold in the jurisdiction whose rules apply to the sending obligation – or it will produce gaps on at least one side of the corridor. This sounds obvious. In our practice, threshold mismatches are among the most common findings in internal compliance gap reviews.
Counterparty status divergence is more subtle. A VASP in jurisdiction A may be registered under a regime that jurisdiction B does not recognize as equivalent. The receiving VASP's regulatory status, from the perspective of the sending VASP's home regulator, may be inadequate to satisfy the "regulated counterparty" condition. Programs that treat any registration in any jurisdiction as equivalent create a systemic exposure. The correct approach is a graded counterparty classification: fully regulated in a recognized equivalent regime; registered but not fully supervised; operating in a non-implementing jurisdiction; unknown. Each category receives a different treatment under the firm's data transmission and enhanced due diligence rules.
Data-field incompatibility is a technical problem with legal consequences. Different jurisdictions require different originator identifier fields. A national identity number is required in some regimes; a date and place of birth is sufficient in others; a legal entity identifier is expected for corporate originators. A program that collects the minimum required in its home jurisdiction may not be able to populate the fields required by the destination jurisdiction. The resolution is to collect at onboarding everything that any jurisdiction in your corridor map could require – not the minimum.
Under the AIFC/AFSA framework in Kazakhstan, the cross-border dimension is particularly acute for operators using Central Asia as a gateway between EU and Asian markets. The AFSA Travel Rule implementing rules align broadly with FATF Recommendation 15 but with jurisdiction-specific particulars that differ from both MiCA and the MAS regime. An operator running a unified program without a Kazakhstan-specific annex will have gaps in that corridor.
If your current program was designed for a single jurisdiction and your transfers now cross multiple regimes, a targeted gap review before your next supervisory cycle is more cost-effective than a remediation exercise after it.
Contact OBOLUS at Map your options for a scoped cross-border compliance gap assessment.
Transaction Monitoring and the Travel Rule Are Not the Same Program
Transaction monitoring and Travel Rule compliance are related but structurally distinct obligations, and programs that conflate them create governance blind spots that regulators identify immediately.
Transaction monitoring is the ongoing surveillance of activity on the firm's own platform to detect patterns indicative of money laundering, sanctions evasion or fraud. It is a continuous, algorithmic process applied to internal data. The Travel Rule is a data-transmission obligation applied to specific inter-VASP transfers at the point of execution. They share a subject matter – the transfers – but they operate on different data, at different points in the transfer lifecycle and under different legal bases.
The practical consequence is that a firm which has invested heavily in transaction monitoring but has a weak Travel Rule program is not AML-compliant. The two obligations must both be met, independently. The MLRO's annual report should address both separately. The board should receive separate KPIs for each.
There is a legitimate integration point, however. When transaction monitoring flags a transfer for investigation, the Travel Rule data associated with that transfer is a primary evidence source. A program with complete, accurate Travel Rule records is substantially better positioned to respond to a regulatory inquiry or a law-enforcement request than one with gaps. This is the operational upside of a well-run Travel Rule program: it produces a compliance record that serves multiple purposes simultaneously.
Under the FCA's financial-crime supervisory approach, the expectation is explicitly that AML and Travel Rule controls are documented as parts of a coherent framework, not as siloed functions. MAS has signaled similar expectations in its supervisory correspondence with DPT service licensees. VARA's compliance requirements under its Exchange and Transfer/Settlement Services rulebooks align the two obligations within the same supervisory review process.
What Does a Regulator Actually Examine in a Travel Rule Audit?
A regulatory examination of a Travel Rule compliance program follows a consistent pattern across the leading supervisory authorities, and preparation for it should begin long before a review is announced.
The first line of examination is documentation. The regulator will request the Travel Rule policy, the counterparty risk framework, evidence of board approval and the MLRO's periodic reporting to the board. Programs that exist in technical infrastructure but not in written policy documents will fail this first test regardless of their operational performance.
The second line is transaction sampling. The regulator will select a sample of in-scope transfers and trace the data transmission: was the data sent, was it complete, was it received and acknowledged, and what happened when a transmission failed? Failure in isolation is not a disqualifying finding. Failure without a documented exception-handling process is.
The third line is counterparty verification. The regulator will examine the firm's counterparty registry: how was each counterparty's regulatory status verified, when was it last checked, and how does the firm treat transfers to counterparties that cannot be verified? An undated registry with no refresh cycle is a finding.
The fourth line is governance. The regulator will examine how the MLRO escalates Travel Rule failures, what authority the MLRO has to halt or reject transfers, and whether the board has actually exercised oversight – evidenced by minutes, reports received and decisions made.
The fifth line, increasingly, is technology architecture. Regulators in the more technically sophisticated jurisdictions – the FCA, MAS, the SFC in Hong Kong – now expect to understand the protocol solution in use, its coverage of the firm's counterparty network, and the manual processes that fill the gaps. A program where the MLRO cannot explain the technology is a program the regulator cannot trust.
We regularly advise firms preparing for supervisory reviews. The consistent finding is that programs built around a commercial protocol without a corresponding governance layer are the ones that generate findings. The technology works. The documentation does not.
A Decision Matrix for Program Design by Operator Profile
The right Travel Rule compliance architecture depends on the operator's activity profile, jurisdictional footprint and counterparty network. There is no single configuration that suits every VASP, and programs built to a generic template typically fail in their specific operating context.
A centralized exchange licensed under MiCA with a predominantly European user base and institutional counterparties should build a program centered on the EU's technical standards, with full integration of the required originator and beneficiary data fields at the account level, a protocol solution that covers its top-twenty counterparties by volume, and a bilateral fallback for the residual. The MLRO reporting framework should produce quarterly metrics sufficient for NCA review. The cross-border risk for this profile is the non-EU corridor: every transfer to a VASP in Singapore, the UAE, the UK or the US crosses into a different regime. The program must include a corridor annex for each of those jurisdictions.
A payments or remittance operator licensed under the MAS Payment Services Act handles high-volume, lower-value transfers across Southeast Asian corridors. The Travel Rule threshold and data requirements under the MAS regime differ from MiCA. This profile requires a program optimized for speed and volume, with automated data collection at the moment of account creation, a high-throughput protocol solution and a near-real-time exception management process. The governance layer is the same as for any profile: board-approved policy, MLRO authority, documented escalation, periodic board reporting.
A custody or staking service licensed under VARA or the ADGM/FSRA framework may process fewer but higher-value transfers between institutional counterparties. The Travel Rule obligation applies equally, but the program design prioritizes accuracy over volume throughput. Every counterparty should be individually verified and classified. The counterparty registry should be reviewed at regular, documented intervals. Enhanced due diligence should apply to any counterparty in a jurisdiction that has not implemented the Travel Rule.
A fund or asset manager with cross-border subscriptions and redemptions involving digital assets sits in the most complex position. The transfers may be classified differently depending on whether they are treated as financial transfers or investment transactions under the applicable regime. The MLRO must determine scope first – whether the Travel Rule applies to the specific transfer type – before designing the data transmission process. This is a legal question, not a systems question, and it should be resolved with counsel before the program is built.
Addressing the Myth: One Offshore Licence, One Program
A common assumption among early-stage operators is that a licence in a single offshore jurisdiction – the BVI, the Caymans, or a light-touch VASP registration – creates a compliant perimeter for global operations, including Travel Rule compliance. That assumption is incorrect and increasingly dangerous.
The Travel Rule obligation follows the transfer, not the licence. If a VASP licensed in the BVI under the VASP Act 2022 processes a transfer that originates in the EU and is received by a MAS-supervised entity in Singapore, the transfer is subject to the Travel Rule as implemented in all three jurisdictions along its path. The BVI licence does not insulate the operator from EU or Singapore obligations; it merely establishes the firm's home regulatory perimeter.
More directly, the major banking and correspondent relationships that digital-asset businesses depend on are operated by institutions subject to full AML/CTF obligations in their home jurisdictions. A bank in the UK, the US or Singapore is not indifferent to the Travel Rule compliance posture of a VASP it services. Deficiencies in a VASP's Travel Rule program are a material factor in the decision to onboard or maintain a business banking relationship. In our practice, we have seen compliant, operationally sound businesses lose banking relationships because their Travel Rule documentation was inadequate – not because their transactions were problematic.
The practical consequence for boards is this: the Travel Rule compliance program must be designed for the operating reality of the business, not for the regulatory minimum of the licensing jurisdiction. If the business serves EU users, the program must satisfy MiCA. If it processes transfers to or from Singapore, it must satisfy MAS. If it banks with a UK-regulated institution, it must satisfy FCA expectations. The licence is the starting point. The operating reality is the compliance standard.
Self-Assessment Checklist for Boards
A board exercising genuine oversight of its Travel Rule compliance program should be able to answer the following questions with documented evidence, not assurances.
Has the board approved a written Travel Rule policy that identifies in-scope transfer types, applicable thresholds by corridor, required data fields, counterparty verification standards and exception-handling procedures? If the policy exists only in an internal systems configuration, it does not satisfy a regulator.
Does the MLRO report to the board – not to a business line – and does that reporting include Travel Rule-specific metrics? Consolidated AML reporting that does not separately address Travel Rule performance is insufficient for most supervisory frameworks.
Has the firm conducted a corridor-by-corridor threshold and data-field mapping for every jurisdiction in which it sends or receives transfers? A single global threshold is non-compliant in almost every multi-jurisdiction operating model.
Is the counterparty registry current, dated and graded by regulatory status? An undated list is operationally unusable and will be treated as such by a regulator.
Does the protocol architecture cover the firm's full counterparty network, and is the residual – unresolvable counterparties – addressed by a documented default policy? A protocol that covers ninety percent of counterparties by volume but has no policy for the remaining ten percent has a material gap.
Has the firm conducted an independent gap review against the Travel Rule requirements of each jurisdiction in its operating footprint? A self-assessment by the team that built the program is not the same as an independent review.
If the board cannot answer each of these questions affirmatively and produce supporting documentation, the program has gaps. The time to identify and close them is before a supervisory review, not during one.
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – full-scope compliance advisory across licensing, AML and the Travel Rule obligation
- AML and Travel Rule in Kazakhstan / AIFC – how the AFSA regime applies and what operators must build for the Central Asia corridor
- Digital asset custody licensing in Jersey – custody regulation, AML obligations and the cross-border structuring angle
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to transmit originator and beneficiary information alongside every qualifying virtual-asset transfer. The required data includes the originator's name, account identifier and address or identity number, and the beneficiary's name and account identifier. The threshold above which the obligation applies varies by jurisdiction, and some regimes apply the rule to all transfers regardless of size. The transmitting VASP must also verify that the receiving party is a regulated VASP capable of receiving compliant data.
Who must act as MLRO for a crypto firm?
Most supervised VASP regimes – including those under MiCA, the MAS Payment Services Act, VARA and the FCA's AML/CTF framework – require the designation of an individual as money laundering reporting officer. That individual must have sufficient seniority, independence from business lines and access to transaction data to perform the role effectively. In the major hubs, regulators increasingly expect the MLRO to report directly to the board and to have documented authority to halt or flag transfers. The precise qualifications and notification requirements for the MLRO role vary by jurisdiction.
How do regulators audit crypto AML programs?
Supervisory reviews of crypto AML programs typically examine documentation first: the written policy, evidence of board approval and MLRO reporting. Regulators then sample transactions to test whether the Travel Rule data was transmitted correctly and what happened when transmissions failed. Counterparty verification records and the exception-handling log are standard examination targets. In the more technically sophisticated jurisdictions, examiners also assess the protocol architecture and its coverage of the firm's counterparty network. Programs with strong documentation and documented exception resolution are consistently treated more favorably than those with higher operational accuracy but no paper trail.
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 that sit around them. Digital assets are the whole of our practice. We map the licence, AML and Travel Rule stack across operating, custody and payment layers – across every jurisdiction your business touches – before you commit to a structure. To discuss your compliance program, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specializing in cross-border AML frameworks, Travel Rule program design and supervisory readiness for digital-asset businesses operating across multiple licensing jurisdictions.
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.