The Case for Treating Data Residency as a Product Decision, Not a Legal One

Key Takeaways

• Regulators across the Gulf and APAC are no longer regulating one thing called "data residency" - they are separately regulating where data is stored, where it is processed, and increasingly, which AI models may touch it. Indonesia's OJK splits storage and processing into different articles with different rules; that split is the tell.

• Most institutions still resolve residency once, at legal sign-off or vendor onboarding, and treat it as settled. It isn't. Every new model call, every new pipeline, every new regulatory update reopens the question - and by the time legal notices, the architecture is already built the wrong way.

• The honest counterargument matters: not every market demands infrastructure localisation. Singapore's MAS runs a principles-based, contractual-controls regime with no hard data-domicile mandate. Applying the same architectural rigour everywhere is its own kind of waste.

• We propose the Domicile Ladder - four rungs (storage, processing, model, access) that should be scored per market at the same design-sprint stage as latency and availability, not bolted on after the fact.

• The practical first move for a CDO or Risk leader is a one-page map: current architecture against each operating market's actual requirements at all four rungs. Most institutions have never produced this map. It usually takes a week, not a quarter.

Introduction

Ask a CDO at a bank operating across three or four APAC or Gulf markets where their customer data resides, and you'll usually get a confident answer: "It's in-region, we cleared that with legal." Ask a follow-up - where is the data processed when a fraud model scores a transaction, and which AI model touches it when a service agent asks a copilot to summarise a case file - and the confidence drops noticeably. Those are different questions with different answers, decided by different teams, on different timelines, and increasingly governed by different rules.

That gap is not a compliance oversight. It's an architecture decision made by default, because residency was treated as a one-time legal clearance rather than a live constraint on system design. This matters more now than it did two years ago because regulators across the region have started regulating the storage question and the processing question separately, and are beginning to write AI-model-specific expectations into supervisory guidance. A legal opinion obtained when the core platform went live does not answer where a large language model runs when it drafts a claims decision summary eighteen months later.

This piece makes the case - grounded in what CBUAE, Bank Negara Malaysia, OJK Indonesia and MAS actually say, not what vendors claim they say - that data residency belongs in the same design conversation as latency budgets and availability targets. We also make the counterargument honestly: in at least one major regional market, that architectural rigour isn't what the regulator is asking for, and over-building it is its own failure mode.

The regulatory evidence: storage, processing and models are no longer the same question

Four regulatory frameworks, read side by side, show the shift clearly.

CBUAE (UAE) - storage is explicit; the AI layer is governed but not geofenced. Article 6 of the CBUAE Rulebook on outsourcing outside the UAE requires that "the Master System of Record, which includes all Confidential Data, is continuously maintained and stored within the UAE," with a narrower daily-copy allowance for foreign bank branches subject to Central Bank approval (CBUAE, n.d. a). The same article bars outsourcing to any jurisdiction that "cannot provide the same level of safeguarding of Confidential Data that would apply if the data was kept in the UAE" - an adequacy test, not just a location test. Separately, CBUAE's guidance note on AI and machine learning use by licensed financial institutions doesn't mandate that AI models run on UAE soil. It instead requires due diligence on third-party AI/cloud vendors' "governance, security and data-protection practices," audit rights in contracts, and - notably - that institutions "retain the clear and immediate ability, with human intervention, to cease use of an AI model system" (CBUAE, n.d. b). That's a control requirement dressed as a governance requirement: you can't retain a credible kill-switch over a model whose operational dependencies you don't know.

OJK Indonesia - the storage/processing split is explicit and codified. This is the cleanest evidence for the thesis in the entire region. OJK Regulation No. 11 of 2022 on the Implementation of Information Technology by Commercial Banks requires banks to place electronic systems in data centres and disaster recovery centres in Indonesia by default (Point 61), with overseas placement permitted only after OJK authorisation and only for six narrowly listed purposes - group regulatory reporting, integrated risk management with an offshore parent, group AML/CTF, global customer service integration, head-office/branch communication, and internal management (Points 62-63) (OJK, 2022). Data placed overseas under that exception cannot be used for anything outside those listed purposes (Point 69). Then, separately, Point 72 requires that banks "process IT-based transactions within the Indonesian territory," with overseas processing again requiring distinct authorisation (Point 75). Storage location and processing location are governed by different points, with different approval logic. Indonesia has now reinforced this with a new IT governance regulation (OJK Regulation No. 1 of 2026, effective 1 March 2026), which replaces the 2017 circular and tightens third-party provider oversight and digital-maturity assessment obligations on top of the existing infrastructure-location regime (Conventus Law, 2026).

