The Regulator Now Looks at How You Change Your Systems. Most Old Systems Cannot Show a Change Was Safe.
We reviewed the public record on how changes and fixes reach old systems in financial services. Here is what we found, what it holds back, the options, and the benchmark we would set.
The business asked for one thing: change the processing fee on a single loan product.
A developer made the edit in an afternoon. Then two people spent a week clicking through screens to see whether anything else had changed. The release went out on a Saturday night. On Monday morning, finance reported that the fee income report no longer matched the ledger.
Nobody had checked that report, because nobody knew it read the fee from the same place.
The paradox: The change took an afternoon, and being sure about it was impossible at any price.
What We Found
For this article we went through the public record on how changes and fixes reach live systems in financial services: the RBI’s enforcement actions as reported in the press, the UK regulators’ findings on TSB Bank, and the US government’s list of software flaws known to be exploited, from 2018 to 2026.
Four findings stand out.
The regulator names the change process itself. In 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 areas the RBI cited was patch and change management: the routine by which fixes and changes reach the live system. The restrictions lasted about ten months. How a firm changes its systems can be grounds for holding back new business.
The size of a change sets the size of the harm when it goes wrong. In April 2018 TSB Bank in the UK moved its customers to a new platform: one very large change to its live systems, made at once. The bank received 225,492 complaints in the year that followed, and in December 2022 the regulators fined it £48.65 million. A small change that goes wrong can be traced and undone. A large one fails everywhere at once.
Fixes for known flaws exist, and still have to be put in. As of 11 October 2026, the US government’s list of flaws known to be exploited held 9 entries for Apache Struts, a framework many business applications were built on, and 13 for WebLogic Server, an application server. On a supported version, a fix exists for each. A fix protects nobody until it is applied, and applying it is a change like any other.
Faster coding tools do not speed up change on their own. This is our own observation from delivery work, with no figure on it. Where releases are done by hand and a system’s parts are tightly joined, a change written quickly with an AI coding tool waits in the same queue to be checked and released.
What our review does not show: The Kotak record gives only the headings the RBI cited, not what lay behind them. The TSB record does not say what testing TSB carried out, and we do not say its change was untested; we use it only to show that harm grows with the size of a change. The list of exploited flaws does not show that any particular firm is exposed. We found no public case of a mid-size NBFC, broker or insurer whose small change broke a report. We use the cases as lessons, not as claims about mid-size firms.
What Waits While Every Change Is a Gamble
A risky change process looks like a technology problem. Our reading is that it is a business problem first.
Products arrive late. When every change needs a week of checking by hand and a night-time window, a new fee or a regulatory change reaches customers weeks after it was ready.
Security fixes wait in a queue. A fix is a change. When changes are feared, fixes queue behind the business requests that have a sponsor.
The team stops improving the system. After a few bad Mondays, developers avoid old code.
The gap we see: most firms on old systems are careful about change. Few can show, after a change, that nothing else moved. The firm that can show it applies changes and fixes as they arrive. The firm that cannot pays for its caution in late products and open flaws.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Make Change Safe, Weighed
Each of these is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| More checking by hand, and more sign-offs | Changes are rare and the system is small | People still test what they expect. Each change takes longer, and the break is where nobody looked |
| A change freeze, except for emergencies | A short, known period of high risk, such as a year-end | Work piles up behind the freeze. Urgent changes go through the emergency route with fewer checks, and the next release is larger |
| Rebuild the whole system | The system has to be replaced for other reasons | It is the largest change of all, and the old system still needs safe changes while it runs |
| Establish what the system does today, add automated tests and an automated release, then hand back to the firm’s own team | The system is still needed and changes often | The first tests are slow to write, and the work will turn up behaviour nobody can explain |
Our recommendation: establish ground truth first: a written record of what the system does today, right or wrong. Then add automated tests around the parts that matter most, and an automated release that runs the same way every time. Then hand the system back. We do not apply patches or run your releases as a service. After hand-back, your own team does both, with tests to tell them what each change did.
Where You Are Now, and Where You Should Be
Before any work begins we set a benchmark: a few measures taken from your own systems, each with a target. For this issue it would look like this.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| Key functions covered by automated tests | None; people check screens by hand | Every function on the money paths: fees, interest, postings and the reports finance relies on | The test run, shown against the list of key functions |
| Release steps done by hand | A long checklist, followed at night | None, apart from a person’s approval | The release record |
| How long a security fix waits | Measured in the first review | Applied as it arrives, after the tests pass | The patch record |
| Changes rolled back | Undone by hand, if at all | Every change can be rolled back by the release itself | Rehearsed on a copy, and recorded |
| A written record of what the system does | In people’s heads | Written down, and confirmed by your own experts | The specification |
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
- We listen: a free Reliability Review. A first conversation about the system and how changes and fixes reach it today. You leave with a short written note of what we found.
- 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.
- We read the system and propose: the Legacy System Specification Assessment. It establishes what the system does today: 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.
- If you approve, we build. We add automated tests and an automated, repeatable release, strengthen the weak points, and hand the system back to your team. Where a module has to be replaced, we replace a system one module at a time while the old one keeps running. 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.
- We review against the benchmark. Before work starts we set the benchmark. As the work goes on 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 | Product and regulatory changes reach customers sooner, because a small change is no longer a risk to the whole system. |
| CTO or CIO | The team changes the system with a signal to rely on. A break is caught before customers see it. |
| CISO | A release cannot quietly remove a control, because the behaviour is checked every time. |
| COO | Fewer mornings spent finding out what last night’s change did. |
| Risk and compliance | A record for each change: what was altered, which tests ran and what they showed. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| The RBI cited patch and change management at Kotak Mahindra Bank among its reasons for restricting the bank (April 2024). | We establish what the system does today and add automated tests and an automated release, so every change leaves a record of what was tested. Answering the regulator is the firm’s own job. |
| TSB Bank made one very large change to its live systems in April 2018, and received 225,492 complaints. | Our part is narrower: with tests and a repeatable release in place, changes to the systems around the core can be made small and checked one at a time. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. When we hand back, your own team makes the changes, with a safety net under each one.
Sources
In this issue
Weak patch and change process
Research note 2
Your Releases Happen at Midnight, by Hand. Four Ways Out, Weighed.
A release done by hand at midnight makes releases rarer and riskier. What that holds back, four ways out weighed, and the benchmark for a repeatable release.
Research note 3
Your Security Fixes Are Waiting in a Queue. Here Is the Benchmark We Would Set.
Security fixes wait on old systems because nobody can see what they break. The benchmark we would set so your own team applies them as they arrive.
Issue study
The Change Nobody Could Test
What the RBI cited on patch and change management, what one very large change cost a UK bank, the options a lender has and the benchmark we would set.
More from Banking
Regulator restrictions and penalties
A Replacement Plan Needs Stages Someone Can Check. Here Is the Benchmark We Would Set.
Dependence on one vendor or shared provider
A Supplier Runs Your System. Here Is the Benchmark for Overseeing It.
Business rules buried in code