Your Busiest Days Are Your Growth Days. Old Systems Fail on Them.

It is the last working day of the month, and the festival offer went live this morning.

Collections has a target to close. Disbursals have been queued since nine. Finance has started the month-end reports. All of it runs on the same application.

At eleven o’clock the screens in the branches slow down. By half past, agents cannot post a payment. The call centre has nothing to tell the people on hold. Service comes back in the afternoon, and the offer has spent its best hours on a system that was not there.

What We Found

We looked at two things: what the public record says about outages on the days that matter most, and how firms usually prepare for those days.

The failure lands on the day the most people are watching. The January and February 2025 outages at a UK bank 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”.

Repeated outages are answered with limits on growth. In April 2024 the RBI barred Kotak Mahindra Bank from taking new customers online and issuing new credit cards for about ten months. Among the reasons it cited were “frequent and significant outages”.

An old system does not fail everywhere at once. This is our reasoning, not a finding from a named case. A system built for the volumes of years ago now also serves a mobile app, UPI and partners. On an ordinary day there is room to spare everywhere. On a peak day, collections, disbursals, interest runs and reports land at once, and one shared part runs out of room first. Everything waiting on it stops, and the whole system appears to fail.

Preparation usually goes where it is easy, not where the limit is. Also our reasoning. Before a peak, firms add servers and put staff on standby. If the limit is one database table, one queue or one overnight job, more servers around it change little.

The Days the Business Was Planned Around

Peak days are usually discussed as risk days: get through them without an incident. Our reading of the record is that they are something else first. They are growth days.

Payday is when customers pay and borrow. Month end is when collections close and disbursals go out. Festival season is when a lender’s campaigns are meant to bring in new customers. An outage on an ordinary Tuesday costs a few hours. An outage on one of these days costs the day the quarter was built around.

It also changes how the business plans: campaigns staggered, disbursals spread across the week, operations asked not to run everything at once. The old system starts to set the pace. And when outages repeat, the regulator can set it too: in both Indian cases we found, the remedy was a limit on new business.

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

Four Ways to Prepare for the Next Peak, Weighed

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 hardware changes little. The spend returns every year
Restore service fast and close each incident	Peak failures are rare and truly unrelated	Each peak teaches one lesson, at the cost of one outage. The record grows
Replace the whole system	The system is small, or failing everywhere	Years before any benefit, and risk across functions that were never failing. The peaks keep coming while it runs
Find the part that gives way first, and move it first	A few shared parts of an old system run out of room under load	It needs the incident record, a map of the system and time from the people who know it. Moving the part takes stages

Where You Are Now, and Where You Should Be

Before the next peak, we would set a benchmark for how the firm meets it.

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 before the peak, with what stops when it does	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, month end and festival season	The firm’s rehearsal record
The moved module tested at peak volume	First tested by customers on the 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 we expect to find. In an engagement they are replaced by your own position, 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, your peak days, and what went wrong on the last few. 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. 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 you need to bring: your calendar of peak days, two years of incident reports, and a few hours from the people who were on call.

What changes for the business:

Role	What they gain
CEO	Payday, month end and festival season become days to grow on, not days to get through.
CTO or CIO	The team knows which part gives way first and what depends on it. Peak days stop being emergencies.
CFO	The cost of the next failure can be weighed against a known price for fixing the part behind it.
COO	Peak days can be planned for staff and campaigns, without rationing work to protect the system.
Risk and compliance	Evidence that the firm has examined how it operates under strain.

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

The case	What IOanyT does
At a UK bank, 56% of online payments failed over three days 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, our assessment maps what depends on what, and we move the part that gives way first, one module at a time.
The RBI restricted Kotak Mahindra Bank for about ten months, citing frequent and significant outages.	Our risk register and staged plan give the firm its weak parts in order, with a price for moving each. 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 busiest day should be the one the business was planned for, not the one it fears.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →