Choose Your Rails, Not Your Labels: A Founder’s Guide to UAE Stablecoins, Wallets, and Retail Payments (PTS, SVF, RPSCS)

Stop asking “What licence should we get?” and start asking “What do our flows actually do?” This article turns the decision tree for the UAE’s three core payments licences into a practical, founder-grade roadmap, with concrete guardrails, common structures, and execution tips. We finish with how CRYPTOVERSE Legal fast-tracks regulator-ready filings.

Why this matters now

In 2026, UAE fintechs and Web3 builders face an unusually clear, but demanding, regulatory landscape. On-shore (outside ADGM/DIFC), three Central Bank of the UAE (CBUAE) regimes set the rails for modern consumer payments and fiat-referenced crypto:

• Payment-Token Services (PTS) for fiat-referenced (“stablecoin”) tokens: Issuance, Conversion (spot only), and Custody & Transfer.
• Stored Value Facilities (SVF)  for wallets that hold customer balances (the “float”).
• Retail Payment Services & Card Schemes (RPSCS)  for retail payments rails: accounts, cards, acquiring/aggregation, domestic and cross-border transfers, and (within RPSCS) a limited payment-token facet.

Every successful licensing program we see starts with one discipline: map your actual customer and treasury flows to the verbs in each rulebook. Labels like “EMI,” “remittance,” or “crypto ramp” blur boundaries. Flows don’t.

This article expands the decision tree you’ve seen into an insightful, step-by-step legal explainer. Use it to decide what you need, how to combine licences, the capital and safeguarding to budget, and the documentation to prepare, then decide whether to keep your crypto leg in-house or partner with a licensed VASP.

The three gateways, in plain English

• SVF: You hold customer fiat balances (top-ups, stored value, redeemable credits) inside your entity. Think “the money sits with us until the customer spends or withdraws.” That “float” triggers SVF.
• RPSCS: You provide retail payment services, accounts, card issuance, merchant acquiring, payment aggregation, domestic and cross-border transfers, whether or not you hold balances.
• PTS: You issue, convert (spot), or safekeep/transfer fiat-referenced tokens. Algorithmic or privacy tokens are excluded and cannot be promoted. AED-pegged tokens require a licence to issue in UAE to UAE residents; foreign-currency tokens require registration to reach UAE users and are typically gated to paying for virtual-asset products/derivatives.

If you do more than one of these, you may need more than one authorisation, sometimes even more than one legal entity (e.g., a clean separation between fiat and non-payment-token crypto activities, which fall under VARA/SCA/FSRA/DFSA).

The decision framework, expanded

Step 1  Do you ever hold customer fiat balances?

If yes, your product sits in SVF unless you redesign the flow. A classic mistake is calling yourself “just a PSP” while your T&Cs grant customers a contractual right to redeem or you “park” funds in your accounts for later use. If the money becomes your float, it is SVF.

If not, you’re either RPSCS (if you provide retail payment services) or PTS (if you touch fiat-referenced tokens), or you might be outside these regimes (e.g., pure technology providers, merchants using licensed PSPs).

Step 2  Do you provide retail payment services?

If your proposition includes account issuance, card issuance, acquiring, aggregation, domestic or cross-border transfers, you’re in RPSCS. You then select Category I–IV based on exactly which services you offer (and your average monthly transaction value for capital tiering). If you also hold user balances, you need SVF + RPSCS.

Step 3  Do you issue, convert, or custody/transfer fiat-referenced tokens?

If yes, you’re in PTS. Choose one or more of:

• Issuance (mint/redeem)  AED tokens: licence to issue, issuance to UAE residents only.
• Conversion  spot only (no lending, margin, or derivatives).
• Custody & Transfer  client token safekeeping and executing token transfers.

If using foreign-currency payment tokens, a Foreign Issuer Registration route exists for market access; acceptance is typically gated to buying virtual-asset products/derivatives (not broad retail).

Important cross-cut: If your flows also touch non-payment-token virtual assets (e.g., BTC/ETH), that leg is a VASP perimeter (VARA in Dubai; SCA on-shore UAE; FSRA/DFSA in the free zones), separate from CBUAE.

Deep-dive: what “good” looks like under each regime

A) Stored Value Facilities (SVF)  when you hold balances

When it applies. You accept money or money’s worth to store value that can be spent or redeemed later under your contract (device- or app-based).

Prudential.

• Paid-up capital: AED 15,000,000 (own funds).
• Aggregate Capital Funds (ACF): ≥ 5% of total customer float at all times.
• Bank guarantee: typically = paid-up capital, unconditional, callable on first demand.

Float safeguarding.

• Legal & operational segregation of floats (trust/escrow/assignment and restricted accounts).
• Daily reconciliation (D and D+1), exception workflows, senior-management MI.
• Liquidity-first treasury (non-cash instruments require prior consent).

Governance & conduct.

• Board-approved risk, compliance, and internal audit with real independence.
• Clear T&Cs and disclosures, refund rules for unauthorised transactions, robust complaint handling.
• UAE data residency, five-year retention, IA-aligned cybersecurity (MFA, encryption, SIEM, DR testing), and annual pen-tests.

When you also need RPSCS. If you add card issuance, merchant acquiring, aggregation, or transfers, you add RPSCS on top of SVF.

B) Retail Payment Services & Card Schemes (RPSCS)  your rails

What it covers. Retail payment verbs: payment account issuance, card issuance, merchant acquiring, payment aggregation, domestic and cross-border transfers, plus PIS/AIS (open-banking). There is also a payment-token facet inside RPSCS, but it is narrower than the dedicated PTS regime.

Category selection.

• Cat I: the full menu including the RPSCS payment-token facet.
• Cat II: Cat I minus that facet, this is the workhorse for wallet + cards + domestic & cross-border.
• Cat III: domestic set without cross-border.
• Cat IV: PIS/AIS only.

Capital (by category and volume tier).

• Cat I: AED 3m / 1.5m (≥ / < AED 10m monthly average).
• Cat II: AED 2m / 1m.
• Cat III: AED 1m / 0.5m.
• Cat IV: AED 0.1m flat.
  Aggregate capital must never dip below the initial threshold; supervisors can uplift.

Safeguarding of funds in transit.

• Segregation at all times; if settlement exceeds 24 hours, use escrow and/or insurance/bank guarantee, no commingling.
• Reconciliations, statements for framework agreements, clear liability/refunds for unauthorised transactions.

Tech & AML. UAE IA-aligned security, tested DR, annual testing/pen-test; risk-based AML with sanctions and (where applicable) wire-transfer obligations.

Common pitfall. Running cross-border flows under Cat III (domestic set). If you add corridors later, vary permission early.

C) Payment-Token Services (PTS)  fiat-referenced tokens

In-scope. Only fiat-referenced tokens. Algorithmic and privacy tokens are prohibited (no issuance, services, or promotions).

Licences/registrations:

• AED Issuer (Licence)  to mint/redeem AED tokens to UAE residents.
• Conversion (Licence)  spot buy/sell (no derivatives).
• Custody & Transfer (Licence)  client token custody, transfers.
• Foreign Issuer Registration distributes foreign-currency tokens into the UAE.
• Non-Objection Registration  limited ancillary PTS by already-regulated firms.

Prudential:

• Issuers: AED 15m base capital + variable add-on on token float (≈ 0.5% under the cash-only reserve model; ≈ 2% if using a bank-subsidiary split reserve).
• Conversion / Custody-Transfer: AED 3m (≥ AED 10m monthly transfer value) or AED 1.5m (below).
• Bank guarantee: typically equals paid-up capital.

100% Reserve of Assets (Issuers):

• Same currency as the token; segregated escrow at a UAE bank (or with CBUAE if directed).
• Daily reconciliation; monthly external audit attestation.
• Limited split reserve option (≥ 50% cash / ≤ 50% UAE T-bills or CBUAE M-bills ≤ 6 months) for wholly-owned bank subsidiaries, triggers the higher capital add-on.

Promotion & acceptance gating:

• Only licensees/registrants (or disclosed agents) may promote; no claims for algorithmic/privacy tokens.
• Acceptance/transfer allowed when flows involve licensed AED tokens (any lawful use) or registered foreign tokens used to purchase VA/VA-derivatives. Bake this routing logic into UX and policies.

Tech & AML. Treat PTS as high-risk: bank-grade AML (EWRA, CDD/eKYC, scenarios, sanctions freezes) and IA-aligned security, including fork/rollback and transfer finality runbooks.

Common combinations (and why)

1. Wallet + Cards + Cross-border (no crypto)
   • SVF (to hold balances) + RPSCS Cat II for rails.
   • Clean, bank-friendly, and the default for consumer apps that store value and issue cards.
2. Wallet + Cards + Payment-Token Ramp (no BTC/ETH)
   • SVF + RPSCS Cat II, plus PTS Conversion and PTS Custody & Transfer for the token leg.
   • If you’ll mint your own AED token, add PTS Issuer.
3. Fiat↔Payment-Token Gateway (no stored fiat)
   • PTS Conversion + PTS Custody & Transfer; add RPSCS for the fiat rails; no SVF (true pass-through).
   • Best for “API ramps” that don’t want to carry floats.
4. End-to-End On/Off-Ramp incl. BTC/ETH
   • Two entities: CBUAE-licensed entity for SVF/RPSCS and a VASP-licensed entity (VARA/SCA/FSRA/DFSA) for non-payment-token crypto execution/custody.
   • Keeps perimeters clean and supervision lines clear.

Capital & prudential cheat-sheet

• SVF AED 15m paid-up; ACF ≥ 5% of float; bank guarantee ~ AED 15m; segregation; daily reconciliation; liquidity-first.
• RPSCS  Cat I: AED 3m / 1.5m; Cat II: 2m / 1m; Cat III: 1m / 0.5m; Cat IV: AED 0.1m flat; aggregate capital ≥ initial.
• PTS Issuer AED 15m base + add-on (≈0.5% or ≈2%); 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 (below).

Planning tip. Capital is not OPEX; regulators expect it unencumbered. Build buffers to avoid dipping below aggregate capital during growth spurts.

Safeguarding & operational triggers you must engineer in

• Funds-in-transit >24 hours (RPSCS) → escrow/insurance/guarantee; no commingling; reconciliations.
• Stored balances (SVF) → ring-fenced accounts, daily D/D+1 reconciliations, exception governance, recovery/wind-down plan.
• Payment-token reserves (PTS Issuer) → same-currency 100% reserve, daily reconciliation, monthly audit attestation, real-time reserve MI to the Board.
• Data & security (all) → UAE hosting, five-year retention, MFA, encryption, SIEM, DR tests, annual pen-tests; for PTS, add fork/finality playbooks.

Documentation snapshot (what “approval-ready” looks like)

• SVF Operating Rules; segregation/escrow letters; daily recon SOPs/screens; auditor capital certificate; bank guarantee; AML suite; consumer T&Cs/fees/refunds; tech dossier; seven independent assessments.
• RPSCS Service mapping to nine retail definitions; safeguarding model (>24h instruments); consumer statements; PCI posture if issuing/acquiring; controller approvals; AML/tech packs.
• PTS Issuer Token disclosure (rights/redemption/insolvency treatment); reserve account docs; daily recon flow; monthly audit plan; promotion/acceptance policy; fork/finality runbooks; AML suite.
• PTS Conversion / Custody-Transfer Spot-only pricing/execution policy; segregated wallet framework (HSM/MPC, dual control); acceptance gating; AML scenarios; incident response.

Frequent pitfalls and quick fixes

• Accidental SVF. T&Cs promise “redemption,” or you “temporarily” hold funds.
  • Fix: either embrace SVF or redesign as true pass-through (bank-held funds; no redemption rights).
• Wrong RPSCS category. Running cross-border on Cat III, or using Cat I without needing the payment-token facet.
  • Fix: map features to the definitions first; vary permissions early if scope expands.
• Token perimeter confusion. Treating BTC/ETH as “payment tokens.”
  • Fix: if it’s not fiat-referenced, it’s VASP territory, not PTS. Separate the entity.
• Promotion breaches. Marketing foreign tokens for general retail use; agents over-promising yields.
  • Fix: embed gating in UX and contracts; legal sign-off on every campaign; train agents.
• Reserve or reconciliation gaps.
  • Fix: automate D/D+1 reconciliations, keep exception logs, push MI to the Board; line up monthly external attestations.
• Thin tech evidence. No pen-test, untested DR, unclear fork handling.
  • Fix: deliver a complete tech pack with tested controls and runbooks at filing.

A realistic timeline (for a well-prepared file)

• Months 1–2 Perimeter memo and service inventory; choose licences and (if needed) split entities. Capital/guarantee plan; bank/escrow term sheets.
• Months 2–4 Safeguarding architecture (SVF/RPSCS) and reserve design (PTS Issuer); reconciliation SOPs; consumer disclosures & T&Cs.
• Months 3–6 Governance (Board/SMF fit-and-proper); AML suite (EWRA, CDD/monitoring/sanctions); complaints and refunds playbooks; agent/outsourcing packs.
• Months 4–7  Tech dossier (architecture/IAM/encryption/SIEM), DR test evidence; pen-test and remediation closure; fork/finality runbooks (PTS).
• Months 7–10  File application(s); manage Q&A; management interviews/demos; refine conditions.
• Months 10–14  Conditions precedent: escrow/live reserve feeds, guarantees issued, auditor engagement for monthly attestations (PTS Issuer), dashboards in production.
• Go-live  soft launch with limits; MI for reconciliation, incidents, fraud, complaints, and AML alerts humming from day one.

How CRYPTOVERSE Legal can help

We specialise in UAE payments and virtual-asset licensing. Our value is simple: we align law, prudential design, AML, and technology so your file reads like a working operation, not a slide deck. That shortens Q&A and avoids “come back later” outcomes.

Strategy & perimeter (Weeks 1–2)

• Service-to-rule mapping across SVF, RPSCS, PTS (and VASP where relevant), with a written perimeter memo your board, banks, and auditors can align on.
• Entity architecture: whether to run one entity (pure fiat) or split (CBUAE for fiat, VASP for non-payment-token crypto).
• Capital/guarantee modelling: paid-up vs. aggregate funds (SVF/RPSCS); PTS reserve options and variable add-ons.

Safeguarding & reserves (Weeks 2–4)

• Float playbooks (SVF) and funds-in-transit models (RPSCS): escrow or insurance/guarantee where settlement >24h; segregation evidence; daily reconciliation MI.
• PTS Issuer reserve design: same-currency escrow mechanics; daily reporting; monthly external attestation cadence; reserve breach runbooks.

Governance, conduct & AML (Weeks 3–6)

• Board/SMF fit-and-proper packs and three-lines-of-defence charters.
• Consumer artefacts: T&Cs, fee/FX, statements, refunds, complaints.
• AML suite: EWRA, CDD/eKYC, monitoring scenarios (including token red flags), sanctions freeze playbooks, STR/SAR processes.

Technology & security (Weeks 4–7)

• Architecture pack: IAM, encryption, data flows, UAE residency, vendor oversight.
• Security evidence: pen-test results, SIEM screenshots, DR failover reports, incident RACI; fork/rollback/finality procedures for PTS.
• Change management: SDLC gates, code review, rollback plans.

Filing, Q&A & conditions (Weeks 7–14)

• End-to-end application: forms, capital and guarantees, policies, tech dossier, independent assessments; controller applications.
• Regulator engagement: written responses, mock interviews, demo scripts; condition tracking to go-live (escrow activation, attestations, dashboards).

Commercials: phase-based fixed fees with capped hours; pass-throughs (application fees, audit/PCI, pen-tests, guarantees) at cost. Optional monthly compliance retainer once live (regulatory reporting, policy upkeep, audit support, and change control).

Why teams pick us

• Specialist UAE focus across SVF/RPSCS/PTS and VASP perimeters, with recent approvals.
• Regulator-ready artefacts that map article-by-article and pre-empt common Q&A threads.
• Practical bank/escrow/auditor coordination and promotion-gating playbooks that prevent last-minute scrambles.

The bottom line

Don’t start with the licence label. Start with flows:

1. If you hold balances, it’s SVF (and likely RPSCS if you run rails).
2. If you provide retail payments, it’s RPSCS (choose the right category and safeguarding).
3. If you touch fiat-referenced tokens, it’s PTS (and possibly SVF/RPSCS for the fiat leg).
4. If you handle non-payment-token crypto, add a VASP entity.

Bake in safeguarding, reserves, and tech/AML evidence before you file. That’s how you convert strategy into a licence, and a licence into a durable, bank-friendly business.

Disclaimer: 

This article is general information and not legal advice. Licensing outcomes depend on your final business model, ownership, technology, partners, and on determinations by the Central Bank of the UAE (and, where relevant, VARA/SCA/FSRA/DFSA). Engage formal counsel for a tailored perimeter memo, documentation set, and regulator engagement plan.

FAQs