Every Outage Was Resolved. The Record Is What the Regulator Reads.

The incident report is two pages long. Service was lost for four hours on Tuesday. A database table locked, it was cleared, service came back, and the last line says resolved.

You sign it. It is the third report like this you have signed this year. Each had a different cause, a different fix and the same last line.

Then a letter arrives from the regulator. It asks for every incident in the past two years, on one page.

What We Found

Before we suggest anything to a lender, we study its sector. For this article we went through the public record on IT outages in banking: the RBI’s enforcement actions as reported in the press, and the figures UK banks have reported on their outages, from 2020 to 2025.

Four findings stand out.

Outages are counted together, not one at a time. Nine UK banks reported “803 hours of outages between January 2023 and February 2025, spanning at least 158 separate incidents”. Each would have been handled and closed on its own. Counted together, they are a record.

The busiest day is where the failure is most visible. In the January and February 2025 outages at a UK bank, which fell on payday, the record describes “severe degradation” of its mainframe processing, with “56% of online payments failing over a three-day period”. The bank expects to pay “between £5 million and £7.5 million in compensation”.

In India, repeated outages have been met with limits on new business. On 24 April 2024 the RBI barred Kotak Mahindra Bank from taking new customers through its online and mobile channels and from issuing new credit cards. Among the reasons it cited were “frequent and significant outages”. The restrictions lasted about ten months.

This is not new. In an older case, after two years of outages at HDFC Bank, the RBI ordered it on 2 December 2020 to stop new digital launches and stop sourcing new credit card customers. Both Indian remedies fell on growth, not on the systems themselves.

What the Record Costs Before Anyone Reads It

Outages are usually treated as an operations problem: restore service, close the ticket, move on. Our reading of the record is that they are also a growth problem.

Look at what the RBI restricted in both Indian cases: new customers online, new credit cards, new digital launches. Every one of them is growth. When outages become a pattern in the regulator’s eyes, new business is what stops.

The second cost is quieter. Each incident report names the immediate cause: a locked table, a full queue, a job that overran. Judged alone, each looks different, and nobody lays them side by side to see whether several are the same weak part.

The third is money. Emergency vendor calls, overtime and goodwill credits follow every outage, and none of it changes the system.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Answer a Growing Incident Record, Weighed

A firm whose outages keep coming back has four real options. Each one is right for somebody.

Option	When it fits	What it risks
Add hardware before each peak	The servers really are the limit	When the limit is one table, queue or job, more servers change little, and the cost comes back every year
Fix each outage as it comes, and close it	Outages are rare and truly unrelated	The pattern stays hidden, and the record grows until someone else counts it
Replace the whole system in one project	The system is small and failing everywhere	Years of work and risk for parts that were never failing, and the outages continue while it runs
Find the part that gives way first, and move it first	A few parts of an old system keep failing under load	Finding the part takes the incident record and a map of the system, and moving it takes stages

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own record, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
Peak-day incidents with a root cause	”Under investigation”, then closed	Every one with a cause, traced to a part of the system	The incident record
The part known to fail first	Found on the day it fails	Named, with what depends on it	The map of the system and the risk register
Recovery rehearsed before each peak	Staff on standby, nothing rehearsed	Rehearsed by the firm’s own team before each payday and month end	The firm’s rehearsal record
The moved module tested at peak volume	No test before the busy day	Tested at the volume of the busiest day before it is accepted	The acceptance record for each module
Repeat incidents	The same weakness under a new name	Falling with each module moved	Reported at every review

The starting points above are what the public cases show and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a lender.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the system, the outages of the past two years, and the days they fell on. You leave with a short written note of what we found.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running, starting with the part that gives way first. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

What changes for the business:

Role	What they gain
CEO	Outages stop being a regular item at the board, and there is a plan to show the regulator.
CTO or CIO	The real cause is found, so the same failure stops coming back under a new name.
CFO	Money moves from repeated emergency repairs to removing the cause once.
COO	Fewer days when branches and call centres work without their systems.
Risk and compliance	An incident record that improves, with a cause and an action against each repeated weakness.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
A UK bank’s mainframe processing degraded in outages that fell on payday.	Our part is narrower. We do not work on mainframes. For the systems a firm builds around its core, we find the part that gives way first and move it, one module at a time.
The RBI restricted Kotak Mahindra Bank and, in an older case, HDFC Bank after repeated outages.	Our assessment gives the firm a list of weak parts and a staged plan to move them. Taking a plan to the regulator is the firm’s own job.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The firm reads its own record first, and the plan beside it is one it can check.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →