UAE Open Banking: What Payment Platforms Need to Prepare For

The UAE Central Bank (CBUAE) has been advancing its Open Finance framework as part of the UAE's broader Financial Infrastructure Transformation Programme. For payment gateways, wallet platforms, and fintech operators licensed in the UAE, this is not a distant regulatory consideration — it is an engineering deadline.

What the Open Finance framework requires

Open Finance in the UAE follows the pattern established by PSD2 in Europe and Open Banking in the UK, adapted for the UAE regulatory and market context. At its core, it requires licensed financial entities to expose regulated APIs that allow third-party providers (TPPs) to access account data and initiate payments on behalf of customers, with customer consent.

The key API categories:

• Account Information Services (AIS): read access to account balances, transaction history, and account metadata
• Payment Initiation Services (PIS): initiation of payments from customer accounts by authorized TPPs
• Confirmation of Funds (CoF): boolean check of whether sufficient funds exist without exposing the balance value

Each category has consent, authentication, and data format requirements that are specified in the regulatory technical standards.

Related: Building Idempotent Payment APIs

Authentication and consent architecture

The consent model is the most architecturally significant requirement. Customers must explicitly authorize each TPP to access specific data or initiate payments, with a defined scope and a defined expiry. This consent must be revocable at any time, and the platform must enforce revocation immediately — not at the next API call or the next login.

This requires:

• A consent management service that stores consent grants with their scope, expiry, and TPP identifier
• An authorization server implementing OAuth 2.0 with PKCE and OpenID Connect
• Token introspection or short-lived access tokens that are validated against the consent store on every API call
• A revocation endpoint that immediately invalidates all tokens associated with a consent grant

If your platform currently implements a simple API key model, migrating to this architecture is a significant project — not because any individual component is complex, but because it touches authentication across your entire API surface.

API design for regulatory compliance

The API specifications for UAE Open Finance are defined by CBUAE and will reference standards from the Berlin Group or UK Open Banking Implementation Entity (OBIE) with UAE-specific adaptations. The key engineering implications:

• Data formats: the regulatory specifications define specific JSON schemas for account data, transaction data, and error responses. Your internal data models may not map cleanly to these schemas.
• Idempotency: payment initiation endpoints must be idempotent. A TPP that retries a failed initiation request must not create a duplicate payment.
• Rate limiting: you will need to apply rate limiting per TPP and per customer consent, not just per API key.
• Audit logging: every API call must be logged with the TPP identity, the consent reference, the data accessed or action taken, and the timestamp. Regulators can request these logs.

Related: Observability for Transaction-Critical Systems

Infrastructure considerations

Regulatory API endpoints often have stricter availability SLAs than your commercial APIs. Regulators may specify uptime requirements (99.5%+ is common) with structured reporting on downtime incidents.

This means your open banking API infrastructure should be isolated from your commercial transaction processing infrastructure — both to protect the SLA and to prevent a commercial traffic spike from degrading your regulated API. Separate API gateway, separate compute, separate monitoring, and a separate on-call escalation path.

What to build now

The gap between a typical UAE payment platform and open banking readiness is usually 6–12 months of engineering work, depending on current architecture. Teams that start early have time to do it properly; teams that start late are forced to make expedient decisions that accumulate compliance debt.

Priority order for preparation:

1. Consent management service — this is the architectural foundation for everything else
2. OAuth 2.0 / OIDC authorization server — assess whether to build, buy, or use a managed service
3. API gateway capable of per-TPP rate limiting and token validation
4. Audit logging infrastructure with the retention and access patterns regulators require
5. Account and transaction data APIs with CBUAE-compliant schemas

Related: The Most Common Architecture Mistakes in Payment Gateways

---

If your platform is licensed in the UAE and you haven't mapped the engineering gap to Open Finance compliance, a platform assessment will give you a clear picture of what needs to be built and a realistic timeline.