VARA Licence Application for Established Operators

Operating a digital-asset business in Dubai without the right authorisation is no longer a calculated risk – it is an enforcement event waiting to happen. The Virtual Assets Regulatory Authority (VARA), Dubai's dedicated crypto regulator, requires operators across advisory, exchange, custody, lending and other activity classes to hold a valid VARA licence before serving clients from or into the emirate. For established operators – businesses already generating revenue, holding client assets or running live infrastructure – the application is not merely administrative. It is a structural review of your entity, your governance and your cross-border footprint. This page explains the regulated basis, the application process, the common mistakes operators make at each stage, and how OBOLUS maps the licence stack before you commit capital.

The VARA Regime: What It Actually Covers

VARA's jurisdiction is broader than most operators expect on first encounter. The authority regulates a defined set of virtual asset activities in mainland Dubai – expressly excluding the DIFC financial free zone, which runs its own regime – and its activity-based rulebooks apply to each service line independently. An operator running an exchange, a lending desk and a custody function does not hold one general licence; it holds one entity authorisation with the specific activities approved within it, each carrying its own capital expectation, conduct obligation and reporting cycle.

The activity categories under the VARA regime include exchange services, broker-dealer services, advisory services, custody services, lending and borrowing services, virtual asset management and investment services, and transfer and settlement services. Each sits under a dedicated VARA rulebook, and the rulebooks are detailed. They address governance structure, technology and security requirements, AML and Travel Rule (the obligation to pass originator and beneficiary data with a virtual asset transfer) compliance, and market-conduct standards. For an established operator migrating from a lighter regime, the substantive lift is significant.

The cross-border dimension matters immediately. VARA's perimeter captures activity directed at UAE residents, not merely entities incorporated in Dubai. An operator based in Europe or Asia that onboards UAE-resident clients through a web platform is inside scope. We regularly advise operators who discover this exposure well after go-live – the structural correction is easier before VARA's supervision team identifies the issue itself.

Who Qualifies as an Established Operator – and Why It Matters

VARA draws a material distinction between a startup seeking first authorisation and an established business seeking to regularise or expand an existing operation. Established operators typically present a different risk profile: they hold client assets, have transaction history, run live technology and often carry legacy compliance gaps inherited from prior regimes or offshore registrations. That profile changes both the documentation burden and VARA's supervisory posture during the review.

In our practice, established operators fall into three broad categories. First, operators already licensed under an earlier Dubai Virtual Asset regime or a mainland UAE framework who must transition to the current VARA structure. Second, operators licensed in another jurisdiction – Singapore's Payment Services Act regime, the EU's CASP (Crypto-Asset Service Provider) authorisation under MiCA, or the FCA's cryptoasset registration in the UK – who are adding Dubai as an operational hub. Third, operators who have been running in Dubai under a provisional arrangement or an informal structure and who now need to formalise.

Each category carries a distinct document set and a distinct regulatory conversation. VARA's review of a transitioning operator focuses on continuity of AML controls and governance. Its review of an inbound operator compares the applicant's existing compliance architecture against the VARA rulebook standard. Its review of an operator seeking to regularise an informal structure is the most sensitive: it is effectively a supervised self-disclosure, and the sequencing of that disclosure is critical.

The process above describes the standard path. Your facts – the entity structure, the user base, the banking relationships and the prior regulatory history – change the analysis materially. For a scoped assessment of your position under the VARA regime, contact OBOLUS at info@oboluslaw.com or map your options here.

How Does the VARA Application Process Work for Established Operators?

A VARA licence application for an established operator runs in distinct phases, and the sequencing of each phase is not optional – VARA's process is structured, and submissions that arrive out of sequence are typically rejected or held pending correction.

Phase one is pre-application scoping. Before submitting, the operator must confirm its legal entity in Dubai – either a mainland entity or, for certain structures, a free-zone entity with the appropriate approvals – and map the specific activities it intends to conduct against VARA's activity categories. This mapping determines which rulebooks apply and which capital expectations the applicant must satisfy. For an established operator with multiple service lines, this exercise often reveals that the intended scope requires more than one activity designation, each with its own governance overlay.

