Guide
Setting Up an Embedded-Finance or Banking-as-a-Service Business in the UAE
The short answer
The Central Bank of the UAE (CBUAE) decides, through its rulebook. Its Retail Payment Services and Card Schemes Regulation (C 15/2021, in force since 6 June 2021) sets the licensing conditions for digital payment services. Embedded finance puts regulated products inside a non-financial journey: a payment in a marketplace, an account in a software tool, credit at checkout. The licence usually belongs to an institution behind the screen, not to the platform in front of it. What decides the route is which party performs each regulated task: onboarding, decisions, money movement, servicing and complaints. The platform's logo does not answer that.
Four shapes of embedded business
The label covers different companies. An orchestration layer connects regulated providers through one interface and may never touch money. A programme manager runs products under a sponsor's licence and does much of the operational work. A marketplace places third-party financial products beside its own. A vertical software company adds payments, accounts or credit to a tool its customers already use. A business that buys receivables is covered in the factoring and invoice finance guide.
They sit in different places on the perimeter. The question to ask of each is the same: which tasks does this company itself perform? Arranging, issuing, servicing and distributing a financial product are each a different answer from displaying one. Write the answer down per product, because a platform that starts with payments and adds credit changes its perimeter on the day it does. A venue or intermediary dealing in carbon credits faces the same function test, set out in the carbon credit marketplace guide.
What the CBUAE rulebook covers
Two CBUAE regulations bear directly on this model. The Retail Payment Services and Card Schemes Regulation covers payment services and cards. The Open Finance Regulation covers access to customer financial data and the initiation of services on a customer's behalf.
Stored value, credit and deposit-taking are governed elsewhere in the rulebook. Confirm the current text for each product you plan to offer, and do not rely on a summary, including this one. This guide states which regulator decides; the capital, safeguarding and governance terms for your category are in the rulebook, and you should confirm the current figures with the CBUAE before applying.
If your product involves virtual assets, the VARA route belongs in the same discussion, and the fintech setup work starts from a product map rather than a licence list.
The sponsor relationship is the business
In most embedded models the sponsor contract matters more than the company formation. It sets what you can offer, how customers are onboarded, who answers a complaint and who bears a loss. It also sets how easily you can leave.
Test the contract on five points:
- which legal entity provides each financial product;
- who owns the customer relationship and the data;
- who handles complaints and who pays for losses;
- how fraud and remediation are allocated;
- whether the programme can migrate to another sponsor, and what data moves with it.
Treating the sponsor as a replaceable interface is the classic error. A sponsor has its own regulator, its own risk appetite and its own right to withdraw. Design for portability on day one, not after a notice letter.
Be careful with copy. Product pages, emails and app screens must not imply the platform is the licensed provider. Disclosures and complaints routes should name the institution that is.
Licence or sponsor, feature by feature
Hold the authorisation yourself, or contract it in. Neither is wrong. Holding it means your balance sheet and your people meet the regulator's terms for that category. Contracting it in means programme fees, revenue share and dependency.
Many platforms mix the two, and move functions in-house as volumes justify the capital. Document the split: functions you perform, functions the sponsor performs, and roadmap features that would shift the line. Sponsors, regulators and banks read that document with different eyes, so it must be one story. Where the platform takes payments from merchants, the merchant acquirer guide covers the acquiring side of the same question.
Group structure can place technology, intellectual property and any licensed function in separate entities. Each needs a genuine role. A structure built to advertise a low setup cost shows up later as a sponsor-diligence problem.
What a bank or sponsor reads
Banks and sponsor institutions both start from whose licence covers each flow of money. Prepare:
- a product-to-provider responsibility matrix;
- the target sponsor and integration plan;
- the customer journey and disclosures;
- compliance and operational service design;
- a commercial model that survives the sponsor's costs.
The commercial model deserves attention. Programme fees and revenue share can make a product that looks profitable in a spreadsheet unprofitable in a contract. Run the numbers on the sponsor's terms before you build.
Bring the same facts to your own bank file. Our corporate bank account readiness work tests that the product, the contracts and the account application tell one story. Coherence removes avoidable questions. It does not guarantee an account or a sponsor.
What commonly goes wrong
- Treating the sponsor as a replaceable interface.
- Copy that implies the platform is the licensed provider.
- No allocation of fraud, complaints and remediation between platform and sponsor.
- Designing data portability only after a partner exits.
- Adding a product, such as credit or a card, without reassessing the perimeter.
Compare complete routes rather than formation quotes. Cost depends on the route, and Velarozone's own fee is itemised in the engagement letter, as set out in how Velarozone works. Regulator-set capital figures come from the CBUAE rulebook, and programme and revenue-share terms come from the sponsor.

