VARA AML Requirements: What Crypto Businesses in Dubai Must Build Before Licensing

One of the most common mistakes crypto founders make in Dubai is treating AML as something to “tighten up later,” after the licence application is already in motion.

Under VARA, that is the wrong sequence.

If you are applying for a Virtual Asset Service Provider (VASP) Licence in Dubai, AML is not a side policy you bolt on at the end. It is part of the operating model you are expected to have thought through before you file seriously. VARA’s public Licence Applications page says that new firms must first go through the ATI stage, then the full licence stage, and that the full application requires broad documentation across governance, risk and compliance, technology, and other areas. It also points applicants to the applicable rulebooks for VASP licence applications.

That matters because the current Compliance and Risk Management Rulebook includes an entire Part III – Anti-Money Laundering and Combating the Financing of Terrorism, covering:

• appointment and duties of the Money Laundering Reporting Officer (MLRO),
• AML/CFT policies and procedures,
• AML/CFT controls,
• risk assessments,
• client due diligence,
• suspicious transaction monitoring and reporting,
• FATF Travel Rule compliance,
• targeted financial sanctions,
• record keeping,
• and enforcement.

So the real question is not:

“Do we need an AML policy for VARA?”

It is:

“What AML framework must we already have built, documented, and operationalized before VARA will take our application seriously?”

That is what this article answers.

1) Start with the right premise: AML is a licensing-readiness issue, not just a post-licence issue

VARA’s public licensing page makes clear that any firm seeking to carry on VA activities in or from Dubai, excluding DIFC, must be licensed before commencing operations, and that the application process for new firms is staged and documentation-heavy. Stage 2 requires submission of the full documentation package and may involve meetings, interviews, and further document requests from VARA.

At the same time, the Compliance and Risk Management Rulebook is one of VARA’s compulsory rulebooks and applies across licensed VASPs. Its structure shows that AML/CFT is not treated as an optional extra. It sits inside the main compliance rulebook alongside compliance management, risk management, books and records, audit, regulatory reporting, and staff management and training.

That tells you something important immediately:

VARA expects AML to be embedded in the business before the licensing file is mature.

In practical terms, that means you should not expect to get very far with:

• a generic AML template,
• a future hiring plan with no clear AML ownership,
• or a vague statement that “the MLRO will be appointed after approval.”

A serious VARA application should already reflect a thought-through AML architecture because AML sits at the heart of how a VASP controls onboarding, transaction risk, sanctions exposure, suspicious activity, and regulator-facing accountability.

2) The AML rulebook tells you exactly what VARA expects businesses to build

One of the clearest ways to understand pre-licensing AML readiness is simply to look at how VARA has structured Part III of the Compliance and Risk Management Rulebook.

The AML/CFT section includes the following building blocks:

• Appointment and Duties of Money Laundering Reporting Officer
• Policies and Procedures
• AML/CFT Controls
• Risk Assessments
• Client Due Diligence
• Suspicious Transaction Monitoring and Reporting
• FATF Travel Rule
• Compliance with targeted financial sanctions
• Record keeping
• Enforcement.

That is already a practical checklist.

It means that before licensing, a VASP should be able to explain:

• who owns AML,
• what the AML policies are,
• what the control framework is,
• how risk is assessed,
• how clients are onboarded,
• how suspicious activity is escalated,
• how sanctions compliance is handled,
• how Travel Rule obligations will be met,
• and how records will be maintained.

So when founders ask what they need to “build before licensing,” the answer is not merely “an AML policy.” It is a full AML operating framework.

3) You need a real MLRO function, not just a name on a draft org chart

The rulebook gives a dedicated AML heading to the Appointment and Duties of Money Laundering Reporting Officer. That is a strong signal that VARA expects AML responsibility to be owned clearly and specifically.

For licensing readiness, this means a business should already have thought through:

• who the MLRO is or will be,
• whether the individual is suitably senior and credible,
• where the MLRO sits in the management and reporting structure,
• how AML matters are escalated,
• and how independence and access to decision-makers will work in practice.

The practical error many startups make is treating the MLRO role like an afterthought:

• “we’ll hire someone later,”
• “our compliance consultant can cover that for now,”
• or “one of the founders will sign off on AML until we scale.”

That may not be persuasive in a serious VARA review, because the existence of a named AML responsibility holder is only useful if the broader control environment around that person is credible too. Since the rulebook also includes compliance management, risk management, books and records, and staff training as part of the same compliance framework, the MLRO is expected to sit inside a functioning compliance system, not beside it.

4) AML policies and procedures must be business-specific

Another core heading in Part III is Policies and Procedures.

That may sound obvious, but it is where many applications become weak. Firms often submit AML documents that could belong to almost any business in any jurisdiction:

• broad policy statements,
• generic financial-crime language,
• vendor-produced templates,
• and little connection to the actual virtual-asset activity being applied for.

That is not enough for a regulator reviewing a crypto business model.

A VARA-ready AML policy set should reflect the actual business:

• Is the firm an exchange?
• A broker?
• A custody provider?
• A transfer and settlement business?
• A management business?
• A token issuer with distribution exposure?

The AML framework should match the real operational flows of the business:

• how customers come in,
• how wallets are controlled or linked,
• how assets or instructions move,
• how counterparties are assessed,
• and where high-risk activity might appear.

So before licensing, the business should already have documents that are tailored to its model rather than copied from a general compliance library. That is one of the clearest ways VARA can distinguish a serious applicant from one that is still only conceptually prepared.

5) Your AML controls need to go beyond policy text

The rulebook does not stop at “policies and procedures.” It separately identifies AML/CFT Controls.

That distinction matters.

A policy says what the business intends to do.
A control framework shows how the business will actually do it.

Before licensing, crypto businesses should therefore be able to show how their AML controls work in practice, including:

• onboarding gates,
• screening controls,
• monitoring logic,
• escalation paths,
• alert handling,
• internal reporting lines,
• and oversight routines.

This is especially important in virtual-asset businesses because the operational risk environment is often more dynamic than in ordinary non-financial businesses. A VASP is likely dealing with:

• wallets,
• transaction patterns,
• counterparties,
• asset flows,
• and cross-border exposure that requires more than a static policy document.

So a practical VARA-readiness test is:
Can we explain our AML controls operationally, not just conceptually?

If the answer is no, the AML buildout is probably not ready yet.

6) A documented AML risk assessment is essential

Part III also includes Risk Assessments as a distinct AML component.

This is one of the most important pre-licensing deliverables because it sits underneath almost everything else.

A serious AML framework should reflect the business’s actual risk profile, including:

• customer types,
• geography,
• products and services,
• distribution channels,
• delivery model,
• wallet and transaction exposure,
• third-party dependencies,
• and higher-risk scenarios inherent in the chosen VA activity.

The practical mistake many applicants make is drafting policies first and trying to reverse-engineer the risk assessment later. In reality, the risk assessment should shape the policy and control framework from the beginning.

For example, the AML architecture of:

• a retail-facing exchange,
• an institutional OTC broker,
• a custody business,
• and a token-issuance project

should not look identical, because the risk drivers are not identical.

So before licensing, the business should already be able to show:

• what its money-laundering and terrorist-financing risks are,
• how it has assessed them,
• and how those assessments drive due diligence, monitoring, escalation, and control intensity.

That is the kind of internal logic regulators usually expect to see.

7) CDD is not just onboarding paperwork — it is a core build item

The rulebook has a dedicated AML section for Client Due Diligence.

That tells you immediately that CDD is not a minor operational detail. It is one of the central pre-licensing systems a VASP needs.

Before filing seriously, a crypto business should already know:

• what information it will collect from clients,
• how identity verification will work,
• when enhanced due diligence will be triggered,
• how beneficial ownership and control issues will be handled,
• how higher-risk customers will be escalated,
• and how onboarding will be paused or rejected when necessary.

This is especially important because crypto businesses often underestimate how much their actual product design affects CDD. For example:

• direct retail onboarding,
• institutional customers,
• corporate accounts,
• intermediated users,
• token purchasers,
• and cross-border users

can all create very different CDD profiles.

So if the business cannot yet explain:

• who its clients are,
• how they will be onboarded,
• what due diligence will apply,
• and how risk-rating decisions will be made,

then the AML build is probably still too immature for a strong VARA licence file.

8) Suspicious transaction monitoring must exist as a real process

Part III also specifically addresses Suspicious Transaction Monitoring and Reporting.

This is another point where many early-stage applicants are underprepared. They assume transaction monitoring becomes relevant only once there is live volume.

But from a licensing-readiness perspective, VARA will want to know the process exists in design before the firm goes live.

That means the business should already have thought through:

• how suspicious activity will be identified,
• whether automated or manual monitoring will be used,
• what alert logic or review criteria exist,
• who reviews suspicious activity,
• how escalation works,
• and how reporting obligations will be managed.

A business that cannot explain how it will detect and handle suspicious activity is essentially telling the regulator:

• we know AML matters,
• but we have not yet built the operational response.

That is rarely a strong position in a regulated virtual-asset application.

9) The FATF Travel Rule is part of the AML build, not a later upgrade

VARA’s AML section includes a dedicated heading for the FATF Travel Rule.

That is an important signal because it shows Travel Rule compliance is not peripheral. It is part of the AML architecture the rulebook expects VASPs to address.

Before licensing, businesses whose models involve transfers or transaction flows that may implicate Travel Rule obligations should already have thought through:

• whether the rule applies to their activity,
• how originator and beneficiary information will be handled,
• what systems or vendors may be needed,
• how counterparty VASP interactions will work,
• and how exceptions, failures, or mismatches will be escalated.