Phase two is document assembly. The VARA application package is substantial. It covers corporate structure and ownership chain (including ultimate beneficial owner disclosures to the required threshold), audited financial statements, a detailed business plan with financial projections, technology and security documentation, AML/CFT policies and procedures, governance documents covering the board and senior management, and fit-and-proper evidence for all key individuals. For an established operator, live transaction data and existing AML records will also be reviewed. Any gap in the AML or governance documentation at this stage does not merely delay the application – it signals to VARA that the operator's compliance culture requires remediation.

Phase three is submission and VARA review. VARA's supervisory team reviews the file and, in most cases, issues clarification requests. The responsiveness and quality of those responses materially affect the timeline. Operators who treat clarification requests as administrative formalities and provide incomplete answers routinely experience extended review cycles. In our experience advising on regulated submissions, the operators who move fastest through review are those who have pre-answered the likely questions in the original file.

Phase four is approval in principle, satisfaction of conditions (which may include capital deposit, technology audit sign-off or appointment of a compliance officer), and issuance of the licence. Post-issuance, the VARA supervision relationship begins – ongoing reporting, conduct obligations and the expectation of regulatory engagement on material changes to the business.

Common Mistakes Established Operators Make at Each Stage

The most expensive VARA application errors are structural, not procedural. They cannot be corrected with an amended submission; they require restructuring the business before reapplication.

The first and most common mistake is misidentifying the activity scope. An operator that maps its business to a narrower activity category than its actual operations – for example, classifying a lending desk as incidental to an exchange service – will either be required to amend the application mid-review or, worse, discover the gap during a post-licence supervision exercise. VARA's rulebooks are granular. An activity that is not expressly covered by the approved scope is an unlicensed activity.

The second mistake is submitting an AML framework built for a different regime without adapting it to VARA's specific requirements. VARA applies the Financial Action Task Force (FATF) Recommendation 15 standards and the Travel Rule obligations, but its own rulebook adds conduct and technology expectations that a generic AML policy does not address. A policy imported from a MiCA CASP application or an FCA registration, without jurisdictional adaptation, will generate clarification requests – and may raise questions about whether the operator genuinely understands the Dubai market.

The third mistake is underestimating the fit-and-proper review. VARA assesses not just formal qualifications but the regulatory history of senior individuals across all jurisdictions where they have held roles. An individual who held a role at an entity that was sanctioned, refused or suspended in another jurisdiction – even in a capacity that was not directly responsible for the compliance failure – must be prepared to address that history. Operators who fail to surface and explain those histories in the application routinely face the most prolonged reviews.

The fourth mistake is treating the governance documents as a formality. VARA expects to see a genuine governance structure – a board or equivalent body with real authority, clear escalation paths, and documented decision-making processes. Governance documents that are clearly templated or that describe structures inconsistent with the actual operation of the business are a significant red flag in review.

Cross-Border Angles: Operating Under VARA Alongside Other Regimes

A VARA licence does not operate in isolation for most established operators. The Dubai entity typically sits within a multi-entity structure that includes an EU-licensed CASP, a Singapore DPT licensee under the MAS Payment Services Act, a Cayman or BVI holding vehicle, or some combination. Each layer carries its own compliance obligation, and the interactions between regimes create complexity that a single-jurisdiction analysis misses.

The most common interaction we see is between VARA and the EU MiCA regime. MiCA requires a CASP authorisation for operators serving EU/EEA clients, regardless of where the operator's servers or entity sits. An operator with a VARA licence and EU clients either needs a MiCA CASP or must ensure its EU operations are structured so that the EU-facing activity is carried on by the MiCA-licensed entity and not by the Dubai vehicle. Getting this wrong generates dual exposure: VARA for the Dubai-side activity and the relevant EU national competent authority for the EU-side.

The banking interaction is equally material. Dubai-based virtual asset businesses report that banking access varies significantly by activity category and by the operator's AML posture. Operators who arrive at the bank with a VARA licence but without a well-documented AML framework and a clear narrative about their client base routinely find that the licence alone does not open the account. In our cross-border practice, we address banking in parallel with the licence application – the banking narrative is built into the business plan, not appended after the fact.

Tax structuring is a third cross-border lever. The UAE's corporate tax regime and the absence of personal income tax in Dubai make the jurisdiction commercially attractive. But an operator with entities in multiple jurisdictions must assess transfer pricing, permanent establishment risk and substance requirements in each operating location. A VARA licence that is not supported by genuine economic substance in Dubai creates exposure in other jurisdictions that may assert taxing rights over Dubai-sourced income.

Decision Matrix: Which VARA Activity Profile Fits Your Business?

Not every established operator needs the full VARA activity suite from day one. The activity authorisation should match the near-term business plan, with a variation process available as the business scales. The choice of initial scope is a strategic decision, not just a compliance one.

Profile A – Pure exchange operator: An operator running a centralized trading platform for retail and institutional clients needs exchange-service authorisation as the core designation. The governance, technology and capital expectations for this category are the most demanding in the VARA regime. The timeline to authorisation, absent major gaps in the file, is measured in months rather than weeks. The key risk at application stage is technology documentation – VARA's expectations for platform security, custody of client assets and system resilience are detailed.

Profile B – Custody-first operator: A digital-asset custodian seeking to serve institutional clients in the Gulf needs custody-service authorisation. Capital and safeguarding expectations are the primary focus. Operators entering this category typically have the most mature compliance architecture but face the most scrutiny on technology – specifically, key management and cold-storage protocols. The cross-border note is that custody in Dubai for non-UAE-resident clients still triggers the VARA scope, so the entity and client-base mapping must be precise.

Profile C – Advisory and management: An operator providing investment advisory or portfolio management services in virtual assets needs the relevant advisory or management authorisation. This category typically has lighter capital requirements than exchange or custody, but the conduct and conflicts-of-interest obligations under the VARA rulebook are substantive. The key risk is scope creep – advisory relationships that drift into discretionary execution without the exchange or broker-dealer authorisation in place.

Profile D – Multi-activity operator: An established operator running exchange, custody and advisory services in a single entity needs to designate all three activities. This is the most complex application and the one most likely to generate extended review cycles. For this profile, pre-submission engagement with VARA – where available – is strongly advisable, and the business plan must demonstrate that the governance structure can manage the conduct obligations across all three lines.

In a recent licensing matter, a payments business with existing MAS oversight sought to add a Dubai entity for its Gulf client base. The initial scope mapping showed that the intended Dubai activity crossed three VARA activity categories. We restructured the application to lead with the exchange designation, addressed the custody element through a separate subsidiary, and aligned the AML documentation to both the VARA and MAS frameworks simultaneously. The operator moved from scoping to submission in a defined window, without restating the application mid-review.

If a prior VARA application stalled, or an application is under active review and generating repeated clarification requests, a second read of the file can surface the structural reason and the route forward. Write to us at info@oboluslaw.com or map your options here.

What Does VARA Expect After Authorisation?

A VARA licence is not a certificate – it is the start of a supervised relationship. Post-authorisation obligations are substantial, and operators who treat the licence as the endpoint rather than the starting point find themselves in remediation conversations within the first supervision cycle.

VARA requires ongoing regulatory reporting, including periodic financial and operational returns. Material changes to the business – new activity lines, changes to senior personnel, significant technology changes, changes to the ownership structure – require prior notification or approval. The Travel Rule obligation is live from authorisation: operators must have technical infrastructure in place to pass originator and beneficiary information with virtual asset transfers above the applicable threshold, and VARA's supervision team will test this in practice.

AML obligations do not diminish post-authorisation. The VARA rulebook requires annual AML risk assessments, ongoing transaction monitoring calibrated to the operator's actual client and transaction profile, and Suspicious Transaction Report filing with the UAE's Financial Intelligence Unit where required. Operators who build their AML framework for the application and then allow it to drift will face regulatory consequences at the first supervision review.

