The Change Nobody Could Test
A study of weak patch and change processes in financial services from the public record: what the RBI named, what one very large change cost a UK bank, the options a lender has, what we would advise against, and the benchmark we would set.
1. At a Glance
Issue study · From the public record. None of the organisations named here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.
| Organisation type | A large Indian bank whose patch and change management the RBI cited, set beside a large UK bank’s very large change to live systems |
| Size band | Both banks: large |
| Region | India and the UK |
| The decision at stake | How a firm makes changes and applies security fixes to an old system it still needs, safely and repeatably |
| The public outcome | The RBI restricted Kotak Mahindra Bank’s new online customers and new credit cards for about ten months from April 2024, citing patch and change management among other areas. TSB Bank’s move to a new platform in April 2018 was followed by 225,492 complaints and, in December 2022, a £48.65 million fine |
| Why it matters to a mid-size lender | Most lenders change their old systems by hand and defer fixes because they cannot check them. The regulator now looks at exactly that |
2. The Business Problem, in the Buyer’s Words
“Every change to the loan system takes an afternoon to make and weeks to be sure about. Releases are done by hand on a Saturday night, once a month. Security keeps sending me the list of overdue fixes, and I keep saying we cannot test them in time. The business thinks we are slow. We are careful, and careful has become the risk.”
These words are imagined. They describe the decision as the research shows it, not a real conversation.
The firm cannot show that a change broke nothing else, so it changes the system rarely, releases in large batches and lets fixes wait.
3. What We Found
Method. We went through the public record on how changes and fixes reach live systems in financial services: the RBI’s enforcement actions as the RBI and the press reported them, the UK regulators’ findings on TSB Bank, and the US government’s list of software flaws known to be exploited, from 2018 to 2026.
What the regulator named. 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. The areas it cited included IT inventory, patch and change management, vendor risk, and “frequent and significant outages”. The restrictions lasted about ten months.
| What | Detail |
|---|---|
| Action | No new online customers, no new credit cards |
| Period | About ten months, from 24 April 2024 to February 2025 |
| Areas cited | IT inventory, patch and change management, vendor risk, “frequent and significant outages” |
What one very large change cost. In April 2018 TSB Bank in the UK moved its customers to a new platform: one very large change to live systems, made at once. The bank received 225,492 complaints between April 2018 and April 2019, and in December 2022 the regulators fined it £48.65 million. This study uses TSB only to show that harm grows with the size of a change. The migration itself is the subject of the issue 01 study.
Fixes exist and must be applied. As of 11 October 2026, the US government’s list of flaws known to be exploited held 9 entries for Apache Struts and 13 for WebLogic Server, two building blocks under many business applications. On a supported version, a fix exists for each. Applying one is a change to the live system.
Background: when basics are missing. In June 2023 the RBI imposed a penalty of 65 lakh rupees on Andhra Pradesh Mahesh Co-operative Urban Bank, a mid-size Indian bank, finding that “the bank had failed to put in place certain mandated controls which led to the cyber security incident.” The case is about missing controls, not patching.
Our reading of why changes to old systems are risky. These four are our reasoning from the cases above. None is a regulator’s finding.
- Nobody has a written record of what the system does today, so there is nothing to check a change against.
- There are no automated tests. People check the screens they expect to change, and the break is somewhere else.
- The release is done by hand, so each one is slightly different and can fail in a new way.
- The parts are tightly joined, so a small change can have a wide effect, and fixes are deferred until they are applied in bulk.
Our own observation from delivery work, with no figure attached: where releases are done by hand and systems are tightly joined, the speed-up from AI coding tools is lost. The code is written faster, then waits in the same queue.
What this record does not show. The Kotak record gives only the headings the RBI cited, not what lay behind them or how the bank released software. The TSB record does not say what testing TSB carried out, and this study does not say its change was untested. The RBI’s finding on the co-operative bank is about missing security controls and does not concern patching. 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 or whose release was done by hand.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| More checking by hand and more sign-offs | Changes are rare and the system is small | People still test what they expect; every change takes longer | Adds delay without adding evidence |
| A change freeze, except for emergencies | A short, known period of high risk | Work piles up, emergencies bypass checks, the next release is the largest | Right only for a few weeks with an end date |
| Rebuild the whole system | The system must be replaced for other reasons | The biggest change of all, while the old system still needs safe changes | We would advise against this as an answer to a change-process problem |
| 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; the work turns up behaviour nobody can explain | Our recommendation |
What we would have advised against: for a firm in this position, answering a finding on change management with more sign-offs alone, and clearing a backlog of security fixes in one large release.
5. Our Recommendation, and the Decision It Asks of the Board
For the systems a lender has built around its core (loan origination, collections, agent and branch portals, reporting): first establish ground truth, a written record of what the system does today. Then add automated tests around the parts that matter most and an automated release that runs the same way every time, with a person still approving each release. Then hand the system back to the firm’s own team, who make the changes and apply the fixes from then on.
The decision it asks of the board: approve a fixed-price assessment now. Then approve the tests and the release on their own evidence, with the freedom to stop after any step. The board stops approving exceptions for overdue fixes and starts approving a change process it can check.
6. Benchmark: Where You Are Now, and Where You Should Be
These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.
| 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 | The test run, 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, then recorded |
| A written record of what the system does | In people’s heads | Written down, and confirmed by the firm’s own experts | The specification |
7. How IOanyT Would Work
- We listen: a free Reliability Review. A first conversation about the system, how changes and fixes reach it today, and what is waiting on them. 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 study 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.
- 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.
8. What the Client Would Own
- The specification: a written record of what the system does today, confirmed by the client’s own experts and portable to any supplier.
- The risk register: the weak points found, listed before any price is set.
- The tests: automated tests around the key functions, in the client’s own codebase.
- The release process: an automated release that the client’s own team runs.
- The filled-in benchmark: each measure, where it started and where it stands.
Where a module is replaced, the client also owns its code and a traceability matrix linking each old function to its replacement.
9. What This Approach Does Not Cover
- IOanyT does not apply security patches on the client’s behalf and does not run the client’s releases as a service. After hand-back the client’s own team does both.
- IOanyT does not supply security controls such as firewalls or monitoring.
- It does not help with software past its maker’s end of support, where no fix exists. That is a different issue.
- IOanyT does not work on mainframe platforms or core banking products.
- Nothing here is a regulatory or compliance service, or a statement that a firm meets the RBI’s requirements. Taking a plan to the regulator is the firm’s own job.
- This study does not say IOanyT would have prevented the events described, or that IOanyT has done this work for a bank.
About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.
10. Sources
| Source | Used for |
|---|---|
| TechCrunch, 24 April 2024; News On AIR; RBI press release, 24 April 2024; RBI press release, 12 February 2025 | Kotak Mahindra Bank restrictions, the areas cited and their end |
| Bank of England, 20 December 2022 | TSB fine and the April 2018 migration |
| FCA Final Notice, TSB Bank plc, 2022 | TSB: 225,492 complaints, 22 April 2018 to 7 April 2019 |
| CISA catalogue | Exploited flaws in Apache Struts and WebLogic Server |
| RBI press release, 19 June 2023 | The RBI’s penalty on Andhra Pradesh Mahesh Co-operative Urban Bank and its finding |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We leave your own team able to change the system and apply its fixes, with tests that show what each one did.
Read the research notes on this issue
Weak patch and change process
Research note 1
The Regulator Now Looks at How You Change Your Systems. Most Old Systems Cannot Show a Change Was Safe.
Regulators now look at how firms change their systems, yet most old systems cannot show a change was safe. What we found, the options, our benchmark.
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.