Bank Negara Malaysia - control retention over hard localisation. Malaysia's Risk Management in Technology (RMiT) policy document, revised November 2025, doesn't mandate that cloud infrastructure sit inside Malaysia. It requires institutions to assess "the location of cloud infrastructure including potential geo-political risks and legal risks that may impede compliance with any legal or regulatory requirements" (BNM, 2025, para. 10.50(c)) as one input to a cloud risk assessment, and separately to "retain ownership, control and management of all data pertaining to customer and counterparty information, proprietary data and services hosted on the cloud" (para. 10.52), including encryption keys, "themselves or with an independent key custodian" (para. 10.21(a)). BNM's model is closer to a logical-control regime than a hard domicile mandate - but location remains a named, assessed factor in every material cloud and AI deployment decision (para. 17.1(a)), not a one-off.

MAS Singapore - no hard domicile mandate, but a fast-moving model-risk layer. Singapore is the clearest counter-case. MAS's Guidelines on Outsourcing take a principles-based, accountability-first approach: institutions must be aware that cloud services carry "a higher propensity for data processing to be carried out in multiple locations" and must manage that risk, but MAS does not prescribe where processing must occur - "institutions are ultimately responsible and accountable for maintaining oversight of cloud services and managing the relevant risks" regardless of location (as summarised in Herbert Smith Freehills Kramer, 2016, characterising MAS's Guidelines on Outsourcing). What has changed is the AI layer. MAS's December 2024 guidance on AI model risk management pushes institutions toward independent testing of third-party and foundation models, contractual audit rights, and contingency plans for vendor failure (K&L Gates, 2025). Clifford Chance's review of how Singapore banks are actually responding is the most telling data point in this research: several banks are choosing "private cloud solutions or open-source models on-premise" specifically as a data-protection mitigation for generative AI use cases (Clifford Chance, 2025) - not because MAS ordered it, but because that architecture makes the governance requirement easy to satisfy. That's the thesis in miniature: the smartest institutions are already making the model-hosting decision an architecture decision, ahead of the rule requiring it.

The Gulf is not one jurisdiction either. A 2026 shift across the DIFC, ADGM and QFC financial free zones - mutual adequacy recognition allowing data to move between the three without transfer assessments or contractual safeguards - does not extend to mainland UAE entities governed by the federal Personal Data Protection Law, and "further clarity is expected" on how the two regimes interact (Addleshaw Goddard, 2026). An institution running a DIFC-licensed entity alongside a UAE onshore entity does not have one Gulf residency answer. It has at least two, and they are diverging, not converging.

The CDO's actual decision problem

Strip away the compliance framing and the CDO's problem is a straightforward architecture trade-off, made under incomplete information, with a long-lived cost of getting it wrong.

A regional insurer building a claims-processing platform across, say, Indonesia, Malaysia and the UAE has to decide: one global data plane with regional read replicas, or genuinely regional deployments with a thin shared services layer? Centralised feature stores and model training, or per-market model instances? A single foundation-model API integration for claims summarisation, or region-specific deployments - some via a hyperscaler's in-region endpoint, some on a smaller local or open-weight model run on-premise because no compliant hosted option exists yet in that market?

Every one of those choices has a residency consequence that is jurisdiction-specific and layer-specific. Indonesia's Point 72 separately regulates the processing choice from the storage choice. MAS makes the same processing choice a risk-management exercise, not a location mandate. CBUAE's AI guidance makes the UAE choice hinge on vendor governance and kill-switch capability more than physical location. These aren't variations on one theme the CDO can solve once - they're four different constraint sets to design against simultaneously, in one shared platform, without either building incompatible regional stacks or quietly picking the loosest jurisdiction's answer and hoping it holds everywhere.

This is exactly the kind of trade-off architecture teams already know how to handle - for latency, availability, disaster recovery. It gets handled badly here specifically because it doesn't arrive through the same channel. Latency requirements come from a performance NFR document engineering owns. Residency requirements come from an external counsel memo legal owns, written once, filed, and rarely revisited against the live system it was meant to govern.

What most institutions get wrong

Three recurring failure patterns showed up consistently across the regulatory and legal-advisory material reviewed for this piece.

They resolve residency at the wrong point in the lifecycle. The legal opinion typically arrives at vendor selection or core-platform go-live - a point-in-time answer to a point-in-time architecture. It is not revisited when a new AI feature is added six months later, even though, as the CBUAE and MAS evidence shows, the AI/model layer is exactly where regulatory expectations are moving fastest and where the original opinion is least likely to have said anything specific.

They treat "the country" as the unit of analysis, when the regulator treats "the layer" as the unit of analysis. Indonesia's own regulation proves this: storage and processing get different rules. Treating "Indonesia" as a single yes/no residency question, when the regulator itself splits it into at least two separately governed questions, guarantees the architecture answer will be wrong on one axis even when it's right on the other.

They confuse the absence of a hard mandate with the absence of a design decision. MAS's principles-based approach is genuinely lighter-touch than Indonesia's or the UAE's. But "no hard mandate" isn't "no consequence." The institutions Clifford Chance describes choosing on-premise open-source models over hosted foundation-model APIs made an active choice to make the MAS risk-management burden lighter. Institutions that make no such choice - that simply call whichever API is fastest to integrate - aren't avoiding the decision. They're making it by default, usually toward least short-term friction and highest long-term audit exposure.

The Domicile Ladder: a design tool, not a compliance checklist

The pattern across all four frameworks reviewed here is that residency obligations stack in layers, and each layer can have a different answer in the same market. We call this the Domicile Ladder - four rungs, scored per operating market, at the same point in the design sprint where a team would set a latency budget or an availability target:

1. Storage domicile - where data at rest physically resides. The layer most legal opinions actually cover, and the one regulators have regulated longest (CBUAE's Master System of Record requirement; OJK's Point 61 data-centre location rule).

2. Processing domicile - where compute executes against the data: ETL, feature engineering, transaction scoring, batch analytics. Increasingly regulated separately from storage, most explicitly in OJK's Point 72, and the layer most architecture teams don't distinguish from storage at all.

3. Model domicile - which AI/ML model touches the data, where it is hosted or called from, and whether it is a foundation-model API, a regionally hosted instance, or an on-premise/open-weight deployment. The newest and least standardised rung - governed today through vendor due-diligence and kill-switch requirements (CBUAE) or model-risk-management expectations (MAS) rather than hard location rules, but moving fastest.