Governance obligations are equally persistent. The board or equivalent governance body must be active, documented and demonstrably engaged with compliance matters. VARA's supervisory engagement is not limited to written returns – the authority expects to be able to speak with senior management and to receive coherent answers about the business. Operators without a genuine governance structure in Dubai – those running the Dubai entity as a letterbox for a parent company's decisions – will struggle in these conversations.

A Common Assumption: One Offshore Licence Is Enough

A common assumption among operators building a global digital-asset business is that a single well-regarded offshore registration – a BVI VASP Act registration or a Cayman CIMA licence – is sufficient to serve clients across markets, including the UAE. That assumption does not survive contact with the actual regulatory position.

VARA's jurisdiction is triggered by activity, not entity location. Serving UAE-resident clients from an offshore entity is within VARA's regulatory perimeter. An operator that relies on an offshore licence to cover its UAE-facing activity is not unlicensed in the jurisdiction of the offshore entity – it is unlicensed in Dubai. The consequences range from enforcement action to prohibition orders to personal liability for the individuals directing the business.

The same logic applies in the opposite direction. A VARA licence covers the activities authorized within its scope, in Dubai. It does not authorize the operator to serve EU clients who need a MiCA CASP, or Singapore clients who need an MAS DPT licence, or UK clients who need FCA registration. Each market has its own perimeter. We map the full licence stack across operating, custody and payment layers before operators commit capital to a structure, because the cost of restructuring after go-live is always higher than the cost of getting the architecture right at the outset.

Related at OBOLUS:

• Licensing and Registration for Digital-Asset Businesses – the full cross-jurisdictional licensing practice at OBOLUS, covering 70+ jurisdictions
• Licence Renewal and Variation: The Compliance Burden in Practice – what happens after authorisation, and how to manage the ongoing regulatory burden
• VARA Licence Application for Regulated Entities – the parallel OBOLUS service page for entities already holding a financial-services authorisation in another jurisdiction

FAQ

How long does a crypto licence take to obtain?

Timeline varies significantly by jurisdiction and by the completeness of the application file. Under the VARA regime, a well-prepared application with no material gaps typically moves through review in a period measured in months rather than weeks. Incomplete files, gaps in AML documentation or fit-and-proper issues with key individuals can extend the process considerably. For MiCA CASP authorisations in the EU, timelines also vary by member state and by the volume of applications the national competent authority is managing. In our practice, the single most reliable way to compress the timeline is to pre-answer VARA's likely clarification questions in the original submission.

Which jurisdiction is best for licensing my crypto business?

There is no universally correct answer – the right jurisdiction depends on where your clients are, where your banking is, what activities you run and what your tax and ownership structure looks like. Dubai under VARA suits operators serving Gulf institutional and retail markets who want a well-developed crypto-specific regime. Singapore under MAS suits operators serving Asian institutional clients. EU MiCA CASP authorisation suits operators needing passporting across the EU/EEA. Operators with global client bases typically need a combination of licences, not a single registration. We map that stack before you commit to a structure.

Do I need a separate custody licence?

Under the VARA regime, custody is a distinct activity designation with its own rulebook, capital expectations and conduct obligations. An operator authorised only for exchange services that holds client private keys – even temporarily, as part of the settlement process – is conducting a custody activity without the requisite authorisation. The same separation applies in most flagship jurisdictions: MAS, MiCA and the FCA all treat custody as a regulated activity in its own right. Whether a separate legal entity is required for custody, or whether a single entity can carry multiple activity designations, is a structural question that depends on your group architecture and the specific requirements of each applicable regime.

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. Operators who engage us on VARA applications typically come with an existing structure and a live business – we map the licence, banking and compliance stack before they commit capital, not after. To discuss your VARA application or your broader licence architecture, contact info@oboluslaw.com or message us at t.me/oboluslaw. Map your options here.

By Aisha Tan, Licensing & Jurisdictions Analyst – specialising in VARA, MiCA and MAS licensing applications and cross-border licence-stack architecture for established digital-asset operators.

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.