Data Residency and Cloud for Banks in the Gulf: What the Regulators Require and How to Architect for It

By Eurisko Team

Roadmap of legacy systems modernising into cloud services

Five years ago a Gulf bank that wanted to run production workloads in the public cloud had two problems: the regulator and the geography. Customer data had to stay in the country, and the nearest hyperscaler region was in Europe. Both problems have changed shape. Every major cloud provider now operates or has announced regions in the UAE and Saudi Arabia, several with sovereign-cloud arrangements, and the central banks have published outsourcing and cloud rules that say what is allowed rather than leaving it to interpretation.

The rules still differ by country and the details matter. This guide sets out what SAMA, the Central Bank of the UAE, the Central Bank of Kuwait and the Central Bank of Oman require on data residency and outsourcing, what the local regions do and do not solve, and the architecture patterns that let a bank modernise without a compliance surprise.

UAE: confidential data stays in the country

The CBUAE Outsourcing Regulation (Circular 14/2021) is the clearest statement in the region. Article 6 requires that confidential customer data be stored and processed in the UAE, with narrow exceptions subject to central bank approval. Material outsourcing, including cloud hosting of core systems, requires notification or approval and a due diligence file covering the provider’s controls, exit arrangements and the bank’s continued ability to meet audit and supervisory access requirements. With AWS, Microsoft, Google and Oracle all operating UAE regions, the residency requirement is now a configuration choice rather than a barrier, but the governance obligations remain the bank’s.

Saudi Arabia: SAMA no-objection and the PDPL

SAMA’s Rules on Outsourcing require a no-objection from the regulator before a bank outsources a material function, and SAMA has historically expected customer data to be hosted inside the Kingdom. The Cloud Computing Regulatory Framework from the Communications, Space and Technology Commission classifies data by sensitivity and restricts where the higher classes may be hosted. Layered on top is the Personal Data Protection Law, whose regulations on cross-border transfer came into force in September 2024 and allow transfers only under specified conditions. In practice a Saudi bank plans for in-Kingdom hosting of anything touching customer data, which the local hyperscaler regions and national providers now make feasible for most workloads.

Kuwait and Oman: approval-based regimes

The Central Bank of Kuwait issued cyber security and outsourcing rules that require prior approval for cloud outsourcing of material systems and expect customer data to remain under the bank’s control, with Kuwait-hosted options preferred where available. The Central Bank of Oman’s framework likewise requires approval for material outsourcing, and Oman’s Personal Data Protection Law, fully enforceable since February 2026, adds transfer restrictions and a requirement for consent or legal basis. Both markets are smaller, local hyperscaler regions are newer or still arriving, and banks there often adopt a hybrid of in-country data centres with cloud services for non-sensitive workloads.

What the local regions solve, and what they do not

A local region solves residency of data at rest and in processing. It does not by itself solve several other things the regulators care about. Support staff located abroad may still access systems, which is why sovereign-cloud offerings with in-country operations exist. Managed services may replicate metadata or telemetry outside the region unless configured not to. Identity, key management and logging services may have global control planes. And a region operated by a foreign company is subject to that company’s home jurisdiction, which some regulators and boards treat as a residual risk to be documented rather than eliminated.

The practical answer is a data classification exercise first: which data is confidential customer data, which is operational, which is anonymised or aggregated, and which services may touch each class. Most banks find that a majority of workloads can move to a local region quickly, a minority need a sovereign arrangement or private cloud, and a small core, often the ledger, stays where it is for reasons that have more to do with the migration risk than the regulation.

Architecture patterns that keep you compliant

Keep systems of record and customer data in-country, and treat that boundary as an architectural rule enforced by network and policy, not a guideline. Build the digital channel and integration layers to be deployable to any of the three: on-premises, local hyperscaler region or sovereign cloud, which in practice means containers, infrastructure as code and no dependence on provider-specific services for anything that holds customer data. Encrypt with keys the bank controls, in a key management service the bank can take with it. Tokenise or pseudonymise before any data leaves the boundary for analytics or AI workloads. And design the exit: the regulators ask for it, and the banks that have one negotiate better contracts.

AI workloads and residency

The newest tension is between data residency and the models banks want to use. Frontier language models are hosted by a handful of providers, and sending customer data to them from a Gulf bank is generally not permitted. The workable patterns are models deployed inside the local region or on the bank’s own infrastructure, retrieval architectures that keep customer data in the bank’s own stores and send only non-identifying context to the model, and strict classification of what is sent where. This is an architecture question before it is a model question, and it is the reason AI programmes at banks succeed or stall.

How Eurisko helps

Eurisko deploys its digital banking platform on-premises, in local hyperscaler regions and in sovereign clouds for banks in Saudi Arabia, the UAE, Kuwait and Lebanon, and has supported outsourcing applications and regulator due diligence for those deployments. If you are planning a cloud migration or an AI programme and need an architecture that satisfies your regulator, our team can help you design it.

FAQ

Frequently asked questions.

Can Gulf banks use the public cloud?

Yes, within rules. All four central banks permit cloud outsourcing of material systems with approval or no-objection, due diligence and exit arrangements, and the UAE and Saudi Arabia in particular require confidential customer data to be stored and processed in-country. Local hyperscaler regions make that feasible for most workloads.

Does a local cloud region satisfy data residency requirements?

It satisfies residency of data at rest and in processing, which is the core requirement. Banks still need to address foreign support access, metadata and telemetry leaving the region, global control planes for identity and keys, and the provider’s home jurisdiction, which is why sovereign-cloud offerings and bank-controlled key management exist.

How can a bank use large language models without exporting customer data?

By deploying models inside the local region or on its own infrastructure, by using retrieval architectures that keep customer data in the bank’s stores and send only non-identifying context to the model, and by classifying strictly what may leave the residency boundary.

Let’s build

Have something ambitious in mind?

Start a project →

Popular searches

Jump to