Building an app like Tabby in the UAE is a licensing project with a software project attached, and most founders get that order backwards. The Central Bank of the UAE regulates buy now pay later as short-term credit, which means you either hold a Restricted Licence as a finance company, with a minimum capital requirement of AED 20 million, or you operate as the agent of a bank that already holds one. The mobile app, the merchant integration and the risk engine are perhaps six to nine months of engineering. The licence, the capital and the credit losses are the part that decides whether the business exists.
Key takeaways
- Under the CBUAE Finance Companies Regulation, Circular No. 3/2023, effective 27 December 2023, short-term credit including BNPL requires a Restricted Licence, or an approved agency arrangement with a licensed bank or finance company.
- The minimum capital is AED 20 million, or capital funds equal to 5 per cent of outstanding lending volume. That figure dwarfs any realistic app development budget.
- The regulation caps what you can build: credit per borrower is limited to AED 20,000 or three months of verifiable net income, total fees including late payment cannot exceed 30 per cent of the initial loan amount, and repayment cannot run beyond 12 months.
- The consumer app is the smallest of the four systems you need. The merchant platform, the decisioning engine and the collections and reconciliation layer are each comparable in size.
- Tabby holds a CBUAE Stored Value Facilities licence granted on 16 April 2026, works with more than 65,000 brands, and was valued at 4.5 billion dollars in an October 2025 secondary share sale. Competing on features alone is not a strategy.
The licence decides whether there is a product at all
The Central Bank brought short-term lending inside its perimeter with the Finance Companies Regulation, Circular No. 3/2023, which took effect on 27 December 2023. Before that, BNPL in the UAE sat in an awkward grey area. It does not any more.
Two routes exist. The first is to apply for a Restricted Licence as a finance company, issued for an initial three years and renewable. It carries a minimum capital requirement of AED 20 million, or aggregate capital funds, meaning capital plus reserves plus retained earnings, equal to 5 per cent of your outstanding lending volume, whichever bites harder as you grow. The second is to act as the agent of an already licensed bank or finance company, with Central Bank approval for the arrangement. The agent route is how most new entrants should start, because the balance sheet risk and the capital sit with the partner while you prove the product works.
This changes the software brief in a way founders rarely anticipate. If you are an agent, your system has to expose the partner’s credit decisions, reporting and audit trail on the partner’s terms, and their compliance team becomes a stakeholder in your release process. Build for that from the first sprint rather than discovering it during integration.
A note before going further: the figures and rules here are indicative, they change, and this is general information rather than legal, financial or regulatory advice. Anyone actually pursuing this should take formal advice on the licensing route before writing code.
The regulation writes part of your product spec
Several rules translate directly into fields, limits and screens, and getting them wrong is not a bug you patch later.
Credit extended to a single borrower cannot exceed AED 20,000 or three months of verifiable net income, whichever is lower. The word verifiable is doing real work there: your onboarding has to capture and validate income, not ask the customer to self-report it. Total fees, including late payment penalties and commissions, cannot exceed 30 per cent of the initial loan amount, so your fee engine needs a hard ceiling per loan that no combination of penalties can breach. Repayment terms cannot run past 12 months. The regulation also requires transparent pricing and a genuine creditworthiness assessment before extending credit.
Creditworthiness in the UAE routes through Al Etihad Credit Bureau, the federal bureau established under Federal Law No. 6 of 2010 on Credit Information and amended by Federal Decree-Law No. 8 of 2020, which aggregates credit behaviour from banks, finance companies, telecoms and utilities. A bureau pull costs money per enquiry and takes time, which is why mature BNPL products run a cheap internal check first and only pay for the bureau when the internal signals are ambiguous or the basket is large.
The four systems behind the app
Founders describe this project as an app. It is four products, and the consumer app is the smallest.
| System | What it does | Why it is hard |
|---|---|---|
| Consumer app | Sign-up, KYC, plan selection, repayment, card management, support | Regulated disclosure and Arabic parity, but conventional engineering |
| Decisioning engine | Identity, income, bureau data, fraud and limit assignment in under two seconds | It decides whether you lose money; needs rule versioning and replay |
| Merchant platform | Checkout SDK, plugins, settlement, refunds, reporting, onboarding | Every integration is a different stack and a different finance team |
| Collections and ledger | Retries, reminders, reconciliation, write-offs, regulatory reporting | Accounting correctness; errors here are found by auditors, not users |
On the API side, the checkout call is deceptively simple and the rest is not. A merchant sends a basket, a customer identifier and a return URL; you respond with a session and a redirect. Behind that you are running identity resolution, a bureau or internal credit check, a fraud model, limit assignment and plan generation, and you are doing it inside the two seconds before a shopper abandons the cart. Then you need webhooks for authorisation, capture, refund and settlement, idempotency keys so a retried call does not double-charge, and a reconciliation file the merchant’s finance team can match against their own ledger.
Payments underneath are their own project. You need card tokenisation and a mandate to charge that card on a schedule, a retry strategy for failed instalments that respects scheme rules, and a settlement flow that pays merchants up front while you carry the receivable. Most teams underestimate refunds. A partial refund on a four-instalment plan has to unwind correctly across paid and unpaid instalments, and getting it wrong generates complaints that reach the regulator.
The merchant side is a separate product with a separate roadmap
Tabby works with more than 65,000 brands including SHEIN, Amazon, Adidas, IKEA, Jarir, Samsung and noon. That distribution is the moat, and it was built merchant by merchant.
For your build this means plugins are not an afterthought. A Shopify app, a WooCommerce plugin, a Magento extension and a clean REST API with sandbox credentials cover most of the UAE mid-market. Each one needs its own release cycle, its own review process and its own support burden. The enterprise retailers who move real volume will instead want a direct integration, a dedicated environment, and a commercial conversation about merchant discount rate before they write a line of code.
The merchant dashboard matters more than founders expect, because it is where the retailer decides whether to keep you. Settlement timing, dispute handling and a report their accountant can reconcile are what retain merchants. Marketing copy does not.
Interface decisions that change approval and repayment rates
The design work here is mostly about honesty under pressure. The instalment schedule should show exact dates and exact amounts before the customer commits, including any fee, because the regulation requires transparent pricing and because surprise is what generates disputes. Show the total repayable next to the basket total rather than burying it.
The KYC flow is where most drop-off happens. Emirates ID capture with automatic data extraction, camera-based liveness, and a resumable flow that survives an app switch will out-convert a form that asks the customer to type their ID number twice. If a decision needs manual review, say so on screen with a realistic time, rather than leaving a spinner running.
Repayment screens should make paying early trivial and make an upcoming instalment impossible to miss, with reminders through the channels people actually read in this market. Arabic is a first-class requirement, not a translation pass. Right-to-left layout affects the instalment timeline component, currency formatting and every date in the schedule, and retrofitting it is more expensive than building for it. Our teams cover this ground on the iOS and Android app development pages, and a cross-platform build using Flutter or React Native is usually the right call for a first version.
What actually drives the cost
We do not publish a price for a build like this, and any agency that quotes one before seeing your licensing route is guessing. What we can do is name the variables that move the number.
The licensing route dominates everything. Going for your own Restricted Licence means AED 20 million of capital plus legal, compliance hires, an audit function and a regulatory reporting stack. Going through a bank as an agent removes most of that but adds integration work against a partner whose systems you do not control. The second driver is native versus cross-platform, and for a first version cross-platform usually wins. The third is how much of the decisioning engine is yours versus bought, since fraud and identity vendors charge per call and those calls become a permanent cost of goods sold rather than a build cost. Fourth is merchant integration breadth, because each additional platform plugin is a small product. Fifth is Arabic, if it is retrofitted rather than planned.
Ongoing costs surprise people more than build costs. Bureau enquiries, KYC and fraud vendor calls, payment processing, cloud, a compliance and support team, and above all credit losses. A BNPL business with excellent software and mediocre underwriting loses money on every transaction. If you want a structured way to think about the app portion of the budget, our finance app cost calculator walks through the modules, and the MVP development page explains how we scope a first version.
A realistic timeline
Assume the agent route, a cross-platform app and a single merchant platform at launch. Discovery, regulatory mapping and partner selection take roughly one to two months, and this runs before engineering rather than alongside it. Core build, meaning consumer app, decisioning integration, checkout API and merchant dashboard, is around four to six months. Partner integration, security review and user acceptance testing add one to two months, and this phase slips most often because it depends on a third party’s calendar. Pilot with a small merchant set and a capped limit is another one to two months before general availability.
Eight to twelve months from start to a live, limited launch is a fair planning assumption. Pursuing your own licence instead of the agent route adds the regulatory application timeline on top, which is outside your control and should not be compressed in a plan you show investors.
Where these projects go wrong
The most common failure is treating underwriting as a feature to add after launch. Teams ship a beautiful app, approve generously to drive adoption, and discover their loss rate three months later when the first cohort defaults. Start conservative and loosen with evidence.
The second is building the consumer app first and the merchant tooling last. Without merchants there is nothing to buy, and merchant integration cycles are long. The third is under-building reconciliation, which is invisible until an auditor asks for a number the system cannot produce. The fourth is copying Tabby’s current product rather than its early one. The company reached a 4.5 billion dollar valuation in an October 2025 secondary share sale and now holds a Stored Value Facilities licence, granted on 16 April 2026, letting it hold customer funds and offer spending accounts and cards. That is where it arrived after years, not where it began.
