AML/CFT Policy Drafting: The Compliance Burden in Practice

A digital-asset business that launches without a defensible AML/CFT program (anti-money laundering and countering the financing of terrorism policy architecture) is not simply non-compliant – it is operating on borrowed time. Regulators across the major hubs have sharpened their supervisory tools considerably. The FATF Recommendation 15 framework, which brings virtual asset service providers within the global AML/CFT perimeter, now has direct equivalents in domestic law across the EU under MiCA, in Singapore under the Payment Services Act supervised by MAS, in Dubai under the VARA regime, and in Hong Kong under the SFC VASP licensing rules. What that means operationally – for policy writers, compliance officers and general counsel – is the subject of this analysis.

AML/CFT policy drafting for a digital-asset firm is harder than for a traditional financial institution. The asset class moves faster. The counterparty universe is wider. The Travel Rule (the obligation to pass originator and beneficiary data with every qualifying transfer) creates technical dependencies that do not exist in conventional payment systems. And the cross-border reality – an entity licensed in one jurisdiction serving users in another, banking in a third – multiplies every compliance obligation. This page maps the burden in practice: the regulatory floor, the operational architecture, the common mistakes and the cross-border decisions that define the compliance stack.

What Is the Regulatory Floor for a VASP AML/CFT Program?

The regulatory floor is set by FATF Recommendation 15 and its Guidance for a Risk-Based Approach to Virtual Assets, which requires every VASP (virtual asset service provider) to maintain a documented AML/CFT program that is proportionate to its risk profile. That requirement is not aspirational. Every flagship jurisdiction – including the EU under MiCA, Singapore under the MAS Payment Services Act regime, Hong Kong under the SFC VASP framework, and the UAE under VARA – has transposed it into enforceable domestic law with supervisory consequences for failure.

The minimum program elements are well-established: a written AML/CFT policy, a risk assessment calibrated to the firm's products and user base, a KYC framework (know-your-customer onboarding and ongoing due diligence procedures), transaction monitoring, suspicious activity reporting, record-keeping, and a named compliance officer carrying statutory responsibility. What varies by jurisdiction is the prescriptiveness of each requirement – the depth of customer due diligence, the threshold at which enhanced due diligence triggers, and the data fields that must accompany a transfer under the Travel Rule.

In our practice, the most common structural gap we identify is not an absence of policy documents. It is a disconnect between the written policy and the operational controls that are supposed to implement it. A policy that says "enhanced due diligence applies to high-risk customers" means nothing without a documented methodology for assigning risk ratings and a process that demonstrably acts on them. Regulators audit the gap between paper and practice.

What Goes Into a Defensible AML/CFT Policy Document?

A defensible AML/CFT policy document does more than recite the statutory obligations – it demonstrates that the firm has thought rigorously about its specific risks and designed proportionate controls to address them. That distinction matters enormously when a regulator conducts a supervisory review.

The core architecture has several interdependent layers. The first is the firm-wide risk assessment: a documented analysis of the business's exposure to money laundering and terrorist financing risk by product line, customer type, geography and delivery channel. Under MiCA, the ESMA regulatory framework expects this to be a living document – updated when the product changes, when a new jurisdiction is served, or when the regulatory environment shifts. VARA in Dubai imposes a similar expectation through its rulebooks, and MAS in Singapore requires the risk assessment to support the firm's customer risk-scoring logic.

The second layer is the KYC framework itself: onboarding procedures, identity verification, beneficial ownership checks for corporate customers, and the thresholds at which simplified or enhanced due diligence applies. The third is transaction monitoring – the rules or models that flag unusual activity for human review. The fourth is the escalation and reporting pathway from a transaction alert to a suspicious activity report filed with the relevant financial intelligence unit.

Two elements that firms routinely underweight deserve direct attention. The first is the Travel Rule implementation chapter. This is not a minor addendum. It requires the firm to specify which counterparty VASPs it will transact with, what data it collects and transmits, how it handles transfers from or to unhosted wallets, and what it does when a counterparty cannot provide compliant Travel Rule data. The second underweighted element is the training program. A policy that staff have not read – and cannot demonstrate they understand – will not satisfy a supervisory examination under any of the flagship regimes.

A practical test: hand the draft policy to a new compliance analyst on day one and ask whether they could run the firm's controls from it without further instruction. If the answer is no, the policy is not operationally complete.

How Does the Travel Rule Create a Distinct Technical Compliance Layer?

The Travel Rule imposes a data-transmission obligation on VASPs that has no direct parallel in traditional banking compliance and requires a technical solution – not just a policy – to discharge. Every qualifying transfer must carry originator name, account information and address, together with beneficiary name and account information. The requirement sits in FATF Recommendation 16 as applied to virtual assets, and it has been implemented across every significant licensing regime: MiCA for EU CASPs, the MAS Payment Services Act for Singapore DPT services, the SFC VASP regime in Hong Kong, and VARA for Dubai-licensed exchanges.

