UAE data residency for open finance: where should your API gateway run?

The Central Bank of the UAE has made open finance mandatory. Under the Open Finance Regulation, Circular No. 03/2025, every bank and insurer in the first onboarding phase must expose customer data and accept transaction initiation through a centralised API Hub, subject to the customer's express consent. There is no opt-out and no bilateral workaround: participation runs through the framework's Trust Framework and API Hub. At the same time, UAE data residency rules constrain where the infrastructure serving those APIs may run. If you are the platform engineer, CISO, or compliance officer holding both mandates, they meet at one component: the API gateway.

The residency side is unusually concrete. The CBUAE Outsourcing Regulation for Banks, Circular 14/2021, requires the Master System of Record, the collection of all data needed to run the bank's core activities including all Confidential Data, to be continuously maintained and stored within the UAE. Confidential Data means any data relating to an identifiable bank customer. Article 6.3 adds that such data must not be shared outside the UAE without Central Bank approval and the customer's prior written consent, with the customer also acknowledging in writing that the data could be reached by legal proceedings abroad. The federal PDPL layers a general cross-border transfer regime on top, but it carves out banking and credit data subject to Central Bank regulation, so for a bank's open finance stack the CBUAE rules do the heavy lifting.

An API gateway sits exactly where these obligations collide. Its request logs hold account identifiers, tokens, and payload bodies: Confidential Data on any reading. Its configuration describes your API estate, consumers, and policies. Its audit trail is what examiners will ask to see. If any of that reaches a vendor-operated control plane outside the country, you have an Article 6 problem before writing a line of integration code. This post works through where each piece of open banking gateway infrastructure should live when the whole thing has to stay inside the boundary.

Why the usual gateway architectures fail the boundary test

Most enterprise gateways were designed as cloud services first, with a vendor-hosted control plane holding configuration, analytics, and audit events. Apigee keeps proxy definitions, portal configuration, and analytics in Google's infrastructure. AWS API Gateway stores configuration in AWS systems with no self-hosted deployment model. Azure API Management can place gateway capacity in a UAE region, but its management plane and logging model are built around Azure's own services. Kong Konnect runs its data plane in your environment while configuration and analytics flow to Kong's cloud. These are reasonable architectures for their home markets. They are hard architectures to defend in a CBUAE outsourcing file.

In-country hyperscaler regions soften part of the problem: Azure has operated regions in Abu Dhabi and Dubai since 2019, and AWS opened its UAE region in 2022, so compute and storage can physically sit in the country. But region selection governs the data plane. The control plane, the management tooling, the telemetry pipeline, and the vendor's own operational access follow the provider's architecture, not your boundary drawing. Articles 6.4 and 6.5 press on precisely this: the bank must show the data enjoys the same safeguarding it would have at home, that the bank and its customers retain ownership of it at all times, and that the Central Bank can reach it on request.

A metadata-only control plane deserves an honest reading. A vendor console holding only route names and rate-limit settings arguably holds no Confidential Data, so the Article 6.3 approval-plus-consent trigger may not fire. In practice, gateway telemetry rarely stays that clean: request analytics, consumer identifiers, and error payloads drift into vendor pipelines, and the moment they do, the trigger applies. Even a genuinely clean control plane remains an outsourcing arrangement that needs a notice of non-objection from the Central Bank if the activity is material. The most defensible filing is the one with nothing to explain: no external control plane at all.

Meeting UAE data residency with an in-boundary deployment

Zerq was built for the deployment model these rules imply. The entire platform, control plane included, runs in your infrastructure: a single Go binary serving the gateway runtime, management API, developer portal API, and MCP endpoints; a management UI; a developer portal for partner access; your own MongoDB holding configuration, audit logs, and request logs; and Redis or KeyDB for rate-limit state and multi-replica coordination, optional for a single instance but required once you scale out or use scheduled triggers. No traffic, configuration, or log data leaves during normal operation. The component layout is described on the architecture page; here is how it maps to a UAE open finance estate.

