Early-stage crypto founders face an immediate compliance cliff. The moment a business touches customer funds, executes transfers or provides exchange services, most major regulatory regimes require a designated Money Laundering Reporting Officer (MLRO) – the individual personally accountable for the firm's anti-money laundering posture – and a functioning compliance program that satisfies AML (anti-money laundering) obligations. Getting this wrong does not mean a quiet regulator letter. It means frozen banking rails, refused licence applications and, in the worst cases, personal liability for the officer who signed off on a broken program.
This page sets out what the MLRO and compliance officer function actually involves for a digital-asset startup, how the obligation arises under the leading regimes, what a defensible program looks like in practice, and where cross-border structures create gaps that enforcement teams routinely exploit.
Why the MLRO function matters now – and cannot be deferred
Most founders treat compliance as a post-licensing task. Regulators treat it as a pre-licensing gate. Under MiCA – the EU's Markets in Crypto-Assets Regulation, supervised by ESMA and national competent authorities – a CASP authorisation application requires demonstrated governance arrangements, which include a named responsible compliance officer before the licence is granted. The same logic applies under VARA in Dubai, where the Virtual Assets Regulatory Authority's rulebooks require applicants to identify the individual responsible for AML and compliance oversight as part of the activity-based licence application. The FCA's registration process under the Money Laundering Regulations in the UK, MAS licensing under Singapore's Payment Services Act, and the SFC's VATP regime in Hong Kong all share this structural expectation.
Founders sometimes read this as a box-ticking exercise – appoint a title, file the name, move on. In our practice, that misreading is one of the most reliable predictors of a stalled application. Regulators assess whether the designated person has actual authority, a real budget and an independent reporting line to the board. A compliance function that exists only on an organogram does not pass scrutiny.
The stakes beyond licensing are equally concrete. Banking correspondent networks – the layer that converts crypto revenue into fiat and keeps settlement accounts open – conduct their own AML due diligence on prospective crypto clients. A startup without a credentialed MLRO and a written program is routinely declined at that stage, regardless of whether a licence has been issued.
Operating without the right compliance architecture risks enforcement, frozen rails and lost banking. The loss is not theoretical. We have seen early-stage operators lose their primary banking relationship within weeks of launch because their onboarding documentation referenced a compliance officer who had no formal terms of reference, no documented authority and no budget line.
What does an MLRO actually do in a crypto firm?
The MLRO's core function is to receive, evaluate and – where required – report suspicious activity. In practice, the role is broader. The MLRO owns the firm's AML/CFT (anti-money laundering and counter-financing of terrorism) program end to end: the risk assessment, the customer due diligence procedures, the transaction monitoring logic, the training calendar, the record-keeping regime and the regulatory filing obligations. In a digital-asset business, that program must also address the Travel Rule – the obligation, derived from FATF Recommendation 15, requiring a VASP (virtual asset service provider) to pass originator and beneficiary data alongside a transfer above the applicable threshold.
The compliance officer function, which in many early-stage firms is held by the same individual, extends to the broader regulatory perimeter: licence condition monitoring, sanctions screening, product-level risk assessments and engagement with supervisors during examinations. Together, these roles form the architecture that regulators examine when they ask whether a firm is "fit to operate."
The practical demands on a founder-stage MLRO are significant. Transaction monitoring must be calibrated to the firm's specific product and user base – a rule set designed for a retail exchange does not translate directly to a B2B stablecoin settlement desk. KYC frameworks (know-your-customer procedures) must be tiered to risk: enhanced due diligence for high-risk customers, simplified procedures where the regime permits, and a documented rationale for each classification. None of this is installed out of a box. It requires legal judgment about what the applicable regime actually demands and operational judgment about what the business can sustain at its current headcount.
How does the MLRO obligation arise across different regimes?
The obligation to have a designated AML officer arises differently depending on whether the business is authorised, registered or merely operating in a jurisdiction. Understanding which trigger applies is the first task for any cross-border structure.
Under MiCA and the CASP authorisation regime, the obligation is explicit in the governance requirements that accompany the application. The applicable CASP provisions require a management body that includes individuals with demonstrable knowledge of AML/CFT, and the compliance function must report directly to that body. National competent authorities – the Bank of Lithuania, the MFSA in Malta, BaFin in Germany and their counterparts – apply these expectations consistently across the EU, though their appetite for detail in the application varies.
Under the VARA regime in Dubai, each activity licence carries its own compliance obligations in the relevant VARA rulebook. The rulebook for exchange services, for custody, and for broker-dealer activity each specify the governance expectations for the compliance function. An operator holding multiple VARA activity licences must ensure the program covers all of them – a common structural gap we address early in engagements.
Under the FCA's MLR registration and the MAS Payment Services Act licensing, the requirement is framed around the nominated officer concept – the individual who receives internal suspicion reports and makes the external report to the financial intelligence unit where a threshold is met. The mechanics differ, but the substance is the same: a real person, real authority, real program.
The cross-border complication arises when the entity is incorporated in one jurisdiction, licensed in a second and serving users in a third. Each layer may trigger its own AML obligation. A BVI holding company with a VARA-licensed Dubai operating entity serving EU retail users faces at minimum the VARA regime for Dubai operations and the question of whether the EU user base triggers MiCA obligations independently. We map that exposure before it becomes an enforcement conversation.
For a scoped assessment of your compliance structure, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity, the user base, the banking – change the analysis. A brief conversation before you file avoids the structural rework that comes after.
What does a defensible AML program look like at the early stage?
A defensible AML program for an early-stage digital-asset business has six documented components, each of which a regulator or correspondent bank will ask to see in some form.
First, a firm-wide risk assessment – a written analysis of the money-laundering and terrorist-financing risks specific to the business model, the product, the customer base and the geographies involved. This is not a generic template. It must reflect the actual risk profile of the firm: a peer-to-peer exchange carries different risks than a B2B custody service.
Second, a KYC framework that sets out customer identification and verification procedures, the risk-tiering logic, the enhanced due diligence triggers and the documentation standards. The framework must align with the applicable regime: the VARA rulebook expectations in Dubai differ in emphasis from the FCA's MLR requirements in the UK.
Third, transaction monitoring – the system and the rules. At the early stage, full platform monitoring may not be technically implemented, but the firm must have a written policy describing the approach, the red-flag indicators, the review workflow and the escalation path to the MLRO. Regulators understand that startups are building systems; they do not accept the absence of a policy.
Fourth, the Travel Rule compliance procedure. Under the FATF-aligned regimes, a VASP must collect and transmit originator and beneficiary information on transfers above the applicable threshold. The procedure must identify which Travel Rule solution the firm uses, how it handles transfers to or from non-compliant VASPs (the "sunrise problem"), and what happens when required data is missing.
Fifth, a sanctions screening program covering at minimum OFAC, the EU consolidated list and the UN list. For a business operating in the UAE or the UK, additional screening lists apply. The program must describe the screening frequency, the false-positive review process and the escalation path.
Sixth, a training and awareness calendar. The MLRO must ensure that staff who interact with customers or transactions understand the red-flag indicators relevant to their role. Training records must be kept, because regulators ask for them during examinations.
In our cross-border practice, we regularly advise founders who have built several of these components in isolation. The common gap is that the pieces do not form a coherent program – the risk assessment does not map to the KYC tiering, the transaction monitoring rules were not calibrated against the risk assessment, and the Travel Rule procedure was drafted by a technical team without reference to what the applicable regime actually requires. The result is a program that fails on cross-referencing inspection, even though individual documents look credible in isolation.
What are the most common AML compliance mistakes at the early stage?
The most consequential mistake is treating the MLRO as a compliance checkbox rather than a governance function. Regulators – and, increasingly, correspondent banks – test this directly. They ask whether the MLRO has a written terms of reference, a defined reporting line, a budget and documented independence from the revenue function. Where those elements are missing, the appointment is treated as nominal and the program is treated as deficient.
A second common error is copying AML documentation from a different industry or jurisdiction without adaptation. A policy drafted to satisfy a fintech registration in one EU member state may miss the specific expectations of a VARA rulebook or a MAS PSA licence. The regime names may overlap; the substance diverges in ways that matter during examinations.
The Travel Rule generates its own category of mistakes. Many founders understand the obligation in principle but implement it only for outbound transfers to other VASPs. The obligation is symmetric: it applies to inbound transfers as well, and the procedure must address what to do when the originating VASP does not transmit the required data. Regulators examine this specific gap.
A further error is the failure to update the risk assessment after a product change. A firm that launches with a simple exchange product and later adds staking, lending or a white-label service for third parties has materially changed its risk profile. The AML program must reflect the current business, not the business at incorporation.
Finally – and this affects cross-border structures disproportionately – founders sometimes assume that a single licence or registration covers all the jurisdictions in which they operate. A common assumption is that an offshore registration is sufficient to serve clients globally without triggering compliance obligations in the client's home jurisdiction. That assumption is incorrect. The applicable AML regime follows the activity, not just the entity's place of incorporation. Serving EU retail users from a non-EU entity may independently trigger MiCA compliance obligations. Serving US persons may trigger FinCEN requirements. Each obligation needs to be assessed on its own terms.
How does a cross-border structure affect the MLRO and compliance function?
Cross-border digital-asset businesses face a structural compliance challenge that single-jurisdiction operators do not: the obligation to maintain an AML program that is coherent across multiple regimes simultaneously. This is not a matter of picking the most demanding standard and applying it everywhere. Different regimes have different formal requirements – the MLRO title, the nominated officer concept, the CASP compliance officer role – and each requires its own documented structure.
In a structure with a UAE holding entity, a VARA-licensed operating subsidiary and distribution to EU users, the compliance architecture must address at minimum: the VARA rulebook obligations for the licensed entity, the MiCA compliance expectations for the EU user-facing activities, and the AML requirements of any jurisdiction in which the firm holds a banking relationship. These do not naturally align.
Banking is often the forcing function. A correspondent bank onboarding a crypto client will conduct its own AML review. That review typically requires a group-level AML policy, the MLRO's curriculum vitae and terms of reference, the most recent risk assessment, evidence of transaction monitoring implementation and the Travel Rule compliance procedure. Where the structure spans multiple jurisdictions, the bank will ask which regime governs the group program and who is responsible at the group level. If the answer is unclear, the account application stalls.
We work with allied counsel in the relevant jurisdiction to ensure that local compliance obligations are met where they arise, while the group-level program maintains internal coherence. The MLRO function at the group level and the compliance officer function at the subsidiary level must have clearly defined responsibilities and a documented escalation path between them. In our cross-border practice, we have seen structures where this division was undefined, resulting in two teams each assuming the other had filed the required regulatory reports.
To map the licence, banking and compliance stack for your build, write to OBOLUS 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.
Decision matrix: which compliance profile fits your build?
Early-stage founders fall into broadly distinct profiles when it comes to the MLRO and compliance officer function. The right approach differs materially depending on the business model, the licence category and the jurisdictional footprint.
Profile A – single jurisdiction, single activity. A startup launching a crypto exchange under one licence, serving one customer jurisdiction, with a headcount under ten. The appropriate structure is a single designated MLRO with a lean, written AML program built to the specific requirements of the applicable regime. Travel Rule compliance can be implemented through a standard solution. The risk assessment is relatively bounded. The timeline to a defensible program, starting from scratch, is typically measured in weeks rather than months. The key risk at this stage is the temptation to over-engineer documentation for a future business that does not yet exist, leaving current operations unaddressed.
Profile B – multi-licence, single jurisdiction. A VARA operator holding exchange and custody activity licences, for example. Each activity licence carries its own rulebook obligations. The compliance program must address both, and the MLRO must have a terms of reference that explicitly covers both regulated activities. The risk assessment must address the custody-specific risks (key management, settlement exposure) separately from the exchange risks. The complexity rises, but the framework is contained within one regulatory perimeter.
Profile C – multi-jurisdiction, multi-activity. A group with a CASP-authorised EU entity, a VARA-licensed UAE subsidiary and a Singapore DPT licence under the Payment Services Act. Three compliance programs, three regulators, three sets of Travel Rule obligations with different applicable thresholds. The MLRO function at group level must coordinate with local compliance officers in each subsidiary. The group-level risk assessment must aggregate the subsidiary-level assessments. Banking documentation must present a coherent picture of a program that functions across all three perimeters. This profile requires the most investment in compliance architecture, but that investment is directly correlated with the firm's ability to retain banking relationships and pass regulatory examinations across all three jurisdictions.
In all three profiles, the cost of addressing compliance after a regulatory examination or a banking refusal is materially higher than the cost of building it correctly at the outset. We map that calculus for founders before they commit to a structure.
From practice: a compliance restructuring ahead of a VARA examination
In a recent matter, an early-stage exchange operator holding a preliminary VARA licence engaged OBOLUS after receiving notice of an upcoming supervisory examination. The firm had a named compliance officer but no written terms of reference, no documented risk assessment and a Travel Rule procedure that covered outbound transfers only. We conducted a gap analysis against the applicable VARA rulebook, drafted the missing documentation, calibrated the transaction monitoring rules to the firm's actual user profile and produced a group-level AML policy that addressed the firm's EU user-facing activities in parallel. The examination proceeded without a formal deficiency finding. The firm's banking relationship, which had been under review pending the examination outcome, was subsequently confirmed. The entire process ran over approximately six weeks in the period leading up to the examination.
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – the full practice overview covering the regulatory perimeter and our service model.
- Sanctions screening for crypto firms – how to build a defensible screening program across OFAC, EU and UN lists.
- Digital-asset licensing in Germany under BaFin – what EU operators need to know about the German CASP authorisation process.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule – derived from FATF Recommendation 15 and implemented across the major VASP regimes – requires a virtual asset service provider to collect and transmit originator and beneficiary information alongside a transfer that meets or exceeds the applicable threshold. The required data typically includes the sender's name, account identifier and, in many regimes, address or identification number, as well as the corresponding beneficiary information. The obligation applies to both the sending and receiving VASP. Where the counterpart VASP does not transmit required data, the receiving firm must have a documented procedure for how it responds – whether it suspends the transfer, requests the information or applies enhanced due diligence. The specific threshold varies by jurisdiction and should be confirmed against the current regime applicable to your operating entity.
Who must act as MLRO for a crypto firm?
Most regulated VASP regimes require the MLRO to be an individual – not a corporate entity or a shared service – with genuine authority within the firm, an independent reporting line to the board and documented responsibility for the AML program. The person does not need to be legally qualified, but must have demonstrable knowledge of AML/CFT obligations relevant to the business and the applicable regime. In practice, regulators assess seniority, independence from the sales function and access to resources. For a startup with limited headcount, the role can be held by a founder, a senior operations officer or an experienced external compliance professional, provided the formal requirements of the applicable regime are met. Some regimes also require prior regulatory approval or notification of the appointment.
How do regulators audit crypto AML programs?
Regulatory examinations of AML programs typically follow a document-first, then interview-based methodology. The examiner will request the firm's risk assessment, AML policies and procedures, the MLRO's terms of reference, training records, a sample of customer due diligence files, transaction monitoring alerts and dispositions, suspicious activity report logs and Travel Rule compliance documentation. They then test whether the documented procedures match actual practice – interviewing staff, reviewing system configurations and sampling real cases. Common deficiency findings include risk assessments that do not reflect the current business, transaction monitoring rules that have not been calibrated to the actual customer base, and Travel Rule procedures that address outbound transfers only. The examination timeline and the consequences of a deficiency finding vary by regulator.
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 entirety of our practice – we act only for businesses, not for individuals, and we do not represent both sides of a transaction. To discuss your MLRO and compliance officer function needs, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML program design, MLRO function structuring and Travel Rule compliance across multi-jurisdictional digital-asset businesses.
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.