For many crypto businesses, the Travel Rule is where “generic AML readiness” breaks down. A firm may have a strong policy at a high level, but still have no credible answer for how Travel Rule compliance will work operationally.

VARA’s structure makes clear that this is not something to leave unresolved until post-licensing implementation. It is part of the licensing-readiness conversation itself.

10) Sanctions compliance needs its own design logic

The AML section also includes Compliance with targeted financial sanctions.

Again, this tells you something important: sanctions are not an implied subtopic buried somewhere inside general AML. They are a defined control area the rulebook expects firms to address.

Before licensing, a crypto business should be able to explain:

• what sanctions screening will apply,
• when screening happens,
• whether wallet or counterparty screening is in scope,
• who reviews matches,
• how false positives are resolved,
• and how escalation works where a sanctions concern appears.

This is especially important in virtual-asset environments because sanctions exposure can arise not only through named customers, but also through wallets, counterparties, and transaction patterns.

So when thinking about what must be built before licensing, sanctions compliance should be treated as a core workstream, not a checkbox.

11) Record keeping is part of AML readiness too

Part III includes Record keeping as a distinct AML heading.

That is easy to underestimate, but it matters enormously in practice.

A VASP may have:

• decent policies,
• a named MLRO,
• and a theoretical monitoring process,

but if it cannot produce records that show what happened, how decisions were made, and what controls were applied, the AML framework will not look robust.

Before licensing, the business should therefore already know:

• what AML records it will keep,
• how client files will be maintained,
• how alerts and escalations will be documented,
• how suspicious-activity decisions will be recorded,
• and how records will be stored and retrievable.

This point also links directly back to VARA’s broader supervisory and examination powers. If a regulator asks for AML evidence, the firm needs to be able to produce it. Building that discipline only after approval is a weak strategy.

12) Staff management and training matter before licensing too

Outside Part III itself, the Compliance and Risk Management Rulebook also includes Staff Management and Training in Part I.

That matters because AML is not only about documentation and a single officer. It is also about whether relevant staff understand:

• onboarding standards,
• escalation procedures,
• suspicious-activity indicators,
• sanctions red flags,
• and who to go to when something looks wrong.

So before licensing, the business should already have a reasonable plan for AML training, especially for:

• compliance staff,
• operations staff,
• onboarding teams,
• client-facing staff,
• and senior management.

A business that treats AML as the MLRO’s private problem rather than an enterprise control issue usually looks underprepared.

13) What a regulator-ready AML build usually looks like before filing

In practical terms, a crypto business preparing for VARA licensing should usually already have the following built, or very close to built, before filing seriously:

• A defined AML governance structure with a credible MLRO and clear reporting lines.
• A set of AML/CFT policies and procedures tailored to the actual VA activity being applied for.
• A documented AML risk assessment aligned with the business model, customer base, geography, product design, and delivery channels.
• A practical CDD framework for onboarding and risk-rating clients.
• A suspicious-activity monitoring and escalation process with clear internal ownership.
• A plan and control logic for Travel Rule compliance where applicable.
• A sanctions-screening and escalation framework.
• A recordkeeping approach that supports future examination and audit.
• A staff AML training plan linked to operational responsibilities.

That is the difference between saying “we understand AML” and actually showing licensing readiness.

Final takeaway

If you want the clearest practical answer to:
“What AML requirements must crypto businesses in Dubai build before licensing?”

it is this:

Before licensing, a crypto business should already have a real AML operating framework, not just a policy file. VARA’s current Compliance and Risk Management Rulebook shows exactly what the regulator expects businesses to address, including:

• MLRO appointment and duties,
• AML/CFT policies and procedures,
• AML/CFT controls,
• risk assessments,
• client due diligence,
• suspicious transaction monitoring and reporting,
• FATF Travel Rule compliance,
• targeted financial sanctions compliance,
• and record keeping.

And because VARA’s public licensing process is documentation-heavy and expects applicants to demonstrate readiness across governance, risk and compliance, and operations, AML should be built early enough to support the application coherently, not added at the end.

How CRYPTOVERSE Legal Can Help

At CRYPTOVERSE Legal Consultancy, we help crypto businesses, exchanges, brokers, custodians, token issuers, and other digital-asset firms build VARA-ready AML frameworks before licensing. That includes:

• AML gap analysis,
• MLRO and governance structuring,
• AML/CFT policy drafting,
• risk-assessment design,
• CDD and onboarding framework review,
• Travel Rule readiness,
• sanctions and escalation workflow review,
• and broader VARA application strategy.

If you want tailored guidance on VARA AML requirements and what your crypto business must build before filing for a licence in Dubai, contact CRYPTOVERSE Legal Consultancy to discuss your regulatory readiness.

Disclaimer: This article is for general informational purposes only and does not constitute legal advice. AML obligations and licensing-readiness requirements are highly fact-specific and should be assessed against the latest VARA rulebooks, the firm’s business model, and applicable UAE legal requirements before filing.

FAQs