CBUAE Payment-Token Services (PTS) Regulation  A Practitioner’s Guide for 2026

What founders, product leaders, and investors need to know about licensing fiat-referenced “stablecoin” services in the on-shore UAE, plus how CRYPTOVERSE Legal can help you get there efficiently.

1) Executive Overview

The Payment-Token Services Regulation (2024) issued by the Central Bank of the UAE (CBUAE) is the on-shore rulebook for fiat-referenced crypto-assets (i.e., payment tokens or “stablecoins”). It creates the licensing/registration architecture, prudential standards, reserve-of-assets requirements (100% backing), conduct and consumer-protection rules, AML/CFT obligations, technology and cyber baselines, and the supervisory/enforcement toolset that applies to anyone who issues, converts (spot only), or safeguards/transfers payment tokens in the UAE or directed at UAE residents.

Four takeaways to frame your build:

1. Perimeter clarity: Only fiat-referenced tokens are in scope. Algorithmic and privacy tokens are banned (no issuance, services, or promotions).
2. Licensing routes: Choose one or more of Issuance, Conversion, Custody & Transfer  with special Registration paths for Foreign Issuers and Non-Objection for certain already-regulated firms.
3. Prudence by design: Expect AED 15m base capital for Issuers plus a variable add-on, AED 3m/1.5m tiers for non-issuers (volumes-based), bank guarantee equal to paid-up capital, and 100% reserve in the same currency with daily reconciliation and monthly audit attestation.
4. Promotion and use gating: Strict rules govern what may be marketed and when tokens may be accepted/transferred as a “Means of Payment.” AED-pegged tokens have the broadest use case once the issuer is licensed; foreign-currency tokens can be registered and are generally gated to VA/VA-derivative purchases.

2) Scope & Service Map

2.1 What is a “Payment Token”?

A fiat-referenced crypto-asset intended and used as a medium of exchange, unit of account, and store of value. It is not legal tender. The Regulation excludes security, commodity, and general “virtual-asset” tokens that are not fiat-referenced.

2.2 Service types (licensable)

• Payment-Token Issuance  mint, distribute, and redeem tokens that reference a fiat currency.
• Payment-Token Conversion  spot buying/selling of payment tokens against fiat (no margin, no derivatives).
• Payment-Token Custody & Transfer safekeeping of client tokens/keys and execution of token transfers.

2.3 Registration routes (non-licensing)

• Foreign Payment-Token Issuer Registration  for non-UAE issuers (including free-zone issuers) seeking to distribute into the UAE market.
• Non-Objection Registration limited/ancillary PTS activity by already-regulated firms (e.g., certain banks, exchange houses, or VA exchanges), subject to CBUAE conditions.

2.4 Bright-line prohibitions

• No algorithmic stablecoins and no privacy tokens: issuance, servicing, and promotions are prohibited.
• Promotion and acceptance constraints apply even for in-scope tokens; see §5.

3) Dirham vs. Foreign-Currency Tokens

• AED-denominated tokens (“Dirham Payment Tokens”):
  • May be issued only by a CBUAE-licensed issuer.
  • Issuance only to UAE residents.
  • Once licensed, AED tokens can be used broadly as a Means of Payment for lawful purposes, subject to general consumer-protection and AML/CFT duties.
• Foreign-currency payment tokens (e.g., USD, EUR):
  • Registration path for foreign issuers to access the UAE market.
  • Use gating typically confines their Means-of-Payment role to purchasing virtual assets (VA) or VA derivatives, unless further permissions are granted.
  • Marketing and acceptance must track these limits (see §5).

4) Licensing Categories & Prudential Requirements

4.1 Licence/registration types

• Dirham Payment-Token Issuer (Licence)
• Payment-Token Custodian & Transferor (Licence)
• Payment-Token Conversion Provider (Licence)
• Foreign Payment-Token Issuer (Registration)
• Non-Objection Registration (for certain firms adding PTS as an ancillary service)

4.2 Capital & bank-guarantee (headline)

