Every embedded finance project in the UAE reaches the same fork. You can build on a licensed partner’s rails and go to market faster with less capital, or you can hold your own licence and own the economics and the roadmap. The decision is usually framed as speed against control, which is accurate but incomplete, because it also determines your cost base, your compliance obligations and how much of the product you are allowed to change without asking someone.
The right answer depends on how central financial services are to your business, not on which option looks cheaper in year one.
Key Takeaways
- Partner-led models get you live faster and with less capital. Own-licence models give better unit economics and control at higher fixed cost.
- The switching cost between the two is high, so decide against a three to five year view rather than a launch date.
- In the UAE, mainland, DIFC and ADGM are separate regimes with different regulators. Where you establish changes what you can do and who you can serve.
- Under a partner licence you inherit their compliance posture, their pace of change and their risk appetite, including on customers they decline.
- Many platforms start partner-led and migrate later. Architect for that from the beginning rather than discovering the coupling at migration time.
What each model actually means
Banking as a Service (BaaS): a licensed institution provides regulated capabilities such as accounts, payments, cards or credit through APIs, so a non-licensed platform can offer them to its own customers under the institution’s regulatory cover.
Under a partner model, the licensed institution holds the regulatory relationship, the customer funds and the compliance obligation. You build the experience and own the customer relationship commercially. You go live faster, you need materially less capital, and you inherit a compliance framework rather than building one.
Under your own licence, you hold the permissions directly. You control product design, pricing and roadmap without a partner’s approval, you keep more of the economics, and you carry the full weight of capital requirements, regulatory reporting, governance and a compliance function with named accountable individuals.
There is a middle position that is increasingly common, which is holding a narrow licence covering only the activity central to your business while using partners for everything adjacent. It is often the most sensible answer and the one least considered, because the debate tends to be framed as binary.
The UAE has three regimes, not one
This is the part that most often surprises teams arriving from other markets. The UAE mainland is regulated by the Central Bank of the UAE. The Dubai International Financial Centre operates under the Dubai Financial Services Authority. Abu Dhabi Global Market operates under the Financial Services Regulatory Authority. These are separate regimes with separate licences, and a permission in one does not carry into the others.
That distinction runs through the regulations themselves. The Central Bank’s Payment Token Services Regulation, issued on 7 June 2024 and in force from 6 July 2024, explicitly carves out the DIFC and ADGM. The Retail Payment Services and Card Schemes Regulation governs payment service provider licensing and card scheme requirements on the mainland. The Open Finance Regulation, gazetted in April 2024, obliges Central Bank licensees including banks and insurers to give Open Finance Providers access to customer data and the ability to initiate transactions.
The practical consequence is that where you establish is a product decision, not an administrative one. A DIFC entity serving mainland retail customers is a different proposition from a mainland entity doing the same thing, and the difference needs to be settled with counsel before architecture, because it determines what your systems must do.
Cost, and where it actually sits
Partner models look cheaper because the visible cost is per-transaction or revenue-share, which scales with the business and requires little upfront. Own-licence models carry regulatory capital, a compliance function, audit, regulatory reporting and the systems to produce it, and those costs exist whether you have a hundred customers or a hundred thousand.
The crossover is a volume question. Below it, partner economics win comfortably. Above it, the revenue share on every transaction exceeds what a fixed compliance base would cost, and the gap keeps widening. Model it honestly over three to five years with your own volume assumptions rather than relying on a general rule, because the crossover point varies enormously by product and margin.
Include one cost that is easy to miss on the partner side, which is the cost of constraint. If a partner cannot support a product change you need, the cost is not their fee. It is the revenue from the product you could not launch.
What you inherit from a partner
Choosing a partner means adopting their risk appetite, their onboarding standards, their pace of change and their operational reliability.
Their appetite decides which of your customers get accepted. If a partner declines a segment that matters to you, that is your problem to solve, not theirs. Their onboarding standards shape your customer experience directly, including how much friction sits in your signup. Their release cadence caps yours, because a product change that needs a partner change moves at their speed. And their outages are your outages, experienced by your customers under your brand.
Diligence should cover their regulatory standing, their track record with other platform clients, their API maturity and versioning discipline, their incident history, and what happens if the relationship ends. That last one matters most. Ask specifically what customer data and account portability look like on exit, and get the answer in the contract rather than in a conversation.
Architect so the decision is reversible
Most platforms that start partner-led eventually reconsider, either because volume has crossed the economics threshold or because the constraint has started costing real product. The migration is painful when the partner’s model has spread through the codebase, and manageable when it has not.
Keep partner-specific logic behind an internal interface that expresses your own domain model, so accounts, payments and customers are your concepts rather than theirs. Own your customer data in your own systems rather than treating the partner as the store of record for anything you would need on day one after a switch. Keep your own ledger, reconciled against the partner’s, rather than relying on their balances as the truth. That ledger is also what makes a later migration verifiable rather than a leap.
This is the same discipline described in legacy system integration, applied to a supplier instead of an old platform. The principle is identical: an anti-corruption layer keeps someone else’s model out of yours.
Frequently asked questions
Which model should we start with?
Most platforms should start partner-led unless financial services are the core business rather than an attachment to it. The exception is where the product depends on something no partner will support, in which case the licence conversation has to happen first regardless of stage.
How long does a licence application take in the UAE?
It varies by regulator, licence category and how prepared the application is, and it is measured in quarters rather than weeks. Treat it as a parallel workstream with its own owner from the start of the programme, not as a step that begins once the product is built.
Can we serve both mainland and free zone customers?
It depends on your permissions, and it is a question for regulatory counsel rather than an architecture decision. What matters technically is that you may need to segregate customers, data and flows by regime, and retrofitting that segregation later is considerably more expensive than designing for it.
What does Open Finance change for us?
It moves the UAE toward customer-consented access to bank-held data and transaction initiation, which reduces the advantage of holding accounts purely to see the data. For platforms, it means some capabilities that once required a partner relationship may become obtainable through an Open Finance Provider position instead. It is worth factoring into a three-year view rather than a launch plan.
Do we need our own ledger if the partner has one?
Yes. A partner’s ledger is their record of your position, not your record of your customers’ positions. Without your own, reconciliation is impossible to verify independently, disputes are unresolvable, and migrating away is close to impossible. It is one of the highest-value pieces of engineering in an embedded finance build.
Choosing your embedded finance model?
Kentro builds embedded finance platforms across mainland UAE, DIFC and ADGM, including the ledger, reconciliation and partner abstraction that keep the decision reversible.
