Move to the cloud only as far as you have rehearsed leaving

Most debates I hear about public cloud in Japanese banking are framed as questions of permission. Does the Financial Services Agency allow it, on what conditions and for which systems? The answer has been clear for some time: banks may use public cloud, as they may use any outsourced service, provided they remain responsible for it. My position is that the useful question for a regional bank is not permission but reversibility. A bank should move a system to public cloud only when it has actually rehearsed leaving, within a time it is prepared to state to its board, and the pace of adoption should follow the exits it can perform rather than the features it wants.

What the supervisor is actually asking

I will describe the supervisory expectations in general terms, because the detail sits across guidelines, inspection practice and the industry's own security standards, and it continues to develop. Its core is not complicated. A bank that outsources must understand and monitor the provider's controls, keep the access it needs for audit and inspection, know where its data is held and processed, manage the risk of depending on a few large providers and be able to continue its business if the provider fails or the relationship ends. None of this is specific to cloud. What is specific is scale: one provider may host many banks' systems, and many of each bank's suppliers' systems too, so a bank's real dependence can be larger than its own contracts show.

Banks tend to answer these expectations with documents: a due-diligence file on the provider, a contract with audit clauses, an annex on data location and an exit plan. I have signed several of those exit plans. Until 2025 none of them had been tried, and I did not know whether any of them would work.

An exit we have actually performed

Our first significant workload on public cloud is the analytics platform that holds lending, deposit and channel data for management reporting, credit monitoring and marketing. It was postponed by nine months in 2023, when I moved money into rebuilding our backups after a failed restore test, and the delay gave us time to reconsider how we would approve it.

We set a condition before migration rather than after it. The platform's critical outputs, the reports on which our credit and liquidity committees rely, had to be reproducible outside the provider within 72 hours, using data and configuration we exported routinely. In August 2025, before go-live, we rehearsed it. A team of nine rebuilt those reports in our own data centre from the previous night's export. It took 58 hours. Two reports differed from the cloud versions because a currency conversion table had been left out of the export, and one engineer held knowledge that appeared nowhere in the runbook. We fixed all three and went live in October.

The rehearsal cost about ¥90 million, including equipment we now keep in reserve. Our head of digital strategy, who had already waited nine months, saw it as one more delay. I understood her frustration, and I still think the rehearsal was the most valuable part of the project. It turned a paragraph in an exit plan into a measured time, a list of dependencies and a team that has done it once. When our supervisor asked about the platform, I could describe what had happened rather than what we intended.

The rehearsal also changed what we ask of the provider. We had assumed that exporting data would be the hard part. It was easy. The difficult parts were the provider-specific services we had adopted for convenience, a managed scheduling tool and an identity integration, each of which had to be replaced with something we could run ourselves. We now limit provider-specific services on regulated workloads to those for which we have a rehearsed replacement.

Why our ledger stays where it is

I am often asked when our core ledger will move to public cloud. My honest answer is not while the concentration is so hard to test. Our core now runs in Kaname's two data centres, shared with eight other regional banks. If that environment moved to a single cloud provider, nine banks would depend on one operator running on one provider, and an exit would require all nine to move together. I do not know how to rehearse that at a reasonable cost, and I would not ask our board to accept a risk I cannot measure.

That is a judgement about today, not a doctrine. In many respects cloud providers' resilience exceeds anything a regional bank can build for itself. A future shared core designed to run across more than one provider, with exits rehearsed by the consortium as a whole, could change my view, and I would welcome it.

Meanwhile we are moving outward from the ledger rather than towards it. The analytics platform went first. Our internet banking front end is next, planned for 2027, and I will not approve that move until we have rebuilt it in our own data centre from exported configuration within the time we commit to. Branch and contact-centre tools may follow. Each step is chosen because we can leave it.

This approach has costs. We move more slowly than some peers. We pay for reserve capacity we hope never to use, and we give up some of the convenience that makes cloud attractive in the first place. Some of our engineers find the restriction on provider-specific services frustrating, and they are right that it makes us less efficient.

I would put a simple proposition to any bank board weighing cloud adoption. For each workload proposed, ask management how long it would take to run it somewhere else, when that was last tried and what was learnt. If the answer is a plan that has never been performed, the workload is not ready to move, however strong the business case. If the answer is a measured time and a team that has done it, the board can make a real decision about risk, which is what the supervisor expects of it in the first place.