Navigating UAE Wallet, Payments, Remittance & On/Off-Ramp Licensing in 2026

How to translate “we want wallets, cards, remittance and crypto ramps” into the exact licences your UAE business actually needs, without over-licensing, under-scoping, or blowing the capital stack.

Executive Snapshot

Founders often ask for two things: (1) a stored-value/e-money licence to run digital wallets and card programs, and (2) a PSP/remittance licence to process payments, do cross-border FX, and enable fiat↔crypto on/off-ramps. In the UAE, those ambitions map to distinct regulatory perimeters:

• Stored Value Facilities (SVF) – Central Bank of the UAE (CBUAE): authorises holding customer balances (“float”) in a wallet; minimum paid-up capital AED 15,000,000 plus Aggregate Capital Funds ≥ 5% of float, and a bank guarantee typically equal to paid-up capital.
• Retail Payment Services & Card Schemes (RPSCS)  CBUAE: licence categories I–IV package activities such as payment account issuance, instrument (card) issuance, merchant acquiring, aggregation, domestic & cross-border transfers; capital ranges from AED 100k to AED 3m depending on category and volume.
• Exchange Business – CBUAE: the traditional exchange house/remittance regime (separate from RPSCS) with materially higher capital and local-substance constraints; suitable only if you truly want a full remittance/FX house footprint.
• Virtual-asset on/off-ramp – VARA (Dubai) / SCA (on-shore outside free zones) / FSRA (ADGM) / DFSA (DIFC): converting between fiat and non-payment-token crypto requires a VASP licence. If your “crypto” is a fiat-referenced payment token, the CBUAE Payment-Token Services framework may apply instead (for payment tokens only).

The art is assembling only what you need and structuring entities so fiat and virtual-asset perimeters do not contaminate each other.

Part I  What You Want vs. What the Law Requires

A. Digital wallets that hold funds and power card programs

What you want: SVF/EMI-style wallet; top-ups; P2P; bill pay; card issuing.

What you need:

1. SVF (CBUAE) to hold customer balances.

• Paid-up capital: AED 15m.
• Aggregate Capital Funds (ACF): ≥ 5% of float (over and above paid-up capital).
• Bank guarantee: commonly required and generally aligned to paid-up capital.
• Core disciplines: float segregation, daily reconciliation, UAE data residency, 5-year retention, robust tech/cyber and AML/CFT.

2. RPSCS (CBUAE) to power wallet rails and cards: choose the category that fits your features and volumes.

• Category I: accounts, card issuance, acquiring, aggregation, domestic & cross-border transfers, plus the payment-token facet.
• Category II: same without the payment-token facet (the typical wallet + cards stack).
• Category III: subset of services, no cross-border.
• Category IV: payment initiation and/or account-information only (open banking).

Capital (RPSCS, Article 6):

• Cat I: AED 3,000,000 (≥ AED 10m monthly average transaction value) / AED 1,500,000 (< AED 10m).
• Cat II: AED 2,000,000 / AED 1,000,000.
• Cat III: AED 1,000,000 / AED 500,000.
• Cat IV: AED 100,000 flat.
• Aggregate capital funds (Article 7) must never dip below the initial-capital threshold.

Practical rule: If you hold balances and issue cards with cross-border capability, expect SVF + RPSCS Category II (or Category I if you also need the Regulation’s payment-token facet).

B. PSP/Remittance & Cross-Border FX (with an on/off-ramp ambition)

What you want: domestic and cross-border payments, FX corridors, fiat↔crypto ramps.

What you need (break it into three layers):

1. RPSCS – To conduct domestic and cross-border fund transfers, merchant acquiring, and aggregation. Most fintechs choose Cat II (or Cat I if the RPSCS payment-token facet is relevant).
2. Exchange House – Only if you plan a traditional remittance business with branches/cash ops: capital often AED 5m–50m+ depending on licence category and footprint, with security deposits/guarantees and local-ownership/premises constraints. Many fintechs do not need this; RPSCS suffices or they partner with an existing exchange house for cash corridors.
3. On/Off-Ramp – Two paths, depending on the “crypto” leg:

• Non-payment-token virtual assets (e.g., BTC/ETH): requires a VASP licence VARA (Dubai), SCA (on-shore UAE), FSRA (ADGM) or DFSA (DIFC). Typical categories: Broker-Dealer, Exchange, Custody, Transfer (scope-dependent).
• Fiat-referenced payment tokens (stablecoins) only: consider the CBUAE Payment-Token Services (PTS) framework (e.g., Payment-Token Conversion and Payment-Token Custody & Transfer). Algorithmic or privacy tokens are out of scope and prohibited.

Part II  The Recommended Licensing Stacks

Option 1  Full on-shore wallet + cards + payments with a crypto partner

• SVF + RPSCS Cat II (or Cat I) in one UAE entity.
• Integrate a VARA-licensed (or other competent regulator-licensed) VASP for the crypto leg via API.
• Why it works: clean perimeter; lower build cost and time; you retain control of the fiat experience; partner handles crypto execution/custody risks.

Option 2  Same as Option 1 plus your own on/off-ramp

• Maintain two legal entities: (i) CBUAE-licensed entity (SVF + RPSCS) for fiat rails and wallet operations. (ii) VASP-licensed entity for crypto execution/custody/transfer.
• Why it works: end-to-end control; avoids cross-contamination of perimeters; clear supervisory lines.

Option 3  Exchange House + Wallet

• Pursue the Exchange Business licence (if you truly need a full remittance/FX house), and add SVF + RPSCS for the wallet/cards layer.
• Why it works: best for groups seeking deep corridor control and cash operations; higher capital and local-presence expectations.

Part III  Capital Stack & Cost Planning (Year-1)

Statutory capital (separate from fees/OPEX):

• SVF: paid-up capital AED 15,000,000; ACF ≥ 5% of float; bank guarantee typically equal to paid-up capital.
• RPSCS: AED 100k–3m initial capital depending on Category and volume tier; aggregate capital must stay ≥ initial threshold.
• Exchange House: category-based; AED 5m–50m+ is common depending on scale.
• VASP: varies by regulator and activity; budget separately.

Year-1 planning fee consideration/Expenses:

• CBUAE application/first-year supervision fees: AED 100k–200k.
• External audit (incl. control reviews): Varies.
• PCI-DSS (if card issuing/acquiring): Varies (scope-dependent).
• Independent penetration testing: Varies (pre-go-live).
• Bank guarantees/insurance for safeguarding: 0.5%–2.0% p.a. of covered amount.
• Card-scheme onboarding (issuer processing/BIN/spend collateral): AED Varies (one-off + collateral).
• KYC/AML tooling: Varies
• SIEM/endpoint/backup (UAE):Varies
• Data hosting (UAE primary + DR): Varies

Tip: capital is not cash burn regulators expect it to be available and unencumbered. Build cushions for scale-up so you don’t trip aggregate-capital floors.

Part IV  Structuring to Win: Design Decisions That Save Months

1. Decide the float perimeter early. If any user balance sits with you (even “temporarily”), you likely trigger SVF. To avoid SVF, design a true pass-through model (settlement bank holds funds, immediate onward flow, no redemption rights with you). Document this cleanly.
2. Category discipline under RPSCS. (i) Cat II is the workhorse for wallet + cards + domestic/cross-border transfers, (ii) Use Cat I only if you genuinely need the RPSCS payment-token facet, (iii) Cat III fits domestic-only plays. Cat IV is open banking (initiation/information).
3. On/off-ramp scope clarity. (i) If you’ll touch BTC/ETH, etc., that is VASP territory, separate entity, separate regulator, (ii) If you’ll only touch fiat-referenced payment tokens, assess the PTS regime (Conversion; Custody & Transfer). Keep algorithmic and privacy tokens out.
4. Safeguarding design matters. For RPSCS fund transfers with settlement beyond 24 hours, build escrow/insurance/guarantee mechanics and strict segregation. For SVF, hard-wire daily reconciliation and monthly senior sign-off.
5. Tech & data are gate-openers. UAE data residency (plus 5-year retention), MFA, encryption, logging/SIEM, BCP/DR, and independent pen-testing are not “after licence” to-dos expect them to be tested before approval.
6. Outsourcing & agents. Both are permitted but remain your liability. Secure prior approvals where required, bake SLAs/KPIs/audit rights, and maintain exit plans.
7. Marketing controls. Keep claims accurate on fees, FX, redemption, and limits; in payment-token contexts, comply with promotion gates (who may promote what, for which use-case).

Part V  A Practical Timeline (Well-Prepared File)

• Months 1–2: Service inventory & perimeter memo; confirm SVF + RPSCS category; decide ramp path (VASP vs. PTS); capital/guarantee approach.
• Months 2–4: Safeguarding & treasury design (escrow/guarantee; reconciliation SOPs); consumer T&Cs and disclosures.
• Months 3–6: Governance (Board/SMF F&P), AML/CFT (EWRA, onboarding/monitoring/sanctions), complaints & refunds.
• Months 4–7: Tech dossier (architecture, IAM, encryption, DR testing), pen-test, data-residency controls.
• Months 7–10: File application(s); manage Q&A; management interviews/demos.
• Months 10–14: Satisfy conditions precedent (escrow live, bank guarantees issued, auditor appointment, dashboards in production).
• Go-live: soft launch with controlled limits; tighten MI, incident reporting, and compliance cadence.

Common Pitfalls (and How to Avoid Them)

• Under-scoping: choosing Cat III while planning cross-border payouts. ➟ Map every feature to a regulatory verb before choosing category.
• Accidental SVF: adding “stored balances” or “redeemability” in T&Cs when you intended pass-through. ➟ Align legal drafting to the precise perimeter.
• On/off-ramp confusion: treating BTC/ETH as if they were payment tokens. ➟ Separate VASP entity and licence if non-payment tokens are in scope.
• Safeguarding leaks: settlement funds sitting too long in opco accounts. ➟ Enforce segregation; use escrow or insurance/guarantee if >24 hours.
• Tech debt at licensing: weak logs, no pen-test, unclear DR. ➟ Ship a complete tech dossier; regulators now test readiness, not intentions.
• Outsourcing without approvals: starting with processors/agents before regulator buy-in. ➟ Plan approvals and oversight artefacts early.

How CRYPTOVERSE Legal Can Help

We act as single-threaded owner from scoping to go-live, aligning legal, prudential, AML, and technology workstreams to the CBUAE and (where relevant) virtual-asset regulators.

What you get:

• Perimeter memo & licensing architecture: a written map of exact licences (SVF, RPSCS Cat I–IV, PTS vs. VASP), entity split, and capital/guarantee plan, so stakeholders and banks see the same picture.
• Policy & control suite: float safeguarding/treasury (SVF), safeguarding of funds in transit (RPSCS), consumer T&Cs and refunds, AML/CFT (EWRA, CDD/monitoring/sanctions), outsourcing/agent oversight.
• Technology dossier: architecture, IAM, encryption, data residency and retention, pen-test integration, BCP/DR, incident playbooks, produced in regulator-ready format.
• Filing execution & Q&A: forms, exhibits, controller approvals, interviews/demos, and conditions-precedent close.
• Card & partner onboarding: BIN sponsorship, scheme documentation, settlement banks, escrow and guarantees, plus vendor oversight artefacts.
• Cost discipline: market-rate fee planning; we help negotiate bank-guarantee and escrow terms, and set realistic audit/PCI roadmaps.

Engagement model: fixed-fee phases with capped hours, or a monthly retainer for ongoing compliance once live.

Bottom Line: What to File For (Most Cases)

• Wallet + cards + domestic/cross-border payments (no exchange of BTC/ETH): SVF + RPSCS Category II (or Category I if the RPSCS payment-token facet is necessary). For crypto exposure, integrate a licensed VASP partner.
• End-to-end on/off-ramp in-house: two entities, CBUAE-licensed (SVF + RPSCS) for fiat, and VASP-licensed for crypto.
• Traditional remittance house ambitions: Exchange Business route plus SVF + RPSCS if you also want a modern wallet/cards layer.

Design your stack around what you actually do, not brand labels. When in doubt, front-load a crisp service inventory and we’ll map each feature to its regulator and article, so you can build with confidence, price the journey accurately, and avoid preventable delays.

Disclaimer:

This article provides general regulatory information at the time of publication and is not a substitute for legal advice. Outcomes depend on your final business model, ownership, technology, partners, and the determinations of the relevant UAE regulators (CBUAE, VARA, SCA, FSRA, DFSA). For formal advice and filings, engage counsel to review your structure, documentation, and disclosures.

FAQs