The Travel Rule (the obligation to pass originator and beneficiary identification data with every qualifying virtual-asset transfer) is no longer a back-office compliance checkbox. As regulators across the leading hubs move from registration to active supervision, a structurally deficient Travel Rule compliance program is the single fastest route to frozen banking rails, suspended licences and personal liability for the MLRO. The structuring question – how a program is designed, where its obligations sit within the entity stack, and which counterparties it must reach – is the one that general counsel and founders most often get wrong.
A well-designed Travel Rule compliance program addresses three layers simultaneously: the legal layer (which regime applies and to which entity), the operational layer (how data flows between originating and beneficiary VASPs), and the structural layer (where within a multi-entity group the obligations are owned). Getting one layer right while leaving the others unaddressed does not satisfy a regulator conducting an AML compliance audit. This analysis works through all three, with particular focus on the cross-border structuring choices that determine whether a program is defensible.
The sections below cover the regulatory perimeter, the data and counterparty architecture, common structural mistakes, how the cross-border entity stack complicates compliance, the MLRO and governance question, the audit posture regulators now expect, and a decision matrix for operators choosing between program models.
What Is the Regulatory Perimeter of the Travel Rule?
The Travel Rule applies to any entity that qualifies as a VASP (virtual asset service provider) under the FATF Recommendations – specifically Recommendation 15, which extends the wire-transfer rule to virtual-asset transfers – and to the equivalent categories in jurisdiction-specific regimes. The practical question is not whether the Travel Rule exists but which version of it, at what threshold, and enforced by which regulator, applies to a given business.
Under MiCA and the EU Transfer of Funds Regulation as extended to crypto-assets, any CASP (crypto-asset service provider) authorised in a member state is subject to Travel Rule obligations on transfers above the applicable de-minimis threshold. The threshold itself is a [VERIFY] figure under the current implementing measures – operators should confirm the current number with counsel before building their filtering logic. What is settled is that the obligation applies to both the originating and the beneficiary CASP, and that unhosted-wallet transfers above that threshold attract enhanced due-diligence requirements rather than a simple exemption.
In Dubai, VARA (the Virtual Assets Regulatory Authority) imposes Travel Rule compliance as a standing requirement across all activity-based licence categories. In Singapore, the MAS (Monetary Authority of Singapore) Travel Rule Notice under the Payment Services Act applies to Digital Payment Token service providers. In the United Kingdom, the FCA (Financial Conduct Authority) has aligned with the FATF standard through the Money Laundering Regulations. In each case the specific threshold and the scope of the unhosted-wallet exemption differ – which is precisely why the structuring angle matters. An entity that is registered in one jurisdiction but routes transfers through a subsidiary in a second jurisdiction with a different threshold can inadvertently create a compliance gap or, conversely, can engineer a cleaner data-handoff if the structure is designed with that in mind.
The perimeter question also has a product dimension. Custodial wallets, exchange settlement flows, OTC desk transfers and stablecoin redemptions each trigger the Travel Rule differently. A firm that treats all outbound transfers as a single product category will mis-classify a material share of them. We regularly advise clients to map their transfer taxonomy before choosing a compliance technology – because the technology choice is downstream of the classification decision, not the other way around.
CTA #1Mapping the regulatory perimeter is the first step – and the one where the analysis most often stalls. The process above describes the standard path. Your facts – the entity, the user base, the banking – change the analysis materially. For a scoped assessment of where your Travel Rule obligations begin and end, contact OBOLUS at info@oboluslaw.com or map your options.
How Does the Travel Rule Data Architecture Work in Practice?
The Travel Rule data architecture requires an originating VASP to collect, verify and transmit a defined set of originator and beneficiary fields to the beneficiary VASP before or simultaneously with the transfer – and requires the beneficiary VASP to receive, validate and store that data. The mechanics appear straightforward. The operational reality, across a fragmented counterparty universe, is not.
The first structural decision is which Travel Rule solution – the protocol layer that carries the data alongside the blockchain transaction – the firm will deploy. The leading approaches (TRISA, TRP and issuer-native channels) are not universally interoperable. A firm that deploys one protocol and encounters a counterparty that has deployed a different one faces a data-handoff failure at the moment of transfer. The practical consequence is either a blocked transfer, a manual workaround that creates a paper trail the regulator will later scrutinise, or a mis-filed record. None of those outcomes is acceptable under an active supervisory regime.
The second decision is how to handle unhosted wallets. FATF guidance distinguishes between transfers to another VASP (where the Travel Rule data flows between two regulated entities) and transfers to an unhosted wallet (a wallet not held by a regulated custodian). Most major regimes now require enhanced due diligence on unhosted-wallet transfers above a threshold, including wallet ownership verification. The precise verification standard – self-attestation, micro-transaction confirmation, or a signed message – varies by regime and, increasingly, by the internal risk appetite the firm documents in its AML policy.
In our practice, the most common data-architecture failure is not a technology failure but a governance failure: the compliance team chose a protocol, the engineering team integrated it, and nobody mapped the outbound transfer population to identify which counterparties are reachable under that protocol and which are not. The result is a program that functions on paper and fails on the majority of real transfers. Regulators conducting AML audits now ask specifically for counterparty-reachability data and for the firm's documented procedure when a counterparty is unreachable – a procedure that must itself comply with the applicable standard.
What Are the Most Common Structural Mistakes in Travel Rule Programs?
The most common structural mistake is building a Travel Rule program at the wrong level of the entity stack – typically at the operating entity that holds the licence, while leaving data obligations at the group treasury or custody subsidiary unaddressed. This is a direct consequence of the AUDIENCE_MYTH that a single offshore licence is sufficient infrastructure for a globally active business. It is not.
Consider a structure in which a Cayman Islands holding company owns a VARA-licensed Dubai entity and a MiCA-passported EU CASP. The Dubai entity executes spot trades. The EU CASP handles fiat on-ramps for European users. Group treasury sits in the Cayman holding company and sweeps balances between the two operating entities nightly. Under this structure, the intercompany sweep may itself constitute a virtual-asset transfer for Travel Rule purposes in one or both jurisdictions – a point that the group's external auditor is unlikely to flag but that a VARA or an EU NCA examiner will identify immediately.
A second common mistake is MLRO fragmentation. Groups appoint an MLRO at each regulated entity – a reasonable response to the regulatory requirement – but fail to specify who owns the group-level Travel Rule policy, who resolves a conflict between the policies of the two operating entities, and who is the single point of contact for a regulator conducting a cross-entity examination. The absence of that architecture is itself a finding.
A third mistake involves transaction-monitoring calibration. The KYC framework and the Travel Rule are not the same obligation, but they interact. A customer whose KYC profile is rated medium risk may nonetheless generate high-risk Travel Rule signals – for example, a pattern of transfers just below the applicable threshold that suggests deliberate structuring to avoid data-transmission requirements. Transaction-monitoring systems that treat KYC risk and Travel Rule risk as independent variables will miss that pattern. We have seen this gap identified in regulatory examinations across multiple jurisdictions.
In a recent matter, a European payments firm had deployed a well-credentialled Travel Rule solution but had calibrated its transaction-monitoring thresholds to the EU standard without adjusting for the lower effective threshold applied by its Singapore correspondent. The firm's outbound transfers to Singapore-based counterparties were systematically under-reported. We restructured the monitoring parameters and the interoperability logic before the firm's scheduled MAS review – a remediation that took several weeks and would have taken several months had it begun after the examination.
How Does a Multi-Jurisdiction Entity Stack Complicate Travel Rule Compliance?
A multi-jurisdiction entity stack creates compliance complexity in direct proportion to the number of regulatory regimes it touches – and the complexity is not additive but multiplicative, because each regime may characterise the same transfer differently. This is the core cross-border challenge that a structuring-angle analysis must address head-on.
Take a transfer from an EU CASP to a BVI-registered VASP. Under the EU Transfer of Funds Regulation, the EU CASP is the originating VASP and bears full data-transmission obligations. Under the BVI VASP Act framework, the receiving entity may or may not be subject to an equivalent Travel Rule obligation depending on the specific registration category. If the BVI entity is not subject to a symmetric obligation, the EU CASP has transmitted data to a counterparty that has no legal obligation to receive or retain it in the required form – which creates a question about whether the transmission was effective for compliance purposes under the EU standard.
The practical resolution is a counterparty due-diligence process – sometimes called VASP due diligence – that precedes any transfer relationship and documents the counterparty's regulatory status, applicable regime, and Travel Rule posture. This is not a one-time exercise. Regulatory status changes. A counterparty registered in Lithuania under the pre-MiCA VASP regime is now mid-transition to CASP authorisation under MiCA. Its compliance obligations shifted as that transition progressed. A firm that conducted VASP due diligence two years ago and has not refreshed it is holding stale data that a regulator will treat as no data at all.
Banking adds a further layer. Most correspondent banks that service digital-asset businesses now conduct their own Travel Rule assessments of their VASP clients as part of ongoing due diligence. A VASP whose internal Travel Rule program is inconsistent with what it disclosed to its correspondent bank at onboarding faces a dual risk: regulatory exposure under the applicable AML regime and banking exposure under the correspondent's ongoing-monitoring framework. We map the licence, banking and compliance stack as an integrated structure rather than three separate workstreams – because the failure mode is almost always at the junction between two of them, not within any one of them.
CTA #2If a prior compliance build stalled, or a banking relationship was terminated after a Travel Rule audit, a structural review can identify the gap and the route back. If a prior application stalled or an account was closed, a second read can surface the structural reason and the route forward. Write to OBOLUS at info@oboluslaw.com or map your options.
Who Owns the Travel Rule Program – and What Does the MLRO Role Actually Require?
The MLRO (Money Laundering Reporting Officer) is the designated individual legally responsible for the AML compliance program, including Travel Rule compliance, under most major regimes – and the person who faces personal regulatory liability if the program fails a supervisory examination. The MLRO role is not a title that can be distributed across a compliance team. It is a singular accountability.
Under the FATF standard and the jurisdiction-specific rules that implement it, the MLRO must have sufficient seniority, independence and resource to fulfil the role. In our practice, we see three recurring failures in MLRO structures at digital-asset firms. First, the MLRO is too junior: a compliance analyst designated MLRO to satisfy a licence application requirement, without the authority to override a business decision that creates a compliance risk. Second, the MLRO is too senior: a Chief Compliance Officer who delegates all operational compliance work, leaving no one with working knowledge of the Travel Rule data flows. Third, the MLRO is shared across entities: a group-level MLRO who is nominally the MLRO of four licensed entities simultaneously, without a documented escalation and decision-making protocol that a regulator could audit.
The Travel Rule introduces a specific governance challenge for the MLRO that is distinct from standard AML reporting. Travel Rule compliance requires near-real-time decision-making: when a transfer is about to execute, the system must confirm that the required data is present, the counterparty is reachable, and the unhosted-wallet verification (if applicable) is complete. The MLRO must have visibility over that decision architecture and must be able to demonstrate, on examination, that they reviewed and approved the logic. That is not a review that happens annually. It is a program that requires standing oversight.
The MLRO also owns the policy governing what happens when a counterparty is unreachable. FATF guidance permits a risk-based approach to unreachable counterparties, but that approach must be documented, applied consistently and subject to periodic review. A firm that blocks all transfers to unreachable counterparties will irritate its users and create business pressure on the MLRO. A firm that permits all such transfers without documentation will fail the next supervisory examination. The policy lives in the middle – and it must be the MLRO's policy, not the product team's preference expressed as a compliance document.
What Are the Contrasting Regulatory Positions on Unhosted Wallets and Program Scope?
The most significant area of doctrinal divergence in Travel Rule compliance today is the treatment of unhosted wallets – and the contrasting regulatory positions create a genuine compliance dilemma for firms operating across multiple regimes simultaneously.
The EU position, as implemented through the Transfer of Funds Regulation as extended to crypto-assets, applies the Travel Rule to transfers to unhosted wallets above the applicable threshold and requires the originating CASP to collect and verify information about the unhosted wallet. The precise verification standard is the subject of ongoing regulatory guidance, but the direction of travel is toward stricter verification, not looser. ESMA and the national competent authorities have indicated that self-attestation alone will not satisfy the standard for transfers above risk-based thresholds.
The FATF position is formally aligned – Recommendation 15 and the associated guidance require VASPs to collect beneficial ownership information for transfers to unhosted wallets above the threshold – but FATF itself acknowledges that the technical means of verifying ownership of an unhosted wallet are still maturing. This creates a gap between the standard and the available technology that each jurisdiction is filling differently.
Singapore's MAS has adopted a risk-based approach that places particular weight on the firm's documented risk assessment of each unhosted-wallet transfer rather than prescribing a single verification method. The FCA in the UK has aligned with the FATF standard but has issued practical guidance on acceptable verification methods. VARA in Dubai applies its own rulebook requirements. The result is that a firm operating in all four jurisdictions simultaneously must maintain a verification standard that satisfies the strictest applicable regime for every unhosted-wallet transfer – or must structure its product offering so that different entity types handle different transfer categories, each applying the standard of their respective regulator.
The latter – structural separation of transfer types by entity – is the approach we see gaining traction among well-advised operators. It is not a simple structure to design or to operate, but it is more defensible than a single compliance standard that attempts to satisfy four regulators simultaneously and satisfies none of them fully.
Which Travel Rule Program Model Fits Which Operator Profile?
The right Travel Rule program model depends on the operator's entity structure, user base geography, transfer volume and the intensity of regulatory supervision it faces. There is no universal answer – but there is a structured way to think through the decision.
Profile A: Single-jurisdiction VASP, primarily retail, high transfer volume. This operator is subject to one regulatory regime and needs a Travel Rule solution that is protocol-interoperable with the widest possible counterparty universe. The primary risk is counterparty non-reachability at scale. The right model is a leading-protocol deployment with a documented fallback procedure for unreachable counterparties, integrated with transaction monitoring at the individual-transfer level. The timeline from policy design to operational readiness is typically a matter of weeks for the technology and a matter of months for the governance structure around it.
Profile B: Multi-jurisdiction group, institutional and retail, intercompany transfers. This operator is subject to two or more regulatory regimes and faces the intercompany-transfer question described above. The right model is a group-level Travel Rule policy with entity-specific annexes, a single MLRO governance protocol that covers escalation across entities, and a VASP due-diligence program that is refreshed on a defined cycle. The capital and operational cost of this model is higher – but the cost of a supervisory finding that the group's intercompany transfers were unaddressed is higher still.
Profile C: Newly licensed VASP, limited transfer history, building from scratch. This operator has the advantage of designing the program before the transfer volume creates operational path dependency. The right model is a policy-first approach: define the transfer taxonomy, map the counterparty universe before launch, choose the protocol based on where the majority of counterparties are concentrated, and integrate the transaction-monitoring system with the Travel Rule logic from the outset. The most common mistake for this profile is choosing the technology first and building the governance around it retroactively.
Profile D: Exchange or OTC desk with significant unhosted-wallet transfer volume. This operator faces the unhosted-wallet challenge most acutely. The right model depends on the primary jurisdiction but almost always involves a documented risk-based verification procedure, a product-level decision about whether to apply the strictest applicable standard universally or to separate products by entity, and a standing review cycle for the verification procedure as regulatory guidance evolves.
How Do Regulators Audit Travel Rule Compliance Programs – and What Do They Expect to Find?
Regulators auditing Travel Rule compliance programs are no longer reading policy documents in isolation. They are requesting transaction-level data, counterparty-reachability logs, MLRO sign-off records and, increasingly, evidence of how the firm responded to specific transfer events where the data was absent or incomplete. The audit posture has shifted from documentation review to operational interrogation.
In an examination, a regulator will typically request a sample of transfers and trace each one through the compliance record: Was the required data collected at origination? Was it transmitted to the counterparty? Was the counterparty reachable under the firm's deployed protocol? If not, what procedure was followed? Was that procedure consistent with the documented policy? Was the MLRO informed? The answers to those questions must be retrievable from the firm's systems within the time window the regulator specifies – which is typically short.
Regulators have also begun examining the transaction monitoring calibration as part of Travel Rule audits. The question is not only whether the firm is transmitting data but whether its monitoring system is identifying patterns that suggest a customer is structuring transfers to avoid the data-transmission threshold – the classic structuring risk that the Travel Rule was partly designed to address. A firm whose monitoring system is calibrated only to the threshold and not to sub-threshold pattern detection will have a gap that an experienced examiner will find.
The AIFC's AFSA in Kazakhstan, VARA in Dubai, the FCA and the EU's national competent authorities have all issued supervisory communications in recent periods signalling that Travel Rule compliance will be a priority examination topic. The direction of regulatory travel is consistent: the days of a paper program that is never tested operationally are ending. Firms that have not conducted an internal audit of their Travel Rule program against the operational record – not just the policy – should treat that as an immediate priority.
An objection-handler note is appropriate here. A common assumption in the market is that Travel Rule compliance is primarily a technology problem – that deploying a recognised protocol solution closes the compliance exposure. It does not. The technology is a necessary condition. It is not a sufficient one. Regulators are not auditing the technology vendor's certification; they are auditing the firm's governance, the MLRO's oversight, the policy coherence and the operational record. Technology without governance is the most expensive way to fail a Travel Rule examination.
Self-Assessment Checklist: Is Your Travel Rule Program Structurally Sound?
A Travel Rule compliance program is structurally sound when it can withstand an operational examination – not just a document review. The following checklist is not a substitute for legal advice but is a starting-point for a general counsel or MLRO conducting an internal pre-audit review.
- Has the firm mapped its full transfer taxonomy – distinguishing VASP-to-VASP transfers, VASP-to-unhosted-wallet transfers and intercompany group transfers – and assigned Travel Rule treatment to each category under the applicable regime?
- Is the firm's deployed Travel Rule protocol interoperable with the counterparty universe it actually transacts with – and is there a documented fallback procedure for unreachable counterparties?
- Does the MLRO have operational visibility over real-time Travel Rule decision logic – not just annual policy sign-off?
- Has the firm conducted VASP due diligence on all material counterparties, and is that due diligence refreshed on a defined cycle?
- Are the transaction-monitoring thresholds calibrated to the strictest applicable regime for each transfer type – and is the system configured to detect sub-threshold structuring patterns?
- Does the group-level policy address intercompany transfers, and does each regulated entity have an entity-specific annex that maps to its own regulator's requirements?
- Can the firm produce, within a short examination window, a transaction-level record that traces a sampled transfer from origination through data transmission to counterparty receipt?
- Has the firm's unhosted-wallet verification procedure been reviewed against current regulatory guidance – not the guidance that was current at the time the policy was written?
If the answer to any of these questions is "no" or "uncertain," that is where the structural review should begin. We map the licence, banking and compliance stack as an integrated structure before a firm commits to an approach – because retrofitting a program after a supervisory finding is orders of magnitude more disruptive than designing it correctly at the outset.
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – full-scope advisory on AML program design, MLRO support and regulatory examination readiness.
- Regulator and AML audit defence in Estonia – jurisdiction-specific counsel for supervisory examinations and enforcement proceedings in the Estonian AML framework.
- Founder relocation and tax counsel for digital-asset firms – integrated structuring advice on entity, tax and residency for founders building cross-border digital-asset businesses.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires an originating VASP to collect specified originator and beneficiary identification data and transmit it to the beneficiary VASP simultaneously with – or before – a qualifying virtual-asset transfer. The beneficiary VASP must receive, validate and retain that data. The precise data fields, the applicable threshold and the treatment of unhosted-wallet transfers vary by jurisdiction; operators must confirm the current standard under their specific regulatory regime.
Who must act as MLRO for a crypto firm?
Most major AML regimes require a designated MLRO (Money Laundering Reporting Officer) who is individually accountable for the firm's AML and Travel Rule compliance program. The MLRO must have sufficient seniority and independence to act on compliance concerns without business interference. In a multi-entity group, each regulated entity typically requires its own designated MLRO, supported by a group-level governance protocol that resolves inter-entity conflicts and provides a single escalation path for cross-border compliance issues.
How do regulators audit crypto AML programs?
Regulators increasingly conduct operational audits – requesting transaction-level records, counterparty-reachability logs and MLRO decision trails – rather than reviewing policy documents in isolation. Examiners test whether the firm's documented Travel Rule procedure was actually applied to real transfers, whether the transaction-monitoring system detects sub-threshold structuring, and whether the MLRO exercised genuine oversight. Firms that can produce a complete, retrievable compliance record for a sampled transfer population are in a materially stronger position than those with strong policies and weak records.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the AML, Travel Rule and compliance architecture that sits around them. Digital assets are the whole of our practice. We map the licence stack across operating, custody and payment layers before clients commit – because the failure mode is almost always at the junction between two workstreams, not within any one of them. Our disputes team coordinates freezing relief and on-chain tracing across leading common-law forums when recovery is needed. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML program architecture, Travel Rule compliance structuring and cross-border VASP regulatory mapping.
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.