Travel Rule Compliance Program: A Cross-Jurisdiction Comparison

A virtual asset service provider that moves funds across borders without a functioning Travel Rule (the obligation, derived from FATF Recommendation 15, to transmit originator and beneficiary identification data alongside every qualifying transfer) is, in nearly every major hub, operating outside the law. The gap between registering as a VASP and building a defensible compliance program is where enforcement actions begin. Regulators in the EU under MiCA, in Singapore under the Monetary Authority of Singapore's Payment Services Act, in Dubai under VARA, and in Hong Kong under the SFC's VASP licensing regime have each translated FATF's baseline into local rules – with material differences in scope, thresholds, and enforcement posture. This analysis maps those differences so that a general counsel or CCO can locate their own program on the compliance spectrum and identify the work that remains.

The stakes are concrete. A Travel Rule deficiency is no longer a technical annotation on a supervisory checklist. It is a licensing condition. Regulators across multiple jurisdictions have suspended, revoked, or declined to renew authorizations where a VASP could not demonstrate end-to-end originator and beneficiary data passing at scale. Operating without the right program risks enforcement action, frozen banking rails, and the loss of correspondent relationships that are already difficult to maintain for digital-asset businesses. The sections below examine how each major regime frames the obligation, where programs most commonly fail, and how a cross-border operator manages the resulting legal exposure.

What the Travel Rule Requires – and Why Definitions Matter

The Travel Rule requires a VASP transmitting a virtual asset transfer to collect, verify, and pass specified originator and beneficiary data to the next VASP or financial institution in the chain. FATF Recommendation 15 and its accompanying guidance set the conceptual floor; every national regime then layers its own thresholds, data-field requirements, and timing rules on top. That layering is where programs diverge.

At the FATF baseline, the minimum data set covers the originator's name, account number (or wallet identifier), and geographic address or other approved identifier, together with the beneficiary's name and account number. Some jurisdictions require additional fields – date of birth, national identifier, or legal entity identifier for corporate senders. A program designed for one regime's minimum may fall short of another's requirements the moment a transaction crosses a border. This is not an edge case. It is the daily operational reality for any exchange, custodian, or payments business serving clients in more than one jurisdiction.

The threshold question adds another layer of complexity. FATF guidance references a threshold above which the full data set must travel with the transaction, but jurisdictions have set that threshold at different levels, and several have moved to require data transmission on all transactions regardless of value. A program calibrated to a single threshold will generate systematic non-compliance wherever a lower threshold applies. We regularly advise operators who discovered this mismatch only after a supervisory review had already commenced.

The cross-border analysis cannot be avoided. A VASP licensed in Singapore sending to a VASP in the EU must satisfy both the MAS Travel Rule rules and MiCA's equivalent provisions – and, where the counterparty is in a jurisdiction that has not yet implemented FATF Recommendation 15, must decide whether to transact at all and on what conditions. Getting that decision architecture right is a program-design question, not a technology question.

CTA #1: The analysis above describes the standard conceptual structure. Your facts – the jurisdictions you serve, the counterparty profile, the transaction volumes, the technology stack – change the risk calibration entirely. For a scoped assessment of where your Travel Rule program stands against the regimes that matter to your business, contact OBOLUS at info@oboluslaw.com.

How MiCA and the EU Transfer of Funds Regulation Frame the Obligation

Under the EU regime, the Travel Rule obligation for crypto-asset transfers is primarily governed by the Transfer of Funds Regulation (TFR) as extended to crypto-assets under MiCA – making the EU's framework one of the most structurally detailed in the world. ESMA and the European Banking Authority have jointly issued guidance elaborating on how CASPs (crypto-asset service providers, the MiCA licence category) must implement the obligation.

The EU approach treats crypto-asset transfers in broadly the same structural manner as wire transfers under the original TFR. A CASP acting as the originator's VASP must gather and verify the data before transmitting. A CASP acting as the beneficiary's VASP must detect missing or incomplete data and, depending on the gap, apply a risk-based decision on whether to make funds available. The requirement applies regardless of transfer size for crypto-asset transfers – meaning that EU CASPs do not benefit from the de minimis thresholds that some other regimes retain.

