UAE open finance pricing: what the API Hub actually costs
The published UAE fee schedule, the page allowances on data sharing, and the pricing rules that quietly constrain how you build.
Most writing about UAE open finance answers whether you need a licence. Very little answers what the thing costs to run, which is the question that decides whether a product works.
Every figure below comes from one document: the Commercial and Pricing Model, version 1.0, published 4 October 2024 by Open Finance UAE as part of the AlTareq Standards. Checked 27 July 2026.
The UAE publishes its numbers in full. They are worth reading closely — not because the fees are high, but because several lines in the schedule are not pricing decisions at all. They are constraints on how you are expected to build.
The structure first
The UAE does not follow the UK and EU model of integrating with each bank’s own API. It routes everything through a central API Hub, operated by Nebras Open Finance LLC, a Central Bank subsidiary established under Al Etihad Payments. Licensed financial institutions (LFIs) and third-party providers (TPPs) all connect to that hub.
For anyone whose instincts were formed on UK open banking, this inverts the integration problem. You are not building and maintaining connections to forty institutions with forty sets of quirks. You are building one connection — to an intermediary that charges per call.
Which is where the economics start to matter in a way they never did under a model with no marginal cost per request.
What you pay the hub
TPPs pay Nebras for hub consumption:
| API type | Fee per call |
|---|---|
| General rate (service initiation, data sharing) | 2.5 fils |
| Quotes — up to 4 entities | 5 fils |
| Quotes — up to 10 entities | 7.5 fils |
| Quotes — up to 25 entities | 10 fils |
| Quotes — 25+ entities | 12.5 fils |
A fils is one hundredth of a dirham. These are small numbers, deliberately.
Quotes are priced by fan-out, and the tiers are far enough apart that querying everyone stops being the obvious default. If you are building a comparison product, panel breadth is a line item rather than a free choice.
One rule removes a whole category of worry: fees are charged only for technically successful API calls. Failed calls and retries are not billable. That is unusually sensible, and it means an aggressive retry policy costs latency and load but not money — the opposite of what you would assume under per-call pricing.
The line that is really an architecture decision
Buried in the hub schedule:
Balance and Confirmation of Payee calls are reduced to 0.5 fils each if a payment occurs within two hours.
A fivefold discount, conditional on your call being followed by a transaction inside a two-hour window.
Read as pricing, it is unremarkable — the hub charging less for calls that generate downstream value. Read as an engineer, it is a statement about when those calls are supposed to happen.
Consider a product that validates a payee at onboarding and lets the user pay days later. Every Confirmation of Payee call in that flow bills at full rate, because no payment follows within two hours. The same product, restructured so validation happens at payment time, pays a fifth for identical functionality.
It also pushes back on speculative calling. Pre-fetching balances to make a dashboard feel responsive is an ordinary optimisation elsewhere. Here it converts a discounted call into a full-price one every time the user does not go on to pay.
None of this is written as guidance. It is a discount, and the design implications are left for you to notice.
Data sharing is mostly free — until it isn’t
For retail and SME customers, TPP-to-LFI data sharing fees are zero, within allowances:
| Call type | Free allowance |
|---|---|
| Attended (user-initiated) | 15 pages per customer per day |
| Unattended (automated) | 5 pages per customer per day |
| Balance, Confirmation of Payee, Payment Status | Zero, no allowance stated |
Above the allowance, the LFI sets the price.
The definition matters more than the number: a page is 100 lines of transactional data, spanning at most 13 months per call.
That is a pagination contract disguised as a pricing unit. It tells you the granularity your sync logic has to work in, and it makes the attended/unattended split architecturally significant — a background reconciliation job gets a third of the allowance a user-triggered refresh does. Design an aggressive polling schedule without accounting for that and you will find the ceiling in production rather than in planning.
LFIs are also prohibited from imposing other charges on retail and SME end users for data sharing via open finance APIs.
Corporate customers are treated differently: data APIs are capped at 40 fils per page, and end-user pricing is not capped at all.
What service initiation costs
TPP-to-LFI fees for retail and SME, by payment type:
| Payment type | Fee |
|---|---|
| Merchant collections | 38 bps in year 1, tapering to 25 bps by year 5. Capped at 50 AED per transaction; first 200 AED per merchant per day exempt |
| P2P / SME-to-SME | 25 fils max |
| Me-to-Me | 20 fils in year 1, falling to 17 fils by year 3 |
| Bulk payment (SME) | 25 fils per transaction, 250 fils per group |
| Large value, rent, invoice | 4 AED per transaction |
The merchant collection taper runs 38 → 35 → 32 → 29 → 25 bps across five years. Compared against card interchange, this is the number that makes open finance interesting as a collections rail rather than a compliance exercise.
Corporate payments cap at 250 fils TPP-to-LFI. All fees are inclusive of VAT.
The quote accuracy rules
Two constraints that are genuinely unusual, and which most pricing documents would never contain:
- In open insurance, the difference between the quoted premium and the executed policy cost must not exceed 17.5% in either direction.
- In open FX, the executed rate should be within 50 pips of the quoted rate.
These are correctness requirements enforced through the commercial model. A quote is not indicative marketing — it is a commitment with a published tolerance, and your pricing engine has to hold to it. If your quote generation and your execution path can drift apart by more than that, you have a compliance problem rather than a UX one.
Insurance referral commissions run from 0% (involuntary loss of employment) through 5% (motor, health) to 15% (travel, home, renters), with life assurance at 10% of first-year premium. Commissions are not paid until 30 days have passed, to cover free-look periods, and clawback applies on a five-year lookback for life policies and two years for everything else.
Anyone modelling revenue on referral commissions needs the clawback window in the model, not in a footnote.
What to work out before you commit
- How many of your balance and CoP calls are followed by a payment within two hours — and what fraction could be, if you moved when they happen?
- Does your data sync fit inside 15 attended and 5 unattended pages per customer per day, at 100 lines and 13 months per page?
- For quote products, what is the marginal value of crossing each fan-out tier?
- Can your quote and execution paths stay within 17.5%, or 50 pips, under load?
Sources
Commercial and Pricing Model, Open Finance UAE, version 1.0, published 4 October 2024. Checked 27 July 2026.
The document is part of the AlTareq Standards and regulated by the Central Bank of the UAE. It states that any breach of the commercial and pricing model is equivalent to a breach of the CBUAE Open Finance Regulations, so the figures are binding rather than indicative.
The model is reviewed annually by the CBUAE together with the Nebras Open Finance board. Treat every figure here as accurate to the date checked, and verify against the source before relying on it commercially.
This article makes no claim about a September 2026 compliance deadline. That date circulates in secondary commentary and could not be corroborated against any Central Bank publication.