Skip to main content

The UAE open finance regulation is an API infrastructure mandate

What the UAE open finance regulation demands from a licensed institution's API infrastructure, and how Zerq covers TPP identity, consent, audit, and residency.

  • banking
  • compliance
  • api-management
  • governance
Zerq team

The UAE open finance regulation reads like a legal document but lands like an engineering backlog. Circular No. 03/2025 from the Central Bank of the UAE makes participation in the Open Finance Framework mandatory for licensed financial institutions, starting with banks and insurers. Consumers will know it as Al Tareq. Your compliance team will file it under regulatory change. The actual deliverable, though, is API infrastructure: governed data APIs, certificate-based partner identity, consent-bound access, per-partner controls, and an evidence trail that satisfies a central bank examiner.

Ask what the CBUAE open finance regulation requires from banks in concrete terms and the list is familiar to anyone who runs a platform team. Article 15 obliges Data Holders and Service Owners to maintain a dedicated interface giving secure online access to accounts and products through the centralized API Hub, and to register as Trust Framework participants within fourteen days of CBUAE approval. Data sharing and service initiation are permitted only with the user's express consent, appropriate authentication, and secure communication. Data scraping is prohibited, as is intercepting a licensee's APIs by reverse engineering. None of that ships as a policy memo. It ships as the systems your platform engineers operate.

This post maps the framework onto the gateway layer: what the regulation asks for, why generic API management stacks struggle with it, and how Zerq covers each requirement.

Why the usual gateway stack falls short

The obvious move is to reach for the gateway you already have, and that is where open finance API compliance programs slow down. Kong covers the transport basics, but consent enforcement and TPP-specific logic end up in custom plugins that sit outside the gateway's own audit model, so proving what was enforced means reading plugin code rather than querying logs. Apigee and Azure API Management place the control plane in the vendor's cloud, which collides with the CBUAE's Outsourcing Regulation: banks must keep the Master System of Record, including all confidential customer data, continuously within the UAE, and sharing confidential data abroad requires Central Bank approval plus the customer's prior written consent. A management plane holding configuration, analytics, or logs outside the country turns a product choice into a regulatory filing.

MuleSoft can model the flows, but the logic lives in integration code that changes through deployments rather than governed configuration, so the audit trail shows that a release happened without showing what enforcement changed. AWS API Gateway pushes identity and consent decisions into Lambda authorizers, scattering evidence across CloudWatch, IAM, and application logs. Each stack is workable for generic APIs and awkward for a framework where the regulator expects one coherent answer to a simple question: which TPP accessed which data, under which consent, and who configured it that way.

What the UAE open finance regulation actually requires

The UAE model differs from UK and EU open banking in ways that shape the engineering. Where the EU rests on a directive transposed into national law, the UAE framework is binding central bank regulation with mandatory participation. Where the UK and EU rely on bilateral APIs between each bank and each third party, the UAE routes participants through a single centralized API Hub, operated by Nebras Open Finance under CBUAE oversight, with a Trust Framework that runs the participants directory and issues the digital certificates used to access open finance services. The scope is cross-sectoral from the start: phase one covers banks and insurance companies, and the published API standards span account data, payments, and insurance policy sharing and quotation. Service initiation is also broader than PSD2's payment initiation, reaching transfers, placements, withdrawals, redemptions, sales, orders, and cancellations across accounts and products.

The security requirements are specific. The official API security profile is a profile of FAPI 2.0 that deliberately reduces optionality: mutual TLS on authorization and resource endpoints, sender-constrained access tokens bound to the client certificate, and access token lifetimes capped at ten minutes. Consent rules are equally concrete. Under Article 22, consent must be specific to its purpose, informed, unambiguous, and freely given, and obtained distinguishably for each purpose; recurring transaction consents carry a validity period of at most twelve months; withdrawal must be at least as simple as granting. Providers must keep records of consents, and a breach exposing user data invites administrative and financial sanctions.

