UAE Open Finance Needs a Control Plane

The UAE Open Finance question is not only whether banks and licensed providers can expose APIs.

The practical question is sharper: can every consented data access or service initiation be traced through participant identity, customer permission, account action, payment-system status and customer evidence?

CBUAE describes open finance as a secure way for financial institutions to open systems to accredited third-party providers, using customer consented financial data to build financial services. Its current Open Finance page says the roadmap includes regulatory design, API prioritisation, the UAE Open Finance Playbook, digital infrastructure, pilots and capability enhancement.

That roadmap points to an operating model, not just an integration backlog.

The rulebook makes the control shape clearer. The UAE Open Finance Framework consists of a Trust Framework, an API Hub and Common Infrastructural Services. The framework supports cross-sector data sharing and the initiation of transactions on behalf of users. Access remains subject to express user consent, appropriate authentication and secure communication.

For product teams, that combination creates a control plane.

The API is not the product boundary

It is tempting to treat open finance as an API programme. That is too narrow.

An API can return data, initiate a service, or pass a payment instruction. The product has to explain who was allowed to call it, which user consent applied, what account or product was in scope, what the service owner accepted, and which downstream system now owns the state.

That boundary matters because CBUAE's payments page shows the UAE payment environment as a set of owned and overseen systems: UAEFTS for large-value funds transfer, and retail systems including ICCS, UAEWPS, UAESWITCH, UAEDDS and UAEPGS. It also describes cross-institution payments, real-time settlement through credit transfers and direct debits, e-cheques, electronic direct debit authorisation and addressing schemes.

Open finance will touch this environment from the customer-facing side. The payment and settlement systems will still need clean evidence from the operating side.

If the product boundary ends at "API call succeeded", the customer journey will fail at the first exception.

What the control plane must preserve

The first control is participant identity. A service initiator or data recipient should be traceable through the Trust Framework, participant directory, digital certificates and API access route. If the bank cannot tell which enrolled participant acted, the audit trail is already broken.

The second control is consent. Consent should not be a screen-level checkbox that disappears into an app database. It needs a durable link to the user, the participant, the account or product, the permitted data or action, the timestamp, expiry and revocation state.

The third control is action scope. Data access, payment initiation, insurance data sharing and other service initiation flows should not share one generic state model. Each action needs its own acceptance criteria, evidence and customer-status language.

The fourth control is downstream status. A service initiation request can be received, authenticated, accepted, rejected, pending, executed or failed later. A payment-related request can also meet a settlement or reconciliation state. Those words should not collapse into "processed."

The fifth control is customer evidence. The user should be able to understand what was authorised, who acted, what happened, what remains pending and where to challenge the result.

The useful product tests

Before a bank, payment firm or fintech treats an Open Finance flow as ready, I would ask for seven tests.

1. Can the team reconstruct the user journey from one consent or initiation reference?
2. Is the participant identity preserved from trust-framework validation into the bank's event trail?
3. Does the product separate data access from transaction initiation in logs, support screens and customer wording?
4. Can support distinguish authenticated, authorised, accepted, rejected, executed and pending states?
5. Are downstream payment-system references captured when the flow touches a payment rail?
6. Does revocation stop future use without destroying evidence of earlier authorised activity?
7. Can operations measure failures by participant, product, action type, customer impact and root cause?

If those tests fail, the institution may have API availability but not Open Finance readiness.

What fintechs should ask partners

Fintechs should ask banks and service owners for more than endpoint documentation.

Ask how participant identity is validated and logged. Ask where consent lives, how expiry is handled and how revocation is proved. Ask whether service initiation has a state taxonomy that support, compliance and reconciliation all use. Ask how payment-related references propagate into payment-system evidence.

Also ask which flows are in phase one. The rulebook says mandated licensees will be onboarded in phases, with the first phase including banks and insurance companies. That means product promises should match the actual phase, not the final ambition of the framework.

The operating lesson

Open Finance becomes valuable when customers can safely let trusted providers act with their data and services. That trust does not come from an API catalogue alone.

It comes from a control plane: participant identity, consent, action scope, authentication, state, settlement evidence and customer language.

The teams that build that plane early will have a simpler launch conversation with banks, regulators, support teams and users. The teams that do not will discover the missing controls later, in disputes, exceptions and reconciliation breaks.

Sources

• CBUAE, "Open Finance", last updated 31 March 2026.
• CBUAE Rulebook, "Open Finance Regulation".
• CBUAE, "Payments and Settlements", last updated 31 March 2026.
• CBUAE, "Al Etihad Payments launches Open Finance to strengthen the financial services sector in the UAE", last updated 24 February 2026.

FAQ

What is an Open Finance control plane? It is the operating layer that links participant identity, customer consent, permitted action, authentication, status, payment evidence and customer explanation.

Is this only a compliance issue? No. Compliance sets requirements, but product and programme teams must turn them into state models, support views, logs, customer wording and launch gates.

What should fintechs test first? Test consent traceability, participant identity, service-initiation states, revocation behaviour, downstream references and customer-support evidence before scaling volume.