The passporting architecture under MiCA creates a further complication. A CASP authorized in one member state may passport across the EU and EEA. But its Travel Rule program must be consistent with the requirements of every member state where it operates – and national competent authorities have not uniformly implemented the supplementary guidance in identical terms. A CASP passporting from Malta's MFSA authorization into Germany or France must ensure its program satisfies both the home-state NCA's expectations and those of the host-state NCA. We have seen passporting entities underestimate this obligation.

Interaction with unhosted wallets (wallets not held by a regulated VASP) is a particular pressure point under the EU framework. Where a transfer involves an unhosted wallet above the applicable threshold, the CASP must take risk-based enhanced measures to establish who controls the wallet. The program must document that process. Regulators in the leading EU hubs have indicated that inadequate unhosted-wallet procedures are among the most common deficiencies identified in supervisory reviews.

VARA's Travel Rule Posture: Activity-Based Licensing and AML Expectations

In Dubai, the Virtual Assets Regulatory Authority (VARA) has embedded Travel Rule compliance as a condition of its activity-based licence – meaning the obligation attaches at the licence level, not merely as an AML registration footnote. VARA's rulebooks set out AML/CFT requirements that align with FATF standards, and VARA has made clear through its supervisory communications that it regards Travel Rule implementation as a threshold compliance matter, not an aspirational one.

VARA's licensing structure is granular. An entity holding a custody licence faces the Travel Rule obligation in a different operational context than one holding a broker-dealer or exchange licence. The data-flow architecture differs by activity type, and a firm operating across multiple activity categories must ensure its program addresses the interaction points – for example, where an in-house custody operation initiates or receives transfers on behalf of clients using the exchange function. Designing a single program that covers all licensed activities requires a clear mapping of transaction flows before the technical solution is chosen.

Dubai's geographic position adds cross-border complexity that is distinctive. A VARA-licensed entity frequently transacts with counterparties in jurisdictions across South Asia, the MENA region, and East Africa where VASP regulation and Travel Rule implementation vary significantly. Where the counterparty jurisdiction lacks a functioning Travel Rule regime, VARA's framework requires the originator VASP to take enhanced risk measures and to document its decision. An undocumented policy of transacting freely with unregulated counterparties is a compliance failure that supervisory review will surface.

Singapore's MAS Framework: Travel Rule Under the Payment Services Act

Singapore's Monetary Authority of Singapore (MAS) implemented the Travel Rule for Digital Payment Token (DPT) service providers under the Payment Services Act, making Singapore one of the earlier major hubs to operationalize the requirement in binding regulatory form. MAS guidance specifies the data fields required, the conditions for transmitting to unregulated counterparties, and the procedures for incoming transfers where the required data is absent.

The MAS framework distinguishes between transfers to other MAS-regulated DPT service providers and transfers to VASPs in other jurisdictions. For transfers to foreign VASPs, the sending DPT service provider must take risk-based measures proportionate to the Travel Rule implementation status of the counterparty's jurisdiction. MAS has published guidance on what those risk measures should address, and the regulator expects documented policies – not informal practices.

Singapore's position as a financial hub means that MAS-licensed businesses frequently maintain correspondent banking relationships with institutions that apply their own FATF compliance expectations. A Travel Rule deficiency flagged by MAS can trigger a parallel review by a correspondent bank. In our cross-border practice, we have observed that banking de-risking events often follow, rather than precede, a regulatory finding on Travel Rule compliance. The two risks are operationally connected, and a program that manages only one of them leaves the other exposed.

Hong Kong's SFC Regime: VASP Licensing and AML Expectations

