Early-stage founders building a virtual asset service provider (VASP) business face a compliance deadline that arrives long before their first institutional client does. The Travel Rule – the obligation, derived from FATF Recommendation 15, to pass originator and beneficiary data alongside every qualifying virtual-asset transfer – applies at the moment a firm begins operating as a VASP, not when it scales. Regulators under MiCA, the VARA regime, the MAS Payment Services Act, the FCA's money-laundering registration rules and virtually every other flagship regime now treat Travel Rule readiness as a precondition for licensing, not a post-launch enhancement. The cost of discovering that gap during a supervisory review is measured in suspended licences, frozen payment rails and lost banking relationships. This page sets out how OBOLUS structures a Travel Rule compliance program for early-stage founders: the regulatory basis, the practical build, the cross-border complexity and the common mistakes we see before they become enforcement events.
What triggers a Travel Rule obligation and why it applies from day one
A Travel Rule obligation arises the moment a business transmits virtual assets on behalf of another person and meets the definition of a VASP under the applicable regime. There is no revenue threshold and no minimum transfer volume below which the obligation disappears entirely. FATF Recommendation 15 sets the international baseline, but each jurisdiction translates that baseline into its own operative rule: under MiCA the obligation attaches to crypto-asset service providers (CASPs); under the VARA regime in Dubai it applies across transfer and settlement licence holders; under the MAS Payment Services Act it falls on digital payment token (DPT) service providers. The rule is consistent across these regimes in its core demand: the originating VASP must collect, verify and transmit originator and beneficiary data, and the beneficiary VASP must receive and screen that data before making funds available.
Where early-stage founders routinely miscalculate is in treating the Travel Rule as a technology question rather than a legal and operational one. The technology – TRISA, OpenVASP, or a third-party messaging solution – is a means of transmission, not the compliance program itself. The program must also cover: counterparty VASP identification and due diligence, a policy for what to do when the counterparty cannot or will not share Travel Rule data (the so-called sunrise problem), a data-retention and privacy framework that reconciles Travel Rule obligations with GDPR or equivalent data-protection law, and an escalation procedure tied to the firm's broader AML policy. Building the technology without the legal architecture around it leaves the firm exposed during any supervisory review.
In our practice, we see founders who launch with a travel-rule tool already integrated into their stack but with no written policy behind it. When the Bank of Lithuania, MFSA or FCA examines the AML program, the absence of a documented procedure – who decides to reject a transaction, who holds the counterparty risk assessment, how exceptions are logged – is the finding that triggers remediation. The tool passes; the program fails.
To map the compliance obligations that apply at your entity's specific stage and jurisdiction, contact OBOLUS at info@oboluslaw.com. The process above describes the standard regulatory path. Your facts – the entity structure, the user base, the intended banking relationships – change the analysis materially. Map your options
How does a Travel Rule compliance program fit into the broader AML architecture?
A Travel Rule compliance program is a component of a broader AML/CFT framework – the full set of policies, controls and procedures a VASP maintains to detect and prevent money laundering and terrorist financing. The Travel Rule is the data-sharing layer; the rest of the AML framework provides the substance that makes that data actionable. The five core pillars of a VASP AML program are: a risk assessment, a KYC framework (customer identification and due diligence procedures), transaction monitoring, Travel Rule compliance, and an ongoing screening function for sanctions and politically exposed persons (PEPs). Each pillar interacts with the others: a transaction-monitoring alert may trigger a Travel Rule data re-check; a KYC risk score may dictate enhanced due diligence on the counterparty VASP.
For an early-stage founder, the sequencing matters. The risk assessment comes first because it determines the scope and calibration of every subsequent control. A peer-to-peer exchange serving a retail user base in multiple jurisdictions carries a different inherent risk profile than a B2B settlement layer serving licensed institutions. FATF guidance, adopted into each major regime's supervisory expectations, requires the risk assessment to be documented, approved at board or senior-management level and reviewed at intervals commensurate with the risk environment. Filing a risk assessment that reads as a generic template – rather than a document specific to the firm's products, geographies and customer types – is a red flag in any supervisory examination.
Travel Rule data must also connect to the KYC record. When a firm receives Travel Rule data naming an originator, that data needs to be screened against sanctions lists and cross-referenced against any existing customer record. This demands an operational link between the Travel Rule messaging system and the KYC and sanctions-screening platforms. In practice many early-stage firms build these as separate silos, with no automated feed between them. The result is a manual reconciliation burden that grows unsustainable at volume – and a control gap that regulators under MiCA, the VARA regime and the FCA's registration process will probe directly.
How does the Travel Rule work across borders when counterparties are in different regimes?
Cross-border Travel Rule compliance is more complex than domestic compliance because no single standard governs the data format, the threshold, or the timing of transmission across every jurisdiction simultaneously. FATF's Recommendation 15 guidance is the common foundation, but the implementation varies: the transfer threshold below which the rule does not apply differs by regime, data fields required differ by regime, and the legal framework for handling a counterparty in a jurisdiction that has not yet implemented the rule – the sunrise problem – differs by regime. A VASP licensed in one EU member state under MiCA sending assets to a counterparty in Singapore under the MAS Payment Services Act must satisfy both regimes' requirements for the same transaction.
The practical consequence for an early-stage founder is that a single Travel Rule policy is insufficient if the business intends to serve a multi-jurisdiction user base or to receive assets from counterparties in varied regulatory environments. The compliance program must include a jurisdictional matrix that maps which data fields are required inbound and outbound for each counterparty location, a risk-based procedure for handling transfers where the counterparty VASP is unresponsive or unregistered, and a procedure for suspending or rejecting transfers where the counterparty cannot be identified at all.
A further complication arises at the banking layer. A VASP holding a fiat settlement account at a correspondent bank is subject to that bank's own AML due diligence requirements, which typically include evidence that the VASP has a functioning Travel Rule program. Banks in Switzerland, Singapore, Lithuania and the UK have all, in our cross-border practice, declined or exited VASP relationships citing inadequate Travel Rule documentation. The compliance program is therefore simultaneously a regulatory obligation and a banking prerequisite.
Operators we advise routinely underestimate the documentation demand at the banking stage. A bank's VASP due diligence questionnaire will ask for the written Travel Rule policy, the name and qualifications of the MLRO (Money Laundering Reporting Officer), evidence of staff training, and a sample of how Travel Rule data is retained. Having the policy in draft form is not sufficient. The bank's AML team wants a dated, board-approved document with version control.
Who needs to act as MLRO and what governance structure supports the program?
Every regulated VASP is required to appoint a named individual as MLRO – the person responsible for receiving internal suspicious-activity reports, filing external reports with the relevant financial intelligence unit, and overseeing the AML/CFT program. Under MiCA, the VARA regime, the MAS framework and the FCA's MLR registration, the MLRO must be a natural person, must hold sufficient seniority and must be approved or at least notified to the regulator. For an early-stage firm, the MLRO is often a founder or a senior hire who wears multiple operational hats. This arrangement is not inherently problematic, but it requires that the conflict between operational and compliance roles is documented and managed.
The governance structure around the MLRO matters as much as the individual. Regulators expect to see: a board-level AML policy approved by the most senior governing body, clear reporting lines from the MLRO to that body, a documented escalation procedure for suspicious-activity reports, and a training record demonstrating that all staff handling transactions understand their AML obligations. This governance structure is not an administrative formality. It is the evidence base the regulator examines when it wants to understand whether the AML program is operationally embedded or exists only on paper.
In a recent compliance-build engagement, we assisted a payments-adjacent Web3 firm establishing its first regulated entity. The founding team had a Travel Rule tool and a draft AML policy but no named MLRO and no board-approved governance document. The Bank of Lithuania's onboarding questionnaire required both before it would proceed with the VASP registration. We structured the governance documentation, identified an appropriately qualified MLRO candidate within the team, and provided the policy suite in the form the regulator expected. The registration proceeded without a formal remediation request.
What are the most common Travel Rule compliance mistakes at early-stage VASPs?
The most consequential Travel Rule mistake at an early-stage VASP is treating the Travel Rule as a technical integration task delegated to the engineering team, rather than a legal and governance obligation owned at the senior-management level. The result is a system that transmits data but a program that cannot withstand supervisory scrutiny.
Other recurrent failures we observe in our practice include the following. First, adopting a Travel Rule messaging protocol without a written policy governing what to do when the protocol fails – when a counterparty VASP cannot be identified, when data is incomplete, or when a transmission error occurs. Second, failing to reconcile Travel Rule data-retention obligations with the jurisdiction's data-protection law. Retaining originator and beneficiary data for the required period is a legal obligation; retaining it without a lawful basis and appropriate access controls may simultaneously breach privacy law. This tension is acute for firms operating under both MiCA and GDPR. Third, building a compliance program sized for the firm's current transaction volume without scaling the controls to the planned growth trajectory. A transaction-monitoring system calibrated for fifty transactions a month will generate unmanageable alert volumes at five thousand transactions a month if the rules have not been retuned.
A fourth and underappreciated mistake is the failure to conduct counterparty VASP due diligence as a distinct process. Sending Travel Rule data to a counterparty VASP does not discharge the originating VASP's obligation to satisfy itself that the counterparty is a legitimate, regulated entity. The FATF guidance adopted into MiCA supervision, the VARA rulebooks and the FCA's registration expectations all contemplate that a VASP maintains a record of its counterparty relationships and the basis on which it assessed each counterparty as acceptable.
Which compliance build profile matches your stage and structure?
Not every early-stage VASP needs the same compliance architecture at the same moment. The right program depends on the firm's licence status, its transaction profile and the jurisdictions in which its users and banking partners are located.
Profile A – Pre-licence, EU entity: A founder preparing to apply for CASP authorisation under MiCA from a member-state NCA needs a full AML policy suite, a documented risk assessment, a named MLRO and a Travel Rule implementation plan as part of the application package. The regulator will not grant authorisation without evidence that the compliance infrastructure is in place or contractually committed. The indicative lead time for building this documentation from scratch is several weeks of focused legal and compliance work. The key risk at this stage is submitting an application with template documentation that fails the NCA's substantive review.
Profile B – Licensed VASP, multi-jurisdiction expansion: A firm already holding a VASP registration in one jurisdiction – for example under the BVI VASP Act or the Cayman VASP regime – that is expanding to serve users in the EU or Singapore faces a compliance uplift. The home-jurisdiction program may not meet the inbound-data, screening or governance expectations of the new regulator. A gap analysis against MiCA CASP standards or the MAS Payment Services Act DPT requirements is the starting point. The key risk here is assuming the existing program is portable without review.
Profile C – Exchange or custodian, banking-relationship pressure: A firm that holds a licence but is losing or cannot obtain a banking relationship due to AML documentation gaps needs a program that is simultaneously compliant and bank-presentable. This means board-approved policies, a dated and versioned AML manual, evidence of staff training and a Travel Rule implementation report that a correspondent bank's compliance team can read in under fifteen minutes. The key risk is that the documentation is compliant in substance but not in form – and banks review form first.
How does OBOLUS structure a Travel Rule compliance program engagement?
OBOLUS builds Travel Rule compliance programs as fixed-scope engagements with defined deliverables and a stated start-to-delivery timeline. We do not sell compliance templates. We map each client's entity structure, licence status, user-base geography and banking relationships, and we build the documentation package to match. Our process has four stages.
First, a scoped intake: we review the existing documentation, map the applicable regulatory regimes and identify the gaps against the standards required by each. This intake is conducted under NDA and produces a written gap analysis. Second, the policy build: we draft or revise the AML policy, the Travel Rule procedure, the KYC framework, the transaction-monitoring calibration guidance and the governance documentation. Each document is built to the specific supervisory expectations of the target regulator – not to a generic standard. Third, MLRO and governance support: where the client does not yet have a qualified MLRO, we assist in identifying the role requirements, structuring the board-level governance and preparing the regulator-notification materials. Fourth, banking and regulatory presentation: we structure the compliance documentation in the form required by both the regulator and the firm's banking partners, and we support the submission or presentation of that documentation.
We regularly advise firms at the point where a prior compliance build has failed supervisory review. In those situations, the remediation timeline is compressed and the documentation burden is higher than in a clean first-build. If your program has already been questioned by a regulator or a bank, the analysis starts from the regulator's specific finding, not from a fresh risk assessment.
If a supervisory review is pending or a banking relationship is at risk, contact OBOLUS now at info@oboluslaw.com. If a prior application stalled or an account was closed, a second read can surface the structural reason and the route back. Map your options
A common assumption: one offshore licence covers global operations
A common assumption among early-stage founders is that a single offshore VASP registration – in the BVI, Cayman Islands or a similar jurisdiction – is sufficient to operate a global crypto business and satisfy AML obligations worldwide. This assumption is incorrect in almost every commercially relevant scenario. Regulators in the EU, Singapore, Hong Kong and the UK apply their AML and Travel Rule requirements to any VASP that actively solicits or serves clients in their jurisdiction, regardless of where the VASP is incorporated or registered. The operative test is the location of the customer, the location of the transaction and, in some regimes, the location of the server infrastructure – not the location of the registered office.
A BVI-registered VASP with a significant EU user base is, in the MiCA regulatory analysis, providing crypto-asset services into the EU and may require CASP authorisation. A Cayman-registered exchange serving MAS-regulated institutions in Singapore may be required to hold a DPT service licence under the Payment Services Act. Serving those markets with only an offshore registration – and an AML program built to the minimum standard of the offshore regime – creates the exposure OBOLUS is regularly engaged to remediate: enforcement inquiries, banking terminations and, in the most serious cases, asset freezes.
We map the licence, banking and AML stack across operating, custody and payment layers before a founder commits to a structure. That mapping often reveals that the intended global reach requires a multi-jurisdiction compliance build rather than a single-entity solution. The cost of building it correctly at the outset is a fraction of the cost of remediation after a regulatory finding.
To pressure-test your structure before you commit, message us via t.me/oboluslaw.
Related at OBOLUS
- AML & Travel Rule for Digital Asset Businesses – the practice overview covering the full AML/CFT compliance regime for VASPs across major jurisdictions.
- Sanctions Screening in Crypto: A Legal Guide – how sanctions-screening obligations interact with VASP AML programs and Travel Rule data flows.
- EU MiCA vs. Cayman Islands: Where to License a Crypto Business – a comparative analysis of licensing profiles for founders choosing between EU CASP authorisation and an offshore structure.
FAQ
What does the Travel Rule require from a VASP?
Under FATF Recommendation 15, adopted into regimes including MiCA, the VARA framework, the MAS Payment Services Act and the FCA's AML registration, a VASP must collect, verify and transmit originator and beneficiary identifying information alongside every qualifying virtual-asset transfer. The originating VASP transmits the data; the beneficiary VASP receives, screens and retains it. The specific data fields and the threshold below which the rule may not apply vary by jurisdiction and must be confirmed against the operative local rules.
Who must act as MLRO for a crypto firm?
Every regulated VASP must appoint a named Money Laundering Reporting Officer (MLRO) – a natural person with sufficient seniority and relevant experience to own the AML/CFT program, receive internal suspicious-activity reports and file external reports with the relevant financial intelligence unit. Under MiCA, VARA and the FCA's regime, the MLRO must be disclosed to or approved by the regulator. For an early-stage firm, the MLRO may be a founder or senior hire, provided the governance structure managing any operational conflict is documented.
How do regulators audit crypto AML programs?
Regulators – including NCAs under MiCA, VARA in Dubai, MAS in Singapore and the FCA in the UK – typically assess AML programs through a combination of documentation review and operational testing. They examine the board-approved AML policy, the risk assessment, transaction-monitoring calibration records, staff-training logs, MLRO reports and, specifically for Travel Rule compliance, the written procedure governing counterparty VASP identification and data transmission. The common finding at early-stage firms is not the absence of a tool but the absence of a documented, tested and board-approved procedure behind it.
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 sit around 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 where recovery is required. To discuss your compliance program or any other matter, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML/CFT program design, Travel Rule implementation and supervisory readiness for early-stage VASPs across EU, UAE and common-law jurisdictions.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.