The technical dependency is acute. A VASP must be able to transmit and receive structured Travel Rule data with every qualifying outbound and inbound transfer. That requires either a proprietary messaging solution or integration with one of the interoperability protocols that have emerged in the market. Neither route is trivial to implement. The policy document must specify the chosen solution, the counterparty verification process (ensuring the receiving VASP is itself a regulated entity), the data retention architecture, and the firm's approach to transactions where compliant data cannot be obtained.

The cross-border dimension adds further complexity. A VASP licensed in the EU sends a transfer to a VASP in Singapore. Both are regulated. But the data fields required, the threshold above which the Travel Rule applies, and the acceptable formats for identity data differ by jurisdiction. The policy must address this. It must also address the "sunrise problem" – what happens when a counterparty jurisdiction has not yet implemented the Travel Rule at all – and specify whether the firm will send, hold or reject transfers in that scenario.

In our cross-border practice, we regularly advise firms that have implemented a Travel Rule messaging tool but have not updated their AML policy to describe how it works. The tool runs; the policy does not govern it. That creates a supervisory exposure under any regime that requires the policy to be the controlling document for operational controls.

CTA #1

The regulatory floor described above represents the minimum. Your specific product, user base and cross-border footprint will determine whether the standard program is sufficient or whether a more complex architecture is required. For a scoped assessment of your AML/CFT policy against the regimes you operate under, contact OBOLUS at Map your options.

Who Carries the MLRO Burden and What Does That Mean in Practice?

Every regulated VASP must designate a Money Laundering Reporting Officer (MLRO) – a named individual with statutory responsibility for the firm's AML/CFT program and for receiving and evaluating internal suspicious activity reports. The MLRO role is not a box to tick in an application form. Across all the major regimes – VARA in Dubai, MAS in Singapore, the FCA in the UK, the SFC in Hong Kong and MiCA's national competent authorities in the EU – the MLRO is a supervised individual whose fitness and propriety can be examined directly.

The core obligations are consistent: the MLRO must have sufficient seniority to challenge the business, adequate resources to discharge the function, and direct access to the board. They must be genuinely independent from the revenue-generating activity they oversee. In smaller firms, the MLRO role is sometimes combined with a broader compliance officer title. That combination is permissible in some regimes but scrutinized in others. Regulators will ask whether the individual has the bandwidth to discharge the MLRO function properly when they also carry other compliance responsibilities.

Outsourced MLRO arrangements – where a third-party compliance firm provides the MLRO on a contracted basis – are accepted in a number of jurisdictions but come with conditions. The individual must be identifiable, contactable by the regulator, and genuinely authoritative within the firm's decision-making process. A nominal MLRO who receives reports but cannot access the transaction data needed to evaluate them does not meet the standard under any of the flagship regimes.

One practical dimension that firms under-resource is succession. If the MLRO departs, the firm must have a documented succession plan and must notify the regulator within the required timeframe. The timeframe varies by regime. The policy should specify it.

How Does the Cross-Border Reality Complicate the Compliance Architecture?

For a digital-asset business operating across more than one jurisdiction, the AML/CFT program is not a single document – it is a layered architecture that must satisfy the highest applicable standard at every point in the operating structure. A firm licensed by VARA in Dubai but serving European users will have obligations under VARA's rulebooks and, potentially, MiCA obligations triggered by the nature of that service. A firm with a Singapore MAS licence whose parent entity is licensed in the BVI under the VASP Act will need to ensure that group-level AML/CFT policies cascade down in a way that satisfies both regulators.

The cross-border compliance burden is most acute at three points. First, customer risk scoring: a customer who is low-risk in one jurisdiction may be high-risk in another because of that country's FATF status, sanctions exposure or domestic PEP (politically exposed person) definitions. The policy must specify how the firm resolves these conflicts. Second, sanctions screening: the firm may be obligated to screen against multiple sanctions lists simultaneously – OFAC, EU, UN, the UAE's own list – and must document how conflicts between them are resolved. Third, the Travel Rule: as noted above, the data requirements and thresholds differ by regime, and the policy must be specific about how the firm navigates those differences.

We have seen firms draft a single policy document written to the requirements of their primary licensing jurisdiction and assume it covers the rest. It rarely does. The safer approach is to build a group-level policy that sets the minimum standard and then layer jurisdiction-specific annexes that address the points where local requirements are more demanding or structurally different.

Which Compliance Architecture Fits Which Operator Profile?

The right AML/CFT policy architecture depends on the firm's operating model, not on a generic template. The following profiles illustrate the decision logic in practice.

