AML/CFT Policy Drafting: The Structuring Angle

A digital-asset business that reaches compliance last reaches it wrong. When a VASP (virtual asset service provider) builds its AML/CFT program as a post-licensing afterthought, the structural decisions – entity jurisdiction, wallet custody model, onboarding flow – have already been locked in. Those decisions determine what the Travel Rule (the obligation to pass originator and beneficiary data with each transfer) requires, which national regulator supervises the firm, and how transaction monitoring sits across the technical stack. Fix the policy later, and you are drafting around a structure rather than for one.

The structuring angle is this: an AML/CFT policy is a legal document whose correct form is dictated by the corporate and operational architecture of the firm, not the reverse. A policy drafted in isolation from structure will pass a desk review and fail a supervisory inspection. With VASP supervision tightening across the major licensing hubs – from ESMA's MiCA oversight in the EU to VARA in Dubai to the MAS Payment Services Act regime in Singapore – regulators are moving well past "does the policy exist" to "does the policy reflect the actual business." This analysis examines the fault lines, contrasts the regulatory positions across key jurisdictions, and maps the practical drafting decisions that follow from structure rather than precede it.

The sections below move from the regulated perimeter through to a cross-border decision matrix and a set of objection handlers for common assumptions that in our practice consistently produce deficient programs.

Why Business Structure Determines AML/CFT Obligations

The legal regime that applies to a firm's AML/CFT program is not chosen by the compliance officer – it is determined by where the firm is licensed, where it serves customers, where it settles transactions, and what activity it performs. Each of those decisions is a structural one. An exchange licensed under the VARA regime in Dubai but onboarding EU retail clients will face dual supervisory expectations – VARA's own AML rulebook and, depending on the distribution analysis, the requirements that flow from MiCA and the underlying FATF Recommendation 15 framework. A policy written only for one jurisdiction will be deficient from the moment the second relationship is established.

In our cross-border practice, the most common structural mismatch we encounter is the custody layer. A parent entity holds the trading licence; a subsidiary or affiliated vehicle holds client assets. The policy covers the licensed entity. The custody vehicle – which actually touches client funds and triggers the originator/beneficiary data obligations under the Travel Rule – has no standalone policy at all. From the regulator's perspective, this is not a drafting gap; it is an unregistered VASP operating beside a registered one.

The second mismatch is geographic. A firm domiciled in a light-touch offshore jurisdiction – the Cayman Islands, the BVI, or a pre-MiCA EU member state – services customers in jurisdictions where local licensing is required for precisely the activity performed. The offshore policy will satisfy the home regulator. It will not satisfy the FCA, MAS, or the SFC when those regulators examine the inbound flow. The firm is, in effect, operating two compliance programs: the one that exists on paper and the one the host regulator expects.

The FATF Baseline: What Every Policy Must Address

FATF Recommendation 15 sets the floor for every jurisdiction that has implemented the standard – which now covers virtually every significant financial centre – and it defines the minimum substantive content a VASP AML/CFT policy must address, regardless of the licensing jurisdiction's own rulebook format.

That floor includes: a business-wide risk assessment, a customer risk-rating methodology, a KYC framework (know-your-customer procedures covering identity verification, beneficial ownership and source of funds/wealth for higher-risk relationships), ongoing transaction monitoring, suspicious activity reporting obligations, record-keeping, staff training, and an independent audit function. None of these is optional. The degree of elaboration required for each element scales with the risk profile of the business – but the element must be present.

Where the FATF standard intersects with structure most sharply is in the business-wide risk assessment. The assessment must reflect the actual product, customer and geographic risk that the firm carries. An exchange that lists privacy-enhancing tokens, accepts unhosted-wallet deposits from self-custody users, or services high-volume institutional counterparties in markets with weak AML supervision carries a materially different risk profile from a single-fiat on-ramp. The policy – and the controls architecture behind it – must be calibrated to the assessed risk, not to a generic template. Regulators in the leading hubs increasingly expect to see the risk assessment and the policy controls in direct, traceable correspondence.

To discuss your firm's risk profile and the policy architecture it requires, 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.

Is the Travel Rule the Most Structurally Sensitive AML Obligation a VASP Faces?

The Travel Rule is the obligation most directly shaped by the firm's technical and corporate architecture, and it is the obligation most frequently under-drafted in policies we review. The rule requires that a VASP transmitting virtual assets above the applicable threshold pass originator and beneficiary information to the receiving VASP before or simultaneously with the transfer. The data elements required mirror the FATF wire-transfer standard applied to correspondent banking – and they include name, account identifier and, depending on jurisdiction, address or national identification number.

