If you are building a regulated crypto business in Dubai, one of the easiest mistakes to make is assuming that all internal control roles can be collapsed into one person with a broad title like “Head of Compliance.”

Under VARA, that assumption is often too simplistic.

The current compulsory rulebooks distinguish between at least three important control roles that matter in different ways:

  • the Money Laundering Reporting Officer (MLRO) under the AML/CFT framework,
  • the Compliance Officer (CO) under the compliance-management framework,
  • and the Chief Information Security Officer (CISO) under the technology and information framework. The role architecture sits across three compulsory rulebooks: the Company Rulebook, the Compliance and Risk Management Rulebook, and the Technology and Information Rulebook.

That matters because VARA does not regulate a VASP as though it were only a product team with a legal adviser. It regulates a VASP as a supervised institution. Its public licensing page says all firms applying for a VASP licence must comply with the four compulsory rulebooks, and the application documentation includes governance framework, organisational structure, fit and proper confirmations, and key personnel details such as job descriptions and CVs.

So the practical founder question is not:

“Do we need a compliance person?”

It is:

“Which control roles does VARA expect us to have, what do they each own, and when can roles be combined without creating a governance problem?”

This guide explains that framework in practical terms.

1) Start with the bigger picture: VARA expects named control ownership

A useful place to begin is the Company Rulebook. It requires VASPs to appoint two Responsible Individuals of sufficient seniority who are responsible for the VASP’s compliance with all legal and regulatory obligations. Each Responsible Individual must be a full-time employee, fit and proper, resident in the UAE or a UAE passport holder, and notified to and approved by VARA during the licensing process.

That requirement tells you something important immediately: VARA wants control accountability to be explicit and resident inside the licensed business. The licensing page reinforces that by requiring applicants to submit key personnel details, including job descriptions and CVs, as part of the full application pack.

So when you think about MLRO, Compliance Officer, and CISO, do not think of them as optional “nice-to-have” job titles. Think of them as part of the broader architecture through which VARA expects a VASP to be governable, controllable, and supervisable.

2) The Compliance Officer: the owner of the compliance management system

The Compliance and Risk Management Rulebook requires VASPs to appoint a Compliance Officer. The current rule says the CO must:

  • possess at least five years of relevant experience in a compliance function,
  • be a Fit and Proper Person as approved by VARA,
  • be a resident in the UAE or hold a UAE passport,
  • be a full-time employee of the VASP,
  • and report directly to the Board.

That is a very specific profile. It shows that VARA does not view the CO as a junior support role or an outsourced afterthought. The CO is positioned as a senior control-function holder with direct Board reporting and a meaningful fit-and-proper expectation.

  • The same rule sets out the CO’s core duties. The CO is responsible for:
  • ensuring staff and senior management are properly trained on applicable laws and regulatory requirements, including consumer-protection and AML/CFT obligations,
  • developing and implementing compliance policies and procedures,
  • assessing emerging issues and risks,
  • reporting compliance activities and compliance audits to the Board,

and ensuring corrective action is taken where there are deficiencies in the compliance management system or non-compliance with law or regulation.

This tells you what the CO is really for under VARA:
The CO owns the compliance management system, not just a policy binder. The role sits above ordinary process administration and closer to enterprise compliance design, monitoring, reporting, and remediation.

In practical terms, the CO is the person VARA expects to be able to explain:

  • how the compliance framework is structured,
  • how staff are trained,
  • how regulatory change is tracked,
  • how issues are escalated,
  • and how the business responds when controls fail.

3) Why the Compliance Officer is not the same thing as the MLRO

A common startup instinct is to say:

  • “Our compliance lead can cover AML too.”

Under VARA, that can be true in some cases, but only if the role architecture is handled carefully.

The AML side of the same rulebook requires VASPs to appoint a Money Laundering Reporting Officer. The MLRO must:

  • possess at least two years of experience handling AML/CFT matters,
  • and be a Fit and Proper Person.

At first glance, that might make the MLRO look narrower or more junior than the CO. But that is not the right reading. The MLRO has a distinct regulatory purpose. The role exists to own the AML/CFT framework specifically, not the full compliance management system.

The MLRO’s duties include:

  • ensuring the Board and staff are properly trained on applicable AML/CFT laws and regulatory requirements relevant to VA activities,
  • developing and implementing AML/CFT policies and procedures,
  • conducting AML/CFT risk assessments,
  • monitoring and reporting suspicious transactions,
  • ensuring corrective action is taken in response to non-compliance with Federal AML-CFT Laws,
  • reporting quarterly to the Board on the effectiveness of AML/CFT policies and procedures,
  • identifying failures and non-compliance,
  • summarising anonymity-enhanced transactions and involved clients in those quarterly reports,
  • and making those reports available to VARA on request.

So if the CO is the owner of the general compliance management system, the MLRO is the owner of the financial-crime control framework within it. That includes:

  • AML/CFT policy,
  • suspicious-transaction handling,
  • AML risk assessment,
  • and AML-specific Board reporting.

