- SVF · RPSCS · PTS — CBUAE
SVF, RPSCS & PTS Under the CBUAE
How the three CBUAE payment regimes interact — and how to structure multi-layered payment models without triggering unintended capital escalation.
📐
CBUAE perimeter triggers
💰
Capital exposure (AED 15m + 5% vs Cat I–IV)
🔗
Token governance requirements
⚙️
Supervisory intensity thresholds
⬆️
Multi-regime structuring strategy
01 / The Big Picture
Three Regimes, One Regulator
The CBUAE regulates three distinct but interconnected payment regimes. Each governs a different layer of payment infrastructure. Understanding where your business sits — and whether it triggers more than one — is critical before launch.
Stored Value Facilities
SVF
Typical Models
- E-wallets storing AED balances
- Prepaid cards
- Super apps holding user balances
- Marketplace stored funds
Prudential Profile
- Capital: AED 15M + ≥ 5% Float
- Mandatory Float segregation
- Liquidity & redemption certainty
⬤ Float-centric.
Retail Payment Services & Card Schemes
RPSCS
Regulated Activities
- Payment Account & Instrument Issuance
- Merchant Acquiring & Aggregation
- Domestic & Cross-Border Transfers
- Payment Initiation & Account Info
- Payment Token Services (Cat I ref)
Prudential Profile
- Tiered capital (Category I–IV)
- Transaction-volume escalation
- Client fund safeguarding
⬤ Transaction-centric.
Payment Token Services
PTS
Regulated Activities
- Issuing Payment Tokens (stablecoins)
- Buying/selling & exchange
- Token custody
- Merchant acceptance
- Offering tokens to the public
Prudential Profile
- Category I under RPSCS
- White paper approval (issuance)
- Reserve governance & enhanced AML
⬤ Token-centric.
02 / How They Interact
How the Three Regimes Interact
Four intersection scenarios — from dual-regime to the full triple-regime super app model.
A
SVF + RPSCS
SVF
RPSCS
If a wallet stores prepaid fiat (SVF) and executes transfers or acquiring (RPSCS), dual regulatory exposure is likely.
Example: A super app holding AED balances and enabling peer-to-peer transfers.
B
RPSCS + PTS
RPSCS
PTS
If a PSP facilitates Payment Token exchange or allows merchant acceptance of tokens, Category I exposure is triggered under RPSCS.
Example: A cross-border remittance provider settling via stablecoins.
c
SVF + PTS
SVF
PTS
If a wallet holds fiat balances and issues or converts into stablecoins, float is governed by SVF while token issuance falls under PTS. Capital and governance expectations escalate significantly.
D
All Three Regimes — SVF + RPSCS + PTS
SVF
RPSCS
PTS
A complex super app may store prepaid fiat (SVF), provide transfers and acquiring (RPSCS), and issue or exchange stablecoins (PTS).
⚠️
03 / Capital Comparison
Capital Comparison Across Regimes
SVF generally has the highest fixed capital floor. PTS escalates supervisory intensity even if capital is similar.
Regime
Base Capital
Escalation Trigger
SVF
AED 15M
Float growth (5%)
RPSCS
Cat III
AED 500k – 1M
Transaction volume
RPSCS
Cat II
AED 1M – 2M
Cross-border exposure
Likely SVF
Cat I
AED 1.5M – 3M
Full-scope PSP
PTS
Category I
Token activity
04 / Decision Checklist
Structuring Decision Checklist
Misclassification can result in incorrect capital modelling, licence rejection, enforcement risk, and banking relationship disruption.
1
Are customers pre-funding balances stored electronically?
→ SVF
2
Are you executing payment transfers or acquiring merchants?
→ RPSCS
3
Are you issuing or facilitating blockchain-based Payment Tokens?
→ PTS
4
Are you combining any of the above?
→ Multi-regime
05 / Supervisory Intensity
Supervisory Intensity Scale
As you layer storage + transfers + tokens, supervisory scrutiny increases exponentially.
Low
Cat IV
Payment Initiation
Moderate
Cat III
Domestic PSP
High
Cat II
Cross-Border PSP
Very High
SVF with
Large Float
Ultra High
SVF + RPSCS
+ PTS Combined
06 / Common Mistakes
Common Structuring Mistakes
- Assuming one licence covers all activities
- Treating stablecoin reserves as SVF Float
- Ignoring Category I escalation under PTS
- Expanding wallet functionality without licence variation
- Underestimating capital interaction effects across regimes
07 / Our Services
How We Structure Multi-Regime Models
🔬
Regulatory Perimeter Mapping
Classify across SVF, RPSCS, PTS
🔄
Multi-Licence Feasibility
Dual / triple licence analysis
📊
Integrated Capital Modelling
AED 15m + 5% vs Category tiers
🛡️
Float vs Reserve Architecture
Cross-regime safeguarding design
🏛️
Governance Harmonisation
Unified governance frameworks
⚖️
AML Risk Segmentation
Fiat vs token AML frameworks
📝
White Paper Drafting
PTS issuance documentation
🤝
Regulator Engagement
Full CBUAE application management
Quick Takeaways
Key Facts
SVF = stored prepaid fiat value
RPSCS = retail payment execution
PTS = blockchain-based tokens
All three supervised by CBUAE
Capital models differ materially
Combined models require deliberate structuring
08 / FAQs
Frequently Asked Questions
Not automatically. Activity-based triggers determine exposure. A firm combining storage, transfers, and tokens may need multiple licences.
SVF has the highest fixed floor at AED 15M, plus the 5% Float requirement which scales with growth. Combined models layer additional capital obligations.
Yes. It typically escalates to Category I licensing under PTS and significantly increases supervisory scrutiny, reserve governance, and AML obligations.
Yes, if designed correctly before launch. Proper activity classification and sequenced licensing can optimise capital allocation across regimes.
Get Started
Structure Your Multi-Regime Model Correctly
Whether your platform triggers one, two, or all three regimes — we map the regulatory perimeter, model integrated capital exposure, and manage the full licensing process under the CBUAE.