Profile A – Single-jurisdiction exchange or custodian (early stage): The firm is licensed in one jurisdiction, serves a defined user base, and has a straightforward product. The appropriate architecture is a single, self-contained AML/CFT policy document covering all six core elements, a risk assessment calibrated to the specific product and user type, a designated in-house or outsourced MLRO, and a Travel Rule solution integrated with the primary transfer mechanism. The timeline to draft and operationalize a compliant policy at this scale is a matter of weeks under normal conditions. The primary risk is the gap between the written policy and day-to-day operational practice – the paper-versus-practice failure mode.

Profile B – Multi-jurisdiction operator with a group structure: The firm holds licences in two or more jurisdictions, or operates through a group with entities in different regulatory perimeters. The architecture requires a group-level AML/CFT policy establishing the floor, jurisdiction-specific annexes addressing local requirements, a governance mechanism for cascading policy updates when one jurisdiction changes its rules, and a group MLRO function with clear lines to local compliance officers. The Travel Rule chapter must address cross-border counterparty scenarios explicitly. The policy maintenance burden is significantly higher, and the risk of inconsistency between the group policy and local annexes is the principal compliance vulnerability.

Profile C – DeFi-adjacent or non-custodial operator: The firm provides services in a space where the application of VASP obligations is contested or evolving. The AML/CFT program must address the regulatory characterization question before it can address the policy design question. If the firm is characterized as a VASP in any major jurisdiction, the full program applies. The policy must therefore be written to be compliant on the assumption that characterization resolves against the firm, while the legal analysis of the characterization question proceeds separately. Building the compliance architecture on the assumption that VASP status does not apply is a structural risk that several enforcement actions across multiple jurisdictions have illustrated.

What Are the Most Common AML/CFT Policy Drafting Mistakes?

The most common AML/CFT policy drafting mistake is writing to the regulatory checklist rather than to the firm's actual risk profile. A policy that reproduces the statutory language without applying it to the specific products, customers and geographies the firm serves is not a compliant policy – it is a compliance liability. Every major regulator expects to see evidence that the firm has genuinely thought about its own risks and designed controls that address them.

A second recurring failure is leaving the Travel Rule as a high-level aspiration rather than an operational procedure. The policy must specify: the threshold, the data fields, the transmission method, the counterparty verification process, and the decision rule for non-compliant inbound transfers. Regulators reviewing Travel Rule compliance expect to see not just a policy statement but evidence of operational implementation.

The third common mistake is stale risk assessments. A risk assessment written at the time of licensing and never revisited ceases to reflect the firm's actual risk profile within months. Product changes, geographic expansion, new customer segments and changes in the regulatory environment all require reassessment. The policy should specify a review cycle – at minimum, annually and upon any material change to the business.

A fourth pattern we see regularly is inadequate documentation of the customer due diligence decision logic. The policy says enhanced due diligence applies to high-risk customers. But the criteria for high-risk classification are buried in an internal spreadsheet that no one can locate during an audit. The risk-rating methodology must be in the policy or an operationally integrated annex.

Finally, firms in multi-entity group structures frequently allow their local-entity policies to fall out of sync with the group policy. This creates a supervisory exposure in every jurisdiction where a local entity is regulated: the local regulator sees a policy that does not match the group document and cannot verify which one controls.

CTA #2

If a prior compliance review flagged gaps in your AML/CFT architecture, a structural read can surface the root cause and the path to remediation. If an account was closed or a licence application queried on compliance grounds, the underlying policy usually explains why. To discuss a remediation scope, write to OBOLUS at Map your options.

AML/CFT in Practice – an Anonymized Illustration

In a recent licensing matter, a payments company seeking a VASP authorization in a major European jurisdiction submitted an AML/CFT policy that had been drafted against the requirements of its existing offshore registration. The policy contained all the required headings. It named an MLRO, described a KYC framework, and included a Travel Rule section. The national competent authority reviewing the application issued a detailed information request identifying twenty-three specific deficiencies – not in the structure of the policy but in its substance. The risk assessment did not reflect the European customer base. The Travel Rule chapter did not specify a transmission protocol or a counterparty verification procedure. The MLRO's role description did not address access to transaction data. We were engaged to conduct a gap analysis and redraft the policy against the applicable MiCA transitional requirements. The application was resubmitted with a fully revised compliance architecture. Authorization followed in the subsequent review cycle.

A Common Assumption: One Offshore Licence Covers the Compliance Obligation

A common assumption among digital-asset businesses entering the market is that a single offshore registration – a BVI VASP registration or a Cayman CIMA record – satisfies the AML/CFT compliance obligation globally, or at least for the jurisdictions where users are served. This assumption is incorrect and, in our practice, is among the most expensive ones a business can carry.

