With VASP supervision tightening across every major licensing hub, a virtual asset service provider that cannot demonstrate a documented, tested Travel Rule program is not merely non-compliant – it is operationally exposed. Regulators under MiCA, VARA, the MAS Payment Services Act and the FCA's Money Laundering Regulations all treat Travel Rule readiness as a precondition for licence grant and renewal, not an afterthought. Operating without that readiness risks enforcement action, frozen banking rails and loss of the licence itself.
A Travel Rule compliance program (the obligation, derived from FATF Recommendation 15, to collect, verify and transmit originator and beneficiary data alongside virtual asset transfers) is not a single software purchase. It is a layered regime spanning legal analysis, technical integration, counterparty due diligence, and staff governance. This guide sets out the essential steps, the regulated basis for each, the cross-border complications that operators routinely underestimate, and the mistake most commonly made at every stage.
What Is the Travel Rule and Why Does It Apply to Your Business?
The Travel Rule requires a VASP (virtual asset service provider) to collect and transmit identifying information about the originator and beneficiary of a virtual asset transfer – and to verify that information above applicable thresholds. The obligation derives from FATF Recommendation 15, which brought virtual assets within the same AML/CFT perimeter as traditional wire transfers. The question of whether your business is caught turns not on your label but on the activity you perform: exchange, custody, transfer, lending and brokerage all engage the rule in most flagship regimes.
Across the EU, the obligation is embedded in the Transfer of Funds Regulation as extended by MiCA's companion instruments, placing CASP authorisation holders firmly within scope. VARA in Dubai imposes equivalent data-transmission obligations across its activity-based licence categories. The MAS Payment Services Act carries a Travel Rule regime administered by the Monetary Authority of Singapore. The FCA requires registered cryptoasset businesses to comply with Travel Rule obligations under the UK's Money Laundering Regulations.
The cross-border note matters immediately: a VASP incorporated in Lithuania, serving users in Germany and settling through a Singapore sub-entity, potentially faces three concurrent Travel Rule regimes. Each may apply a different de-minimis threshold, a different data-field standard, and a different enforcement posture. A program built to satisfy one regime in isolation will almost certainly fail in another.
Common mistake at this step: treating the Travel Rule as a purely technical matter for the engineering team. The threshold analysis, counterparty scoping and inter-regime conflict resolution are legal questions. Delegating them entirely to a software vendor produces a product without the legal framework to sustain it.
To scope whether your current entity structure triggers Travel Rule obligations in more than one regime, contact OBOLUS at info@oboluslaw.com. The cross-border analysis – which regime governs which leg of a transfer – is where the program either stands or falls from the outset.
Step 1 – Conduct a Legal Scoping Analysis Before You Build Anything
Before a technical solution is selected or a policy drafted, a VASP must map the legal perimeter: which jurisdictions' Travel Rule obligations apply, what data fields and verification standards each requires, and how conflicts between regimes are resolved. This is the foundation on which every subsequent step depends.
The scoping analysis should answer three questions. First, in which jurisdictions does the VASP hold a licence or registration – and what does each applicable regime (MiCA/ESMA, VARA, MAS, FCA, AFSA under the AIFC regime, SFC in Hong Kong) specifically require? Second, where are the counterparty VASPs located, and are they operating under a regime with recognized equivalence? Third, where data-field requirements differ, which standard controls the transfer – the sending jurisdiction's rules, the receiving jurisdiction's rules, or both simultaneously?
The cross-border complexity is acute for businesses operating across the UAE and EU simultaneously. VARA's rulebooks and MiCA's Transfer of Funds instrument do not share identical data requirements. A transfer from a VARA-licensed entity to an EU CASP must satisfy both sets of requirements on the outbound leg.
Common mistake at this step: copying a competitor's Travel Rule policy without verifying whether that competitor operates under the same licence set. Policy templates are a starting point, not a compliance program. Regulators distinguish between a policy that reflects a genuine legal analysis and one assembled from public documents.
Step 2 – Appoint a Qualified MLRO and Define the Governance Structure
Every regime that imposes Travel Rule obligations also requires the appointment of a Money Laundering Reporting Officer (MLRO) – the individual with ultimate accountability for the firm's AML/CFT posture. The MLRO is not merely a sign-off function. Under MiCA, VARA, MAS and FCA requirements, the MLRO must be sufficiently senior, sufficiently resourced and demonstrably independent from the revenue-generating parts of the business.
Regulators in the leading hubs increasingly expect the MLRO to hold relevant AML credentials, to maintain a documented compliance calendar, and to produce a regular board-level report. VARA and ESMA guidance both contemplate that the MLRO has direct escalation rights to the board or equivalent governance body. Where a VASP operates through multiple licensed entities – a common structure for operators with EU and UAE presences – each licensed entity may require its own appointed MLRO under local rules.
The governance structure must also define the three-lines-of-defense model: first line (business functions performing customer due diligence at origination), second line (compliance monitoring and Travel Rule oversight), and third line (internal audit or an independent external review). Most early-stage VASPs build only the first line and call it a compliance program. That approach will not withstand a supervisory assessment.
Common mistake at this step: appointing the founder or the CFO as MLRO to reduce headcount costs. Regulators treat a nominally qualified but practically unavailable MLRO as evidence of a paper program. The appointment must be real, resourced and documented in the governance structure.
Step 3 – Build the KYC and CDD Framework That Feeds Travel Rule Data
Travel Rule data is only as reliable as the KYC and customer due diligence process that generates it. A VASP cannot transmit verified originator information if it has not verified that originator in the first place. The KYC framework (the customer identification, verification and risk-rating process) and the Travel Rule program must be designed together, not sequentially.
At a minimum, the KYC framework must collect and verify the information required by the applicable Travel Rule regime for every transfer above the relevant threshold – name, account number or wallet address, and the jurisdictional identifiers that each regime specifies. Under the FATF baseline, the minimum is name plus account reference. MiCA and the EU Transfer of Funds Regulation add address and date of birth for natural persons. VARA's rulebooks carry their own verification standards under the applicable activity licence.
The cross-border note: when a transfer is received from a VASP in a jurisdiction without a recognized Travel Rule regime – a so-called sunrise issue – the receiving VASP must decide whether to proceed, request missing data, or apply enhanced due diligence. That decision must be documented in a written policy, not resolved ad hoc by the compliance officer on duty. Different regimes approach the sunrise issue differently; MAS guidance and MiCA-era EU guidance each set out their expected treatment, and they are not identical.
Common mistake at this step: treating the Travel Rule data field as a checkbox separate from KYC records. If the data field is populated from an unverified source – a self-declared wallet address, for example – the Travel Rule obligation is technically met but the underlying verification is absent. Regulators audit both.
Step 4 – Select and Integrate a Technical Travel Rule Solution
The technical infrastructure for Travel Rule compliance must support counterparty VASP identification, secure data exchange and message matching. The selection of a solution is a legal decision as much as a technical one: the solution must cover the messaging protocols recognized by the regimes under which the VASP operates and must interoperate with the counterparty networks those regimes expect.
The major protocols in market use – TRISA (Travel Rule Information Sharing Architecture), OpenVASP, and proprietary interoperability networks – each carry different counterparty network effects. A VASP selecting a solution that its counterparties do not use has a technically compliant system that cannot function in practice. Counterparty VASP directories and the networks they support must be mapped before vendor selection, not after.
Integration must also account for the unhosted wallet (self-custodied wallet) challenge. Transfers to or from unhosted wallets sit at the edge of Travel Rule applicability; MiCA-era EU rules, VARA and MAS each take a distinct position on the due-diligence steps required. The technical solution must be configured to route unhosted wallet transfers through the correct policy decision tree, not simply exclude them from the Travel Rule workflow.
In our cross-border practice, we regularly advise operators that a solution which handles EU-to-EU transfers cleanly can fail on a UAE-to-Singapore leg because the counterparty network is not enrolled in the same protocol. That gap is invisible until the first enforcement inquiry.
Common mistake at this step: selecting a Travel Rule vendor before completing the legal scoping in Step 1. The vendor's supported protocols and jurisdictional coverage must be matched against the firm's actual regime obligations. We have seen operators purchase and implement a solution, then discover it does not cover the data-field standard required by their primary regulator.
Step 5 – Establish a Counterparty VASP Due Diligence Process
A Travel Rule program is only as strong as the due diligence applied to the counterparty VASPs through which transfers flow. Transmitting Travel Rule data to an unverified or unregulated counterparty does not discharge the obligation – it compounds it. Every flagship regime requires the originating VASP to assess whether the beneficiary VASP is subject to AML/CFT requirements consistent with FATF standards.
The counterparty due-diligence process should maintain a scored counterparty register, covering: whether the counterparty holds a licence or registration in a recognized jurisdiction, the regime under which it operates, whether it participates in a recognized Travel Rule protocol, and any adverse regulatory history. This register must be updated regularly and must drive a risk-based decision on whether to transact, apply enhanced controls, or decline.
The cross-border angle is acute: a VASP licensed under VARA sending to an unregistered exchange in a jurisdiction with no FATF-equivalent regime must apply enhanced due diligence or decline the transfer, depending on VARA's applicable rulebook requirements. The policy decision cannot be left to the transaction-monitoring system alone. A human escalation path must exist and be documented.
Common mistake at this step: relying entirely on a third-party directory listing to establish counterparty legitimacy. Directory inclusion confirms enrollment in a protocol network; it does not constitute AML due diligence. The counterparty VASP's regulatory status, jurisdictional licence and adverse history must be independently verified.
If your firm is onboarding counterparty VASPs in unfamiliar jurisdictions and needs the regulatory status mapped, write to info@oboluslaw.com. The licensing and regulatory landscape shifts rapidly, and a counterparty that was compliant at onboarding may have lost its registration since.
Step 6 – Deploy Transaction Monitoring Integrated With Travel Rule Controls
Transaction monitoring (the ongoing surveillance of virtual asset transfers for patterns consistent with money laundering, sanctions evasion and fraud) must operate in conjunction with the Travel Rule program, not independently of it. A Travel Rule data field that does not align with the transaction monitor's customer profile is a red flag that the monitoring system must be capable of detecting.
The FCA, MAS and VARA all expect transaction monitoring to be calibrated to the specific risk profile of the business, its customer segments and the virtual assets it handles. A monitoring rule set copied from a traditional payment institution will systematically miss the velocity and wallet-cluster patterns characteristic of crypto-asset misuse. Rule calibration requires both the legal standard (which behaviors the applicable regime treats as suspicious) and the operational data (the firm's own transaction baseline).
Sanctions screening must be integrated at the Travel Rule data layer. The originator and beneficiary names, wallet addresses and jurisdictional identifiers generated by the Travel Rule workflow must pass through a screening system calibrated to the relevant sanctions lists – OFAC, EU consolidated list, UK financial sanctions list, and the UN list at minimum. A Travel Rule message that generates a sanctions hit but is not routed to a human reviewer is a systemic failure, not a technology gap.
In our practice, we have seen operators with technically functional Travel Rule solutions fail supervisory assessments because the transaction monitoring rules were not updated when new token types were added to the product. The monitoring scope must track the product scope.
Common mistake at this step: treating transaction monitoring as a vendor-managed function that does not require internal legal input. The thresholds, rule triggers and SAR/STR filing decisions are legal and compliance judgments. They cannot be fully outsourced.
Step 7 – Document, Train and Audit the Program
A Travel Rule compliance program that exists only in software configurations and spreadsheets will not survive a regulatory examination. Every regime that mandates Travel Rule compliance also requires documented policies, staff training records and an independent audit or review cycle. The documentation is not administrative overhead – it is the evidence that the program is real.
The core documentation set should include: the AML/CFT policy (incorporating Travel Rule obligations); the counterparty due-diligence policy; the unhosted wallet policy; the transaction monitoring calibration rationale; the SAR/STR filing procedure; and the MLRO annual report template. Each document must be version-controlled, board-approved and reviewed at least annually or on material regulatory change – whichever comes first.
Staff training must cover the specific obligations of every role that touches a Travel Rule workflow: the compliance team, the customer-onboarding function, the operations desk handling transfers, and the technology team managing the solution. Generic AML awareness training is insufficient. ESMA guidance and VARA's compliance expectations both contemplate role-specific, documented training with tested comprehension.
The independent audit cycle – whether conducted by internal audit, an external compliance reviewer, or a combination – must include a technical walkthrough of the Travel Rule solution, a sample file review against the data-field standard, a test of the escalation and SAR/STR workflow, and a calibration review of the transaction monitoring rules. The findings must be reported to the board or governance equivalent and tracked to remediation.
One micro-matter from our recent experience: a payments company operating under a MiCA-equivalent EU licence engaged us after a supervisory review identified that its Travel Rule policy had not been updated to reflect a change in its product range. The policy referenced only cryptocurrency transfers but the business had expanded into e-money token distribution. We assisted in scoping the gap, updating the documentation suite, and preparing a remediation timeline for submission to the relevant national competent authority. The regulator accepted the remediation plan, and the company avoided formal enforcement action by demonstrating that the gap had been identified and addressed through its own compliance review cycle.
Common mistake at this step: treating the annual policy review as a formatting exercise. A review that confirms no changes are required without a substantive analysis of regulatory developments in each applicable jurisdiction is not a review – it is a risk. Regulatory expectations under MiCA, VARA and MAS have each evolved materially in recent years, and policies must reflect current requirements, not the regime that existed at launch.
Related at OBOLUS
- AML and Travel Rule compliance for digital asset businesses – end-to-end compliance advisory across licensing, policy and audit
- Transaction monitoring setup in Mauritius – jurisdiction-specific guidance on building monitoring programs under VAITOS
- Founder relocation and tax in the Bahamas – cross-border structuring considerations for operators and founders
If your program has a documentation gap, a policy that has not been reviewed since launch, or an audit finding that needs a regulatory response, contact OBOLUS at info@oboluslaw.com. We map the remediation path and prepare the submission.
Is a Single Offshore Licence Enough to Cover a Global User Base?
A common assumption among early-stage operators is that a single offshore registration – in the BVI, Cayman Islands or a similar jurisdiction – provides a sufficient regulatory wrapper for a globally accessible exchange or wallet service. It does not. The Travel Rule and the AML obligations that surround it attach to the activity performed for users, not only to the jurisdiction of incorporation.
A VASP incorporated in the BVI under the VASP Act 2022 and serving users in Germany, Singapore and the UAE simultaneously is, in most analyses, engaged in regulated activity in each of those jurisdictions. The BVI FSC registration addresses BVI-law obligations. It does not displace MiCA's CASP authorisation requirement for EU users, MAS licensing requirements for Singapore-based customers, or VARA's reach over UAE-directed marketing. Each of those regimes carries its own Travel Rule standard.
The cross-border reality that operators in our practice consistently underestimate is that the Travel Rule's enforcement exposure sits in the jurisdiction of the user, the counterparty, or the banking correspondent – not only the jurisdiction of the licensed entity. A correspondent bank in New York applying FinCEN standards will apply its own assessment of whether an inbound VASP has an adequate Travel Rule program, regardless of where that VASP is licensed.
We map the licence, banking and compliance stack across operating, custody and payment layers before a business commits to a structure. The Travel Rule program must be designed around the full licence stack – not reverse-engineered after the structure is fixed.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule, derived from FATF Recommendation 15, requires a VASP to collect, verify and transmit originator and beneficiary information alongside virtual asset transfers above applicable thresholds. The specific data fields and verification standards vary by jurisdiction. Under MiCA-era EU rules, name, account reference and additional identifiers apply. VARA, MAS and FCA requirements each carry their own specifications. The obligation applies to both the originating and beneficiary VASP on a transfer.
Who must act as MLRO for a crypto firm?
Every regime that imposes AML/CFT obligations on VASPs requires the appointment of a Money Laundering Reporting Officer – a sufficiently senior individual with ultimate accountability for the firm's compliance posture. The MLRO must be independent from revenue-generating functions, properly resourced, and capable of reporting directly to the board. Regulators under MiCA, VARA and the MAS Payment Services Act each assess MLRO suitability as part of the licensing and supervisory process. A nominal appointment that lacks real authority will not satisfy regulatory expectations.
How do regulators audit crypto AML programs?
Regulators in the major hubs – including ESMA's national competent authorities, VARA and MAS – conduct AML program assessments through a combination of document review, technical system walkthrough and sample file examination. Examiners review the firm's AML policy, Travel Rule documentation, transaction monitoring calibration rationale and MLRO reporting records. They also test whether the program reflects the firm's actual product range and risk profile. A gap between documented policy and operational practice is the most common finding in supervisory reviews.
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 frameworks that sit across all of them. Digital assets are the whole of our practice. We map the licence stack across operating, custody and payment layers before you commit – and we work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications when recovery is needed. To discuss your compliance program or your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML, Travel Rule program design and cross-border VASP compliance across EU, UAE and Asia-Pacific 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.