The structural question is: what constitutes a "transfer" for the purposes of the rule? This turns on the technical model. A custodial exchange moving assets between two of its own wallets – an internal sweep – is generally not a Travel Rule transfer. An exchange instructing a blockchain send to an external address is. A firm that confuses the two will either over-report (creating data-processing risk) or under-report (creating compliance failure). The policy must define the perimeter of the obligation by reference to the firm's own wallet architecture, not by reference to the generic FATF language.

The cross-border dimension compounds this. The Travel Rule threshold is not uniform. The applicable standard in the EU under MiCA, in Singapore under the MAS regime, in the UK under the FCA's MLR-derived rules, and in Dubai under VARA each varies. A firm with counterparty VASPs in multiple jurisdictions must manage a matrix of obligations. The receiving VASP's jurisdiction may impose requirements the sender's jurisdiction does not – and the receiving VASP's compliance posture becomes a vendor-due-diligence issue for the sender. In our practice, operators routinely underestimate how much of the Travel Rule burden sits on the commercial relationships with counterparty VASPs rather than on the technical system alone.

How Do VARA, MiCA and MAS Differ in Their AML/CFT Policy Expectations?

Three of the most consequential licensing regimes for internationally active digital-asset businesses – VARA in Dubai, MiCA/ESMA in the EU, and the MAS Payment Services Act in Singapore – each impose AML/CFT policy requirements, but their emphasis, format expectations and supervisory posture differ in ways that matter significantly to policy drafters.

Under the VARA regime, VARA's AML rulebook specifies both the structural elements of the compliance function and the controls expected at the product level. VARA expects the Compliance Officer to be resident and senior; it expects the policy to address activity-specific risk (exchange, custody, lending, transfer and settlement are each separately licensed activities with distinct risk profiles). A single omnibus policy covering all licensed activities without activity-level differentiation will not satisfy a VARA supervisory examination. The drafting implication is that the policy must be modular by activity, even if the licensed entity performs all activities under one corporate vehicle.

Under MiCA and the ESMA framework, CASP (Crypto-Asset Service Provider) authorisation brings with it AML/CFT obligations that flow from both the MiCA regime and the underlying national AML transposition of the EU's Fourth and Fifth Anti-Money Laundering Directives. The interaction between the two layers – and the fact that MiCA passporting does not automatically extend the AML/CFT passporting benefit in the same way as for financial services under MiFID – means that a firm authorised in one EU member state and passporting into others must address the local AML supervisory requirements of the host state. The policy must anticipate the host-state layer, not just the home-state NCA.

Under the MAS Payment Services Act regime, MAS places significant weight on the risk-based approach – the expectation that controls are demonstrably proportionate to assessed risk. MAS has been explicit, through its inspection findings published over successive supervisory cycles, that generic policies that do not reflect the firm's actual product and customer profile are a primary source of regulatory findings. The drafting implication is that the business-wide risk assessment and the policy controls section must cross-reference each other with precision: identified high risks must have identifiable enhanced controls; identified low risks must have a documented rationale for the lighter control applied.

Who Owns the AML/CFT Policy, and Why Governance Structure Matters

The Money Laundering Reporting Officer (MLRO) is the named individual accountable for the AML/CFT policy – and the MLRO's placement in the corporate structure is a regulatory expectation, not merely a best-practice suggestion. Across VARA, MiCA, MAS and the FCA's MLR framework, the MLRO must be senior, independent from revenue-generating functions, and adequately resourced. In practice, what "adequately resourced" means is tested at inspection: does the MLRO have access to transaction monitoring outputs, to customer risk ratings, and to the board? Is there a documented escalation path from the MLRO to the board or a board-level committee?

The structural tension emerges when a digital-asset group operates through multiple regulated entities. Each regulated entity typically requires its own MLRO. The group MLRO model – one individual with nominal responsibility across all entities – will generally not satisfy the expectation in jurisdictions that require the MLRO to be an approved person or a senior function holder under the local fit-and-proper regime. The policy drafting implication is that the governance section of each entity's policy must clearly identify the entity's own MLRO, the MLRO's reporting line within that entity, and the interface with any group-level AML function.

We have seen enforcement action in multiple jurisdictions arise not from a failure of the policy's substantive content but from a failure of its governance scaffolding: no named deputy; no documented escalation protocol; an MLRO who was also the CEO of the operating entity and therefore not independent of commercial decisions. Policy drafters must treat the governance section as a legal document, not a formality.

If a prior compliance program has attracted supervisory comment or an account closure, a structural review can identify the underlying cause. Map your options with OBOLUS.

How Should Transaction Monitoring Be Reflected in the AML/CFT Policy?

Transaction monitoring is the control that converts the risk assessment into ongoing surveillance – and it is the area where policy language most frequently diverges from operational reality. A policy that describes monitoring rules by reference to fiat-world typologies, without addressing the on-chain dimension, will produce a monitoring program that is blind to the risks specific to digital assets.

