Founders don’t get licensed for labels; they get licensed for activities. The Central Bank of the UAE (CBUAE) frameworks reward teams who can describe, with precision, where client money sits, who moves it, who converts it, and who is on the hook for redemption. This article converts a practical decision tree into a legal narrative you can use to scope your perimeter, pick the right licence(s), and prepare an approval-ready file.

1. Begin With Flows, Not Labels

The quickest way to mis-file is to start with the brand you think you are, “wallet,” “PSP,” “stablecoin ramp.” The correct starting point is a three-question triage:

  1. Will your product hold customer fiat balances at any time? If yes, you are in Stored Value Facilities (SVF) territory, full stop. If you also issue cards, acquire merchants, or execute transfers, you will add a Retail Payment Services & Card Schemes (RPSCS) licence on top. If not, proceed.
  2. Will you provide retail payment services (payment accounts, card issuance, merchant acquiring, payment aggregation, domestic or cross-border transfers, payment initiation or account-information services)? If yes, you are in RPSCS territory (choose Category I–IV according to scope/volume). If not, proceed.
  3. Will you issue, convert (spot only), or custody/transfer fiat-referenced payment tokens? If yes, you are in Payment-Token Services (PTS) territory, potentially alongside RPSCS (for your fiat rails) and, where you hold balances, SVF.

Cross-cut: if you touch non-payment-token crypto (e.g., BTC/ETH), that leg generally requires a VASP licence (VARA/SCA/FSRA/DFSA) in parallel to any CBUAE authorisation for your fiat/payments side.

2. SVF: When You Hold Customer Balances

Trigger. If customers have a contractual right to redeem or spend balances later with you or your network, and that balance sits with your entity, you require an SVF licence. If you only pass funds straight through to a merchant or settlement bank with no storage or redemption right, you may be pass-through (no SVF), but you must align both T&Cs and operations to that reality.

Prudential core.

  • Capital: AED 15m paid-up plus Aggregate Capital Funds (ACF) ≥ 5% of customer float, maintained at all times.
  • Bank guarantee: typically ≈ AED 15m (equal to paid-up capital), unconditional.

Safeguarding. Float must be legally and operationally segregated; operate daily reconciliation (D and D+1) with exception workflows; treasury is liquidity-first (no risky instruments without approval). Tech and data expectations include UAE data residency, five-year retention, pen-tests, and BCP/DR. Consumer outcomes require clear T&Cs, refunds for unauthorised transactions, and a risk-based AML/sanctions regime.

Combinations. If you also run retail rails (cards, acquiring, transfers) you will hold SVF + RPSCS (category chosen per §4 below). If you support payment tokens inside the wallet, you may add PTS for the token leg while retaining SVF for fiat float.

3. RPSCS: When You Run the Rails

Scope. RPSCS covers payment account issuance, payment instrument (card) issuance, merchant acquiring, payment aggregation, domestic and cross-border fund transfers, plus PIS/AIS (open-banking). The structure is category-based, select the category from your actual menu of services and then size capital by volume tier:

  • Category I: accounts + cards + acquiring + aggregation + domestic & cross-border + RPSCS payment-token facet.
  • Category II: same as I without the token facet (typical “wallet + cards + x-border”).
  • Category III: subset with no cross-border.
  • Category IV: PIS/AIS only (open-banking).

Capital (initial, by average monthly transaction value).

  • Cat I: AED 3m (≥ AED10m) / 1.5m (< AED10m)
  • Cat II: AED 2m / 1m
  • Cat III: AED 1m / 0.5m
  • Cat IV: AED 0.1m (flat)
    ACF must remain ≥ initial-capital at all times.

Safeguarding funds in transit. Segregation is mandatory; if settlement exceeds 24 hours, implement escrow and/or insurance/bank-guarantee with strict non-commingling. Maintain reconciliations, statements for framework agreements, and refunds for unauthorised transactions. Tech and AML expectations align to UAE IA and risk-based AML practice.

Watch-outs. Category II typically fits wallet + cards + x-border; choose I only if you truly need the RPSCS token facet. If you later add cross-border to a Cat III file, you must vary permission (upgrade). If you also hold balances, add SVF.

4. PTS: When You Touch Fiat-Referenced Tokens

Scope & prohibitions. PTS is for fiat-referenced payment tokens (stablecoins). Algorithmic and privacy tokens are out of scope and cannot be issued, serviced, or promoted.

Licences/registrations.

  • Dirham Payment-Token Issuer (Licence)  AED token issuance to UAE residents.
  • Payment-Token Conversion (Licence)  spot buy/sell (no margin/derivatives).
  • Payment-Token Custody & Transfer (Licence) client token safekeeping and transfers.
  • Foreign Issuer Registration  non-UAE issuer market access.
  • Non-Objection Registration  limited ancillary PTS for already-regulated firms.

Capital & reserves.

  • Issuers: AED 15m base + variable add-on tied to outstanding float (≈ 0.5% under the standard reserve model; ≈ 2% if using a bank-subsidiary split reserve with ≤50% UAE T-bills/M-bills).
  • Conversion/Custody & Transfer: AED 3m if monthly average token-transfer value ≥ AED 10m; else AED 1.5m.
  • Bank guarantee: typically equal to paid-up capital.

100% Reserve of Assets. Issuers must hold a same-currency, 100% reserve in segregated UAE escrow (or with CBUAE if directed), run daily reconciliation, and obtain monthly external-audit attestation.

Promotion & acceptance gating. Only licensees/registrants (or disclosed agents) may promote; no promotion for algorithmic/privacy tokens. Providers must not knowingly execute or direct transfers unless they relate to: (i) a licensed AED token (any lawful use), or (ii) a registered foreign token used to purchase virtual-asset products/derivatives. Embed this gating in UX, policies, and agent materials.

Combinations. If you operate fiat rails alongside PTS, you will pair PTS with RPSCS (for fiat flows). If you hold balances, SVF still applies.

5. Quick Mapping: What You Do → What You Need

  • Hold customer balances (P2P, bill pay, spend): SVF (add RPSCS if you issue cards, acquire merchants, or move funds).
  • Issue cards / acquire merchants / domestic & cross-border transfers: RPSCS Cat II (often) or Cat I if the RPSCS token facet is truly needed; if settlement exceeds 24h, add escrow/insurance/guarantee; no SVF unless you hold balances.
  • Issue AED-pegged token: PTS AED Issuer (AED 15m + add-on; 100% same-currency reserve; strict promotions).
  • Spot convert fiat ↔ payment tokens: PTS Conversion (+ RPSCS for fiat rails) with acceptance gating.
  • Custody/transfer payment tokens: PTS Custody & Transfer with segregated wallets, HSM/MPC, consent controls.
  • Foreign USD/EUR token distribution into UAE: PTS Foreign Issuer Registration (Means-of-Payment generally for VA/VA-derivatives purchases).
  • Domestic payouts only; no cross-border; no balances: RPSCS Cat III (upgrade if you add cross-border).
  • Open-banking only: RPSCS Cat IV (no account holding or card issuance).
  • Traditional exchange-house with cash ops: separate Exchange Business regime (often paired with RPSCS/SVF).

6. Capital & Safeguarding A One-Page Cheat-Sheet

  • SVF: paid-up AED 15m; ACF ≥ 5% of float; bank guarantee ≈ AED 15m; daily float reconciliation; liquidity-first.
  • RPSCS: initial capital by category/tier (Cat I AED 3m/1.5m, II 2m/1m, III 1m/0.5m, IV 0.1m); ACF ≥ initial at all times.
  • PTS Issuer: AED 15m + 0.5% (or 2% under the split reserve); 100% same-currency reserve in UAE escrow; daily recon; monthly audit; bank guarantee ≈ AED 15m.
  • PTS Conversion/Custody-Transfer: AED 3m (≥10m monthly transfer value) or AED 1.5m (<10m).

Operational triggers to engineer in.

  • RPSCS funds >24h: escrow/insurance/bank guarantee; no commingling; reconciliations.
  • SVF balances: ring-fenced accounts; daily D/D+1 recon; liquidity-first treasury.
  • PTS reserves: same-currency 100% reserve; daily recon; monthly external attestation.
  • All regimes: UAE data residency; five-year retention; IA-aligned cyber; BCP/DR; pen-tests.

7. Common Patterns That Survive Review

  1. Wallet + Cards + Cross-border (no crypto): SVF + RPSCS Cat II in one entity.
  2. Wallet + Cards + Payment-Token Ramp (no BTC/ETH): SVF + RPSCS Cat II, plus PTS Conversion/Custody & Transfer; add PTS Issuer if launching an AED token.
  3. Fiat ↔ Payment-Token Gateway (no stored fiat): PTS Conversion + PTS Custody & Transfer; RPSCS for fiat rails; no SVF.
  4. End-to-End On/Off-Ramp incl. BTC/ETH: two entities; CBUAE-licensed (SVF/RPSCS) for fiat + VASP-licensed for non-payment-token crypto.

8. Pitfalls (and How to Avoid Them)

  • Accidental SVF via T&Cs that grant redemption or by operationally “parking” funds.
    → Either embrace SVF or redesign for true pass-through with bank-held funds.
  • Mis-categorising RPSCS (e.g., running cross-border under Cat III).
    → Map services to the nine RPS definitions first; choose category second; vary permissions early if scope expands.
  • Token perimeter errors (treating BTC/ETH as payment tokens).
    → If not fiat-referenced, it’s VASP territory, not PTS.
  • Promotion breaches (marketing foreign tokens for general retail).
    → Bake PTS acceptance/promotion gating into UX and agent contracts; legal sign-off on all copies.
  • Reserve shortfalls / late reconciliations (PTS Issuer or SVF).
    → Automate D/D+1 reconciliations; board-level MI; monthly audit cadence.
  • Thin tech evidence (no pen-test or DR proof).
    → Submit a complete tech dossier with tested controls.

9. Documentation: What an “Approval-Ready” File Looks Like

  • SVF: Operating Rules; segregation & escrow letters; daily recon SOPs; auditor certificate for paid-up capital; bank guarantee; AML and conduct suites; tech dossier; independent assessments.
  • RPSCS: Service mapping; safeguarding model (including >24h instruments); consumer T&Cs & statements; AML programme; tech dossier; controller approvals (≥20%); PCI posture if issuing/acquiring.
  • PTS Issuer: White-paper-style token disclosure; reserve account docs; daily recon & monthly audit plan; promotions/acceptance policy; AML for high-risk designation; fork/finality runbooks.
  • PTS Conversion / Custody-Transfer: Pricing & execution policy (spot only); wallet segregation/HSM-MPC; acceptance gating; AML scenarios for token flows; incident response.

10. Final Checklist (Fast Triage Before You Draft)

  1. Do you hold fiat balances? → SVF (plus RPSCS if you run rails).
  2. Do you offer accounts/cards/acquiring/transfers? → RPSCS (pick category; check safeguarding).
  3. Do you issue/convert/custody fiat-referenced tokens? → PTS (Issuer/Conversion/Custody-Transfer; register foreign issuers if relevant).
  4. Any BTC/ETH/etc.? → VASP (separate entity/licence).
  5. Promotion/acceptance logic embedded? → Required for PTS.
  6. Data/tech/AML evidence ready at filing? → Accelerates approvals.

Disclaimer: 

This article is an informational summary based on a practical decision framework for UAE payments licensing. It is not legal advice. Final scoping, prudential obligations, and licence outcomes depend on your exact services, flows, ownership, technology, and partners, and on CBUAE determinations (and, where relevant, VARA/SCA/FSRA/DFSA). For a tailored perimeter memo and filing pack, instruct qualified counsel.

FAQs

1. What is the difference between PTS, SVF, and RPSCS in the UAE?

PTS regulates fiat-referenced payment tokens (stablecoins), SVF applies when a business holds customer fiat balances, and RPSCS governs payment services such as cards, transfers, acquiring, and payment accounts. The correct licence depends on actual money flows, not branding.

2. Can a fintech company hold more than one CBUAE licence?

Yes. Many approved structures combine SVF + RPSCS or RPSCS + PTS. The CBUAE assesses each regulated activity separately, and multiple licences are common for wallets, payment apps, and token-enabled platforms.

3. What activities require a PTS licence in the UAE?

Issuing AED-referenced payment tokens, converting fiat to payment tokens, and providing custody or transfer services for payment tokens all require a PTS licence under the CBUAE framework.

4. What documents does the CBUAE expect for fintech licensing?

Typical submissions include operating rules, safeguarding and reconciliation procedures, AML/CFT frameworks, technology and cybersecurity documentation, capital evidence, and detailed service mapping aligned to regulated activities.

5. Is marketing of payment tokens regulated in the UAE?

Yes. Only licensed or registered PTS entities may promote payment tokens, and promotion of algorithmic or privacy tokens is prohibited. Acceptance and promotion controls must be embedded in both UX and contracts.

6. What is the difference between RPSCS Category I, II, III, and IV?

RPSCS categories vary by service scope. Category II is common for wallets with cards and cross-border transfers, Category III excludes cross-border services, and Category IV applies only to open-banking services like PIS/AIS.

Newer TOKEN ISSUANCE IN DUBAI
Back to list
Older Choose Your Rails, Not Your Labels: A Founder’s Guide to UAE Stablecoins, Wallets, and Retail Payments (PTS, SVF, RPSCS)