The UAE open finance regulation is an API infrastructure mandate

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 the API Hub, and the Hub calls your institution. The connection reaching your boundary carries the Hub's C4 client certificate, issued by the Trust Framework, and terminates over mutual TLS. Your edge validates that certificate against the framework trust chain and hands the request to your gateway, which must identify the Hub as the caller, check that it may reach this API at all, optionally re-check the consent behind the request against your own records, apply a capacity limit, forward to the core banking or insurance system, and record every step, including the TPP named in the Hub's o3-caller-* headers. 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 and the Hub's certificate subject is pinned; the ingress then sets Zerq's identity headers for the Hub, X-Client-ID for the client and X-Profile-ID for the profile, plus the Authorization header an mTLS profile still requires. The TPP's identity arrives from the Hub in o3-caller-* headers, which the request log records. Zerq enforces everything after that point: profile checks, method restrictions, collection access, and policy limits. Zerq sees the ingress address rather than the Hub's, so admit only the Hub's egress IP at the ingress. Deny outcomes are explicit, and all but the last are request-logged: 401 for a profile that does not belong to the client; 403 for IP restrictions; 404 for a path outside the client's collections; 405 for a method the profile does not allow; 429 for policy limits, which is returned before the request logger runs, so count 429s per client at the ingress. 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

Per-TPP clients, each with its own system-generated client ID and only the collections that TPP may reach, are the pattern for bilateral regimes; on the TPP side of the Hub, the egress gateway gives each app its own client instead (see the TPP integration guide). An LFI sees one caller, the API Hub, so it models the Hub as one client and attributes TPPs from the logged o3-caller-* headers (see the LFI implementation guide). 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, the production Hub client looks like this:

# Client: the API Hub, the LFI's only caller
client:
  name: ofp-api-hub-production
  collections: [ozone-connect]  # the API sets in scope for your licence
  policy: hub-capacity

# Profile: the production access contract
profile:
  name: production
  auth_type: mtls                    # Hub certificate validated and pinned at ingress
  allowed_methods: [GET, POST, PATCH]
  # leave IP restrictions empty: Zerq sees the ingress address; enforce the Hub's egress IP at the ingress

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

Narrowing the Hub profile's methods, or cutting off Hub traffic by toggling the 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, enforcement and revocation in the Hub's Consent and Authorization Manager, so calls under a consent the Hub no longer treats as authorized should not reach you. Article 16 still requires a Data Sharing Provider to act only on the user's explicit consent, and many risk teams add an independent check in the request path as defense in depth, for example against drift between the Hub's consent state and your own suspension records. 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 call from the Hub. 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 that clears the policy limiter, 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, through which management call, and with what request body. A rate limit change on the Hub client's policy is recorded like this:

{
  "id": "66f5a0e3c2b14d7e9a1f3c58",
  "timestamp": "2026-09-14T08:41:07Z",
  "actor_id": "[email protected]",
  "actor_type": "modifier",
  "resource_type": "policy",
  "action": "update",
  "ip_address": "10.30.1.12",
  "user_agent": "Mozilla/5.0 (...)",
  "request_id": "9d2e51c0-4b7a-4f1e-9c2d-7a6e10b83f55",
  "metadata": {
    "url": "/api/v1/policies/66f2b0d7e8a9d30012ab4c70",
    "request_body": "{\"name\":\"hub-capacity\",\"rate_limit_interval\":\"1m\",\"rate_limit_requests\":300}",
    "response_body": "{\"id\":\"66f2b0d7e8a9d30012ab4c70\",\"name\":\"hub-capacity\",...}",
    "status_code": 200
  },
  "created_at": "2026-09-14T08:41:07Z"
}

The actor_type field holds the roles on the actor's token, the action comes from the audit rules in lowercase, and the resource ID travels in metadata.url. Audit logs are visible only to users with the Auditor role (the shipped config also maps admin into OIDC_AUDITOR_ROLES; remove it for strict separation), so the compliance function reviews changes without the ability to make them: the separation of duties the regulation's independent audit requirements point toward. Zerq has no built-in retention setting; enforce your regulatory period in the MongoDB you operate (TTL index or archival job) and in your SIEM. 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 the API Hub map to one gateway identity, scoped to specific API collections, with each request's TPP attributable from the logged o3-caller-* headers?
Is the Hub profile limited to the methods your API sets use, with 405 returned and logged for anything else?
Is a capacity rate limit and quota enforced on the Hub client, with 429s counted at the ingress, since policy rejections are not request-logged?
If your risk function wants an independent consent check, does it run in the request path, so a consent you have suspended 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

Illustrative scenario, not a specific customer deployment.

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 keeps Hub traffic within what the core can take? 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, admits only the Hub's egress IP there, and registers the API Hub as one client with an mTLS production profile. Account and insurance APIs become governed collections, consent checks run as workflow steps in front of the core, and a policy sets a capacity ceiling for Hub traffic. When an examiner asks what a specific TPP accessed in March, the answer is a request-log query: one o3-caller-* value, one date range, every request with its outcome. When they ask who loosened the Hub client's rate limit, the audit log names the actor, the time, and the request body submitted. 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 caller identity, consent-bound access, governed limits, 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.