The AML/CFT obligation follows the activity, not just the entity's domicile. A firm registered in the BVI under the VASP Act but providing services to users in the EU, the UK or Singapore is subject to the AML/CFT rules of those jurisdictions as well – either directly, if the service is characterized as being provided locally, or through the conditions attached to access to payment rails, banking and institutional counterparties in those markets. A single offshore registration does not provide a passporting or mutual-recognition mechanism into any of the major regulated markets.

The practical consequence is that AML/CFT policy drafting for a business with an international user base must be designed against the most demanding applicable standard from the outset – or must be upgraded as the firm grows into additional markets. The cost of upgrading a non-compliant policy architecture during a live regulatory review or a banking relationship crisis is substantially higher than the cost of building it correctly at the start.

We map the licence stack across operating, custody and payment layers before a business commits to a structure. That process consistently surfaces AML/CFT obligations that a single-jurisdiction analysis would miss.

How Do Regulators Audit a Crypto Firm's AML/CFT Program?

Regulators audit a crypto firm's AML/CFT program through a combination of document review, interviews with the MLRO and compliance team, transaction file sampling, and – increasingly – direct examination of the firm's technical systems. The audit methodology varies by regulator and by the firm's risk classification, but the underlying questions are consistent across VARA, MAS, the SFC, the FCA and the national competent authorities implementing MiCA.

The first audit question is always: does the policy document exist, is it current, and does it cover all required elements? The second question – more revealing – is whether the operational controls match what the policy describes. Auditors will pull a sample of customer files and ask the compliance team to walk through the onboarding process against the policy. They will look at transaction monitoring alerts and ask how they were evaluated and what happened to them. They will test the MLRO's independence and access. They will review the training records for all staff with AML/CFT responsibilities.

Under the VARA regime in Dubai, supervisory examination includes a review of the firm's rulebook compliance more broadly, but AML/CFT is consistently a primary focus. MAS in Singapore has published its supervisory expectations for digital payment token service providers in detail, and examinations are structured against those published expectations. The SFC in Hong Kong aligns its VASP audit approach to its broader intermediary supervision methodology, which includes thematic reviews across the licensed population.

Firms that perform well in regulatory audits share a common characteristic: their compliance team can demonstrate, with reference to documented evidence, that the policy controls are operating in practice. Firms that perform poorly almost always have a paper-versus-practice gap – a well-drafted policy sitting alongside operational processes that do not implement it.

One practical preparation step is to conduct a pre-audit internal review using the same methodology a regulator would apply: pull random customer files, test the transaction monitoring output, review training records, and interview the MLRO without preparation. The gaps that surface in that exercise are the gaps a regulator will find.

Related at OBOLUS

• Compliance, AML & Travel Rule for Digital-Asset Businesses – full-service compliance program design, policy drafting and ongoing MLRO support.
• Travel Rule Compliance Program: Where the Legal Lines Are Drawn – deep analysis of Travel Rule implementation across the major licensing regimes.
• EU MiCA vs Hong Kong: Where to License a Crypto Business – comparative jurisdiction guide for exchanges and custodians assessing the European and Asian regulated pathways.

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 collect and transmit originator and beneficiary information with every qualifying transfer. The required data includes the originator's name, account identifier and address, and the beneficiary's name and account identifier. The specific threshold above which the obligation applies, and the precise data fields required, vary by jurisdiction – every firm operating across multiple regimes must design its Travel Rule procedures to satisfy the most demanding applicable standard and address the scenario where a counterparty VASP cannot provide compliant data.

Who must act as MLRO for a crypto firm?

A Money Laundering Reporting Officer (MLRO) must be a named individual with sufficient seniority to challenge the business, direct access to the board, and genuine independence from revenue-generating functions. Across the major regimes – VARA, MAS, the FCA, the SFC and MiCA national competent authorities – the MLRO is a supervised person whose fitness and propriety can be examined by the regulator. Outsourced MLRO arrangements are accepted in several jurisdictions under specified conditions. The policy must document the MLRO's responsibilities, decision authority and succession arrangements.

How do regulators audit crypto AML programs?

Regulators audit crypto AML programs through document review, MLRO and compliance staff interviews, customer file sampling, transaction monitoring output review, and direct examination of technical systems. The audit tests whether the written policy matches operational practice – the paper-versus-practice gap is the most common finding. Firms that perform well in supervisory examinations can demonstrate, with documented evidence, that every policy control is operating as described. Preparation through internal pre-audit reviews – using the same sampling methodology a regulator applies – is the most effective way to identify and close gaps before an examination.

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 compliance, AML and Travel Rule programs that sit around them. Digital assets are the whole of our practice. We map the licence stack across operating, custody and payment layers before a business commits to a structure, and we work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications when recovery is required. To discuss your situation, contact info@oboluslaw.com.

By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML/CFT program design, policy drafting and cross-border compliance architecture 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.