Hong Kong's Securities and Futures Commission (SFC) operates the VASP licensing regime for virtual-asset trading platforms (VATPs), and the VATP requirements incorporate AML/CFT obligations that expressly include Travel Rule implementation. The SFC's AML/CFT guidelines for VATPs are detailed and draw on both FATF standards and Hong Kong's own Anti-Money Laundering and Counter-Terrorist Financing Ordinance.

The SFC's approach emphasizes the governance dimension of AML compliance. It is not sufficient to have a Travel Rule solution deployed; the platform must demonstrate board-level oversight, a designated AML officer with appropriate authority, documented policies and procedures, and a testing and audit cycle that verifies the program's effectiveness. A Travel Rule solution that processes data correctly but sits outside the firm's governance structure will not satisfy the SFC's expectations.

Hong Kong's VATP regime also addresses the interaction between Travel Rule compliance and customer due diligence (CDD). Where Travel Rule data arrives with a transfer, the VATP must reconcile that data against its own CDD records. Discrepancies trigger enhanced scrutiny obligations. A program that handles Travel Rule data as an isolated compliance function, disconnected from the KYC framework and transaction monitoring systems, creates a structural gap that audit will identify. In our practice, firms entering the Hong Kong VASP licensing process frequently require a program redesign rather than a documentation exercise.

The AIFC/AFSA Framework in Kazakhstan: An Emerging Hub's Approach

The Astana Financial Services Authority (AFSA) within the AIFC has developed its digital-asset regulatory framework along common-law lines, drawing on FATF standards and adapting them to the AIFC's distinct legal architecture. For firms seeking a Central Asian licensing base – often in combination with an EU or UAE presence – the AIFC's Travel Rule expectations must be understood alongside those of the primary hub.

The AIFC operates as a common-law jurisdiction within Kazakhstan, which means its legal instruments and supervisory approach are structurally closer to London or Singapore than to Astana's domestic regulatory environment. For a digital-asset trading facility or custody business operating under AFSA supervision, Travel Rule compliance is expected to meet FATF standards – including the data transmission obligation and the enhanced-measures requirement for counterparties in non-compliant jurisdictions.

Cross-border operators licensing through the AIFC in combination with an EU or Gulf presence face the challenge of operating a single Travel Rule program that satisfies AFSA's expectations alongside those of MiCA's national competent authorities or VARA. The program architecture must be flexible enough to apply the stricter standard in each direction without creating operational failures on the lower-threshold side. That architecture question is resolved at the design stage, not after a supervisory inquiry has commenced.

CTA #2: If a prior application stalled or a compliance program has already attracted supervisory comment, a structured second read can surface the underlying gap and map the route to remediation. Write to OBOLUS at info@oboluslaw.com.

Where Travel Rule Programs Most Commonly Fail: A Cross-Jurisdiction View

Across the jurisdictions above, the most common Travel Rule program failures fall into a recognizable pattern – not because operators are careless, but because the compliance architecture decisions made at launch do not scale to the operational reality of a cross-border business. Understanding that pattern is the first step toward a defensible program.

The first failure category is threshold miscalibration. A program designed around a single jurisdiction's threshold fails silently in every jurisdiction where a lower threshold applies. The failure accumulates in data. By the time a supervisory review occurs, the volume of non-compliant transactions is significant. Remediation after the fact is operationally expensive and regulatorily uncomfortable.

The second failure category is unhosted-wallet procedure gaps. Regulators in the EU, Singapore, and Hong Kong have each flagged this issue prominently. A program that transmits Travel Rule data cleanly between regulated VASPs but applies no documented risk assessment to unhosted-wallet transactions is materially deficient in every regime that has addressed the question.

The third failure category is the disconnection between the Travel Rule solution and the broader AML program. Travel Rule data has limited value if it is not integrated with the KYC framework, the transaction monitoring system, and the sanctions screening function. A VASP that runs its Travel Rule solution as a standalone technical module – rather than as a component of an integrated AML program – will fail the governance and effectiveness tests that regulators now apply.