Trace one request end to end and the infrastructure mandate is plain. A licensed TPP calls through the API Hub. The connection reaching your boundary carries a Trust Framework certificate and terminates over mutual TLS. Your edge validates that certificate against the framework trust chain and hands the request to your gateway, which must resolve the TPP's identity, check that this partner may reach this API at all, confirm the consent behind the request is still valid, apply that partner's rate limits, forward to the core banking or insurance system, and record every step. That is six control points on a single request path, and the regulator expects evidence for each one.

Mapping the mandate to Zerq

Zerq treats each of those control points as a first-class object rather than a plugin. The full model is on the capabilities page; here is the mapping, requirement by requirement.

TPP identity through Trust Framework certificates

Mutual TLS is a profile authentication type in Zerq. Certificate validation happens at your ingress, where the TLS handshake on the inbound connection is verified against the Trust Framework chain; the ingress then translates the TPP identity conveyed with each request through the framework into Zerq's identity headers, X-Client-ID for the client and X-Profile-ID for the profile. Zerq enforces everything after that point: profile checks, IP and method restrictions, collection access, and policy limits. Deny outcomes are explicit and logged: 403 for IP restrictions, collection access denials, or profile mismatches; 405 for a method the profile does not allow; 429 for policy limits. This split mirrors the UAE security profile itself, which mandates mutual TLS at the connection layer with authorization decisions behind it, and the security model keeps both layers auditable. Where the token leg matters, OIDC profiles can additionally require RFC 8705 certificate-bound access tokens, the sender-constrained pattern the UAE profile calls for, so a stolen bearer token cannot be replayed without the matching private key.

One client per licensed TPP, with scoped profiles and limits

Each licensed TPP becomes a Zerq client with its own system-generated client ID, assigned only the collections it is entitled to reach. Profiles carry the runtime contract per environment, and a policy caps request rates and long-term quotas across the client's active profiles. Set up in the management UI, a production TPP looks like this:

# Client: one per Trust Framework participant
client:
  name: tpp-aggregator-104
  collections: [accounts-data, insurance-policies]  # only what this TPP may reach
  policy: ofp-standard

# Profile: the production access contract
profile:
  name: production
  auth_type: mtls               # identity comes from the TLS certificate at ingress
  allowed_methods: [GET, POST]  # data sharing plus service initiation
  ip_restrictions:
    - 10.40.8.0/24              # hub-facing egress range only

# Policy: enforced across the client's active profiles
policy:
  rate_limit: 300 requests per 1m   # sliding window
  quota: 2000000 requests per 30d   # resets on the 1st of the month, 00:00 UTC

Restricting a data-sharing-only TPP to GET, or suspending a partner by toggling its profile inactive, is a configuration change that takes effect on the next request and is written to the audit log with the actor's identity.

Consent checks in the request path

The framework centralizes consent creation and revocation in the hub's Consent and Authorization Manager, but honoring consent state on every request remains the institution's obligation. In Zerq that check lives in the workflow attached to a proxy: open the collection, click into the proxy, and click Edit Workflow. An http_request_node queries consent status, a condition_node routes on the result using plain JavaScript conditions, a validate_node can check the consent payload against a JSON Schema, and a response_node returns a 403 with a machine-readable reason when consent is revoked or expired. Client, profile, and policy checks run before the workflow executes, so any request reaching the consent step is already an authenticated, in-quota TPP. The regulation's consent granularity, per-purpose consent and the twelve-month cap on recurring consents, becomes checkable data in that flow rather than a paragraph in a policy document. The pattern is covered in the open banking use case.

The audit trail an examiner recognizes

Zerq keeps two distinct records. Request logs capture every API call with request ID, timestamp, method, path, target endpoint, status code, latency, client ID, profile ID, collection, client IP, and full headers and bodies, filterable by each of those scalar fields, with full-text payload search across request and response bodies. Audit logs capture every configuration change: who altered a client, profile, policy, or credential, and exactly what changed. A rate limit change on a TPP policy is recorded like this:

