A virtual asset service provider (VASP) expanding its user base across three continents faces a question that has stopped more than one compliance build in its tracks: is your firm actually passing the right data with every transfer, or are you running a Travel Rule gap that a regulator will find before you do? The Travel Rule – the obligation, derived from FATF Recommendation 15, to pass originator and beneficiary identifying information alongside a virtual asset transfer – is now embedded in the licensing conditions of every major digital-asset hub. Non-compliance is not a paperwork issue. It is a licence-suspension risk, a correspondent-banking termination trigger, and, in the worst cases, a criminal referral pathway. This analysis examines the practical compliance burden, maps the cross-border friction points, and identifies where programs most commonly break down.
What the Travel Rule Actually Demands from a Regulated VASP
The Travel Rule requires a VASP to collect, verify and transmit originator and beneficiary data with each qualifying virtual asset transfer – and to retain that data for regulatory inspection. FATF Recommendation 15 sets the baseline. Every jurisdiction that has implemented it translates that baseline into its own supervised regime, with its own data-threshold, its own sunrise exemption posture and its own enforcement priority. Under MiCA and the EU Transfer of Funds Regulation, the obligation applies from the first euro of a transfer between two regulated VASPs. Under the UK Financial Conduct Authority regime, a similar obligation sits inside the Money Laundering Regulations. Under the MAS Payment Services Act framework in Singapore, the same principle applies at the applicable local threshold.
The data payload a sending VASP must transmit typically covers the originator's full name, account number or wallet identifier, and address or other identifying information, alongside equivalent beneficiary data. The receiving VASP must verify the beneficiary information against its own records and apply a risk assessment to any counterparty VASP it has not previously screened. This is not a one-time task. It is a continuous operational function.
In our cross-border practice, we regularly advise VASPs that underestimate the operational weight of this function at the licensing stage and then scramble to build it post-authorisation. The compliance burden is not the legal obligation itself. It is the infrastructure, the counterparty network and the governance required to discharge that obligation in real time, at scale, across dozens of jurisdictions simultaneously.
For a scoped assessment of your Travel Rule exposure – entity by entity, jurisdiction by jurisdiction – contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity structure, the user base, the banking rails – change the analysis materially.
Why Does the "Sunrise Problem" Still Create Compliance Gaps?
The sunrise problem – the asymmetry between jurisdictions that have implemented the Travel Rule and those that have not – remains the most structurally difficult issue in any multi-jurisdictional Travel Rule program. A VASP sending funds to a counterparty in a jurisdiction that has not yet enacted the rule faces an immediate question: do you treat the counterparty as unhosted, apply enhanced due diligence, or proceed on the basis of a policy exception? The answer varies by the sending VASP's own regulatory regime.
Under the EU's Transfer of Funds Regulation, a sending obliged entity that cannot obtain the required data from a non-compliant counterparty must assess whether to suspend or terminate the business relationship. The FCA takes a comparable position. VARA in Dubai has embedded Travel Rule requirements into its rulebooks and expects VASPs operating under its authorisation to have protocols for exactly this scenario.
The practical consequence is that a VASP with a global user base must maintain a dynamic counterparty registry – one that tracks each destination VASP's regulatory status, its Travel Rule protocol compatibility and its response-time history. Most early-stage compliance programs do not build this. They build a static list that becomes outdated within months.
Operators we advise routinely discover that their Travel Rule solution handles the easy case – two MiCA-authorised VASPs exchanging data via an IVMS 101 message – but fails the harder case: a transfer to a VASP in a developing market that has no compliant messaging protocol and no regulatory mandate to respond. The program must address both. A compliance architecture that handles only the easy case is not a compliant program.
How Does the Travel Rule Apply to Unhosted Wallet Transfers?
Transfers to or from unhosted wallets – wallets not held at a regulated VASP – sit at the hardest edge of Travel Rule compliance and represent the sharpest point of divergence between jurisdictions. Under the EU Transfer of Funds Regulation, a VASP transacting with an unhosted wallet must apply enhanced due diligence when the transfer meets or exceeds the applicable threshold, collecting and verifying the identity of the wallet's beneficial owner. The MFSA in Malta and national competent authorities across the EU are expected to take this seriously as MiCA supervision matures.
In the VARA regime in Dubai, unhosted wallet interactions are subject to defined controls within the VARA rulebooks. The AFSA within the AIFC in Kazakhstan applies a risk-based approach aligned to FATF guidance. Singapore's MAS has published guidance on digital payment token service providers and unhosted wallet risk, emphasising that the Payment Services Act framework's AML requirements apply regardless of wallet type on the receiving side.
The practical difficulty is verification. A VASP can demand a self-declaration from a customer claiming ownership of an unhosted wallet. It can apply blockchain analytics to assess wallet activity. But it cannot compel a response, and a customer who does not cooperate triggers a risk escalation that most operational playbooks handle inconsistently. We have seen compliance programs that block all unhosted wallet transactions above threshold, programs that apply a manual review queue, and programs that rely entirely on analytics without any customer verification. Only one of those approaches is defensible under the leading regulatory regimes.
Where KYC and AML Intersect with the Travel Rule Program
A Travel Rule program does not operate in isolation. It sits inside a broader KYC framework (know-your-customer infrastructure) and an AML/CFT policy that must be coherent end-to-end. The data a VASP collects at onboarding – name, date of birth, address, identity document – is the same data it needs to transmit under the Travel Rule. If the onboarding data is incomplete, the Travel Rule transmission will be deficient.
This is a design problem as much as a legal problem. A VASP that onboards customers under a tiered KYC model – allowing limited activity before full verification – must decide at what tier the Travel Rule threshold is met. If a customer reaches the transmission threshold before completing enhanced KYC, the VASP either halts the transfer or transmits incomplete data. Neither outcome is costless. The first creates a user-experience failure. The second creates a compliance violation.
Transaction monitoring – the automated and manual review of transaction patterns against expected behaviour – is the mechanism that connects the KYC record to the Travel Rule obligation in practice. A transaction that triggers a monitoring alert may also require a Travel Rule re-check: is the beneficiary VASP on a sanctions list? Has the counterparty's regulatory status changed? Has the wallet address been flagged by a forensics tool? These are real-time questions that a well-designed compliance program answers automatically. A poorly designed one answers them never.
The MLRO – money laundering reporting officer – sits at the intersection of all of this. Under every major regulatory regime, a VASP is required to appoint a natural person responsible for AML compliance, Travel Rule compliance and suspicious activity reporting. That individual must have the authority, the resources and the access to data to do the job. Regulators increasingly assess the MLRO's actual capacity, not just the appointment on paper.
How Does a Multi-Entity Cross-Border Structure Affect the Travel Rule Program?
For a group operating a VASP in Dubai under VARA, a custody entity in Singapore under MAS, and a European-facing CASP authorised under MiCA, the Travel Rule program is not one program. It is three programs that must be interoperable without creating a compliance gap at the intra-group transfer level.
Intra-group transfers between affiliated VASPs in different jurisdictions are still transfers for Travel Rule purposes under the EU regime and under VARA. The group must maintain counterparty screening records for its own affiliates, exchange IVMS 101 data between group entities, and ensure that each entity's local Travel Rule implementation satisfies its local regulator – even where the group-wide policy is the same document. A single offshore licence is not sufficient to cover this. That is not a minority view. It is the explicit position of ESMA, VARA and MAS.
A common assumption at this stage is that a shared compliance function – one MLRO, one policy, one monitoring system – resolves the entity complexity. It does not. A shared function can supply the policy and the tooling. But each licensed entity must demonstrate to its own regulator that the function is actually governing that entity's activity. Joint governance documentation, entity-level risk assessments and regulator-specific reporting lines are not optional extras for a multi-entity group. They are licence conditions.
If your group structure has grown faster than your compliance architecture, contact OBOLUS at info@oboluslaw.com. If a prior application stalled or a banking relationship was terminated, a structural review can identify the reason and the path forward.
Does the Technology Stack Create Compliance Risk?
The choice of Travel Rule solution vendor is itself a compliance decision, and it is one that regulators are beginning to scrutinise directly. A VASP that delegates its Travel Rule data exchange to a third-party protocol must still own the outcome. If the vendor fails to deliver a message, if the data format is non-compliant, or if the counterparty VASP is not on the vendor's network, the legal liability rests with the VASP – not the vendor.
The major Travel Rule protocol providers have built networks of varying coverage. A VASP that is connected to only one protocol may be unable to exchange data with a counterparty using a different protocol. This is an architectural risk that sits in the commercial contract, not in the compliance policy. We have seen compliance programs that assume universal vendor interoperability and then discover mid-quarter that a significant portion of their transfer volume involves counterparties outside their vendor's network.
Blockchain analytics tools – used for transaction monitoring, wallet screening and forensic attribution – are a separate layer. A VASP that uses analytics for counterparty risk assessment but does not integrate the output into its Travel Rule decision process has two parallel systems that do not talk to each other. The compliance program must specify how analytics findings affect Travel Rule decisions: at what risk score does a transfer halt, who makes that call, and what is the documented rationale?
In a recent compliance review matter, a payments company discovered that its Travel Rule solution was correctly transmitting data for outbound transfers but was not capturing inbound data for reconciliation against its own customer records. The gap had persisted through two regulatory reporting cycles. We assisted in designing a remediation architecture and a backward-looking audit trail for the regulator's review. The key lesson: inbound data obligations are as real as outbound, and they are checked first in an FCA or ESMA-coordinated audit.
How Do Regulators Actually Audit a Travel Rule Compliance Program?
A regulator auditing a Travel Rule compliance program will typically examine five areas: policy documentation, system capability, record completeness, governance accountability and incident response. The audit approach varies by regime – the FCA in the UK tends toward thematic reviews and information requests; VARA in Dubai conducts supervised examinations with defined scopes; ESMA coordinates with NCAs under MiCA on supervisory convergence.
Policy documentation must show not just that the VASP has a Travel Rule policy but that the policy is current, reflects the applicable regulatory regime in the entity's home jurisdiction, and has been approved at board or senior management level. A policy that was drafted at authorisation and has not been reviewed since is a red flag in any audit. Regulators look at the version history.
System capability is assessed against transaction data. A regulator will select a sample of transfers and trace each one: was the Travel Rule data collected, verified, transmitted and retained? If the VASP cannot produce a complete record for a sampled transaction – including the timestamp of the data exchange, the counterparty VASP identifier and the specific data fields transmitted – the auditor draws an adverse inference. This is not a hypothetical. It is the standard audit methodology described in FATF guidance and reflected in national supervisory expectations.
Governance accountability means demonstrating that the MLRO has real oversight. Regulators increasingly ask to interview the MLRO directly, review their management information, and assess whether the board receives Travel Rule compliance metrics as a standing agenda item. An MLRO who cannot answer questions about their own firm's transfer volumes, counterparty risk ratings and open exception items will not satisfy a competent examiner.
Which Compliance Build Profile Fits Your Operation?
Not every VASP faces the same Travel Rule compliance challenge. The right program architecture depends on the entity's licence, its transaction profile and its growth trajectory. A structured assessment starts with three operator profiles.
A single-jurisdiction VASP – licensed under MiCA in one EU member state, serving retail customers primarily within the EU – needs a Travel Rule program that is MiCA-compliant, handles the Transfer of Funds Regulation data requirements, and integrates with at least one Travel Rule protocol covering the major EU counterparties. The MLRO function can be lean. The monitoring system can use a standard risk-scored tool. The unhosted wallet policy will be the most operationally intensive element. Timeline to build: typically a matter of weeks for the policy layer, longer for system integration depending on the platform.
A multi-jurisdiction operator – licensed in Dubai under VARA and in Singapore under MAS, with a European CASP in progress – needs a group-level Travel Rule framework that maps to each entity's local requirements, a VASP counterparty registry that is actively maintained across at least two protocol networks, and an MLRO governance model that satisfies each regulator independently. The cross-border intra-group transfer protocol is a specific deliverable, not an assumption. Timeline to build a defensible program at this complexity: typically several months of structured work.
A DeFi-adjacent platform or token issuer with user-facing transfer functionality sits in a third category. Whether the Travel Rule applies at all turns on whether the platform is a VASP under the applicable definition – which depends on the degree of control the platform exercises over transfers. If the platform is a VASP, the full obligation applies. If it is not, it still faces AML obligations in most regimes. The classification question must be answered before the compliance architecture is designed. Getting this wrong in either direction creates structural risk.
Related at OBOLUS
- AML and Travel Rule Compliance for Digital-Asset Businesses – the full practice overview covering regulatory scope, MLRO obligations and cross-border program design.
- AML/CFT Policy Drafting for Established Operators – structured policy build and remediation for VASPs under active regulatory supervision.
- NFT Project Legal Structuring – legal counsel for digital-asset firms at the boundary of token issuance, DeFi and regulated activity.
What Are the Most Common Travel Rule Program Failures in Practice?
Across the compliance matters we have worked through, program failures cluster around five repeating patterns. Each one is avoidable with the right design at the outset. Each one is expensive to remediate after a regulatory finding.
The first is policy-system mismatch: the written policy describes a process the actual system cannot execute. The policy says transfers are halted if Travel Rule data is unavailable; the system allows them through with a manual-review flag that is never reviewed. A regulator who runs a sample audit finds the discrepancy immediately.
The second is counterparty screening inertia. A VASP screens its counterparty VASPs at onboarding and then does not re-screen them. A counterparty that was compliant at onboarding may have lost its licence, been sanctioned or suspended by its home regulator. Without a re-screening schedule, the VASP is sending Travel Rule data – and transfer value – to an entity it can no longer safely transact with.
The third is the inbound data gap, described in the micro-matter above. Most VASPs build their outbound process first. Inbound is treated as the counterparty's problem. It is not. The receiving VASP has its own obligations to verify and retain inbound data. These are checked in audit.
The fourth is MLRO under-resourcing. A nominal MLRO appointment with no budget, no direct system access and no board reporting line is a compliance liability, not a compliance asset. Regulators know the difference between an active MLRO and a named placeholder.
The fifth is the assumption that a third-party vendor removes the compliance obligation. It does not. The vendor is a service provider. The VASP is the regulated entity. Due diligence on the vendor, contractual SLAs tied to compliance outcomes, and fallback procedures for vendor failure are all part of the program – not afterthoughts.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP to collect, verify and transmit originator and beneficiary identifying information alongside each qualifying virtual asset transfer, and to retain that data for regulatory inspection. The obligation derives from FATF Recommendation 15 and is now embedded in the supervised regimes of every major digital-asset hub, including MiCA in the EU, VARA in Dubai, the MAS Payment Services Act framework in Singapore and the FCA regime in the UK. The applicable data threshold and exact data fields vary by jurisdiction.
Who must act as MLRO for a crypto firm?
Every regulated VASP must appoint a natural person as its money laundering reporting officer (MLRO) – an individual with sufficient seniority, independence and resource to oversee AML and Travel Rule compliance, file suspicious activity reports and engage with the regulator directly. The MLRO must have genuine authority and meaningful access to transaction data. A nominal appointment without budget or board reporting line will not satisfy the expectations of ESMA-aligned competent authorities, VARA or MAS examiners. Some regimes require the MLRO to be pre-approved or notified to the regulator.
How do regulators audit crypto AML programs?
Regulators auditing a crypto AML program typically examine five areas: the currency and board-approval status of the policy, the system's demonstrated ability to collect and transmit Travel Rule data, the completeness of transaction records on a sampled basis, the MLRO's actual governance capacity, and the firm's incident-response history. Examiners will request transaction samples and trace each one end-to-end. Gaps in inbound data retention, outdated counterparty screening records and policy-system mismatches are the most common adverse findings across FCA, VARA and MiCA-framework audits.
About OBOLUS
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 programs 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 before you commit – and our disputes team coordinates freezing relief and on-chain tracing across leading common-law forums when things go wrong. To discuss your compliance program, contact info@oboluslaw.com or message us via t.me/oboluslaw.
By Roman Levitt, Technology & DeFi Counsel – specialising in the regulatory treatment of DeFi protocols, token transfer mechanics and the technology layer of VASP compliance programs.
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.