4. Access domicile - where the humans who can view, export or administer the data sit: vendor support engineers, sub-processors, auditors. Governed through jurisdiction-adequacy tests (CBUAE's "same level of safeguarding" standard) and contractual audit rights (MAS) rather than infrastructure location, but still a real constraint on vendor selection and support-model design.

The point of scoring all four rungs per market, at design-sprint stage, is not to produce a compliance artefact. It's to surface, before the architecture is built, which rungs are already resolved by regulation (build to the rule), which are open to contractual/architectural trade-off (build to the cheapest compliant option), and which are simply unaddressed yet (flag as a live risk, not a closed question). That last category is where most institutions currently have silent gaps - particularly on the model domicile rung, which barely existed as a regulatory concern two years ago and is now moving quickly across every framework reviewed here.

Business and technology implications

Designing to the Domicile Ladder from the outset has concrete consequences. Data classification has to happen early enough to drive routing decisions - which records are in scope for which rung's constraints - rather than being retrofitted onto an existing pipeline. Encryption key ownership, which BNM treats as a standalone control (para. 10.21(a)) independent of physical location, becomes a portable compliance lever: retaining keys under institutional control can satisfy part of the access-domicile rung even when infrastructure is multi-region. Model deployment choices need a documented decision tree - hosted foundation-model API, in-region managed endpoint, or on-premise/open-weight - made per use case and per market, mirroring what Clifford Chance found Singapore banks already doing informally. Disaster-recovery architecture has to be designed against the same four rungs as the primary deployment, since a failover that silently moves processing to an out-of-scope jurisdiction defeats the whole design.

The cost dimension matters as much as the technical one. Retrofitting a residency-compliant architecture after a regulatory update, an audit finding, or a new AI feature launch is materially more expensive than designing to it, because by the time the gap surfaces, the pipeline, the contracts and the model integrations are already load-bearing. Multi-region architecture isn't free either - which is why the ladder should be scored per market rather than applied uniformly. Over-building UAE-grade infrastructure controls into a Singapore deployment MAS would accept under a lighter contractual regime is real, avoidable cost.

A fair counterargument

The case for architecture-first design shouldn't be overstated. Singapore's own posture is the strongest evidence against a one-size-fits-all response: MAS manages residency-adjacent risk through accountability and contractual controls, not infrastructure mandates, and institutions that meet that bar with strong vendor contracts, audit rights and risk oversight aren't under-engineered - they're correctly matched to what the regulator actually requires. Even Indonesia, the hardest infrastructure mandate reviewed here, built an approval-based exception route (Points 62-64) rather than an absolute rule, meaning legal and regulatory engagement remains part of the answer even in the most demanding market covered - architecture doesn't supersede it, it works alongside it. For a smaller institution in a single, lighter-touch market, a full Domicile Ladder exercise may be disproportionate to the actual exposure. The realistic position: architecture-first design reduces the cost and risk of change - new markets, new AI features, new regulatory updates - more than it reduces the cost of standing still in a stable, single-market deployment.

What leaders should do next

The first move is not a re-architecture. It's a map. Take the current data and AI architecture - every pipeline, every model integration, every vendor - and score it against the Domicile Ladder's four rungs, per operating market, using the actual regulatory text rather than the vendor's compliance marketing. Most institutions have never produced this map in one place; legal holds the storage answer, engineering holds the processing answer, and nobody owns the model-domicile answer at all. Building it typically surfaces two or three unaddressed gaps immediately, usually at the model layer, and rarely takes more than a couple of weeks with the right people in the room. From there, the map becomes a standing input to every future design sprint, reviewed on the same cadence as any other non-functional requirement - not reopened only when the next audit or regulatory update forces the question.

The sourceCode’s perspective

We build and modernise core systems for banks, insurers and fintechs across these exact markets, and the pattern is consistent: the institutions that get burned are not the ones operating in the strictest jurisdiction. They're the ones that never wrote down which rung of the ladder each market actually requires, so nobody notices until a new AI feature, a new market entry, or a new regulatory circular collides with an architecture that was never asked to answer the question.


Treating residency as a design-sprint input - scored the way you'd score a latency budget, revisited the way you'd revisit a capacity plan - is not extra rigour for its own sake. It's the difference between a residency question that costs a week of mapping now and one that costs a platform rebuild under audit pressure later. Talk to us!

Conclusion

Data residency has quietly stopped being a single question with a single legal answer. CBUAE, OJK Indonesia, Bank Negara Malaysia and MAS each regulate a different combination of storage, processing, model and access location - and the newest, fastest-moving layer, which AI model touches the data and where it runs, is barely standardised across any of them yet.


Institutions that keep resolving this once, at legal sign-off, will keep being surprised by it. Institutions that score it per market, per layer, at the same point they'd set any other architectural constraint, will not eliminate the legal work - but they will stop discovering the gap at the worst possible time.

Frequently Asked Questions

Is data residency the same as data sovereignty? No. Data residency generally refers to where data is physically stored or processed; data sovereignty is the broader principle that data is subject to the laws of the jurisdiction it sits in, including government access rights. In practice regulators blend the two - CBUAE's adequacy test under Article 6, for instance, is about sovereignty (whether a foreign jurisdiction's legal system provides equivalent protection) applied through a residency-style location requirement.

Does data residency mean customer data can never leave the country? Not usually, and not in any of the frameworks reviewed here. Even Indonesia's OJK Regulation 11/2022, the strictest infrastructure mandate covered in this piece, allows overseas data centre and processing placement under regulator approval for defined purposes (Points 62-64, 75). The more common pattern is conditional cross-border transfer, not an absolute ban.

Can we use a foundation model hosted overseas (e.g., a US or EU-hosted LLM API) and stay compliant? It depends on the market and the rung. In Singapore, MAS's principles-based approach means this is a risk-management and contracting exercise, not an automatic breach - though MAS's December 2024 AI risk guidance raises the bar on due diligence and audit rights for third-party models. In the UAE, CBUAE's AI/ML guidance note requires vendor due diligence, contractual audit rights and a credible human-intervention kill-switch, but does not itself mandate the model run on UAE soil. In Indonesia, if the API call constitutes "processing" of IT-based transactions, Point 72's default requirement to process within Indonesian territory applies unless a specific OJK-approved exception exists. There is no single regional answer - it has to be checked per market.

