For an established exchange, custodian or payments firm, an inadequate AML/CFT program (anti-money laundering and counter-financing of terrorism policy suite) is not a compliance gap – it is a direct path to supervisory enforcement, banking termination and licence suspension. Regulators across the major digital-asset hubs – VARA in Dubai, the FCA in the UK, ESMA and national competent authorities under MiCA, and MAS in Singapore – have made AML/CFT program quality the first line of examination. A policy document drafted for a startup, copied from a template or last reviewed before your current product suite went live is not adequate. This page sets out what a properly scoped AML/CFT policy revision looks like for an operator already in the market, what the process involves and where the cross-border pressure points lie.
Why Established Operators Face a Different AML/CFT Problem Than Startups
An established operator's AML/CFT exposure is structurally different from a new applicant's. A startup drafts its program in the abstract, before real transaction flows, real customer segments and real correspondent-banking relationships exist. An established operator must reconcile its written program with what it actually does – and regulators inspect the gap between the two with increasing precision.
In our practice, the most common source of supervisory criticism for established operators is not a missing document but a document that no longer matches the business. A firm that added fiat on-ramps, expanded into derivatives or onboarded institutional counterparties after its initial AML/CFT filing will often hold a policy written for an entirely different risk profile. Under FATF Recommendation 15 – the international standard requiring states to apply AML/CFT measures to virtual asset service providers – the risk assessment and the policy must reflect the current business model, not the business that was described at the time of authorisation.
The secondary pressure is the Travel Rule. The obligation to pass originator and beneficiary data with a virtual-asset transfer has been implemented unevenly across jurisdictions. An operator moving funds between a MiCA-regime entity and a counterpart in a jurisdiction with a different de-minimis threshold faces a genuine compliance conflict. Resolving that conflict requires policy language, not just technology. We have seen firms invest heavily in Travel Rule software while leaving the underlying policy silent on how conflicting threshold obligations are to be handled – and then face examiner questions they cannot answer.
What the Regulated Basis Requires From a Policy Suite
Every major digital-asset regime requires a documented, risk-based AML/CFT program as a condition of authorisation and as an ongoing supervisory expectation. The specific frameworks differ, but the structural requirements converge around four pillars: a business-wide risk assessment, documented policies and procedures, a designated Money Laundering Reporting Officer, and an independent audit or review function.
Under MiCA, a CASP (crypto-asset service provider) must maintain AML/CFT arrangements that satisfy the relevant provisions of the EU's applicable AML directives as implemented by the member state of authorisation. In practice, national competent authorities – including those in Malta and Lithuania, both active MiCA transition jurisdictions – apply their own supervisory expectations on top of the minimum regime requirements. A policy drafted for EU passporting must therefore address both the ESMA-level standard and the NCA-specific overlay in the home member state.
VARA in Dubai operates an activity-based licensing regime. Each activity authorisation – advisory, broker-dealer, custody, exchange, lending, management, transfer and settlement – carries its own rulebook, and the AML obligations under those rulebooks are informed by the UAE's national AML legislation and the CBUAE guidelines. A multi-activity VARA licensee cannot hold a single undifferentiated policy; it needs activity-specific risk assessments and procedures mapped to each authorised activity.
In Singapore, MAS applies its AML/CFT notices to holders of Digital Payment Token licences under the Payment Services Act. The MAS notices are prescriptive and regularly updated. An operator that has held a DPT licence for more than a year and has not reviewed its policy against the most recent MAS notice cycle is almost certainly out of alignment.
CTA #1 — The standard path above describes the minimum. Your entity structure, your customer mix and the jurisdictions you serve from will change the analysis materially. Map your options with OBOLUS.
What Does an AML/CFT Policy Drafting Engagement Actually Involve?
A policy drafting engagement for an established operator is not a document-production exercise. It is a structured legal assessment that produces documentation as its output. The engagement runs in four sequential stages.
The first stage is intake and scoping. We review the current policy suite, the authorisation documents, any prior supervisory correspondence and the operator's current product and service map. This stage identifies the delta between the existing documentation and the current business reality. It also surfaces any cross-border structural issues – for example, where one group entity holds a MiCA CASP authorisation and another holds a VARA licence, and the two policy suites must be consistent without being identical.
The second stage is risk assessment revision. A business-wide risk assessment (BWRA) is the foundation document for any AML/CFT program. If the operator's BWRA predates significant product changes, it must be revised before the policy can be updated. We conduct the BWRA revision as a legal work product, drawing on the operator's own transaction data, customer segmentation and jurisdictional footprint. The BWRA drives the risk-scoring logic for customer due diligence, the enhanced due diligence triggers and the transaction monitoring alert thresholds.
The third stage is policy drafting and procedure writing. The core deliverables are the AML/CFT policy itself, a KYC framework (customer identification and verification procedures), enhanced due diligence procedures for higher-risk customers and counterparties, Travel Rule procedures specifying how originator and beneficiary data is gathered, transmitted and verified, a transaction monitoring policy specifying alert typologies, escalation paths and SAR/STR filing obligations, and a sanctions screening policy. Each document is jurisdiction-keyed: where the operator is regulated in more than one jurisdiction, we produce a master policy and jurisdiction-specific annexes.
The fourth stage is implementation support. Policy documents that sit on a server and are not embedded in operational workflow do not satisfy regulators. We provide implementation guidance – reviewing the gaps between the written policy and current operational practice and advising on the remediation steps required to close them. For firms with an in-house compliance function, this stage typically involves working sessions with the MLRO and the compliance team.
The Cross-Border Pressure Points Every Multi-Jurisdiction Operator Faces
Operating an exchange or custody business across multiple jurisdictions does not mean holding multiple copies of the same policy. Each regulatory regime imposes its own requirements, and the interaction between them generates obligations that a single-jurisdiction policy cannot address.
The Travel Rule is the clearest example. The FATF standard requires VASPs to obtain and transmit originator and beneficiary information for virtual-asset transfers above a defined threshold. But each implementing jurisdiction sets its own threshold, its own treatment of transfers to or from unhosted wallets, and its own interoperability standards. An operator running a MiCA-entity in the EU, a VASP entity in a common-law offshore jurisdiction and a VARA entity in Dubai simultaneously holds three different threshold obligations. The policy must specify how each entity handles a transfer where the counterpart is in a jurisdiction with a different rule – including the option to refuse or delay the transfer pending further verification.
Sanctions screening is a second cross-border pressure point. An operator with US-person exposure – even indirectly, through USD settlement rails – holds OFAC compliance obligations regardless of where it is incorporated. A firm regulated under MiCA with no US nexus still faces EU sanctions obligations enforced by ESMA and the relevant NCA. Where the two sanctions lists diverge, the policy must specify which list governs and in what circumstances additional screening applies.
In our cross-border practice, we regularly advise operators holding allied counsel in the relevant jurisdiction to review jurisdiction-specific policy annexes before submission. A policy that passes legal review in Malta may require additional specificity on customer risk-scoring to satisfy the expectations of a GCC regulator. The cross-border review step is not optional for operators seeking to scale.
What Are the Most Common AML/CFT Policy Mistakes for Established Operators?
The most common mistake is temporal: the policy reflects the business at the time of initial authorisation rather than the business as it operates today. We have seen policies that still describe a three-person team managing compliance for a firm with two hundred employees and a multi-currency fiat stack. Regulators read policies in light of what the business actually does, and the mismatch is immediately visible on examination.
The second common mistake is generic customer risk-scoring. A policy that assigns all customers to one of three undifferentiated risk tiers – low, medium, high – does not satisfy the risk-based approach required by FATF and implemented by every major digital-asset regulator. Effective customer risk-scoring must be anchored to the operator's actual customer segments: retail spot traders carry different typologies from institutional borrowers or OTC counterparties, and the policy must reflect that differentiation.
The third mistake is a Travel Rule gap. The Travel Rule obligation under FATF Recommendation 16 applies to originator and beneficiary data on qualifying transfers, and most major jurisdictions have now implemented some version of it. Yet many established operators hold policies that describe the obligation in a single paragraph, without specifying the data fields required, the verification standard, the procedure for transfers where the counterpart VASP is not Travel Rule-enabled, or the escalation path for conflicting threshold obligations. That level of policy detail is now a supervisory expectation, not an aspiration.
A fourth, less obvious mistake is the failure to update the policy after a significant transaction-monitoring tool change. When an operator migrates to a new blockchain analytics platform or changes its alert-threshold configuration, the written policy must be updated to reflect the new tool's logic. A policy that references superseded thresholds or a deprecated tool creates an audit trail that examiners use as evidence of a control gap.
In a recent matter, a payments firm regulated across two EU jurisdictions had migrated to a new transaction monitoring platform eighteen months before a supervisory examination. The written policy still described the logic of the legacy system. The examiner cited the discrepancy as evidence of inadequate governance. We were engaged to rebuild the policy suite and document the migration, including a retrospective risk assessment of the gap period. The matter resolved without formal sanction.
Decision Matrix: Which Operator Profile Needs Which Approach?
Not every established operator faces the same AML/CFT policy problem. The engagement scope and priority depend on the operator's profile.
An exchange holding a single MiCA CASP authorisation with a retail-only customer base and no fiat rails needs, primarily, a BWRA refresh and updated KYC risk-scoring aligned to the current NCA supervisory expectations. The Travel Rule annex must reflect the current EU implementation and address unhosted wallet transfers. Timeline: typically a matter of weeks for a firm with clean documentation and a responsive compliance team.
A multi-activity VARA licensee – for example, an operator holding both an exchange and custody activity licence in Dubai – needs activity-specific AML procedures mapped to each VARA rulebook, a consolidated BWRA that addresses the interaction between activities, and a Travel Rule procedure consistent with the UAE's current implementation posture. The cross-border dimension becomes acute if the same group entity also holds a MiCA authorisation, because the two regimes' expectations on enhanced due diligence for high-risk customers differ in ways the policy must address explicitly.
A Singapore DPT licensee under MAS that has recently expanded its customer base to include corporate clients from higher-risk jurisdictions needs an enhanced due diligence framework that goes substantially beyond the standard KYC procedure. MAS is known in our practice to examine EDD procedures closely for institutional and corporate onboarding. A policy that relies on a generic "higher-risk customer" tier without specifying the EDD steps for each sub-category of higher-risk customer will not hold under examination.
An operator holding licences in multiple jurisdictions – a not-uncommon profile for firms that licensed early in BVI or Cayman under those jurisdictions' VASP regimes and then sought an EU or GCC authorisation – needs a master policy that can anchor jurisdiction-specific annexes without contradiction. The structural challenge is that the Cayman VASP Act and MiCA impose different requirements on suspicious transaction reporting timelines and on the governance of the MLRO function. The policy must address both without creating a compliance conflict the firm cannot resolve operationally.
A Common Assumption That Costs Established Operators
A common assumption among operators who expanded internationally on the strength of an early offshore registration is that the existing policy, once filed with one regulator, satisfies the rest. It does not. A registration-level AML program acceptable to the BVI FSC under the VASP Act 2022 is not the same document that will satisfy the FCA's AML examination in the UK or ESMA's expectations under MiCA. The supervisory standard in the leading financial centres has moved materially in the past three years. Firms that have not revised their policy suite since initial authorisation are typically behind the current supervisory expectation by at least two revision cycles.
A second assumption is that AML/CFT policy is a compliance function's internal matter and does not require legal counsel. In our practice, the distinction matters most at two points: when the policy is examined by a regulator with legal authority to impose sanctions for deficiencies, and when the policy must be coordinated across multiple jurisdictions whose legal requirements conflict. At both points, the policy is a legal document, and it needs to be drafted and reviewed as one.
CTA #2 — If a prior supervisory examination identified AML/CFT policy weaknesses, or if your policy has not been updated since your last licence renewal, a structured review can identify the gap and the remediation path. Contact OBOLUS to discuss a scoped assessment.
Self-Assessment: Is Your AML/CFT Policy Suite Current?
The following checklist reflects the questions a regulator will ask. If the answer to any of them is "no" or "unsure," the policy suite needs attention.
- Does the business-wide risk assessment reflect the current product and service map, including all fiat and crypto rails added after the last review?
- Does the customer risk-scoring methodology distinguish between your actual customer segments – retail, professional, institutional, corporate – with specific indicators and EDD triggers for each?
- Does the Travel Rule procedure specify the data fields required, the verification standard, the procedure for non-Travel-Rule-enabled counterpart VASPs and the handling of conflicting jurisdictional thresholds?
- Does the sanctions screening policy address OFAC obligations where any USD-denominated transaction flows exist, and EU sanctions obligations separately?
- Does the transaction monitoring policy reflect the current tool's alert logic, and has it been updated after any tool migration or threshold reconfiguration?
- Is the MLRO's authority, escalation path and SAR/STR reporting obligation documented in the policy, and is that documentation consistent with the governance requirements of every jurisdiction in which the operator holds authorisation?
- For multi-entity groups: is there a master policy with jurisdiction-specific annexes, and has each annex been reviewed by counsel familiar with that jurisdiction's current supervisory expectations?
Related at OBOLUS
- AML/CFT Compliance Practice for Digital Asset Businesses – our full compliance and Travel Rule practice overview
- VASP Business Risk Assessment for Established Operators – scoped business-wide risk assessment service
- AML/CFT Policy Drafting – Legal Counsel for Digital Asset Firms – counsel-led policy drafting for firms at any stage
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule – derived from FATF Recommendation 16 as applied to virtual assets – requires a VASP to obtain originator and beneficiary information for qualifying transfers and to transmit that data to the receiving VASP. The specific data fields, the de-minimis threshold below which the obligation does not apply and the treatment of transfers to unhosted wallets vary by jurisdiction. Under MiCA and its implementing measures, the obligation applies to all transfer amounts for transfers within the EU/EEA. Most other major regimes apply a threshold, but that threshold differs across implementations. A compliant policy must specify how each of these variables is handled for every jurisdiction in which the operator is active.
Who must act as MLRO for a crypto firm?
Every authorised digital-asset firm must designate a Money Laundering Reporting Officer (MLRO). The MLRO holds personal responsibility for the firm's AML/CFT program and for submitting suspicious transaction reports to the relevant financial intelligence unit. Most major regimes – including those under MiCA, VARA and the MAS Payment Services Act – require the MLRO to be a named individual approved by, or at minimum notified to, the regulator. The MLRO's qualifications, seniority and authority must be documented in the AML/CFT policy. In a multi-entity group, each regulated entity must hold its own MLRO appointment; a group-level MLRO designation is not a substitute unless the relevant regime expressly permits it.
How do regulators audit crypto AML programs?
Regulators in the major digital-asset hubs audit AML/CFT programs through a combination of document review, transactional sampling and direct examination of compliance personnel. The document review focuses on the written policy suite – whether the BWRA reflects the current business, whether the KYC and EDD procedures are specific enough to be operational and whether the Travel Rule and sanctions procedures are complete. Transactional sampling tests whether the actual transaction monitoring alerts match the policy's stated logic. Personnel examination – typically of the MLRO and senior compliance staff – tests whether the people responsible for the program understand it. A policy that looks adequate on paper but cannot be explained by the compliance team will not pass examination.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on AML/CFT program design, licensing and compliance across more than 70 jurisdictions, on disputes and on-chain asset recovery across more than 25 forums, and on the tax, banking and structural questions that sit around them. Digital assets are the entirety of our practice. We map the compliance, licence and banking stack across operating, custody and payment layers before you commit – and we act only for businesses. To discuss your AML/CFT program, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML/CFT program design and cross-border compliance obligations for digital-asset service providers.
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.