What VARA Actually Regulates — and What It Doesn't

Among the questions that appear most frequently in GCC enterprise due diligence and international vendor assessment processes, one stands out for its frequency and the misunderstanding it often reveals: "Are you VARA-regulated?" The question is reasonable. The UAE has made serious regulatory investments in virtual asset oversight, and any enterprise buyer or banking partner wants to understand where a vendor sits within that framework. The problem is that the question assumes a binary — either you have a VARA licence, or you are operating outside the law. The actual regulatory architecture is more layered than that, and understanding the layers is essential for any operator evaluating UAE-incorporated virtual asset infrastructure vendors.

Three Bodies, Different Mandates

The UAE's approach to financial and virtual asset regulation involves three distinct regulatory bodies that operate across different jurisdictions and subject matter, and it is important not to conflate them.

The Central Bank of the UAE (CBUAE) regulates banks, payment systems, licensed financial institutions, and payment service providers operating in mainland UAE. Its mandate covers fiat currency, payment infrastructure, and licensed financial intermediation. Virtual asset activities are not directly within its core mandate, though it has issued guidance on payment tokens and will regulate stablecoin issuers under proposed frameworks.

The Virtual Assets Regulatory Authority (VARA) is Dubai's dedicated virtual asset regulator, established under Dubai Law No. 4 of 2022. VARA's mandate covers virtual asset activities conducted in or from Dubai — including from Dubai free zones, with specific carve-outs for the DIFC and ADGM which maintain their own financial services regulatory frameworks. VARA introduced a comprehensive regulatory framework through its Virtual Assets and Related Activities Regulation 2023, defining which activities require a licence and which do not.

The DMCC Free Zone is a commodity and trade free zone — one of the UAE's largest — with its own company licensing regime administered by the DMCC Authority. DMCC companies engaging in virtual asset-related activities operate under DMCC's own activity framework, with VARA oversight applying where the activities conducted fall within VARA's defined regulatory perimeter. A DMCC licence for a technology company is a company licence, not a financial services licence, and the two are not interchangeable.

How DIFC and ADGM Fit In

The three-body framework above — CBUAE, VARA, DMCC — covers mainland UAE and Dubai's non-financial free zones. Two additional jurisdictions appear frequently in international client questions and deserve direct treatment: the Dubai International Financial Centre (DIFC) and Abu Dhabi Global Market (ADGM). Both operate as financial free zones with independent regulatory frameworks, and neither falls under VARA's jurisdiction.

The DIFC is regulated by the Dubai Financial Services Authority (DFSA). The DFSA operates a digital assets regime under which digital asset activities conducted in or from the DIFC require DFSA authorisation. The framework is oriented toward financial services: exchange, custody, advice, and dealing in investment tokens. A technology company operating in the DIFC that does not provide financial services is subject to DIFC company law and employment law, but not DFSA financial services authorisation — the same tool-maker versus service-provider distinction applies.

The ADGM is regulated by the Financial Services Regulatory Authority (FSRA). ADGM has built a well-regarded virtual asset framework covering spot digital asset trading, custody, and derivatives under the FSRA's Digital Asset regime. Again, the FSRA regulates virtual asset activities, not the software infrastructure that underpins them. A non-custodial technology company in ADGM would be incorporated under ADGM company law without falling under FSRA financial services requirements.

The practical choice between DIFC, ADGM, and DMCC for a non-custodial technology company comes down to positioning and operational profile. DIFC and ADGM carry international financial centre prestige and are well-suited for companies that provide financial services or seek to access institutional capital through those frameworks. DMCC is operationally focused, lower cost to establish and maintain, and carries the specific recognition that comes from being the world's largest commodity and trade free zone. For a company whose activities are software licensing rather than financial intermediation, DMCC is the structurally appropriate fit — and the one most familiar to international banking compliance teams as a straightforward technology company domicile.

What Triggers a VARA Licence Requirement

VARA's Virtual Assets and Related Activities Regulation 2023 defines seven regulated virtual asset activities, each of which requires a VARA licence if conducted in or from Dubai:

• VA Issuance Services
• VA Exchange Services
• VA Transfer Services
• VA Broker-Dealer Services
• VA Management and Investment Services
• VA Lending and Borrowing Services
• VA Custody Services

A company must hold an appropriate VARA licence for any of these activities if conducted in or from Dubai. The framework is explicit about this. What the framework does not include in this list — and what is therefore not a directly VARA-regulated activity — is the provision of software infrastructure services or the licensing of technology tools that others use to conduct virtual asset activities. The regulatory hook is the activity, not proximity to the activity.

The Software Infrastructure Exemption

VARA's framework draws a meaningful distinction between entities that conduct virtual asset activities and entities that provide technology services that others use to conduct those activities. This is not a novel or UAE-specific concept — it mirrors the approach taken by FATF internationally, by MAS in Singapore, and by the FCA in the United Kingdom. The principle is consistent: tool makers are not the same as service providers.

Fexr Technologies provides self-custody trading software, market intelligence services, and developer APIs — under a transparent fee structure disclosed before every transaction. It does not custody, manage, or lend virtual assets. Users hold their own private keys and self-execute every transaction under a capped, revocable permission they control. Fexr cannot move user assets, and withdrawals can only return to the user's own wallet.