The on-chain dimension includes: interaction with mixer or tumbler services, exposure to high-risk counterparty addresses flagged in blockchain analytics databases, unhosted-wallet deposit patterns inconsistent with stated purpose, rapid layering through multiple wallet addresses, and activity patterns associated with sanctions-designated entities or clusters. Each of these is a digital-asset-specific typology that the policy must address in the monitoring rules section, either by describing the alert logic or by incorporating by reference the firm's monitoring system configuration and the methodology behind it.

The policy must also address what happens after an alert fires: the triage workflow, the escalation path, the timeline for investigation, and the decision logic for filing a suspicious activity report. In our practice, firms that have strong monitoring systems but weak post-alert procedures routinely receive the same supervisory findings as firms with weak monitoring: the finding is not "you failed to detect" but "you detected and failed to act within a documented and timely process." The policy's post-alert section is where many programs are weakest, and it is where supervisory examinations increasingly focus.

The cross-border dimension of transaction monitoring is the sanctions overlay. A VASP serving customers globally must apply the sanctions lists of each jurisdiction where it operates – US OFAC designations, EU consolidated list, UK HM Treasury list, UN Security Council designations – and the policy must specify which lists the firm screens against, at what frequency, and how the screening system is updated when new designations are published.

What KYC Framework Does a Digital-Asset Business Need, and How Does Structure Shape It?

A KYC framework for a digital-asset business is not a single procedure; it is a layered architecture of customer identification, risk rating, enhanced due diligence and ongoing monitoring that must be mapped onto the firm's actual onboarding and customer lifecycle model. The structural dependencies are significant.

The first dependency is the onboarding channel. A firm that onboards customers entirely through a mobile application, with no face-to-face element, is relying on electronic identity verification. The policy must specify the electronic verification methodology, the acceptance criteria, and the fallback for cases where the primary verification method fails or produces uncertain results. The choice of verification technology – and its adequacy – will be examined by the regulator both at authorisation and at inspection.

The second dependency is the product set. A firm offering spot trading, staking, lending and NFT services to the same customer base has a product-level KYC question at each layer: does the customer's risk rating and due diligence level authorise access to each product? A customer onboarded for standard spot trading at a basic risk level should not automatically have access to a lending product that carries a different risk profile without an additional review step. The policy must specify the product access logic and the KYC threshold for each.

The third dependency is the beneficial ownership layer for corporate customers. Digital-asset businesses attract institutional and semi-institutional customers – funds, family offices, other VASPs – that require a beneficial ownership analysis going beyond the simple individual-identification flow. The policy must define the ownership threshold for identification and verification, the documentation requirements for complex structures, and the enhanced due diligence trigger for politically exposed persons (PEPs) and higher-risk corporate structures. Across VARA, MiCA, MAS and the FCA regime, the expectation for corporate customer due diligence has hardened materially in recent supervisory cycles.

A Cross-Border Policy Failure: An Anonymized Illustration

In a recent matter, a payments company – licensed in a mid-tier EU member state under the pre-MiCA VASP registration framework – expanded its customer base into the Gulf and Southeast Asia. The firm's AML/CFT policy had been drafted at registration and never updated. It addressed European customer typologies, EU-standard identity verification documentation, and Travel Rule thresholds calibrated to the home state's transposition. When the firm opened institutional relationships with counterparty VASPs in Dubai and Singapore, it had no policy mechanism for assessing counterparty VASP risk, no sanctions overlay for OFAC or the UAE Central Bank's list, and no Travel Rule procedure for transfers to receiving VASPs operating under different threshold rules. The firm's new banking relationship was reviewed in the course of the bank's own VASP counterparty due diligence, the deficiency was identified, and the account was placed under restriction. We were engaged to conduct a structural review and redraft the policy with jurisdiction-specific modules for each operating territory. The firm's banking relationship was restored following the resubmission of the revised compliance program.

Which AML/CFT Policy Architecture Fits Which Operator Profile?

Not all digital-asset businesses require the same policy architecture. The appropriate depth and modular structure follow from three factors: the activity set, the customer base, and the jurisdictional footprint. The following matrix describes the indicative approach for four common operator profiles.

Profile A – Single-jurisdiction exchange, retail-only, single fiat pair. The appropriate policy is a jurisdiction-specific document tracking the home-regulator's rulebook precisely, with a standard KYC flow for retail customers, a rule-based transaction monitoring program calibrated to the single product, and Travel Rule procedures scoped to the home-state threshold. The primary risk is volume-driven false negatives in transaction monitoring as the customer base scales. The policy should include a review-trigger keyed to volume thresholds.

