Operating a virtual-asset business out of Dubai without the right authorisation is not a calculated risk – it is an enforcement event waiting to happen. VARA (the Virtual Assets Regulatory Authority, Dubai's dedicated crypto regulator) has made clear that the licensing perimeter it draws covers activity-by-activity, entity-by-entity, and the consequences of a misstep include suspended operations, cancelled banking relationships and reputational damage that outlasts any fine. For operators already live in the market, the question is not whether to engage the regime; it is whether the structure they built can survive scrutiny. For operators planning their entry, the question is where the legal lines are drawn – and how to stay on the right side of them.
A VARA licence application (the formal request to operate a regulated virtual-asset activity in mainland Dubai under the VARA regime) is not a single instrument. VARA regulates by activity: advisory, broker-dealer, custody, exchange, lending, management and transfer/settlement each carry their own rulebook, their own capital expectations and their own conduct obligations. The cross-border reality compounds this: an entity incorporated outside Dubai but serving Dubai-based users, or an entity incorporated in Dubai but sourcing liquidity from foreign venues, sits in a regulatory grey zone that VARA's rulebooks address directly – and that many operators underestimate.
This analysis walks through the regulatory perimeter, the activity-based licence map, the application process as VARA currently administers it, the cross-border interactions that most commonly create legal exposure, and the structural decisions that determine whether an application succeeds or stalls. A decision matrix closes the body before the FAQ.
What Does the VARA Regulatory Perimeter Actually Cover?
The VARA regime covers any entity conducting a regulated virtual-asset activity in or from mainland Dubai. The word "mainland" matters: VARA's authority does not extend inside the DIFC, which is a separate financial free zone with its own regulator. An operator with a DIFC entity conducting the same activities falls under DFSA rules, not VARA. This geographic split is one of the first structural decisions a Dubai-bound operator must make, and it has material consequences for licence scope, regulatory cost and the banking universe available.
Within the mainland perimeter, VARA has issued separate rulebooks for each regulated activity. The coverage is deliberately wide. It reaches entities that are incorporated in the UAE and operate globally, and it reaches entities incorporated outside the UAE that solicit or serve users within the emirate. The territorial hook is the activity, not the corporate seat. In our practice, we regularly encounter operators who assumed that a foreign parent licence – whether a MAS Digital Payment Token licence, an FCA cryptoasset registration or a MiCA CASP authorisation – would cover their Dubai-facing book. It does not. VARA applies its own threshold test independently of what a foreign regulator has authorised.
The VARA regime also distinguishes between a VASP (virtual asset service provider, the entity-level classification) and the specific activity licences that entity must hold. Holding VASP status alone does not permit any particular activity; each regulated function requires its own approval within the VASP framework. This layered structure is a frequent source of application errors.
To map your entity's exposure against the VARA perimeter and identify the minimum licence set for your operating model, contact OBOLUS at info@oboluslaw.com. The analysis above describes the standard perimeter. Your entity structure, user base geography and product mix change the conclusion.
How Does the Activity-Based Licence Map Work Under VARA?
VARA issues activity-specific licences, and an operator running more than one regulated function must hold the corresponding approval for each. The seven regulated activities – advisory services, broker-dealer services, custody services, exchange services, lending and borrowing services, virtual-asset management services, and transfer and settlement services – each carry a dedicated rulebook that sets out conduct standards, capital expectations, technology requirements and AML/CFT obligations.
The practical consequence is that a business running a spot exchange alongside a custodial wallet and an OTC desk will need three separate activity approvals, each governed by its own rulebook. The capital and operational requirements stack accordingly. Operators who have modelled the cost of a single "exchange licence" and discovered mid-application that their business model attracts two additional activity categories are a recurring pattern in our experience. Repricing the licence stack at that stage is disruptive to both timelines and capital planning.
Two activity categories deserve particular attention in the cross-border context. First, custody services under VARA cover any arrangement by which an entity holds, stores or safeguards virtual assets on behalf of another person. The definition is broad enough to capture arrangements that many operators describe internally as "technical" or "non-custodial" – and VARA's analysis turns on economic substance, not the label in the user agreement. Second, transfer and settlement services engage the FATF Travel Rule (the obligation to pass originator and beneficiary data alongside a virtual-asset transfer), which VARA has incorporated into its AML/CFT rulebook. Operators crossing the applicable threshold must have a compliant Travel Rule solution operational before going live, not at some later compliance milestone.
What Does the VARA Application Process Involve in Practice?
A VARA licence application is a multi-stage process that runs from initial registration through to final activity approval, with VARA conducting substantive review at each gate. The process is not a box-ticking exercise; VARA's review team interrogates business model documentation, governance arrangements, AML/CFT frameworks and technology architecture in detail. Applications that arrive without a completed policy suite, without demonstrated AML officer appointments or without coherent answers to the cross-border questions VARA routinely raises are deferred or returned – adding weeks to a timeline that is already measured in months rather than days.
The broad stages are: entity establishment and initial registration with VARA; submission of the minimum viable application package (business plan, governance documents, AML/CFT policies, technology assessment, capital evidence); VARA review and queries; conditional in-principle approval; operational buildout to meet conditions; and final licence issuance. Each stage can generate multiple rounds of query and response. The timeline from initial filing to final approval varies by activity category and application quality. In our practice, well-prepared applications for a single regulated activity have completed the process in a matter of months; complex multi-activity applications, or those that required material restructuring during review, have taken considerably longer.
A recurring mistake at the application stage is treating the business plan as a marketing document rather than a legal instrument. VARA reads the business plan as a commitment: the services described, the user categories served and the geographies covered define the scope of the licence. Operators who describe a narrower model to simplify the application, then expand after licensing, face a material change notification process that amounts to a partial re-application. Front-loading scope accuracy – even where it makes the initial application more complex – is almost always the better approach.
In a recent matter, a financial technology business with an existing Payment Services Act licence from MAS sought to establish a Dubai exchange. The business assumed its Singapore compliance infrastructure would largely transfer. VARA's requirements diverged on several points: the AML/CFT policy structure, the governance documentation format and the technology-risk attestation process all required material reworking. We assisted in mapping the delta between the MAS framework and the VARA rulebook, restructuring the policy suite accordingly and presenting a coherent cross-border group compliance narrative to the regulator. The application reached conditional in-principle approval in the same quarter.
Where Does Cross-Border Activity Create Legal Exposure Under VARA?
The VARA regime does not operate in isolation, and the cross-border dimension is where the most consequential legal mismatches arise for international operators. Three vectors account for the majority of the exposures we work through with clients.
The first is the MiCA passporting asymmetry. A CASP authorisation (the Crypto-Asset Service Provider licence issued under MiCA, the EU Markets in Crypto-Assets Regulation, which allows passporting across all EU/EEA member states) creates no rights whatsoever in Dubai. Conversely, a VARA licence creates no EU passporting rights. An operator serving both EU-resident and UAE-resident clients from a single entity needs both sets of authorisations, or a group structure that clearly separates the client populations. The regulatory cost of the dual-licence model is material; the regulatory cost of the wrong structure is potentially existential.
The second vector is the banking interaction. UAE correspondent banking for virtual-asset businesses is a studied subject in its own right. Banks in the UAE conduct their own due diligence on VARA-licensed entities that goes beyond the licence itself: they assess the AML/CFT framework, the client base geography, the stablecoin or token types handled and the cross-border transfer volumes. Operators who obtain a VARA licence but cannot open a UAE bank account are effectively non-operational. In our experience, the banking assessment should run in parallel with the VARA application – not after it.
The third vector is the group entity question. Many operators use a Dubai entity as the regulated face of a global group, with trading infrastructure, technology and treasury held elsewhere. VARA's rulebooks address intra-group arrangements explicitly: outsourcing to group entities requires notification and, in some cases, approval; and the Dubai entity must demonstrate that it has real decision-making authority and is not a shell pointing at a foreign parent. Regulators in the leading hubs increasingly expect genuine substance – physical presence, senior staff in-jurisdiction, and a management body that actually governs the Dubai book.
If your structure spans two or more regulatory regimes, the interaction risks compound quickly. Map the full licence, banking and tax stack before you commit – write to info@oboluslaw.com.
What Are the Most Common Mistakes in a VARA Licence Application?
Most VARA application failures are not failures of intent; they are failures of preparation, and they cluster around predictable categories. Understanding where applications break down is essential for any operator entering the process.
Scope miscalibration is the single most frequent problem. An application that describes a narrower product than the operator actually intends to run creates two failure modes: the licence, when issued, does not cover the intended business; or VARA identifies the mismatch during review and requires the applicant to expand scope mid-process – resetting timelines and capital calculations. The solution is a rigorous product-to-activity mapping exercise before any documentation is prepared.
AML/CFT policy deficiency is a close second. VARA's AML/CFT rulebook is detailed and reflects the FATF Recommendations, including the Travel Rule provisions under Recommendation 15. Applications that arrive with a generic AML policy borrowed from a banking or payments context – rather than one calibrated to virtual-asset activity, Dubai-specific risk factors and the Travel Rule threshold – rarely pass VARA's first substantive review. The AML officer appointment, the enhanced due diligence triggers for virtual-asset-specific risks and the transaction-monitoring methodology must all be documented and credible.
Technology-risk attestation is a third area where applications regularly stall. VARA requires operators to demonstrate that their technology architecture is fit for purpose, that cybersecurity controls meet the relevant standards and that key management practices for custodial activities are appropriately robust. Many operators, particularly those scaling from a startup context, have not had their technology formally assessed to the standard VARA expects. Commissioning that assessment after the application is filed – rather than before – adds delay and occasionally surfaces issues that require architectural changes.
Finally, governance documentation is consistently underweighted. VARA expects to see a clearly constituted board or management body, defined roles for compliance and risk functions, documented escalation procedures and – for larger or more complex businesses – an independent audit pathway. Applications from entities that have never operated in a formally regulated environment often arrive with governance documentation that looks appropriate from a corporate law perspective but does not satisfy a financial regulator's expectations.
Contrasting Positions: How Wide Is VARA's Regulatory Net?
There are two genuinely contested interpretive questions in the VARA regime that shape application strategy for a significant number of operators. Neither has been definitively resolved in published regulatory guidance, and reasonable practitioners take different positions.
The first concerns the definition of "exchange services." VARA's activity definition covers the operation of a platform that facilitates the buying or selling of virtual assets. Operators running a peer-to-peer aggregator, an OTC matching service or a decentralised-protocol interface argue that their model does not squarely fit the exchange-services definition because they do not hold client assets, do not set prices and do not act as counterparty. VARA's position, to the extent it has been articulated, leans toward substance over form: if the economic function of the service is to facilitate exchange, the activity label applies regardless of the technical architecture. Operators in this space should assume a conservative reading until there is clear regulatory guidance to the contrary.
The second concerns the territorial scope of "advisory services." An entity incorporated in a jurisdiction outside Dubai that provides investment analysis or advisory services relating to virtual assets to UAE-resident clients may be within scope of VARA's advisory-services licence. The question is whether solicitation or provision of service to a UAE resident triggers VARA jurisdiction even where the entity has no physical presence in the UAE. The analogous question under MiCA – where reverse solicitation doctrine is a live debate – has a parallel in the VARA context, though the doctrine has not been clearly codified in the VARA rulebooks. The prudent position, in our view, is to assume that recurring provision of advisory services to UAE-resident clients triggers a licensing obligation, and to structure accordingly.
Decision Matrix: Which Operator Profile Needs What Licence Structure?
Not every operator entering the VARA regime faces the same licence stack. The structure that makes sense for a well-capitalised institutional exchange differs materially from the structure appropriate for a boutique asset manager or a payments infrastructure provider. The following matrix describes the relevant decision branches in prose rather than as a table, because the right answer for any given operator depends on fact-specific analysis that a grid cannot capture.
Profile A – Spot exchange with custody: An operator running a spot trading platform that also holds client assets in a custodial wallet service needs at minimum exchange-services and custody-services approvals. The capital requirements and conduct obligations for the custody activity are the more onerous of the two in terms of operational infrastructure. The Travel Rule obligation is engaged on the transfer side of any withdrawal flow. Timeline: a well-prepared multi-activity application of this type is a multi-month process; operators should plan their banking and technology buildout to run concurrently with the application, not sequentially.
Profile B – OTC broker and advisory desk: An operator running an over-the-counter brokerage desk alongside an advisory function for institutional clients needs broker-dealer and advisory-services approvals. If the OTC desk facilitates client-to-client matching rather than acting as principal, the exchange-services analysis is live. The advisory component must be carefully scoped against the investment services that would pull the business into the securities regulatory perimeter – in Dubai, through the SCA – rather than exclusively under VARA. The cross-border risk here is that institutional clients seated in the EU may pull in MiCA obligations simultaneously.
Profile C – Virtual asset fund manager: An operator managing a fund or discretionary portfolio with virtual-asset exposure needs virtual-asset management services approval from VARA. If the fund is also structured as a regulated vehicle in another jurisdiction – the Cayman Islands under CIMA, or the ADGM under FSRA – the group structure must be designed so that each regulated entity's scope is clear and there is no unintended triggering of additional activity licences in either jurisdiction. The management-services rulebook imposes obligations on governance, disclosure and AML/CFT that sit alongside, and must be reconciled with, the fund jurisdiction's own requirements.
Profile D – Payments and remittance corridor: An operator using virtual assets as a settlement rail for a cross-border payments corridor needs transfer-and-settlement-services approval and must have a FATF-compliant Travel Rule solution operational from day one. The banking interaction is critical: correspondent banks on the fiat legs of the corridor will scrutinize the VARA licence, the AML/CFT framework and the counterparty due diligence process in detail. An operator in this profile should expect the banking onboarding to be as demanding as the VARA application itself.
A Common Assumption: One Offshore Licence Covers Global Operations
A common assumption among operators we encounter at the structuring stage is that a single licence in a permissive jurisdiction – a BVI VASP registration, a Cayman Islands registration under CIMA, or an early-EU registration from the pre-MiCA period – provides sufficient cover to serve clients in any market, including Dubai. This assumption does not survive contact with VARA's territorial scope rules.
VARA assesses whether a regulated activity is being conducted "in or from" mainland Dubai. An entity incorporated in the BVI that directs marketing at Dubai residents, onboards Dubai-resident clients and provides services consumed in Dubai is, on VARA's analysis, conducting activity within its perimeter – regardless of where the corporate seat is. The offshore licence does not satisfy VARA's requirement. It may, in fact, make the compliance conversation harder: an operator who has structured deliberately offshore to avoid licensing obligations in the jurisdictions where its clients are located faces a credibility problem with any regulator reviewing the group structure.
The same logic applies in reverse. A VARA licence does not authorise the provision of services to EU residents under MiCA, to Singapore residents under the MAS Payment Services Act, or to UK residents under the FCA's MLR registration and financial-promotion regime. The licence stack must reflect the actual geography of the client base. We map the full multi-jurisdiction exposure as a starting point in every licensing engagement – precisely because the single-licence assumption creates the enforcement and banking risks that most commonly drive operators to seek counsel after the fact rather than before.
Related at OBOLUS
- Licensing and Registration for Digital Asset Businesses – how we scope and execute multi-jurisdiction licence stacks for operators
- VARA Licence Application in France – AMF/PSAN – the French AMF/PSAN pathway and how it interacts with the MiCA transition
- Digital Asset Counsel for Venture Funds – licensing, structuring and compliance considerations for VC and institutional investors with digital-asset exposure
If a prior VARA application stalled or your banking rails were closed after a regulatory review, a structural re-read can identify the fault line. Contact OBOLUS at info@oboluslaw.com. We have seen this pattern often enough to move quickly from diagnosis to a remediation plan.
FAQ
How long does a crypto licence take to obtain?
Timeline varies substantially by jurisdiction, activity category and application quality. Under the VARA regime in Dubai, a well-prepared single-activity application is typically a matter of months from initial filing to final approval; multi-activity applications or those requiring material restructuring during review take longer. Under MiCA in the EU, the CASP authorisation timeline is governed by the regulation but depends on NCA processing capacity in the chosen member state. Operators should plan banking and technology buildout to run concurrently with the application, not after it.
Which jurisdiction is best for licensing my crypto business?
There is no universally correct answer. The right jurisdiction depends on the activity type, the geography of the client base, the banking relationships needed, the capital available and the group's tax posture. Dubai under VARA suits operators focused on the MENA market and institutional clients. EU licensing under MiCA suits those needing EU passporting. Singapore under MAS suits businesses with an Asia-Pacific orientation. A single offshore registration is not a substitute for jurisdiction-specific licensing where the client population is located. We map the full decision matrix before recommending a structure.
Do I need a separate custody licence?
Under VARA, custody services are a separately licensed activity. If your business model involves holding, storing or safeguarding virtual assets on behalf of clients – including arrangements that your user agreement describes as technical or non-custodial – VARA's analysis may nonetheless classify the function as a custody service requiring its own approval. The same activity-specific logic applies under MiCA, MAS and the SFC regime in Hong Kong. Whether a custody licence is required turns on the economic substance of the arrangement, not the label applied to it in documentation.
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 – so the structure you build is the structure that survives regulatory review. We also work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications when recovery matters arise. To discuss your situation, contact info@oboluslaw.com.
By Lydia Brennan, Tax & Structuring Analyst – specialising in multi-jurisdiction licence and tax structuring for digital-asset businesses, including VARA applications and cross-border compliance stack design.
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.