The fourth failure category is counterparty jurisdiction assessment. Every regime requires a documented risk assessment of the Travel Rule implementation status of counterparty jurisdictions. Operators frequently treat this as a static exercise conducted at onboarding. Regulators treat it as a dynamic obligation that must be refreshed as the counterparty's regulatory environment evolves. A policy document from two years ago does not satisfy an examiner asking about current practice.

In a recent compliance matter, a payments company operating across EU and Gulf jurisdictions discovered, during an internal audit conducted ahead of a licence renewal, that its Travel Rule solution was applying an EU-calibrated threshold globally – leaving a category of Gulf-direction transfers outside the data-transmission obligation. We assisted in redesigning the program architecture, mapping the data flows against each applicable regime, and producing the documentation package for regulatory submission. The matter resolved ahead of the renewal deadline.

A Decision Matrix: Which Program Architecture Fits Which Operator Profile

Choosing a Travel Rule compliance architecture is not a generic exercise. The right design depends on the operator's licence footprint, transaction profile, and counterparty base. The following profiles illustrate the principal decision branches.

Profile A – EU CASP with passporting ambitions: An operator holding or seeking a CASP authorisation under MiCA and planning to passport across multiple member states needs a program calibrated to the zero-threshold standard, with a documented unhosted-wallet procedure and a counterparty jurisdiction matrix. The governance structure must satisfy the home NCA's expectations on board oversight and MLRO authority. Technology must produce audit-ready data at scale. Timeline to a defensible program typically runs to several months of design, testing, and documentation work.

Profile B – VARA-licensed exchange with regional counterparties: An operator holding an exchange or broker-dealer licence under VARA and transacting with counterparties across the MENA and South Asia region faces a heightened counterparty-risk dimension. The program must include a dynamic jurisdiction-assessment matrix and a documented enhanced-measures policy for counterparties in non-FATF-compliant jurisdictions. The cross-activity compliance architecture – where custody and exchange functions share infrastructure – requires explicit design attention. VARA supervision is active and expects demonstrable program effectiveness, not paper compliance.

Profile C – Singapore DPT service provider expanding to Hong Kong: An operator licensed by MAS seeking SFC VATP authorisation must reconcile two detailed regimes whose requirements overlap but do not perfectly align. The program must satisfy both regulators' expectations simultaneously. The governance elements are particularly important for Hong Kong – the SFC expects clear documentation of board-level ownership and MLRO accountability. A program that satisfies MAS's operational requirements may require governance augmentation before it meets SFC expectations. Indicative timeline for the governance build and documentation package: a matter of months, not weeks.

Profile D – AIFC/AFSA-licensed entity as part of a multi-hub stack: An operator using the AIFC as one licensing node in a structure that also includes an EU or UAE presence needs a program that applies the strictest applicable standard in each transaction direction. The AIFC's common-law framework makes its documentation expectations familiar to operators from London or Singapore, but the dynamic counterparty assessment obligation applies equally here. The multi-hub program design is best done as a unified exercise rather than as three separate programs bolted together after the fact.

A Common Assumption: One Offshore Licence Is Enough

A common assumption among operators entering the digital-asset market is that a single offshore or base jurisdiction licence – whether in the BVI, Cayman Islands, or another light-touch regime – is sufficient to serve clients globally, including in jurisdictions where the regulator has its own VASP licensing and Travel Rule requirements. That assumption is incorrect, and regulators have demonstrated a consistent willingness to act on it.

The legal analysis is straightforward. A VASP licence in one jurisdiction authorizes activities within that regime's scope. It does not authorize the VASP to provide services to clients in jurisdictions that require their own authorization or registration. Where a VASP's clients are located in the EU, in Singapore, or in Hong Kong, the relevant regulators in those jurisdictions will assess whether the VASP is providing regulated services into their markets without authorization. Travel Rule compliance is not the only exposure – but it is often the trigger that brings the broader question to a regulator's attention.

The banking dimension compounds the risk. Correspondent banks and electronic money institutions servicing digital-asset businesses apply their own FATF compliance expectations. A VASP that cannot demonstrate an effective Travel Rule program – calibrated to the regimes relevant to its actual transaction flows – is a client that correspondent banks find difficult to retain. The enforcement risk and the banking risk converge on the same program weakness.