The analogy that holds up under scrutiny is the core banking software provider. A company like Temenos or Finastra builds and licences software that banks use to process transactions, manage accounts, and execute financial operations. That software company is not a bank. It does not hold deposits, process payments on its own balance sheet, or bear the regulatory obligations of a licensed financial institution. Its customers — the banks — assume the regulatory relationship with their own regulators. The software vendor is assessed as a technology supplier, not as a financial intermediary.

Fexr's position in the virtual asset infrastructure stack is structurally analogous. Operators deploy Fexr's smart contract tooling to run their own loyalty, participation, or community reward programmes. The operator governs the deployed contract. Fexr retains no control over the contract after deployment. Fexr does not custody any assets. The operator assumes the regulatory relationship with their own users and their own regulatory environment.

The MiCA Parallel — What EU-Facing Operators Should Know

Operators deploying loyalty infrastructure accessible from the European Union will encounter the EU's Markets in Crypto-Assets Regulation (MiCA), which reached full application in December 2024. MiCA introduces a harmonised licensing regime for Crypto-Asset Service Providers (CASPs) across all EU member states, covering exchange, transfer, safekeeping, and advice services performed for clients. The CASP definition has direct relevance to any operator whose programme involves digital assets, stablecoins, or tokenised reward instruments distributed to EU participants.

The software infrastructure analysis under MiCA closely mirrors the FATF and VARA analyses. MiCA's recital language draws an explicit distinction between the provision of CASP services and the provision of technical services — including software or infrastructure — that merely facilitate the provision of those services without the provider itself performing them. A software platform that holds no client assets and exercises no discretion over user funds is not expected to be classified as a CASP under MiCA merely because its tooling touches digital assets — though MiCA interpretation is still developing and EU member states may reach their own conclusions.

For operators, the MiCA compliance question is separate from the vendor assessment. If an operator's programme offers digital asset services to EU residents — exchange, transfer, or custody of digital assets — the operator may require CASP authorisation in the relevant member state, regardless of who built the underlying tooling. What the infrastructure vendor's non-CASP status means in practice is that the EU operator is not inheriting a regulatory compliance layer from their technology supplier. The vendor assessment defaults to the same framework described throughout this briefing: does the vendor custody assets, control transactions, or exercise ongoing discretion? If the answer is no on all three counts, the standard technology supplier procurement framework applies.

Why the DMCC Structure Matters for Vendor Assessment

For international clients evaluating UAE-incorporated vendors — whether through a bank's AML/KYC process, a procurement compliance review, or a legal due diligence exercise — the DMCC Free Zone structure carries specific and well-understood signals.

A DMCC technology company licence indicates legitimate UAE incorporation under a recognised and internationally credible free zone authority, a software or technology activity scope (not financial intermediation), and a straightforward corporate structure that is familiar to banking compliance teams across the GCC and internationally. DMCC is not an obscure jurisdiction. It is one of the world's most recognised free zones, with over 22,000 member companies and a well-established compliance and licensing infrastructure.

Critically, a DMCC-licensed technology company with a non-custodial architecture presents a different risk profile to a bank's transaction monitoring system than a virtual asset exchange or custodian. There is no custody of client funds and no pooling of user assets: platform fees are disclosed before each transaction and collected without Fexr ever taking possession of user balances. Banks that have spent years building complex AML frameworks around virtual asset businesses are generally well-equipped to classify this correctly once the model is explained clearly.

What the Fee Model Means for Banking Relationships

One of the most common practical questions from operators evaluating Fexr is whether partnering with Fexr will create complications in their own banking relationships. The concern is legitimate — banks have terminated accounts or restricted services for companies perceived to have virtual asset exposure, sometimes without adequate assessment of what the actual relationship involves.

Fexr does not receive staking fees, yield distributions, or gas fee revenue, and never takes possession of user assets. Its revenue model consists of transparent platform fees: a percentage-based fee on trades and swaps that users self-execute (shown in the order preview before confirmation), fixed per-query fees for market-intelligence reports paid via the x402 protocol, and annual Enterprise plan subscriptions. Every fee is disclosed before it is incurred, and fee collection never involves custody of user balances.

From the perspective of a bank's transaction monitoring system, the decisive feature is the absence of custodial flow. Fexr never pools, holds, or settles user balances: fees are disclosed before each transaction and collected as they occur, while user assets remain in user wallets throughout. Every fee event is individually attributable and audit-logged. This is a materially different profile from what bank AML systems are typically calibrated to flag as high-risk virtual asset exposure — the commingled client-asset flows of exchanges and custodians.

A Practical Note for Operators

Operators deploying infrastructure on Fexr are not inheriting a VARA licensing obligation from their vendor. Fexr does not hold a VARA licence because its activities do not require one under the current framework. The absence of a VARA licence reflects where Fexr's legal analysis places it in the activity taxonomy under the current framework — operators are encouraged to seek their own counsel on vendor licensing status as the framework evolves.

However, operators must take their own legal advice on whether the activities they conduct through Fexr infrastructure trigger a VARA licence requirement for themselves. Operators offering exchange services, custody, or lending to their end users may require a VARA licence for those activities, regardless of who built the underlying tooling. Operators running a loyalty or community participation programme that uses stablecoin settlements as a reward mechanism occupy a different and generally less regulated position — but that analysis is jurisdiction-specific and should be conducted with UAE counsel familiar with VARA's current application guidance.

The division of regulatory responsibility is clear: Fexr is the infrastructure vendor. Operators are the programme operators. Each party's compliance obligations follow from what they do, not from what their vendor does.