DMCC, VARA, and the Software Infrastructure Gap: How UAE Frameworks Treat Non-Custodial SaaS Providers

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.

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 smart contract deployment tooling, dashboard hosting, API compatibility maintenance, and security monitoring — all under a fixed Usage-Based Software Licensing fee structure. It does not exchange virtual assets on behalf of anyone. It does not transfer virtual assets on behalf of anyone. It does not custody, manage, or lend virtual assets. It does not act as a broker-dealer. It builds the infrastructure that others deploy and operate.

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 identical. 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.

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 and a fixed-fee revenue model presents a different risk profile to a bank's transaction monitoring system than a crypto exchange or custodian. There are no variable flows linked to asset values, no custody of client funds, and no financial intermediation activity. The payment relationship is a SaaS subscription — a recurring fixed fee for software access and maintenance. Banks that have spent years building complex AML frameworks around crypto businesses are generally well-equipped to classify this correctly once the model is explained clearly.

What "Usage-Based Software Licensing Fees" 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 crypto exposure, sometimes without adequate assessment of what the actual relationship involves.

Fexr does not receive staking fees, yield distributions, transaction spreads, gas fee revenue, or any form of participation in the economic activity of deployed contracts. Its revenue model consists of a fixed implementation fee paid at the time of contract deployment and a fixed monthly maintenance retainer covering API infrastructure, security monitoring, and platform updates. These fees are categorised as Usage-Based Software Licensing Fees or API Infrastructure Fees depending on the contract structure.

From the perspective of a bank's transaction monitoring system, this is indistinguishable from paying a SaaS subscription to any other enterprise software vendor. There is no variable component, no crypto-linked revenue sharing, and no custodial flow. The payments are fixed, predictable, and clearly attributable to software licensing. This is a materially different profile from what bank AML systems are typically calibrated to flag as high-risk crypto exposure.

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 is not a compliance gap — it is an accurate reflection of where Fexr sits in the activity taxonomy.

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.

---