This is why the two roles are related but not identical.

4) The MLRO is more than a suspicious-reporting contact

Many founders think of the MLRO as “the person who files suspicious reports.”

That is too narrow under VARA.

The rulebook shows the MLRO is responsible not only for suspicious transaction monitoring and reporting, but also for:

  • AML training,
  • AML policy design,
  • AML risk assessments,
  • corrective action on AML non-compliance,
  • and quarterly AML reporting to the Board.

That means the MLRO is a real control-function role, not just a reporting mailbox.

For licensing readiness, this has major implications. A VASP should be able to show:

  • who the MLRO is,
  • where the role sits in the organisation,
  • how AML escalations reach the Board,
  • and how the MLRO interacts with onboarding, transaction monitoring, sanctions screening, Travel Rule processes, and investigations.

In a regulated crypto business, the MLRO is often one of the most scrutinised individuals because AML/CFT failures are among the most serious enforcement-risk areas under VARA’s framework. The Regulations’ fine schedule specifically treats AML/CFT and KYC failures as sanctionable categories.

So the MLRO should be viewed as a core regulatory-control appointment, not a box-ticking exercise.

5) Can the Compliance Officer also be the MLRO?

This is where VARA gives firms some flexibility.

The Compliance Officer rule expressly states that, subject to the relevant requirements in the Company Rulebook and where appropriate, the CO may hold more than one non-client-facing role within the VASP, including the MLRO and the head of the risk function, provided the combined roles do not create conflicting duties. VARA also says it will take other roles held by the CO into account when determining whether the individual is fit and proper.

This means the answer is:
yes, the CO can also be the MLRO in some structures — but not automatically, and not carelessly.

The practical conditions are important:

  • the individual must still satisfy the separate competency expectations,
  • the combined roles must not create conflicts,
  • and the overall governance structure must still be credible under the Company Rulebook.

So for smaller or early-stage VASPs, a combined CO/MLRO structure may be possible if:

  • the person is genuinely qualified for both roles,
  • the business model is not too complex,
  • and the reporting and oversight arrangements are strong.

But for more complex models — especially exchanges, custody providers, transfer businesses, or firms with significant transaction volumes — combining the two roles may become harder to justify in practice, even if technically permissible. That is a judgement call that should be made against the actual activity profile and governance burden of the business. That point is an inference from the rulebook’s conflict-of-duties and fit-and-proper logic, not an express prohibition.

6) The CISO is a separate technology-control role, not an optional IT label

The Technology and Information Rulebook requires VASPs to appoint a Chief Information Security Officer (CISO). Rule I.I states that the CISO is responsible for ensuring that the VASP complies with Part I and Part III of the Technology and Information Rulebook. It also states that the CISO must be a separate individual from the Compliance Officer, although the CISO may also take on the responsibilities of the Data Protection Officer under the same rulebook. The CISO must also be of sufficiently good standing and appropriately experienced.

This is a crucial distinction.

Unlike the CO/MLRO combination, where dual-hatting may be allowed in appropriate cases, the rulebook draws a hard separation between the CISO and the Compliance Officer.

That means a founder cannot simply say:

  • “Our Head of Compliance will also be CISO.”

Under the current rulebook, that is not how the role structure is supposed to work.

The logic is easy to understand. The CISO is responsible for the technology and information-security control environment. That includes compliance with the Technology and Information Rulebook’s governance, security, and confidentiality requirements. The same rule also says senior management must regularly assess and review the effectiveness of the VASP’s processes, procedures, and controls under that rulebook and allocate duties to prevent conflicts of interest.

So the CISO is not just “the IT lead.” Under VARA, the CISO is a regulated control-function holder with a distinct role in the technology-governance layer.

7) Why VARA separates the CISO from the Compliance Officer

The CISO/CO separation tells you something bigger about VARA’s philosophy.

VARA expects compliance risk and information-security risk to be distinct enough that they should not sit in the same individual by default. The CISO must be separate from the CO, while senior management must allocate duties and apportion roles to prevent conflicts of interest.

That implies VARA wants at least three control perspectives in a VASP:

  • a general compliance perspective,
  • an AML/financial-crime perspective,
  • and a technology/security perspective.

Those perspectives can interact, but they should not be blurred into one undifferentiated “control person” model. That is especially important in virtual-asset businesses, where technology risk is not ancillary. Wallet management, cybersecurity, transaction integrity, business continuity, and information security are central to the regulated business.

So the presence of a separate CISO requirement is one of the clearest signs that VARA regulates crypto firms as technology-intensive financial institutions, not merely as online businesses with compliance policies.

8) How these roles fit with Responsible Individuals and senior management

The Company Rulebook adds another layer by requiring VASPs to appoint two Responsible Individuals of sufficient seniority who are responsible for the VASP’s compliance with all legal and regulatory obligations. Those individuals must be full-time, fit and proper, UAE-resident or UAE passport holders, and approved by VARA during licensing.

This means MLRO, CO, and CISO do not sit in a vacuum. They exist inside a wider governance structure where:

  • the Board has oversight,
  • senior management allocates duties,
  • and Responsible Individuals carry regulatory accountability at the institutional level.

So a practical org-chart question is not just:

  • Who is our CO?
  • Who is our MLRO?
  • Who is our CISO?

It is also:

  • how do these roles report,
  • who challenges them,
  • who receives their reports,
  • and how do they interact with the Responsible Individuals and the Board?

That is what makes the structure look regulator-ready rather than merely staffed.

9) What founders should think about before licensing

VARA’s licensing page requires applicants to submit governance framework, organisational structure, fit-and-proper confirmations, and key personnel details including job descriptions and CVs.

That means the question of who fills these roles is not something to defer until after licence grant. A serious applicant should already have thought through:

  • whether the CO is in place and qualified,
  • whether the MLRO is in place and qualified,
  • whether the CISO is identified and suitably experienced,
  • whether the CO and MLRO are combined or separated,
  • whether any combination creates conflict-of-duties issues,
  • and how all of these roles fit into the governance structure shown to VARA.

This is especially important because VARA’s licensing page also points all applicants to the compulsory rulebooks, which means firms are expected to understand role architecture at the application stage, not only after authorisation.

So the safest founder mindset is:
Role design is part of the licensing strategy.

10) A practical way to think about the three roles

A useful shorthand is this:

The Compliance Officer owns the compliance management system and the broader regulatory-compliance framework.

The MLRO owns the AML/CFT framework, suspicious-activity handling, AML risk assessment, and AML reporting line to the Board.

The CISO owns the technology and information-security control environment and compliance with the relevant parts of the Technology and Information Rulebook.

That is not a perfect shorthand for every operational detail, but it is a good starting point for founders building an org chart and a regulatory business plan.

It also explains why VARA sometimes allows one person to wear two hats and sometimes does not:

  • CO + MLRO may be possible if no conflicting duties arise and the overall structure remains fit for purpose,
  • but CISO must be separate from the CO.

Final takeaway

If you want the clearest practical answer to:
“Who do we need under VARA, and why?”

it is this:

VARA expects VASPs to identify distinct control ownership across compliance, AML, and technology. The Compliance Officer is the senior owner of the compliance management system and must be a UAE-based, full-time, fit-and-proper individual with at least five years of relevant compliance experience who reports directly to the Board. The MLRO is the AML/CFT control owner and must be fit and proper with at least two years of AML/CFT experience. The CISO is the technology and information-security control owner, must be suitably experienced and in good standing, and must be a separate person from the Compliance Officer.

The practical lesson is not just that these roles exist. It is that VARA uses them to test whether your VASP is genuinely governable and supervisable as a regulated institution.

How CRYPTOVERSE Legal Can Help

At CRYPTOVERSE Legal Consultancy, we help founders, exchanges, brokers, custodians, transfer businesses, token issuers, and other digital-asset firms design VARA-ready governance and control structures, including:

  • role-mapping for MLRO, Compliance Officer, and CISO,
  • fit-and-proper readiness,
  • org-chart and reporting-line review,
  • dual-hatting analysis,
  • governance framework drafting,
  • and broader VARA licence application strategy.

If you want tailored guidance on which key control roles your VASP needs under VARA and how to structure them properly before licensing, contact CRYPTOVERSE Legal Consultancy to discuss your regulatory readiness.

Disclaimer: This article is for general informational purposes only and does not constitute legal advice. Role design under VARA is highly fact-specific and should be assessed against the latest rulebooks, the proposed VA activities, the firm’s complexity, and its actual operating model before filing.

FAQs

1. Does VARA require a Compliance Officer for a VASP?

Yes. VARA requires every licensed VASP to appoint a Compliance Officer. The Compliance Officer must be a full-time employee, fit and proper, UAE-based or a UAE passport holder, have at least five years of relevant experience, and report directly to the Board.

2. What is the difference between an MLRO and a Compliance Officer under VARA?

The Compliance Officer oversees the overall compliance framework, while the MLRO is responsible for AML/CFT compliance. The MLRO handles AML risk assessments, suspicious transaction monitoring, and AML reporting, whereas the Compliance Officer manages broader regulatory compliance and governance.

3. Can a Compliance Officer also be the MLRO under VARA?

Yes. VARA allows a Compliance Officer to also act as the MLRO where appropriate. The individual must meet the requirements for both roles, and the arrangement must not create conflicts of interest or weaken governance controls.

4. Does VARA require a separate CISO?

Yes. VARA requires VASPs to appoint a Chief Information Security Officer (CISO). The CISO oversees information security and technology controls and must be a separate individual from the Compliance Officer.

5. What control roles are required for a VARA licence application?

A VARA licence applicant should identify key control-function holders, including a Compliance Officer, MLRO, CISO, Responsible Individuals, and senior management. These roles form part of the governance framework reviewed during the licensing process.