An early-stage crypto firm can close its seed round, sign its first institutional clients, and begin processing transactions – all before anyone has drafted a single AML/CFT policy. That gap is the moment regulators notice. A VASP (virtual asset service provider) without documented controls is not simply non-compliant; it is a business whose banking rails can be severed, whose licence application will be refused, and whose founders may face personal liability under the anti-money-laundering obligations that now apply in every significant digital-asset hub.
AML/CFT policy drafting for early-stage founders means translating the FATF Recommendations (the Financial Action Task Force's global standards, including Recommendation 15 on virtual assets) and the applicable local VASP regime into a documented compliance architecture that a regulator can audit and a bank can accept. The work spans a written AML/CFT policy, a KYC framework, a transaction-monitoring program, a Travel Rule procedure, and an appointed MLRO (Money Laundering Reporting Officer). This page maps each element, flags the cross-border complications, and explains what a practical engagement looks like.
Why Early-Stage Founders Face a Steeper AML Bar
Regulators treat the absence of an AML policy at launch as evidence of systemic failure, not an oversight – and they act accordingly. Under FATF Recommendation 15, VASPs are subject to the same baseline AML/CFT obligations as traditional financial institutions, including risk-based customer due diligence, suspicious transaction reporting, and record-keeping. National implementations vary, but the floor is consistent across the EU under MiCA and the accompanying Anti-Money Laundering Regulation, in Dubai under VARA's compliance rulebook, in Singapore under MAS's Payment Services Act framework, and in the United Kingdom under the FCA's Money Laundering Regulations registration regime.
The practical consequence for a founder is this: a bank completing its own due diligence on your account will ask for the policy before it opens the rails. A regulator reviewing a CASP authorisation application under MiCA will reject a submission that lacks a documented risk assessment. A custody partner onboarding your firm will want to see a named MLRO before the first integration call.
What makes early-stage firms particularly exposed is the tendency to treat compliance as a post-launch task. In our practice, the operators who encounter the most serious delays – refused accounts, stalled licence reviews, demands for remediation – are those who began building their product without legal input on the compliance architecture. The cost of retrofit is consistently higher than the cost of a properly scoped first-pass policy.
Operators we advise routinely discover that their user base spans three or four regulatory perimeters simultaneously, each with its own AML threshold, its own Travel Rule implementation, and its own MLRO qualification expectation. A single policy drafted to the lowest common denominator covers none of them adequately.
To map your AML/CFT obligations before you open banking or begin the licence process, contact OBOLUS at info@oboluslaw.com. The process above describes the standard path. Your facts – the entity structure, the user base geography, the transaction types – change the analysis materially. Map your options
What an AML/CFT Policy Must Cover
A compliant AML/CFT policy for a digital-asset business is not a generic financial-services template with "crypto" inserted. It addresses the specific risk profile of virtual-asset activity. The core document set typically includes six components, each of which has a distinct regulatory basis and a distinct operational footprint.
The first is the written AML/CFT policy itself: a statement of the firm's obligations under the applicable regime, a description of how those obligations are discharged, and an account of the governance structure around them. Under VARA's compliance rulebook and under the MiCA/AMLR framework, this document must be board-approved and reviewed at defined intervals.
The second component is a business-wide risk assessment (BWRA). The BWRA identifies the money-laundering and terrorist-financing risks specific to the firm's activities – the asset classes it handles, the geographies it serves, the delivery channels it uses, and its customer profile. FATF guidance on virtual assets is specific about the factors that elevate risk: anonymity-enhanced coins, peer-to-peer transfer volumes, high-risk jurisdictions, and unhosted wallet interactions.
Third is the KYC framework (Know Your Customer), which operationalises the customer due diligence requirement. For a VASP, that means tiered onboarding, enhanced due diligence triggers for high-risk customers, screening against sanctions lists (including OFAC, UN, EU), and PEP (politically exposed person) identification. The MAS Payment Services Act regime sets out specific KYC expectations; the FCA's MLR registration requires equivalent documentation.
Fourth, transaction monitoring: the regime and the logic by which the firm flags, reviews and reports suspicious activity. This is not simply a matter of setting thresholds in a monitoring tool; the policy must document the methodology, the escalation path to the MLRO, and the basis for filing suspicious activity reports (SARs) with the relevant financial intelligence unit.
Fifth, a Travel Rule procedure. The Travel Rule – the obligation to pass originator and beneficiary data with a virtual-asset transfer above the applicable threshold – now applies in substance across every leading hub. The procedure must identify the firm's chosen technical solution, the data fields collected and transmitted, the handling of unhosted wallet counterparties, and the steps taken when a counterparty VASP cannot be identified.
Sixth, the governance wrapper: the MLRO appointment, the training programme, the audit schedule, and the escalation matrix. Regulators inspect all six components. Gaps in any one of them can result in a licence condition, a remediation requirement, or an enforcement referral.
Travel Rule: What Does It Require Operationally?
The Travel Rule is the single most operationally demanding element of a VASP's AML program – and the one most frequently underestimated by early-stage teams. The rule requires that, when a VASP transfers a virtual asset above the applicable threshold, it collects, verifies and transmits specified originator and beneficiary data to the receiving VASP. The data set typically mirrors wire-transfer requirements: full name, account identifier, and, depending on the jurisdiction, address or identification number.
In practice, the obligation extends in both directions: the originating VASP sends data; the beneficiary VASP screens it and applies its own due-diligence obligations before crediting the funds. Where the counterparty is not an identifiable VASP – as happens frequently in the crypto environment – the procedure must document the enhanced-due-diligence steps taken before the transfer proceeds.
The technical solution matters. A firm relying on manual email exchange to satisfy the Travel Rule will not pass regulatory scrutiny in any tier-1 jurisdiction. The standard approach involves a FATF-aligned messaging protocol, and the firm's policy must explain how the chosen solution interacts with its transaction-monitoring system and its sanctions-screening workflow.
Cross-border complications arise immediately. A transfer from a Singapore-licensed entity to a VARA-licensed counterpart in Dubai involves two different Travel Rule implementations with potentially different data thresholds. A transfer to a wallet in a jurisdiction without a functioning Travel Rule regime requires a documented risk decision. In our practice, we have seen licence applications stalled specifically because the Travel Rule procedure did not address these edge cases.
The unhosted-wallet problem is the sharpest version of the issue. FATF guidance recommends enhanced due diligence for transfers to or from unhosted (self-custody) wallets, but the precise requirement varies by jurisdiction. MiCA's accompanying Transfer of Funds Regulation imposes specific rules on VASP-to-unhosted-wallet transfers that differ from the MAS approach and from the VARA rulebook position. A single Travel Rule procedure that ignores these differences will be non-compliant in at least one of those regimes.
How Does the MLRO Appointment Work for a VASP?
Every regulated VASP must appoint a qualified Money Laundering Reporting Officer (MLRO) – the person responsible for overseeing the firm's AML/CFT program, receiving internal suspicious-activity reports, deciding on external disclosure, and liaising with the relevant financial intelligence unit. The MLRO is also the primary point of contact for the regulator on compliance matters.
The qualification and fitness standard differs by jurisdiction. Under the FCA's MLR registration process, the MLRO must demonstrate adequate seniority and experience; the FCA has publicly indicated that a founder serving as their own MLRO on a thin compliance basis will not satisfy the test. Under VARA's regime, the compliance function must be appropriately resourced and, for larger licence categories, the MLRO must be a resident. Under MiCA and the national implementations across EU member states, the MLRO role connects to the broader senior-management accountability framework, with personal liability for systemic compliance failures.
For early-stage firms, the practical options are: appoint an internal MLRO with documented credentials and a clear mandate; appoint an outsourced MLRO on a managed-service basis; or, in some jurisdictions, contract a qualified compliance officer on a part-time basis while the business scales. Each option has a different regulatory risk profile and a different cost structure. The policy must document which approach is taken and how the MLRO function is resourced.
The MLRO appointment is also a banking requirement, not only a regulatory one. Banks conducting due diligence on a VASP account will review the MLRO's CV, the scope of their mandate, and the resources allocated to the function. In our practice, we have seen account applications rejected because the named MLRO was a junior employee with no documented compliance authority and no access to the SAR filing system.
Cross-Border AML Complications for Multi-Jurisdiction Builds
A digital-asset business operating across more than one jurisdiction does not get to pick the most permissive AML regime and apply it everywhere. Each jurisdiction where the firm has a regulated presence – or where it actively solicits customers – imposes its own AML obligations. The policy architecture must be structured accordingly.
The most common structural pattern we advise on is a group with a primary licensed entity – say, an EU CASP under MiCA – and one or more affiliated entities or branches in other hubs, such as a VARA-licensed entity in Dubai and a Payment Services Act-licensed entity in Singapore. Each entity requires its own AML/CFT policy that satisfies its local regulator. At the same time, the group needs a coherent global policy that sets the floor and ensures that the highest standard applied in any one jurisdiction does not conflict with the minimum required in another.
Banking is the pressure point. Banks providing corporate accounts to VASPs routinely require sight of the AML policy, the MLRO appointment letter, the results of the most recent internal audit, and the firm's sanctions-screening methodology. A group whose policies are inconsistent across entities will find that a bank in one jurisdiction rejects the account application on the basis of apparent policy gaps visible in the document pack provided by the entity in another jurisdiction.
The FATF mutual evaluation cycle adds a further layer. Jurisdictions that receive a poor FATF rating face correspondent banking restrictions that can make it materially harder for entities licensed there to maintain banking relationships with institutions in higher-rated jurisdictions. Founders who choose a licensing hub primarily for speed or cost sometimes discover – after the fact – that the banking environment is constrained by the jurisdiction's FATF standing. We map this risk as part of the pre-commitment analysis we do for clients building across multiple hubs.
A common assumption at this stage is that a single offshore licence covers global operations. It does not. If a VASP solicits clients in the EU, the MiCA regime applies to those activities regardless of where the entity is domiciled. If it serves Singapore residents, the MAS Payment Services Act applies. The jurisdictional analysis must follow the user, not just the entity.
If a prior application stalled or an account was closed because of AML policy gaps, a structured second read can identify the root cause and the remediation path. Write to info@oboluslaw.com. Map your options
Decision Matrix: Which Policy Architecture Fits Your Profile?
The right AML/CFT policy structure depends on the firm's current stage, its licence footprint, and its user-base geography. The following profiles cover the most common early-stage configurations we work through.
Profile A – Pre-licence, pre-banking, building the first policy. The firm has no current regulatory approval and is preparing its first licence application. The primary deliverable is a policy document set that satisfies the application requirements of the target regulator – most commonly an EU NCA under MiCA, VARA, or MAS. The timeline for producing a first-version policy set is typically a matter of weeks, not months, if the underlying business model is clear. The key risk is producing a document that looks complete but lacks a realistic BWRA or a workable MLRO structure, both of which are common first-pass deficiencies.
Profile B – Licensed in one jurisdiction, expanding to a second. The firm has a working policy for its primary licence. It is now seeking a second licence in a different hub – for example, moving from a MiCA CASP authorisation in an EU member state to a VARA licence in Dubai. The task is to adapt the core policy architecture to the second regime without creating inconsistencies that a regulator or a bank will flag in either jurisdiction. The cross-referencing and gap analysis is the technical work here; it typically adds time but is less extensive than a full first-pass build.
Profile C – Unlicensed but operationally active. The firm is processing transactions, has customers, and has no current AML policy. This is the highest-risk profile. The remediation work requires a policy build, a retrospective risk assessment of the existing customer base and transaction history, and – depending on jurisdiction – a decision about whether to make a voluntary disclosure or a suspicious-activity report in connection with any historical transactions that would have been caught by a functioning program. Allied counsel in the relevant jurisdiction must be engaged for the disclosure decision. The timeline is driven by the regulator's awareness of the situation and the volume of historical activity to review.
Profile D – Fund or DAO with token-distribution activity. The entity is not a traditional VASP but has engaged in token distributions that attract AML obligations in one or more jurisdictions. The policy build follows a different template, focused on participant due diligence, source-of-funds verification for contributors, and the intersection with securities-law registration obligations. The Travel Rule question turns on whether the entity operates a transfer function; many do not, but the analysis must be documented.
Common Mistakes in AML/CFT Policy Drafting for Crypto Firms
The most persistent mistakes in early-stage AML/CFT policy drafting share a common cause: the policy was written to look complete rather than to work. A document that ticks the formal headings but lacks operational specificity will not survive a regulatory inspection or a bank's due-diligence review.
The first and most frequent mistake is a risk assessment that is generic rather than business-specific. The BWRA must address the firm's actual risk profile – its asset classes, its customer geographies, its delivery channels. A BWRA copied from a traditional financial-institution template that does not mention unhosted wallets, DeFi protocol interactions, or high-risk jurisdictions is immediately identifiable as non-bespoke and will draw regulator scrutiny.
The second is an MLRO appointment that is nominal rather than substantive. Naming a founder or a technical co-founder as MLRO without providing documented authority, a reporting line to the board, access to transaction data, and a described SAR process is a compliance fiction. Regulators and banks see through it quickly.
The third is a Travel Rule section that treats the rule as a checkbox rather than an operational procedure. Stating that "the firm complies with the Travel Rule" without specifying the technical solution, the data fields, the unhosted-wallet procedure, and the steps for non-compliant counterparties is not a procedure; it is an aspiration.
Fourth, and particularly relevant for early-stage firms, is the absence of a training programme. Every AML regime requires that relevant staff are trained on the policy, and that training is documented. A regulator reviewing the policy will ask for training records. If none exist, the policy is treated as incomplete regardless of its written quality.
In a recent matter, a payments-focused VASP approaching its first VARA application submitted a policy set that covered all six formal components but contained a Travel Rule section that addressed only VASP-to-VASP transfers. The unhosted-wallet procedure was absent entirely. VARA's review identified the gap during the pre-authorisation stage; we were engaged to rebuild that section and to document the firm's risk decision on unhosted-wallet interactions. The revised submission was accepted. The delay was avoidable.
Self-Assessment Checklist Before Submitting a Policy Set
Before submitting an AML/CFT policy to a regulator or providing it to a banking partner, a founder should be able to answer yes to each of the following questions. A no answer in any row identifies a gap that should be addressed before submission.
- Does the AML/CFT policy name the specific regulatory regime under which the firm operates, and is it approved at board level?
- Is the business-wide risk assessment specific to the firm's asset classes, customer geographies, and delivery channels – and does it address virtual-asset-specific risk factors including unhosted wallets and high-risk jurisdictions?
- Does the KYC framework document tiered onboarding, enhanced due diligence triggers, sanctions screening, and PEP identification?
- Is the transaction-monitoring section operational – naming the tooling, the threshold logic, the escalation path, and the SAR filing process?
- Does the Travel Rule procedure name the technical solution, specify the data fields, address unhosted-wallet counterparties, and document the response to non-compliant counterparty VASPs?
- Is the MLRO appointment documented with a mandate letter, a reporting line, and access rights to transaction data and the SAR system?
- Is a training programme described, and are records kept of training delivered to relevant staff?
- Is the policy set consistent across all entities in the group, and does the highest-standard policy not create obligations that conflict with the minimum required in another entity's jurisdiction?
Related practices at OBOLUS cover the licensing and tax dimensions that sit alongside the compliance build. The links below connect the relevant sections.
Related at OBOLUS
- AML, Travel Rule and compliance for digital-asset businesses – the full practice overview across all regulatory hubs and VASP types
- AML/CFT policy drafting in El Salvador – jurisdiction-specific guidance on the Bitcoin Law framework and VASP obligations
- EU MiCA vs Kazakhstan AIFC – where to licence a crypto business – a comparative analysis of two leading licensing environments for digital-asset operators
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance architecture that sits around them. Digital assets are the whole of our practice. We map the licence, banking and AML stack across operating, custody and payment layers before a client commits to a structure – and our disputes team coordinates freezing relief and on-chain tracing across leading common-law forums when things go wrong. To discuss your compliance build, contact info@oboluslaw.com or message us at t.me/oboluslaw.
To pressure-test your AML/CFT policy set before submission, message us at t.me/oboluslaw or write to info@oboluslaw.com. Map your options
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule requires a VASP, when transferring virtual assets above the applicable threshold, to collect specified originator and beneficiary data and transmit it to the receiving VASP. The data set typically includes full legal name and account identifier, with additional fields required in some jurisdictions. The receiving VASP must screen the data before crediting the transfer. Unhosted-wallet counterparties require enhanced due diligence. The precise threshold and data requirements vary by jurisdiction and must be confirmed against the applicable local implementation of the FATF standard.
Who must act as MLRO for a crypto firm?
The MLRO (Money Laundering Reporting Officer) must be a sufficiently senior individual with documented authority, access to transaction data, and the ability to file suspicious activity reports with the relevant financial intelligence unit. Regulators including the FCA, VARA and the MAS each apply their own fitness and propriety standard. In most tier-1 regimes, the MLRO cannot be a purely nominal appointment; they require a mandate letter, a board reporting line, and adequate resources. For early-stage firms, outsourced or part-time MLRO arrangements are permissible in certain jurisdictions, subject to regulatory approval.
How do regulators audit crypto AML programs?
Regulators audit AML programs through a combination of document review, interviews with the MLRO and senior management, and transaction-level sampling. They typically request the written AML/CFT policy, the business-wide risk assessment, training records, SAR filing logs, and transaction-monitoring alert histories. Under MiCA and VARA's compliance rulebook, the firm must be able to demonstrate that the policy is operational – not merely documented. Gaps between the written policy and actual practice are treated more seriously than gaps in the written document alone, because they indicate systemic non-compliance rather than a drafting oversight.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML/CFT program architecture, VASP licensing compliance, and Travel Rule implementation across multi-jurisdiction 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.