A shared core system also shares its worst night
Regional banks are right to join shared core systems, but the savings arrive with a concentration of failure that member banks rarely test together. Each member should insist on joint failure exercises and keep its own fallbacks for the few services customers cannot do without.
I recommended that Shiomine join a shared core banking system, and I would make the same recommendation today. I also think that most regional banks, mine included until recently, have understood only half of what they bought. A shared system spreads the cost of building, running and changing a core ledger across its members. It also concentrates failure. When the shared environment has a bad night, every member has it at once, with the same cause, the same engineers and the same queue for attention. My position is that member banks should treat that concentration as a risk they own and test together, not as something the operator has absorbed on their behalf, and that each bank should keep a small set of fallbacks under its own control.
What we bought when we joined
In 2019 our choice was between rebuilding our own core and joining Kaname, a system then used by eight regional banks and operated by Mikage Information Systems from two data centres, one in eastern Japan and one in the west. Rebuilding would have cost more, taken longer and left us dependent on a shrinking group of specialists. Joining meant giving up most of our 211 customisations, accepting a common release calendar and arguing for changes in a committee of peers. We moved our 3.4 million accounts in May 2025. Our annual core running cost falls from ¥7.8 billion to ¥5.3 billion from this financial year, and the engineering quality of the shared environment is higher than anything we could have afforded alone.
Those benefits are real, and I do not want this essay read as regret. Shared systems are one of the reasons Japanese regional banks can still afford modern cores at all. But the case for joining was made, at our bank and I suspect at most others, almost entirely in terms of cost and engineering capacity. The risk discussion concentrated on the migration itself, which is where the industry's most painful lessons lay. Over the past quarter-century Japanese banks have suffered failures during and after system integrations that left ATMs unavailable and transfers delayed for days, and that ended in public apologies and business improvement orders. Every board approving a migration has those episodes in mind. Fewer boards ask what happens in the tenth year of a shared system rather than its first week.
When nine banks fail at the same moment
In June 2025, six weeks after our cut-over, internet banking log-in failed for 23 minutes one weekday morning at three of Kaname's nine banks, ours among them. The cause was a certificate configuration change in the shared environment. The incident was brief and the operator handled it well. What interested me was what followed. Three banks' contact centres took calls at once, three banks drafted reports to their supervisors at once, and three banks asked the same engineers the same questions in the same hour. Each of us had incident procedures. None of us had a procedure for an incident we shared.
The pattern is not new. In 2023 a fault in shared equipment connecting a group of banks to the interbank funds-transfer network delayed a very large number of transfers over two days. Shared infrastructure makes the sector cheaper to run and more uniform, and uniformity means that failures arrive together.
Our consortium tests resilience seriously, but it tests one member at a time. Each bank rehearses switching to the backup data centre on its own schedule, with Mikage's engineers concentrating on that bank. That is a sensible way to prove each bank's configuration. It does not prove what happens when the primary centre fails for everyone, when nine banks' batches, channels and interfaces must move together and the operator's best people are needed in nine places. I have proposed to the member banks that we run that exercise, all nine at once, in 2027. It will be expensive, it will need a holiday weekend every member can agree on and it will probably expose weaknesses that are uncomfortable for the operator and for us. That is the reason to do it.
The governance question is harder than the technical one. In a shared system nobody owns the whole risk. The operator owns the service it has contracted to provide; each member bank remains responsible to its customers and its supervisor for what it offers them. Supervisors have been consistent that outsourcing an activity does not outsource responsibility for it. A member bank's board therefore has to understand a risk it cannot manage alone, and the consortium's committees end up making what are, in effect, risk decisions for nine boards at once.
What each member must still own
Whatever the consortium does, I think each member bank should keep three things for itself.
The first is a short list of services that must continue, or resume first, whatever caused the outage, agreed in advance with the business. At Shiomine the list begins with corporate salary payments, because most of our corporate customers pay their staff on the 25th, and with cash withdrawals at branches. Internet banking log-in, which customers notice first, comes later. The list is ours to set, because no operator can rank nine banks' customers for them.
The second is a manual or semi-manual fallback for those services that the bank can run without the shared environment for at least one business day. Ours lets branches pay out limited cash against a recent balance file and lets us release a held salary file through a separate route. These arrangements are crude and costly to maintain. We rehearse them twice a year, and each rehearsal finds something that has drifted since the last.
The third is the ability to explain an incident in our own words, quickly. Customers and supervisors do not distinguish between Shiomine's outage and Kaname's. We now hold statements agreed in advance with the other members for shared incidents, so that three banks do not publish three versions of the same cause.
There are fair objections. A joint failover exercise could itself cause an incident, and some members argue that the operator's single-bank tests already cover every component. Others worry that fallbacks add cost to a system chosen for its economy. I accept both points as matters of degree. The exercise should be staged with care, and the fallbacks should cover only the services whose interruption would harm customers who cannot wait.
My advice to any regional bank considering a shared core is to join if the economics work, as they did for us, and then to ask three questions at the first board meeting after signing. What happens if the shared environment fails for every member at once, and when was that last tried? Which of our services must survive it, and can we run them ourselves for a day? Who speaks for us while the operator is still diagnosing the cause? A bank that cannot answer them has bought a cheaper core and an outage nobody has rehearsed.