• Issuers: AED 15,000,000base capital+ variable add-on tied to outstanding float.
  • Standard model: add-on ~0.5% of float.
  • Alternative reserve option (≤ 50% UAE T-bills/CBUAE M-bills): add-on ~2% of float.
• Custody & Transfer / Conversion:
  • AED 3,000,000 if average monthly token-transfer value ≥ AED 10m; otherwise AED 1,500,000.
• Bank guarantee: typically = paid-up capital, unconditional and callable on first demand.
• Supervisory uplift: CBUAE may raise capital case-by-case based on scale/complexity.

4.3 Reserve of Assets (Issuers)

• 100% same-currency reserve equal to the full token float, held in a segregated escrow with a UAE bank (or with the CBUAE if directed).
• Daily reconciliation of float vs. reserve; monthly external-audit attestation.
• Alternative for a wholly-owned bank subsidiary: ≥ 50% cash, ≤ 50% UAE T-bills/CBUAE M-bills (≤ 6-month average duration), but this triggers the higher capital add-on noted above.

5) Promotion, Acceptance & Transfer Gating

The Regulation strictly controls who may promote, what may be promoted, and when a token may be used/accepted as a Means of Payment:

• Promotions:
  • Only licensed/registered firms (or their disclosed agents) may promote payment-token services.
  • No promotion of algorithmic or privacy tokens.
  • Claims must be accurate and not imply yields, non-existent redemption rights, or unrestricted use.
• Acceptance/transfer rules:
  • Providers must not knowingly execute or direct transfers unless the transfer concerns:
    • A licensed AED token (any lawful use), or
    • A registered foreign token used as a Means of Payment for VA/VA-derivative purchases.
  • Internal controls should block disallowed flows and flag exceptions for review.

Implication: Your product menu, T&Cs, agent contracts, UX copy, and monitoring logic must embed these gates.

6) Conduct of Business & Customer Protection

• Customer Agreements: spell out fees, FX spreads, redemption, rights/obligations, complaints, and statements cadence.
• Safeguarding client tokens: segregated wallets; strong key-management (HSM/MPC), access controls, dual-control for signing, and transfer-consent mechanics.
• Liability & refunds: clear treatment for unauthorised transfers and operational errors; well-defined refund timelines.
• Monthly statements for holders where appropriate; dispute-resolution SLAs and escalations.
• Marketing controls: align materials with promotion gating and use-case limits; maintain pre-publication legal sign-off.

7) AML/CFT & Sanctions

• High-risk designation for payment-token services: treat AML/CFT as a gate-opener, not a box-tick.
• Risk-based programme aligned to UAE AML Law and FATF:
  • Enterprise-wide risk assessment (EWRA) tied to products, corridors, and customers.
  • CDD/eKYC (digital onboarding acceptable if bank-grade).
  • Transaction monitoring: scenarios for layering, mule accounts, rapid in/out, chain-hopping (where relevant), structuring, and mixer exposure.
  • Sanctions screening/freezing: real-time screening, alerts triage, freezing/notification workflows.
  • Wire-transfer-style obligations where applicable.
  • Reporting: STR/SAR to FIU; timely incident notices to CBUAE.
• VASP counterparties: enhanced due diligence for exchanges, brokers, or token issuers; wallet screening; proof-of-reserves representations (where relevant).

8) Governance, Technology & Operational Resilience

• Governance & fit-and-proper: Board and Senior Management must be suitable; institute independent risk, compliance/MLRO, and internal audit lines commensurate with scale.
• Information Assurance baseline:
  • Architecture & IAM: environment segregation; least privilege; MFA; periodic access recertification.
  • Encryption at rest/in transit; key-lifecycle management.
  • Logging/SIEM with correlation rules; alerting; incident playbooks and RACI.
  • BCP/DR: documented RTO/RPO; tested failover (evidence required).
  • Pen-tests & cyber-attack simulations (volume-scaled).
  • Fork/rollback handling and transfer finality policies for chains you support.
• Data & records: secure storage, UAE data residency where applicable, 5-year retention minimum, rapid retrieval for audits and disputes.

9) Reporting, Supervision & Enforcement

• Ongoing reporting: volumes, onboarding, complaints, incidents, capital/reserve positions; CBUAE may require daily, monthly, or ad-hoc returns.
• Supervisory powers: the Bank can cap issuance/usage/onboarding, impose conditions, and suspend/withdraw licences.
• Enforcement: administrative/financial sanctions; management changes; cease-and-desist; public notices in serious cases.

10) Transitional Arrangements & Interplay with Other Rulebooks

• Transition: one-year from entry-into-force for pre-existing businesses to obtain the relevant authorisations; non-compliant activity must cease thereafter (subject to CBUAE discretion to extend).
• Interplay: the PTS Regulation clarifies where it overrides or complementsRPSCS (retail payments) and SVF (stored value) in virtual-asset contexts:
  • RPSCS remains your wrapper for fiat payment services (accounts, cards, acquiring, transfers).
  • SVF applies if you hold balances or grant contractual fiat redemption.
  • PTS governs the payment-token leg (issuance, spot conversion, custody/transfer).
  • For non-payment-token virtual assets (e.g., BTC/ETH), expect VASP perimeters (VARA/SCA/FSRA/DFSA) in addition to your fiat licences.

11) Structuring Patterns that Work

Pattern A  Fiat↔Payment-Token Gateway (no stored fiat value)

• Licences: Payment-Token Conversion + Payment-Token Custody & Transfer.
• Add RPSCS Category II (or I if you also need the RPSCS payment-token facet) to move fiat in/out (domestic and cross-border).
• When to use: You don’t want to hold fiat balances; you just convert fiat ↔ payment tokens and settle out.

Pattern B  Full Wallet + Cards + Payment-Token Ramp

• SVF (to hold customer fiat balances) + RPSCS Cat II (or I) for payment rails.
• PTS: Conversion and Custody & Transfer for the token leg; Issuance if you’ll launch your own AED token.
• When to use: You need a stored-value wallet with cards and a payment-token on/off-ramp.

Pattern C  Institutional Settlement Token Hub

• PTS: Conversion and Custody & Transfer only; integrate with wholesale fiat rails via partner banks.
• When to use: B2B/treasury use cases (no retail wallet, no SVF).

12) Timeline (Well-Prepared File)

• Months 1–2 Perimeter memo: tokens supported; fiat vs. token flows; promotions/acceptance gating; pick PTS licence set; if relevant, confirm SVF/RPSCS add-ons.
• Months 2–4  Prudential & reserve design (if Issuance); treasury and reconciliation SOPs; audit attestation plan.
• Months 3–6  Governance & AML: Board/SMF F&P; EWRA; CDD/monitoring/sanctions; Customer Agreements; agent/outsourcing pack.
• Months 4–7  Tech dossier: architecture; IAM; encryption; logging/SIEM; DR evidence; pen-test results; fork/finality runbooks.
• Months 7–10  File & engage: forms, capital/guarantee evidence, policy suite, tech pack; Q&A; demos/interviews.
• Months 10–14 Conditions precedent: escrow live; auditor engagement and monthly attestation cadence; reporting dashboards; go-live readiness.

13) Common Pitfalls (and How to Avoid Them)

• Token mis-classification: treating BTC/ETH as payment tokens.
  Fix: lock scope to fiat-referenced tokens for PTS; otherwise obtain VASP authorisations.
• Promotion breaches: marketing use cases beyond what’s permitted (e.g., foreign tokens for general retail).
  Fix: legal sign-off on all copy; embed gating logic in flows and agent materials.
• Reserve shortfalls: weak reconciliation or non-segregated escrow.
  Fix: automate daily D/D+1 reconciliations; escrow letters with restrictions; monthly audit attestation.
• Capital under-sizing: volumes outgrow capital tier.
  Fix: forecast and set early-warning triggers; prepare board-approved top-up pathways.
• Tech evidence gaps: no pen-test; untested DR; unclear fork handling.
  Fix: deliver a full tech pack with tested controls and documented playbooks.
• Blurring perimeters: combining fiat custody (SVF) and token operations in one team/entity with no controls separation.
  Fix: separate entities/functions or implement strict Chinese walls and role segregation.

14) How CRYPTOVERSE Legal Can Help

We act as your single-threaded owner from scoping to go-live, aligning law, prudential design, AML, and technology to the PTS framework, and, where relevant, to SVF and RPSCS. Our approach is to submit a working-grade model with evidence, so the file passes credibility checks quickly.

A. Strategy & Perimeter 

• Service-to-rule mapping: which tokens, which chains, which use cases (retail vs. VA purchases); confirm AED vs. foreign token implications and promotion/acceptance gates.
• Authorisation architecture: PTS licence set (Issuance/Conversion/Custody & Transfer) plus any SVF/RPSCS pairing; whether you need a Foreign Issuer Registration or Non-Objection route.
• Capital & guarantee plan: model float, pick reserve option (cash-only vs. bank-subsidiary split), and align variable add-ons.

B. Reserves, Reconciliation & Treasury

• Reserve structure: same-currency escrow with UAE bank; mandated design for daily reconciliation and monthly audit attestation.
• Reconciliation tooling: D and D+1 workflows, exception handling, MI to senior management and the Board.
• Audit cadence: draft the monthly external attestation plan and auditor engagement letters.

C. Governance, Conduct & AML 

• Board/SMF fit-and-proper: role descriptions; reporting lines; committee charters.
• Customer Agreements & disclosures: fees/FX/redemption; liability/refunds; complaint handling; statement templates.
• Agent/outsourcing: contracts, SLAs/KPIs, audit rights, training packs; pre-clearance where needed.
• AML/CFT: EWRA; CDD/eKYC and monitoring scenarios tailored to token flows; sanctions freeze workflows and STR/SAR playbooks.

D. Technology & Security 

• Architecture pack: IAM, encryption, data flows, UAE data residency, vendor oversight.
• Security evidence: pen-test results, SIEM screenshots, DR failover reports, incident RACI, and fork/finality runbooks.
• Change management: secure SDLC, code reviews, rollback plans.

E. Filing, Q&A & Conditions 

• End-to-end application: forms, capital/guarantee proofs, reserve documentation, policy suite, tech dossier, independent assessments.
• Q&A and hearings: written responses, live demos, management interviews; close conditions (escrow go-live, auditor attestations, reporting dashboards).
• Go-live: soft-launch limits, MI packs for reconciliation/incidents/complaints, and AML reporting cadence.

Why teams pick us

• Specialist UAE focus across PTS/SVF/RPSCS and parallel VASP perimeters.
• Regulator-ready artefacts that map requirements article-by-article, compressing Q&A cycles.
• Bank/escrow/audit coordination and practical promotion-gating playbooks that keep operations compliant at launch.

Commercials: fixed-fee phases with capped hours; pass-throughs (e.g., application fees, audit/attestations, pen-tests, bank guarantees) at cost. Optional monthly compliance retainer post-launch.

15) What You Should Do Next

1. Confirm scope: tokens (AED vs. foreign), chains, use cases, and whether you’ll issue, convert, or custody/transfer.
2. Decide on fiat rails: will you hold fiat balances (SVF) and/or need RPSCS for account/cards/transfers?
3. Model capital & reserves: pick cash-only or bank-subsidiary split; size variable add-on and bank guarantee.
4. Start the artefacts: Customer Agreements, agent contracts, AML pack, architecture/IAM diagrams, pen-test and DR test plans.
5. Engage early with settlement bank(s) for escrow and with your external auditor for the monthly reserve attestation plan (if issuing).

Disclaimer:

This guide provides general regulatory information and is not a substitute for formal legal advice. Authorisation outcomes depend on your final business model, ownership, technology and partners, and on CBUAE determinations. For formal filings or regulator engagement, please seek tailored counsel.nd filings, engage counsel to review your structure, documentation, and disclosures.

FAQs