Moving a bank to the cloud without losing the regulator

The situation

Banking in the UAE does not treat the cloud as a procurement decision. The Central Bank's Outsourcing Regulation requires a bank to retain ownership of all data given to a service provider, to guarantee the Central Bank can access that data on request, and to avoid any jurisdiction whose bank secrecy or other laws would restrict access needed for supervision. In February 2026 the Central Bank went further and launched sovereign financial cloud infrastructure of its own, and its Operational Risk Management Regulation came into force on 14 September 2026.

Read together, those rules mean a bank cannot answer "is this compliant" by pointing at a provider's certification. It has to be able to say where each category of data rests, who can reach it, and what happens when a supervisor asks.

The problem

This bank had board approval for a cloud migration and had made no progress for eleven months. The programme was not blocked on technology. It was blocked on a question nobody would own.

The migration partner had scoped a lift-and-shift and treated residency as a configuration setting. The risk function had read the same regulation and reached a different conclusion. Neither would move, so the programme sat in a monthly steering committee where the same disagreement was minuted and deferred.

Underneath it was a real ambiguity. The bank knew where its data would be stored. It did not know where its data would be processed, who in the provider's support organisation could see it during an incident, or who held the encryption keys. Those are three different questions and the programme had one answer for all of them.

What we did

We refused to start with a migration plan. The first four weeks produced a data map instead: every store, classified by whether it held confidential customer data, and for each one a written answer to storage, processing, support access and key custody.

That was an unpopular opinion in week one. The steering committee had been waiting eleven months and wanted to see servers move. Our position was that a migration begun without those four answers would be stopped by the regulator later, at a far worse moment, and that the eleven months already lost were the argument for doing it properly rather than against it.

The map changed the design. Roughly a fifth of the estate turned out to hold data that could not leave UAE jurisdiction under any configuration the provider offered at the time, which pointed at the sovereign infrastructure rather than the commercial region. The rest could move conventionally. Treating the estate as one thing had been the original error.

We then built a landing zone around that split, with customer-managed keys held by the bank, support access brokered through a break-glass process the bank controlled, and logging that could answer a supervisory question without a support ticket to the provider.

Migration ran in waves, quietest systems first, with the core banking platform last and a rehearsed rollback at every wave.

The outcome

About 1.74 petabytes moved with no customer-facing downtime. The core banking cutover ran inside a planned window and did not need its rollback.

The post-migration supervisory review raised no findings. That is the outcome the bank actually bought: not the migration, which any competent partner could have executed, but the ability to answer the regulator's questions without having to go and ask somebody else first.

A cloud migration in a regulated bank is less like moving house and more like moving a library that people are still borrowing from, where a committee can ask at any moment which shelf a particular book is on and who else has a key to the room. The lifting is the easy part.