The request path, end to end

Inbound open finance traffic arrives over mutual TLS, as the UAE's FAPI 2.0 security profile requires of every participant endpoint. Your ingress terminates TLS, validates the client certificate against your CA trust, and maps the certificate subject to Zerq's identity headers: certificate CN to X-Client-ID, OU to X-Profile-ID. The gateway then enforces the rest before any request reaches a backend: profile status, IP and method restrictions, collection access, and rate-limit policies. Consent-shaped checks can run in the same request path through the workflow builder, so a revoked consent is rejected at the gateway and logged there. This is the institution's half of the regulation's Article 15 dedicated-interface obligation: the framework operates the hub, but the secure interface into your accounts and products is yours to build, run, and defend. Every hop in that description happens on machines you operate, and the MongoDB that stores the routing configuration is the same MongoDB that stores the audit and request logs: your replica set, your backups, your retention policy, inside the UAE.

Production deployment on Kubernetes

For production, run Zerq on Kubernetes with the stateless surfaces (backend, frontend, developer-portal) scaled horizontally, and MongoDB, Redis, and your OIDC identity provider treated as critical dependencies. Bootstrap starts with a namespace, RBAC, and secrets, and the secrets are the residency story in miniature:

# Created at cluster bootstrap, before the first workload deploy.
# Every value resolves to infrastructure inside the UAE boundary.
apiVersion: v1
kind: Secret
metadata:
  name: zerq-backend-env
  namespace: zerq
stringData:
  # Config, audit logs, and request logs all live in this database.
  # Point it at a MongoDB replica set you run in-country.
  MONGODB_URI: "mongodb://zerq:<password>@mongo-0.mongo.zerq.svc:27017/zerq?replicaSet=rs0"
  # Required platform signing secret for Zerq-issued tokens.
  # Generated by you, known only to you.
  JWT_SECRET: "<random-secret>"
  # AES-256-GCM key for credential values encrypted at rest.
  ENCRYPTION_KEY: "<32-byte-base64-key>"

The backend deployment's environment carries the rest. Nothing in it points outside your network:

env:
  - name: AUDIT_ENABLED
    value: "true"              # admin audit trail, written to your MongoDB
  - name: REDIS_URL
    value: "redis://keydb.zerq.svc:6379"   # rate limits + replica sync, in-cluster
  - name: CACHE_TYPE
    value: "redis"             # shared limiter/cache state across replicas
  - name: OIDC_ISSUER_URL
    value: "https://sso.bank.internal/realms/zerq"  # your own IdP, not a vendor's
  - name: AUTH_METHODS_ENABLED
    value: "token,jwt,oidc,mtls"           # mtls for FAPI-grade machine identity

Rolling updates are ordinary Kubernetes deployments, verified with:

kubectl -n zerq rollout status deploy/backend
kubectl -n zerq rollout status deploy/frontend
kubectl -n zerq get pods -o wide

Multiple backend replicas coordinate through Redis. When an admin saves or enables a workflow, the backend publishes a proxy_changed event on the workflow.trigger.sync channel; every pod, including the publisher, receives it and calls SyncProxy so no replica serves stale configuration. On startup or Redis reconnect, each pod runs a full bootstrap sync from MongoDB. The coordination fabric is a Redis instance in your cluster, not a vendor message bus. For environments that cannot reach public registries at all, the documented air-gapped path builds and exports images in a connected environment, transfers the archives, and deploys from pinned tags, so even updates never require the boundary to open.

Evidence that stays in the country