In our cross-border practice, we map the full licence stack – operating jurisdiction, custody jurisdiction, payment and banking layer – before a client commits to a structure. That mapping routinely surfaces Travel Rule obligations in jurisdictions the operator had not identified as relevant to its compliance program. The correction is substantially cheaper before the structure is live.

A Self-Assessment Checklist for Travel Rule Program Readiness

A Travel Rule program is defensible when it can answer each of the following questions affirmatively and produce the documentation to support the answer under supervisory examination.

First, has the operator identified every jurisdiction in which it is required to apply Travel Rule obligations – based on where it is licensed, where its counterparties are located, and where its clients are based? Second, is the data-threshold calibration correct for each applicable jurisdiction – including jurisdictions that apply a zero threshold or a threshold lower than the operator's home regime? Third, does the program include a documented unhosted-wallet procedure that addresses the enhanced-measures expectation in each relevant regime?

Fourth, is Travel Rule data integrated with the KYC framework, transaction monitoring system, and sanctions screening function – rather than operating as a standalone module? Fifth, does the program include a dynamic counterparty jurisdiction assessment matrix that is reviewed and updated at a defined frequency? Sixth, is there documented board-level ownership of the AML program, a designated MLRO with appropriate authority and resources, and a testing and audit cycle that verifies program effectiveness?

If the answer to any of these questions is uncertain, the program has a gap. The question is whether that gap surfaces in an internal audit or in a regulatory examination.

Related at OBOLUS

• AML and Travel Rule for Digital-Asset Businesses – end-to-end compliance program design across the major VASP regimes.
• AML and Travel Rule Regime in Kazakhstan's AIFC – the AFSA's specific requirements for digital-asset businesses operating within the AIFC.
• De-Risking and Account Closure Defence in Hong Kong – managing banking relationship risk for Hong Kong-based digital-asset businesses.

FAQ

What does the Travel Rule require from a VASP?

The Travel Rule requires a VASP to collect, verify, and transmit specified originator and beneficiary identification data alongside every qualifying virtual asset transfer. The minimum data set – derived from FATF Recommendation 15 – covers names, account or wallet identifiers, and geographic or other approved identification. The exact data fields, thresholds, and timing requirements vary by jurisdiction. A VASP operating across multiple regimes must calibrate its program to the strictest applicable standard in each transaction direction.

Who must act as MLRO for a crypto firm?

Most major VASP regimes – including MiCA across the EU, VARA in Dubai, the MAS Payment Services Act in Singapore, and the SFC's VASP regime in Hong Kong – require a designated Money Laundering Reporting Officer (MLRO) with appropriate seniority, authority, and resources. The MLRO is responsible for the AML program, Travel Rule implementation, and regulatory reporting. Regulators expect the MLRO to have direct access to senior management and the board, and to be sufficiently resourced to fulfil the function effectively. The role cannot be a nominal designation.

How do regulators audit crypto AML programs?

Regulators across the leading hubs typically assess a VASP's AML program through a combination of documentary review, transactional testing, and governance examination. They request policies, procedures, MLRO reports, board minutes, and evidence of program testing. They test whether the Travel Rule solution is producing accurate and complete data in practice, not merely on paper. They examine the integration between Travel Rule data, KYC records, and transaction monitoring outputs. Governance gaps – inadequate MLRO authority, absent board oversight documentation, or untested procedures – are among the most frequently cited deficiencies.

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 programs that regulators across every major hub now examine as licensing conditions. Digital assets are the entirety of our practice. We map the licence, compliance, and banking stack across operating, custody, and payment layers before our clients commit to a structure – because the correction is always cheaper before the program is live. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.

By Glen Sorensen, Disputes & Recovery Analyst – specializing in cross-border AML compliance program assessment and regulatory exposure mapping for digital-asset businesses across multiple VASP 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.