{
  "timestamp": "2026-09-14T08:41:07Z",
  "actor_id": "u-8c1f42",
  "actor_type": "user",
  "action": "UPDATE",
  "resource_type": "policy",
  "resource_id": "ofp-standard",
  "http_method": "PUT",
  "url": "/api/v1/policies/ofp-standard",
  "ip_address": "10.30.1.12",
  "request_id": "9d2e51c0-4b7a-4f1e-9c2d-7a6e10b83f55",
  "request_body": { "rate_limit": { "max_requests": 300, "interval": "1m" } },
  "response_status": 200
}

Audit logs are visible only to users with the Auditor role, so the compliance function reviews changes without the ability to make them: the separation of duties the regulation's independent audit requirements point toward. Retention is configurable to your regulatory horizon on both; audit logs export to SIEM systems such as Splunk, Elastic SIEM, and Microsoft Sentinel as structured JSON, and request logs can be filtered and exported for any compliance review period. The observability surface is where a request for proof becomes a filter query.

Running it in-country

The CBUAE's Outsourcing Regulation requires banks to keep the Master System of Record continuously within the UAE and bars sharing confidential customer data abroad without Central Bank approval and prior written customer consent. The practical implication for API management is that a vendor-hosted control plane outside the country is, at best, a compliance question you now own. Zerq removes the question. The platform runs as a single deployment in your own environment, on Kubernetes in a UAE cloud region or on your own hardware, with configuration, request logs, and audit data in your own MongoDB and Redis as the in-country cache and coordination layer. An air-gapped installation path exists for environments that cannot pull from public registries: images are built and exported in a connected environment, transferred with a signed manifest of names and tags, and run with pinned tags. Nothing in the architecture phones home.

A readiness checklist

Before the CBUAE's onboarding phase reaches your institution, the platform team should be able to answer yes to each of these:

  • Can your edge terminate mutual TLS and validate Trust Framework certificates against the framework chain?
  • Does every TPP map to a distinct gateway identity, scoped to specific API collections?
  • Can you restrict a data-sharing-only TPP to read methods, with 405 returned and logged for anything else?
  • Are per-TPP rate limits and quotas enforced at the gateway, with 429 responses attributable per partner?
  • Is consent state checked in the request path, so a revoked consent stops the request before core systems see it?
  • Can you produce, for any TPP and any time range, every request with status, latency, and payload from one log source?
  • Is every configuration change recorded with actor identity, and reviewable by a role that cannot make changes?
  • Do configuration, request logs, and audit data live inside the UAE, and can you show where?

What this looks like in practice

A UAE-incorporated retail bank in the framework's first phase typically starts from a familiar position: a core banking vendor's bolt-on API module, an ingress layer configured for an earlier project, and consent handling sketched into a middleware backlog. The gap analysis lands on the platform team at about the same time as the conformance testing calendar does, and the questions are specific. Where do Trust Framework certificates get validated? Which system enforces per-TPP limits? What exactly would we hand an examiner?

With Zerq the shape of the answer changes. The bank deploys the platform into its existing in-country Kubernetes environment, terminates mutual TLS at its ingress against the framework chain, and registers each licensed TPP as a client with an mTLS production profile locked to the hub-facing network range. Account and insurance APIs become governed collections, consent checks run as workflow steps in front of the core, and policies encode the per-partner limits. When an examiner asks what a specific TPP accessed in March, the answer is a filtered request-log view: one client ID, one date range, every request with its outcome. When they ask who loosened that TPP's rate limit, the audit log names the actor, the time, and the change. Evidence assembly that previously spanned ingress logs, middleware traces, and change tickets becomes minutes in one interface.

The UAE open finance framework compresses years of European open banking evolution into one binding regulation with centralized infrastructure, and it assigns the hard parts to the licensed institution's platform team. Certificate-based TPP identity, consent-bound access, per-partner governance, complete evidence, in-country operation: these are gateway properties. Choosing a gateway that treats them as governed configuration rather than custom code is the difference between a compliance program with an end date and a permanent integration project.

Zerq is an enterprise API gateway built for regulated industries — one platform for API management, AI agent access, compliance audit, and developer portal, running entirely in your own infrastructure. See how it works or request a demo to walk through your specific requirements.

Request Enterprise DemoExplore capabilities