Why does the storage vs processing distinction matter so much in practice? Because they are frequently handled by different teams with different tooling and can have different regulatory answers in the same market, as OJK Indonesia's regulation demonstrates directly. An architecture that satisfies the storage requirement (data centre located in-country) can still breach a separate processing requirement if compute for that data is later moved offshore - for example, by routing transaction scoring through an overseas analytics service.

Is this only relevant to large, multi-market institutions? Multi-market institutions face the sharpest version of the problem because they have to reconcile several jurisdictions' rungs in one shared platform. But single-market institutions are not exempt - the model domicile rung, in particular, is moving quickly even in single-market deployments as generative AI features are added to existing platforms.

What's the first practical step for a CDO or Head of Risk? Produce the map: current architecture against each operating market's requirements across the four Domicile Ladder rungs (storage, processing, model, access), sourced from the actual current regulatory text rather than a vendor's compliance summary. This usually takes one to two weeks and reliably surfaces gaps that legal sign-off alone did not catch - most often at the model and processing rungs.

Reference List

Addleshaw Goddard (2026) A new era for cross-border data flows across QFC, DIFC and ADGM. Available at: https://www.addleshawgoddard.com/en/insights/insights-briefings/2026/data-protection/new-era-cross-border-data-flows-across-qfc-difc-adgm/ (Accessed: 29 September 2026).

Bank Negara Malaysia (2025) Policy Document on Risk Management in Technology (RMiT), revised November 2025. Available at: https://www.bnm.gov.my/documents/20124/938039/pd-rmit-nov25.pdf (Accessed: 29 September 2026).

Central Bank of the UAE (CBUAE) (n.d. a) Article 6: Outsourcing Outside the UAE, CBUAE Rulebook. Available at: https://rulebook.centralbank.ae/en/rulebook/article-6-outsourcing-outside-uae (Accessed: 29 September 2026).

Central Bank of the UAE (CBUAE) (n.d. b) Guidance Note on the Consumer Protection and Responsible Adoption and Use of Artificial Intelligence and Machine Learning by Licensed Financial Institutions in the U.A.E., CBUAE Rulebook. Available at: https://rulebook.centralbank.ae/en/rulebook/guidance-note-consumer-protection-and-responsible-adoption-and-use-artificial-intelligence (Accessed: 29 September 2026).

Clifford Chance (2025) Good Practices for AI Model Risk Management for Singapore Financial Institutions. Available at: https://www.cliffordchance.com/insights/resources/blogs/talking-tech/en/articles/2025/05/good-practices-for-ai-model-risk-management-for-singapore-financ.html (Accessed: 29 September 2026).

Conventus Law (2026) Indonesia's Financial Services Authority Strengthens the Digital Backbone of Banking Sector through Regulation No. 1 of 2026 on IT Governance for Commercial Banks. Available at: https://conventuslaw.com/report/indonesias-financial-services-authority-strengthens-the-digital-backbone-of-banking-sector-through-regulation-no-1-of-2026-on-it-governance-for-commercial-banks/ (Accessed: 29 September 2026).

Herbert Smith Freehills Kramer (2016) Monetary Authority of Singapore Updated Outsourcing Guidelines. Available at: https://www.hsfkramer.com/insights/2016-08/monetary-authority-of-singapore-updated-outsourcing-guidelines (Accessed: 29 September 2026).

K&L Gates (2025) Managing Artificial Intelligence: The Monetary Authority of Singapore's Recommendations on AI Model Risk Management. Available at: https://www.klgates.com/Managing-Artificial-Intelligence-The-Monetary-Authority-of-Singapores-Recommendations-on-AI-Model-Risk-Management-1-22-2025 (Accessed: 29 September 2026).

Otoritas Jasa Keuangan (OJK) (2022) Regulation No. 11 of 2022 concerning Implementation of Information Technology by Commercial Banks. Available at: https://ojk.go.id/en/regulasi/Documents/Pages/Implementation-of-Information-Technology-by-Commercial-Banks/OJK%20Regulation%2011%202022%20concerning%20Implementation%20of%20Information%20Technology%20by%20Commercial%20Banks.pdf (Accessed: 29 September 2026).