The UAE Central Bank (CBUAE) launched its Open Finance framework in 2023, with phased implementation requirements for licensed financial institutions and payment service providers. Most teams focus on the regulatory deadlines and miss the engineering complexity. This guide covers the technical requirements and what they mean for your architecture.
What UAE Open Finance Requires
The CBUAE Open Finance framework mandates that licensed financial institutions provide standardised APIs for third-party providers (TPPs) to access customer account data and initiate payments — with the customer's explicit consent. The key technical components are:
- Account Information APIs: APIs that expose account balances, transaction history, and account metadata to TPPs.
- Payment Initiation APIs: APIs that allow TPPs to initiate payments on behalf of customers.
- Consent Management: Infrastructure for obtaining, storing, revoking, and auditing customer consent for data sharing.
- TPP Directory Integration: Integration with the CBUAE's directory of licensed TPPs to verify that incoming API requests are from authorised parties.
- Strong Customer Authentication (SCA): Multi-factor authentication for consent issuance and payment initiation, meeting CBUAE's SCA standards.
The API Layer
Specification conformance
The UAE Open Finance framework specifies API standards based on (but not identical to) the UK Open Banking standard. The surface differences are manageable — the deeper challenge is that these APIs must be built to a conformance standard that will be tested by the CBUAE's sandbox and conformance testing suite. Implementation that works in your internal testing environment may fail conformance testing on data format details, response code usage, or error structure.
Build against the conformance test suite from the start, not as a final validation step. Running conformance tests in your CI pipeline catches specification drift before it becomes a compliance problem.
Rate limiting and SLAs
Open Finance APIs will face traffic patterns unlike your existing APIs — TPPs will call Account Information APIs on schedules determined by their own business logic, with no coordination with your systems. You need rate limiting that protects your infrastructure while not impeding legitimate TPP access, and SLA commitments that you can actually meet under this load profile.
The architecture for Open Finance APIs should be isolated from your core transaction processing infrastructure. Shared infrastructure means that a TPP polling pattern can affect transaction authorisation latency — a compliance risk and a customer experience problem simultaneously.
Consent Management Infrastructure
Consent management is the area that most engineering teams underestimate. The requirements are not just "store a consent record" — they include:
- Capturing customer consent with a specific permission scope (which data, which TPP, for how long)
- Providing customers with a real-time view of active consents through your own interface
- Implementing consent revocation that takes effect immediately and propagates to active API sessions
- Maintaining an immutable audit log of all consent creation, modification, and revocation events
- Handling consent expiry and re-authorisation flows
- Storing consent records with data residency requirements that meet CBUAE standards
Each of these requirements has non-trivial implementation complexity. Consent revocation in particular requires immediate propagation to any active API sessions that were issued under the revoked consent — which requires a session store that can be queried and invalidated in real time.
Consent UI requirements
The CBUAE framework specifies requirements for how consent must be presented to customers — language clarity, disclosure of what data will be shared and for how long, and the ability to selectively grant or deny specific permission scopes. Your consent UI must meet these requirements and should be designed to make consent meaningful rather than a box-ticking exercise.
Strong Customer Authentication (SCA)
SCA requirements under the UAE Open Finance framework require multi-factor authentication for consent issuance and payment initiation. The authentication factors must be:
- Something you know: PIN, password
- Something you have: Device, hardware token
- Something you are: Biometric
Two of the three factors must be used, and at least one must be from "something you have" or "something you are." The technical implementation — OTP delivery, device binding, biometric verification — must be robust against the attack vectors that SCA is designed to prevent, not just technically compliant.
TPP Directory Integration
Before serving any API response to a TPP, your platform must verify that the requesting party is a licensed TPP in the CBUAE directory. This verification must happen in real time and must be resilient to CBUAE directory availability issues — a directory outage cannot make your Open Finance APIs unavailable.
The standard pattern: cache TPP directory entries with an appropriate TTL and a fallback to the cache if the directory is unavailable. The cache must be invalidated when a TPP's licence is revoked — which requires either frequent TTL-based cache expiry or a subscription to CBUAE's TPP status change events.
Operational Requirements
Incident response
The CBUAE framework includes incident reporting obligations — security incidents affecting Open Finance APIs must be reported within specific timeframes. Your incident response playbooks must include Open Finance-specific procedures, and your monitoring must be capable of detecting the specific failure modes that affect Open Finance APIs (consent system failures, TPP directory unavailability, authentication service degradation).
Compliance reporting
CBUAE will require periodic reporting on Open Finance API usage, consent statistics, and incident history. Build the data pipelines that produce these reports as part of the initial implementation, not as a post-launch project.
Architecture Recommendation
The cleanest architecture for UAE Open Finance compliance is a dedicated API gateway layer that handles all Open Finance traffic — TPP authentication, rate limiting, consent validation, and request routing — before requests reach your core financial infrastructure. This isolation:
- Prevents Open Finance traffic from affecting core transaction processing
- Makes conformance testing straightforward — the conformance test suite hits one defined boundary
- Simplifies the security audit scope — the Open Finance boundary is a defined, auditable perimeter
- Makes future framework updates manageable — changes to API standards or authentication requirements affect the gateway layer, not your core systems
See our related article on UAE Open Banking and payment platform architecture for more on the regulatory context and how it shapes engineering decisions.
If you are building for UAE Open Finance compliance and want an independent review of your architecture approach, an architecture assessment can identify the gaps before your CBUAE conformance testing does.