VARA Licence Application from a Cross-border Perspective

A payments company expanding into the UAE once assumed its existing EU authorisation would smooth the path to a Dubai operating licence. It did not. The Virtual Assets Regulatory Authority (VARA) — Dubai's purpose-built regulator for virtual assets — operates an activity-based regime that requires separate authorisation for each regulated function, regardless of what the applicant holds elsewhere. The cross-border question is not merely which licence you need. It is how the VARA regime sits alongside the entity structure, the banking relationships, the user-base geography and any other regulated licences in the stack. That analysis is where applications succeed or stall.

A VARA licence (a Virtual Assets Regulatory Authority authorisation issued under Dubai's virtual-asset regulatory regime) is the operating permission for virtual-asset businesses operating in mainland Dubai. It is activity-specific, not entity-specific: a business conducting exchange, custody and advisory functions requires separate VARA approval for each. This page explains the regulated basis, the application process, the cross-border interactions and the structural decisions that determine whether an application moves or stalls.

The sections below cover the regulatory perimeter, the activity map, the process, cross-border interaction points, common structural mistakes, a decision matrix by operator profile and a self-assessment checklist. A mid-page micro-matter illustrates how these variables interact in practice.

What Activities Does VARA Regulate — and Who Is Caught?

VARA's jurisdiction covers any entity conducting virtual-asset activities within or from mainland Dubai — including operators that may be incorporated elsewhere but provide services into the Dubai market or operate infrastructure from within it. The regime is activity-based, not entity-based. That distinction matters immediately for any cross-border operator.

The regulated activity categories under the VARA regime include advisory services, broker-dealer services, custody services, exchange services, lending and borrowing services, payment and remittance services, and management and investment services for virtual assets. An operator running a combined exchange and custody function requires distinct VARA approval — and distinct compliance infrastructure — for each. Running those activities from a single legal entity without disaggregating the licence obligations is one of the most common structural errors we see at the pre-application stage.

VARA's jurisdiction covers mainland Dubai, not the DIFC financial free zone. Operators structured in the DIFC operate under the DIFC's own regulatory authority. A business that wants to serve both the mainland Dubai market and DIFC-based counterparties will often need to consider both regimes simultaneously, which has structural and capital implications that the application itself does not resolve.

The threshold question for any inbound operator is not "do we need a licence?" — in almost every case, conducting virtual-asset activities from or within Dubai answers that question in the affirmative. The real threshold question is which activities are in scope on day one, which are planned for a later phase, and whether the entity structure supports the licence architecture that results.

How Does the VARA Application Process Work?

The VARA application follows a structured multi-stage process: an initial market-engagement phase, a formal application submission, a regulatory review and queries period, a minimum-viable-product assessment for active operators, and a final full-market-product authorisation for businesses at scale. Not every applicant progresses through all stages on the same timeline, and the regulator's responsiveness varies with the completeness and quality of the initial submission.

The documentary requirements are substantial. VARA expects detailed business-model documentation covering the applicant's technology infrastructure, governance arrangements, AML and CFT policies, cybersecurity posture, custody and segregation approach and risk management framework. For cross-border applicants, the regulator will also look at the applicant's relationship to its parent group, the jurisdictions in which group entities hold other regulated licences, and the flow of client assets and data across the group.

Applicants that have already obtained a CASP authorisation (a Crypto-Asset Service Provider authorisation under the EU's MiCA regime) or a comparable authorisation from a recognised regulator in another major hub typically find that the governance and compliance documentation they prepared for that authorisation provides a useful scaffold for the VARA submission. The regimes differ in important respects, but a well-prepared applicant from a MiCA-aligned jurisdiction carries demonstrable regulatory maturity that the VARA review team considers. That said, the documentation is not transferable: VARA has its own rulebooks, its own technology requirements and its own disclosure expectations, and each must be addressed on its own terms.

Timeline from initial submission to authorisation varies considerably by activity category and application quality. In our practice, we have seen straightforward single-activity applications progress materially faster than complex multi-activity or group-restructuring submissions. Operators who engage with the process expecting a fixed statutory clock are routinely surprised: the clock runs from a complete submission, and completeness is a judgment the regulator makes.

CTA — for the reader encountering VARA for the first time: The process above describes the standard path. Your facts — the entity, the user base, the banking arrangement, the activity scope — change the analysis. For a scoped assessment of your VARA readiness before you commit to the application process, contact OBOLUS at info@oboluslaw.com. Or map your options with our licensing team.

What Cross-border Issues Affect a VARA Application Most?

The VARA regime does not exist in isolation. For any business operating across jurisdictions — serving users in Europe, Asia or the Americas while operating infrastructure or holding client assets in Dubai — the VARA licence is one layer of a multi-jurisdiction regulatory stack, and the interactions between layers create the real risk.

Three cross-border pressure points consistently emerge in our advisory work. First, entity structure. VARA expects the licensed entity to have genuine operational substance in Dubai — governance, key personnel, infrastructure and decision-making. A brass-plate entity holding the licence while the real business sits offshore will not satisfy the regulator, and it will not satisfy correspondent banks assessing the group. Second, banking. Dubai-licensed virtual-asset businesses can access banking in the UAE, but the relationship between the VARA licence, the licensed entity's activities and the bank's own compliance expectations must be managed proactively. Group banking arrangements that route client funds through entities in other jurisdictions require careful mapping before the application is filed — not after the account is rejected.

Third, user-base geography. A VARA licence authorises activity within and from Dubai. It does not, of itself, authorise the operator to serve users in the EU, Singapore, Hong Kong or the United Kingdom. Operators who build a Dubai-licensed entity as their global operating vehicle without overlaying the licence requirements of their user-base jurisdictions face enforcement risk in those markets. The single-licence assumption — the belief that one strong offshore authorisation covers all client activity — is addressed directly in the decision matrix below.

The Travel Rule (the obligation to pass originator and beneficiary data with a virtual-asset transfer, aligned to FATF Recommendation 15) applies under the VARA regime as it does across the major hubs. For a cross-border operator, Travel Rule compliance requires a technical solution that integrates with the operator's transaction infrastructure and that functions across the counterparty network — which frequently spans institutions in multiple jurisdictions with different data formats and threshold rules. Getting Travel Rule compliance operational before the VARA application review concludes is a practical requirement, not a post-licence aspiration.

What Are the Most Common Mistakes in VARA Applications?

The most consequential structural mistakes in VARA applications are not drafting errors — they are architecture errors made before a single document is prepared. Correcting them mid-process is expensive and often forces a restart.

The first is activity misclassification. Operators frequently frame their business model in commercial terms — "a trading platform with a wallet" — without mapping those functions to the VARA activity categories. A platform that holds client assets while facilitating trading is conducting exchange and custody services simultaneously. Applying only for an exchange licence and treating custody as incidental will produce a gap that the regulator identifies and the applicant must then resolve, either by adding a licence category or by redesigning the business model. Both options extend the timeline materially.

The second is entity and substance mismatch. Some applicants attempt to license a newly incorporated Dubai entity that shares technology infrastructure, staff and governance with a parent entity outside the UAE. VARA will probe this. The licensed entity must have demonstrable local substance — key personnel in Dubai, governance processes that genuinely operate from Dubai, and technology that is not entirely dependent on an offshore parent. Meeting this standard requires planning at the structuring stage, not as a response to VARA's questions.

The third is banking sequencing. Operators who obtain the VARA licence first and then attempt to open a bank account frequently discover that banks require the licence — but also require a relationship that satisfies the bank's own enhanced due diligence for virtual-asset clients. Beginning the banking conversation early, in parallel with the application, and understanding which banks are currently active in the Dubai VASP space is a material advantage. In our cross-border practice, we map the banking architecture as part of the pre-application assessment, not as an afterthought.

A fourth error — common in groups coming from less demanding regulatory environments — is treating VARA's compliance documentation expectations as a formality. The VARA rulebooks are detailed. AML policies, cybersecurity documentation and technology-governance frameworks must be bespoke and operational, not generic templates lifted from a compliance consultant's library. Regulators in the leading hubs increasingly expect documentation that reflects the applicant's actual systems and controls, not an idealised version of them.

A Cross-border Application in Practice

In a recent licensing matter, a fund manager with an existing licence in an Asia-Pacific hub sought to establish a Dubai operating presence to serve institutional clients in the GCC. The group had a Singapore-regulated entity and a Cayman holding structure. The initial plan was to apply for a VARA management and investment services licence from the Cayman holding company. On review, the holding company lacked the necessary Dubai substance, and VARA's activity scope for management and investment services required additional governance and reporting infrastructure that the group did not yet have. We restructured the approach: a new Dubai entity was incorporated with appropriate local governance, the Singapore entity was designated as the technology and operations provider under a documented intra-group agreement, and the application was resequenced around VARA's minimum-viable-product stage. The first activity authorisation was obtained within the regulator's typical process window, with the secondary activity categories filed in a subsequent phase aligned to the business launch schedule. The banking relationship was introduced during the application period, which meant that accounts were in place before the licence was needed operationally.

Which Operator Profile Should Pursue a VARA Licence — and How?

Not every operator is best served by a primary VARA licence. The decision depends on where the real business sits, where the users are and what other regulated permissions the group holds or needs.

Profile A: a EU-based exchange seeking GCC market access. This operator likely holds or is building a MiCA CASP authorisation for its European user base. A VARA licence for exchange services makes sense as a distinct Dubai operating entity — not a branch of the EU entity — with its own governance and capital. The MiCA compliance infrastructure provides a starting point for VARA documentation, but the two regimes are not interchangeable. Timeline and capital requirements are set by VARA independently. The primary risk is assuming the EU entity's compliance posture transfers without rework.

Profile B: an Asia-Pacific custodian expanding into the Middle East. This operator likely holds a licence under the MAS Payment Services Act regime in Singapore or the SFC VASP regime in Hong Kong. A VARA custody licence requires demonstrable Dubai substance — key personnel, local infrastructure, segregated custody architecture. The cross-border complexity here is highest: custody of client assets across multiple regulated entities creates regulatory capital, reporting and segregation obligations in each jurisdiction simultaneously. The indicative path is a VARA custody licence for Dubai-domiciled assets, held by a dedicated Dubai entity, with clear intra-group documentation governing the relationship with the Asia-Pacific parent.

Profile C: a start-up seeking a UAE base from which to build a global exchange. This profile is the most common and carries the most risk. VARA is a credible, demanding regulator. A start-up without prior regulatory experience in another jurisdiction will face a longer review period and more requests for documentation than an established operator. The business case must support a genuine Dubai substance commitment — offices, staff, compliance function. A VARA licence alone does not authorise the operator to serve users in the EU, UK, Singapore or the United States. If the business model requires serving those users, the licence architecture must include the relevant permissions in each market, and the Dubai entity's role in the global structure must be defined precisely.

CTA — for the reader who has already explored VARA and hit a structural question: If a prior assessment raised questions about entity structure, banking or activity scope that were not resolved, a second read can surface the structural reason and the route forward. To map the licence, banking and substance stack for your Dubai build, write to OBOLUS at info@oboluslaw.com. Or map your options with our team directly.

Self-assessment: Are You Ready to File a VARA Application?

Before filing, a well-prepared applicant should be able to answer each of the following questions with documented evidence rather than an intention.

On entity and substance: is the applicant entity incorporated in Dubai (mainland), and does it have local governance, key personnel in the UAE and operational infrastructure that is not wholly dependent on an offshore parent? On activity scope: have all regulated VARA activities the business intends to conduct on day one been identified and mapped to the relevant VARA activity category? On AML/CFT: is the applicant's AML and CFT framework documented at the policy, procedure and system level, with a named compliance officer and a board-approved risk appetite? On technology: has the cybersecurity and technology governance documentation been prepared to VARA's rulebook standard, not to a generic ISO template? On Travel Rule: is the Travel Rule solution identified, integrated and tested, including for cross-border transfers to and from counterparties in other jurisdictions? On banking: has a banking relationship been initiated in parallel with the application, and does the bank understand the activity scope and the client's cross-border group structure?

An applicant who cannot answer all of these questions with confidence is not yet ready to file. Filing prematurely extends the overall timeline — the regulator's completeness review identifies gaps that the applicant must then resolve, often under time pressure and with the regulatory relationship already under scrutiny.

Addressing the Single-licence Assumption

A common assumption among operators building from a non-EU base is that a single strong authorisation — VARA, or a comparable offshore licence — is sufficient to serve clients across all markets. This assumption is incorrect, and acting on it is one of the most reliably costly errors in cross-border virtual-asset business.

VARA authorises activity within and from Dubai. The MiCA regime governs crypto-asset service provision to EU clients, regardless of where the provider is incorporated. Singapore's MAS regime applies to digital-payment-token services directed at Singapore users. The FCA's financial-promotion rules govern marketing of cryptoassets to UK persons. Each regime has its own trigger — often the location of the user, not the location of the operator — and its own enforcement toolkit.

In our cross-border practice, we regularly advise operators who have obtained a VARA licence and then discovered that their user-base geography requires a MiCA CASP authorisation, a Singapore DPT licence, or FCA registration — sometimes all three simultaneously. The discovery typically arrives via a banking rejection or a regulatory inquiry rather than proactive counsel. The time and cost of retrofitting a multi-jurisdiction licence architecture onto an operating business are significantly greater than building it in at the structuring stage.

The answer is not to delay the VARA application. It is to begin the VARA process with a clear picture of the global licence stack the business will eventually need, and to sequence the applications and entity structure to support that stack from the outset.

Related at OBOLUS

• Licensing & Registration for Digital-Asset Businesses – our full practice overview across 70+ licensing jurisdictions
• CASP Authorisation under MiCA for Early-stage Founders – EU regulatory authorisation for crypto-asset service providers under MiCA
• PSP and Acquiring Agreements: Where the Legal Lines Are Drawn – payment and acquiring agreement risk for digital-asset operators

FAQ

How long does a crypto licence take to obtain?

Timeline varies considerably by jurisdiction, activity category and application quality. Under the VARA regime, the process follows a staged structure — from initial engagement through minimum-viable-product authorisation to full-market-product status. A single-activity application with complete, well-prepared documentation moves materially faster than a multi-activity or group-restructuring submission. In most leading hubs, the realistic window spans several months. Filing with gaps extends every stage. Beginning with a readiness assessment significantly improves predictability.

Which jurisdiction is best for licensing my crypto business?

There is no universal answer. The right jurisdiction depends on where your users are, where your team and infrastructure sit, what banking relationships are available to your business, and which regulated activities you need to conduct on day one. VARA suits operators genuinely building in Dubai for GCC and international institutional markets. A MiCA CASP authorisation is essential for EU user access. Singapore's MAS regime suits Asia-Pacific-focused businesses. Most operators at scale need licences in more than one jurisdiction. We map the full stack before you commit.

Do I need a separate custody licence?

Under VARA, custody is a distinct regulated activity. A VARA exchange licence does not cover custody of client virtual assets — a business holding assets on behalf of clients requires separate VARA custody authorisation. The same principle applies across the major hubs: MiCA treats safekeeping and administration of crypto-assets as a standalone CASP service; the MAS Payment Services Act and the SFC VASP regime in Hong Kong similarly treat custody as a discrete regulated function. Combining exchange and custody in a single product without the relevant authorisations for both is a common and consequential oversight.

OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across more than 70 jurisdictions — including VARA, MiCA, the MAS Payment Services Act regime, the SFC VASP regime and the FCA — on disputes and on-chain asset recovery across more than 25 forums, and on the tax, banking and compliance that sit around them. We map the licence stack across operating, custody and payment layers before our clients commit to a jurisdiction or an application. Digital assets are the whole of our practice. To discuss your VARA application or your broader licence architecture, contact info@oboluslaw.com or message us at t.me/oboluslaw.

By Aisha Tan, Licensing & Jurisdictions Analyst — specialises in multi-jurisdiction VASP and CASP authorisation across the UAE, EU and Asia-Pacific hubs.

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.