UAE Wallet App Development: Build for CBUAE SVF
AI Summary: UAE wallet app development starts by identifying whether the product is a Stored Value Facility and which CBUAE permissions or partner arrangements cover it. The issuer, customer funds and redemption obligations shape the architecture. Onboarding, wallet ledgering, payments, reconciliation, safeguarding controls and operational oversight must follow the actual regulated business model. |
If your UAE wallet lets customers load money now and spend or transfer it later, you are almost certainly building a Stored Value Facility. The Central Bank of the UAE (CBUAE) regulates that activity under its Stored Value Facilities (SVF) Regulation, and the decisions it forces on you, from who issues the balance to where the float sits, shape the product architecture long before the first screen is designed.
This guide is for founders, banks and product teams building a wallet for the UAE onshore market. It covers when the SVF Regulation applies, the routes to market, what the licensing requirements mean in practice, and how to turn float safeguarding, limits and AML/CFT into software. For general wallet features and UX, see our digital wallet app development guide. For crypto wallets in the region, see our white-label crypto wallet guide for UAE and Middle East fintechs. For licences across markets, see our Fintech Licensing Requirements 2026 guide.
UAE wallet app development: When a UAE wallet is a Stored Value Facility
The SVF Regulation in the CBUAE Rulebook covers facilities that store value customers have paid in and that can be used to make payments. In product terms, the trigger is the stored balance. An app that only initiates payments from a customer's bank account without holding value is a different problem; an app that keeps a balance customers can spend later is squarely in SVF territory.
The Regulation also allows certain schemes to be exempted from licensing, for example some cash-reward, bonus-point and limited-provider schemes (Article 2, scope of application). If you are building a closed-loop loyalty wallet, check the exemption criteria with counsel before assuming you need a licence, and before assuming you do not.
Three CBUAE regimes are easy to confuse:
Regime | What it governs | When a wallet touches it |
Issuing and operating stored value, the float, SVF conduct and AML | Any wallet that holds a customer balance | |
Retail payment services such as payment account issuance, merchant acquiring, payment aggregation, domestic and cross-border transfers, payment initiation and account information | Wallets that also acquire merchants, aggregate payments or move funds in ways beyond stored value | |
Payment token issuance, conversion, and custody and transfer | Wallets that hold or move stablecoin-type payment tokens |
This guide covers onshore CBUAE licensing. The financial free zones, DIFC and ADGM, have their own regulators and rules, and the SVF Regulation's eligibility rules exclude companies incorporated in financial free zones from applying for an SVF licence.
Three routes compared
Route | Who issues the stored value | What you need | Best for | Trade-offs |
Own SVF licence | Your UAE company | CBUAE licence under the SVF Regulation, capital, float safeguarding, governance and AML/CFT framework | Wallet businesses that want full control of product, pricing and partnerships | Significant capital and governance commitment; long preparation |
Bank-issued wallet | A UAE licensed bank | Bank notifies CBUAE and obtains a No Objection letter before starting SVF business | Banks launching a wallet, or fintechs building one for a bank | Bank owns the licence, risk appetite and roadmap |
Partner with a licensed SVF issuer or bank | The partner | Commercial agreement, clear allocation of regulated activities, outsourcing controls | Brands and platforms that want a wallet experience without becoming an issuer | Partner dependence; limited control of limits, onboarding and fees |
According to Article 4 on the application procedure, licensed banks are deemed authorised to issue SVFs but must notify CBUAE in writing and obtain a No Objection letter before starting. For a fintech, that makes a bank partnership a realistic route: the bank holds the authority, and your team builds and runs the platform under the bank's oversight.
The partner route works best when contracts and software agree. If the partner is the issuer, your app should show that clearly in terms, disclosures and receipts, and your system should not make decisions, such as raising a customer limit, that the agreement reserves to the issuer. We cover the general pattern in our License-as-a-Service guide.
Licensing requirements in plain terms
The SVF Regulation sets out who can apply and what they must hold. Key points for planning:
Incorporation. A non-bank applicant must be a company incorporated in the UAE, which can include free zones but excludes financial free zones (Article 3).
Capital. An SVF licensee must maintain paid-up capital of at least AED 15 million, and aggregate capital funds of at least 5% of the float (Article 7). The second test means required capital rises as customer balances grow.
Float safeguarding. The float must be segregated from the licensee's own funds and held in segregated accounts with a bank under the conditions in Article 11, with protections designed for customers if the licensee fails.
Conduct. Article 13 covers business conduct and customer protection, including that storage limits be reasonable, justified and set out in your operating rules.
AML/CFT. Article 14 requires risk-based AML/CFT procedures, including controls such as limits and monitoring for higher-risk facilities.
The application asks for substantial documentation, including a business plan, ownership and financial information, policies and independent assessments. Much of that is technical: what you describe in the application becomes the system the regulator expects to see.
What the SVF Regulation turns into software
The float becomes a ledger problem
The float is the sum of customer balances you owe. Your platform needs a double-entry ledger where every customer balance is a liability, matched by money in the segregated float account. Build daily, and ideally intraday, reconciliation between the ledger and bank statements, with break investigation, ageing and sign-off. Your capital monitoring should read the same ledger, because the 5% test depends on it.
Limits become a rules engine
Storage limits, transaction limits, velocity rules and funding-source restrictions should live in a configurable rules engine, not in app code. Limits can vary by account type and customer risk, and you will want to change them without a release. Log every limit change with who approved it.
Conduct rules become UX and back office
Fee disclosures, terms, receipts, complaints and redemption flows are customer-facing obligations. Store which version of terms each customer accepted, give support teams a view of the full transaction history, and design refund and redemption paths that move money out of the float cleanly.
AML/CFT becomes onboarding, monitoring and case management
Identity verification, beneficial ownership for business wallets, sanctions and PEP screening, ongoing monitoring and suspicious transaction reporting all need workflow tooling. Detecting multiple accounts held by the same person or group is a common expectation for stored value products, so design customer identity resolution early.
Technology risk becomes evidence
Security architecture, access control, encryption, logging, penetration testing, business continuity and exit planning will be reviewed. Treat them as continuous evidence the platform produces, not a document written once. Confirm hosting and outsourcing expectations with CBUAE and your partners before choosing cloud regions and vendors.
Reference architecture
Layer | Components | SVF concern |
Channels | iOS, Android, web, Arabic and English UI, merchant SDKs | Disclosures, terms acceptance, accessibility |
Identity | eKYC, document and liveness checks, business onboarding, screening | AML/CFT, customer identity resolution |
Ledger | Double-entry wallet ledger, fee engine, statements | Float accuracy, redemption, capital test inputs |
Float and banking | Segregated float accounts, top-up and payout rails via bank partner | Article 11 segregation, reconciliation |
Limits and risk | Rules engine, velocity, device and fraud signals | Storage and transaction limits, higher-risk controls |
Payments | P2P, merchant QR or checkout, bill payment, cards where in scope | RPSCS boundaries, scheme rules |
Compliance | Transaction monitoring, case management, regulatory reporting | Suspicious transaction reporting, audit trail |
Operations | Back office, complaints, disputes, refunds | Conduct and customer protection |
Platform | Observability, immutable logs, BCP and DR | Technology risk evidence |
Key APIs and integrations
eKYC and identity verification, sanctions, PEP and adverse-media screening
Bank partner APIs for segregated float accounts, top-ups, payouts and statements
Card issuing or acquiring processors if the wallet issues cards or accepts card top-ups
Merchant payment acceptance (QR, online checkout) and bill payment aggregators
Transaction monitoring and fraud engines
Notifications, e-signature and document generation for terms and statements
If you are choosing a build partner in the region, our overview of fintech companies in the UAE for custom software development explains what to look for.
Compliance features checklist
Ledger with float reconciliation, break management and daily sign-off
Capital monitoring that recalculates the float-based requirement from live data
Configurable storage, transaction and velocity limits by account type and risk
Versioned terms, fee disclosures and consent records
Redemption and refund flows with clear timelines shown to customers
Risk-based onboarding, ongoing monitoring, screening and STR workflow
Multiple-account detection and device or identity linking
Complaints handling and dispute tracking
Role-based access, maker-checker approvals and audit logs
Incident management, BCP tests and an exit plan that returns customer funds
Cost and timeline drivers
Driver | Why it moves cost and time |
Route | Own licence means building the full control set and evidence; bank or partner route shifts effort to integration and oversight |
Use cases | P2P only is simpler than merchant payments, bill pay, cards and cross-border |
RPSCS or payment token scope | Extra licences or partners add requirements and integrations |
Bank partner readiness | Float accounts, APIs and statement feeds often set the schedule |
Limits and risk model | More tiers and rules need more testing and governance |
Localisation | Arabic and English UX, local documents and support |
Existing platform | Reusing a proven ledger and onboarding stack shortens the build |
We do not publish a fixed price for a UAE wallet because the route and use cases change the scope so much. The fastest way to an estimate is mapping your features to the three regimes above.
Teams that have already built elsewhere will recognise the pattern. India's prepaid wallets follow a different rulebook, covered in our PPI wallet guide, and US wallets in our US digital wallet guide. The ledger and reconciliation core carries over; the licence, limits and float rules do not.
Build plan
Regulatory scoping with counsel: SVF, RPSCS and payment token boundaries, exemptions, and route choice.
Ledger and float design first, with the bank partner's account structure agreed.
Core wallet: onboarding, top-up, P2P, payments, redemption.
Risk and compliance layer: limits engine, monitoring, case management, reporting.
Evidence and testing: security testing, reconciliation reports, BCP and exit tests for the application or the partner's due diligence.
Controlled launch with conservative limits, then expand use cases.
FAQs
Does every wallet app in the UAE need an SVF licence?
No. The SVF Regulation applies to facilities that store value for later payments, and some schemes can be exempted. Apps that only initiate payments without holding a balance need a different analysis. Get legal advice on your specific model.
What capital does an SVF licensee need?
The SVF Regulation requires paid-up capital of at least AED 15 million and aggregate capital funds of at least 5% of the float, so the requirement can rise as balances grow.
Can a bank launch a wallet without a separate SVF licence?
Licensed banks are deemed authorised to issue SVFs, but they must notify CBUAE in writing and obtain a No Objection letter before starting SVF business.
Can I apply for an SVF licence from DIFC or ADGM?
The SVF Regulation's eligibility rules exclude companies incorporated in financial free zones. DIFC and ADGM have their own regulators and regimes, which you would evaluate separately.
Do I also need a retail payments licence?
Possibly. If your wallet acquires merchants, aggregates payments or provides other retail payment services, check the Retail Payment Services and Card Schemes Regulation alongside the SVF Regulation.
Can a UAE wallet hold stablecoins?
Payment tokens are covered by CBUAE's separate Payment Token Services Regulation. Treat stablecoin features as a separate regulatory workstream.
Build your UAE wallet with Fintegration
Fintegration builds regulated wallet platforms: double-entry ledgers, float reconciliation, limits engines, eKYC and AML workflows, bank and card integrations, and the evidence regulators and bank partners ask for. We help you choose between your own SVF licence and a partner route before the architecture locks you in. Talk to our team to scope your UAE wallet.