Profile B – Multi-licensed exchange, retail and institutional, multiple fiat pairs. The policy requires a modular architecture: a base policy addressing the FATF floor, jurisdiction-specific annexes for each licensed entity, product-specific risk overlays, and a counterparty-VASP due diligence framework for the institutional segment. The Travel Rule section must address the multi-jurisdiction threshold matrix. The primary risk is inconsistency between the base policy and the annexes when one jurisdiction's rules are updated and the others are not. The policy must include a review-and-sync schedule.

Profile C – Offshore holding structure with onshore operating subsidiaries. The policy question is where the AML/CFT obligation sits. Each onshore subsidiary requires its own policy conforming to the local regime. The holding entity may require its own policy if it performs VASP activity in the regulatory sense. The primary risk is the holding entity's unacknowledged regulatory status, as discussed above. The structural review must precede the policy draft.

Profile D – DeFi protocol with a regulated fiat on-ramp. The regulated perimeter is the fiat on-ramp. The policy must be scoped precisely to the activities that constitute regulated VASP activity – and must be candid with the regulator about the protocol layer and the firm's relationship to it. Attempting to draft the policy in a way that minimizes the regulated perimeter will invite a broader supervisory inquiry into the protocol relationship. Transparency on structure, with a precisely drawn policy, is the appropriate approach.

A Common Assumption: One Offshore Licence Covers Global Operations

A common assumption among early-stage digital-asset businesses is that a single offshore registration – in the BVI under the VASP Act 2022, or in Cayman under the CIMA regime – provides sufficient regulatory cover to serve customers globally. This assumption is incorrect in almost every scenario where it matters. The offshore licence satisfies the registration requirement of the home jurisdiction. It does not displace the licensing and AML/CFT requirements of the jurisdictions where the customers are located.

The FCA, MAS, SFC and VARA each assess the jurisdictional nexus for their regime independently. A VASP marketing its services to UK retail customers from a BVI entity is subject to the FCA's financial promotion rules and, depending on the activity, the MLR registration requirement, regardless of where the entity is incorporated. The BVI licence provides no regulatory cover in London. The AML/CFT policy written for the BVI regulator will not satisfy an FCA supervisory examination.

The practical consequence is that the policy architecture must follow the customer geography. Where customers are located in jurisdictions with their own AML/CFT supervisory regimes, the policy must address those regimes – either through jurisdiction-specific annexes or through a policy design that meets the highest common standard across all relevant regimes. The latter approach is more efficient but requires careful calibration: writing to the most demanding standard in every respect will produce a policy that is operationally burdensome for customers in lighter-touch jurisdictions. The modular approach – a base policy plus jurisdiction-specific supplements – is generally more proportionate.

Related at OBOLUS

• AML/CFT and Travel Rule compliance for digital-asset businesses – Our core practice area: full-cycle compliance design, policy drafting and regulatory engagement.
• VASP business risk assessment – Legal counsel for digital-asset firms conducting the risk assessment that anchors the AML/CFT program.
• Crypto regulation and licensing in Malta – The MFSA regime, VFA framework and MiCA transition for EU-anchored digital-asset businesses.

FAQ

What does the Travel Rule require from a VASP?

The Travel Rule requires a VASP transmitting virtual assets to pass originator and beneficiary information to the receiving VASP before or simultaneously with the transfer. The required data elements include name and account identifier and, depending on the jurisdiction, address or national identification. The applicable threshold varies by licensing regime – EU under MiCA, Singapore under MAS and Dubai under VARA each set their own thresholds – so a VASP with international counterparty relationships must manage a multi-jurisdiction compliance matrix rather than a single standard.

Who must act as MLRO for a crypto firm?

The Money Laundering Reporting Officer must be a senior individual, independent from revenue-generating functions, with direct access to transaction monitoring outputs, customer risk data and board-level escalation. Most flagship regimes – including VARA, MiCA, MAS and the FCA's MLR framework – treat the MLRO as a named approved function. Each separately regulated entity in a group typically requires its own MLRO; a single group-level appointment will not satisfy the personal accountability expectations of jurisdictions with a formal senior-function regime.

How do regulators audit crypto AML programs?

Regulators at VARA, ESMA's national competent authorities, MAS and the FCA assess AML/CFT programs by examining whether the written policy reflects the actual business, whether controls are calibrated to the risk assessment, and whether post-alert investigation procedures are documented and followed. Inspections typically request the risk assessment, sample transaction monitoring alerts with investigation records, customer due diligence files for higher-risk relationships, and MLRO activity reports. Generic policies that do not cross-reference the firm's specific product set, customer base and geographic exposure are a primary source of adverse findings.

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 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 structure licensing, banking and tax as one mandate rather than three disconnected workstreams. To discuss your AML/CFT policy architecture or compliance program, contact info@oboluslaw.com.

By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML/CFT program architecture, VASP supervisory engagement and cross-border compliance structuring for 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.