Residency is not only about where data rests; it is about where you can prove things from. Zerq writes two evidence streams into your MongoDB. Request logs capture every API call with request ID, timestamp, method, path, status code, latency, client ID, profile ID, collection, client IP, and full request and response headers and bodies, filterable by path, method, status, client, profile, IP, request ID, and latency, with full-text payload search, in the observability views. Audit logs capture every administrative change with the actor's identity from their OIDC token, actor type, action, resource type and ID, IP address, and the request body of the change itself. A dedicated Auditor role gives compliance teams read access without admin rights. Retention for both is configured in gateway settings to match your regulatory horizon, and audit events export as structured JSON to the SIEM you already run, whether Splunk, Elastic, or Sentinel. If that SIEM lives in an Abu Dhabi datacentre, the evidence chain never crosses a border.

Secrets never leave either

Credentials for upstream systems, database connection strings, client certificates, and API keys are encrypted at rest with AES-256-GCM under a key you supply through ENCRYPTION_KEY, with a unique nonce per value; values are decrypted in memory only at the moment of an outbound call. Credential fields can also reference environment variables instead of stored values, so you can inject secrets from whatever secret manager your platform already standardises on and keep Zerq's database free of plaintext material. Either way, key custody is yours. The full model is covered under security.

A residency due-diligence checklist for any gateway

Whatever you deploy, these are the questions a CBUAE-grade review will ask. Put them to every vendor on your shortlist, and to your incumbent:

Where does the configuration store physically run, and who administers it? Map the answer against the Article 6.1 requirement to keep the Master System of Record in the UAE.
Do request logs, analytics, or error payloads ever reach vendor infrastructure? They almost always contain Confidential Data, which brings Article 6.3's approval and written-consent conditions into play.
Does the gateway keep serving traffic with all external connectivity removed? A control-plane dependency you cannot sever is a residency commitment you cannot keep.
What leaves the boundary during normal operation: telemetry, licence checks, usage reporting? Ask for exact endpoints, then verify at the firewall.
Can updates be applied entirely from inside: internal registry, transferred image archives, pinned tags?
Where does credential material live, and whose keys encrypt it?
Can your SIEM ingest the audit trail without the data transiting a foreign service?
If the contract ends, do you keep configuration and logs in usable form? Article 6.5 expects the bank and its customers to retain ownership of the data at all times.
Can you draw the whole arrangement for a material-outsourcing non-objection filing without a single arrow crossing the border?

What this looks like in practice

Consider a mid-size UAE retail bank preparing its onboarding to the Al Tareq framework. Its incumbent gateway is a managed cloud service, and the outsourcing-register update for open finance go-live stalls because request analytics flow to the vendor's processing region abroad. The remediation options are unattractive: obtain prior written consent from every affected customer under Article 6.3, restructure the vendor arrangement, or re-platform.

The bank re-platforms. Zerq deploys into the Kubernetes clusters it already runs on in-country infrastructure: three backend replicas behind the existing nginx ingress, which now also terminates the framework's mutual TLS and maps certificate subjects to client and profile headers. Configuration, audit logs, and request logs land in a MongoDB replica set the database team already operates. Audit events stream to the bank's SIEM in its own datacentre. The workflow that checks consent state runs in the gateway request path, so denied requests are logged with the exact client and profile that made them.

The before-and-after shows up in the paperwork more than in the traffic. Before, the residency section of the outsourcing file needed legal argument about what counts as Confidential Data inside a vendor's analytics pipeline. After, the network diagram answers by inspection: every component, log, and secret sits inside the boundary, and the examiner's data-access question is answered with a read-only Auditor account instead of a support ticket to a foreign vendor.

The bottom line

Open finance obliges UAE banks and insurers to open their data; for banks, the CBUAE's outsourcing rules oblige them to keep the machinery of that opening at home, and insurers face their own CBUAE outsourcing and data expectations that point the same way. The two mandates conflict only if your gateway assumes a foreign control plane. Run the control plane yourself, in your own cluster, on your own database, with your own keys, and the conflict dissolves: the gateway becomes the one component where openness and residency are both enforced and both provable, priced as software you run rather than a service you must trust.

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.