The Regulator Can Now Stop a Lender's Growth Over Its IT. Most Boards Hear It Last.
We reviewed the RBI's published action over IT failings. Here is what we found, what a restriction holds back, four ways to find out where an old system stands, and the benchmark we would set.
It is the board’s strategy day. The plan for the next three years is on the screen.
Most new customers will come through the app. A new card launches in the second quarter. A director asks what could stop this.
The answers are the usual ones: competition, credit quality, funding costs. Nobody says: our own systems.
The paradox: The risk most able to stop the plan is the one the board has always left to somebody else’s department.
What We Found
Before we advise a lender, we study its sector. For this article we went through the public record on regulatory action over IT in Indian banking: the RBI’s direction on IT governance and its published enforcement releases, from 2023 to 2025.
Four findings stand out.
There is now a written rule. The RBI’s direction on IT governance, in force since 1 April 2024, says regulated entities “shall avoid using outdated and unsupported hardware or software”.
The remedy can be a stop on growth. On 24 April 2024 the RBI directed Kotak Mahindra Bank to “cease and desist, with immediate effect, from (i) onboarding of new customers through its online and mobile banking channels and (ii) issuing fresh credit cards”, while it kept serving its existing customers. The RBI lifted the restrictions on 12 February 2025, about ten months later. It was not a fine but a limit on new business.
The areas named are the everyday machinery of an old system. The RBI’s release said “serious deficiencies and non-compliances were observed in the areas of IT inventory management, patch and change management, user access management, vendor risk management, data security and data leak prevention strategy, business continuity and disaster recovery rigour and drill, etc.” It also said the bank’s core banking system and its online and digital banking channels “have suffered frequent and significant outages in the last two years”. Our reading: each area is hard to show on paper for an old, layered system.
It reaches co-operative banks too. On 19 June 2023 the RBI announced a penalty of 65 lakh rupees on Andhra Pradesh Mahesh Co-operative Urban Bank, Hyderabad, by an order of 12 June 2023, for non-compliance with its cyber security framework directions. The RBI said its IT examination and an investigation of a cyber security incident showed the bank “had failed to put in place certain mandated controls which led to the cyber security incident”.
What our review does not show: We read the RBI’s press releases, not its inspection reports or its letters to the banks, so we have the areas it named and not the detail behind them. We saw no inspection questionnaire, finding or response letter, and do not know what deadlines the RBI sets. The RBI’s release does not say Andhra Pradesh Mahesh ran unsupported software, and we do not claim it did. We found no public case of a mid-size NBFC, broker or insurer restricted over its IT, and no figure for what a restriction cost in business. We use the cases as lessons, not as claims about mid-size firms.
What Stops While a Restriction Lasts
A restriction over IT is usually read as a compliance event. Our reading is that it is first a growth event.
Look at what was held back in the Kotak case: new customers through digital channels and new credit cards. A restricted firm keeps the customers it has and cannot add the ones the plan counted on.
The second cost is time: the people who would build the next product are answering the regulator about the last one.
The third is how the board learns: an old system reaches it as a budget request that loses to revenue projects. The first full account the board sees can be the one an inspection writes.
The gap we see: most firms can say their systems are old. Few could put in front of the board, today, what they run, where each area the regulator has named stands, and a dated plan for the weak parts. A firm that holds that record knows its own position. One that does not may learn it from an inspection.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Find Out Where an Old System Stands, Weighed
There are four options, each right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Wait until someone asks | The systems are recent, documented, and past inspections found little | The firm learns its position from someone else, on someone else’s timetable |
| Fix the weak areas one by one, as each team sees them | One area is weak and the rest are in order | The areas are connected: nobody can patch what has not been listed. The fixes do not add up to a plan |
| Commission a compliance audit | The firm wants an independent view of where it stands against the rules | It says what is wrong, not how to fix it inside the system. This is not work we do |
| Map the system, then build a staged plan with evidence at each stage | The system is old, layered and customised | An assessment comes before any plan, and the map will show more than expected |
Our recommendation: map the system first, then build a staged plan with evidence at each stage. Where an independent audit is also wanted, commission one; the two answer different questions. What the firm tells its regulator, and how, is for the firm and its own compliance advisers. We are not a compliance or audit firm. We do not write a firm’s response to a regulator, and we cannot promise that a regulator will accept a plan, lift a restriction or withhold a penalty.
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.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| An IT inventory | Several lists that do not agree | One complete record of every application in scope and what it runs on | The record is compared with the servers, databases and code |
| Each area in the RBI’s 24 April 2024 release | Known to each team, never put together | What the system record shows on each area, in one place | The risk register, one entry per area |
| A plan for the weak parts | ”Replacement planned”, with no date | A staged plan, each stage dated by the firm | The staged plan |
| Evidence for each stage | Nothing to show until the end | A record for every stage, showing what moved and how it was checked | The traceability matrix |
| What the board sees | One amber line, carried forward | The position on each area and progress against the plan | Board papers, at every review |
The starting points above are 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.
The areas are the ones the RBI listed in one bank’s case. Using them as headings is our choice, not a statement of what the RBI expects any firm to show.
How We Work With You
- We listen: a free Reliability Review. A first conversation about the system and what past inspections have asked. 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 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.
- If you approve, we build. We replace a system one module at a time while the old one keeps running. 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.
- 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.
We do not secure, patch or maintain the old system while it waits, or supply security controls; your current team or vendor does that. We offer no RBI or DPDP compliance service, and do not work on mainframes or core banking products.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The growth plan is no longer exposed to a finding the board never saw coming. |
| CTO or CIO | The mandate and the money to act early. |
| CFO | The cost of acting is weighed against the cost of a restriction, and the spending is planned. |
| CISO | Security gaps on old systems get the board’s attention before an incident does. |
| Risk and compliance | The board sees IT risk on the record, with the facts in front of it. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| The RBI restricted Kotak Mahindra Bank’s new business for about ten months, citing areas that included IT inventory management. | Our assessment produces a map of the system and a risk register before anyone asks. What the firm tells its regulator is its own decision. |
| The RBI penalised Andhra Pradesh Mahesh Co-operative Urban Bank 65 lakh rupees in June 2023 over cyber security controls. | Our part is narrower: security controls are the firm’s own work. We give the board a record of the system and a staged plan. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The record is yours, and the board can read it before an inspection does.
Sources
In this issue
Regulator restrictions and penalties
Research note 2
The Regulator Named the Areas in Public. The Record Behind Them Can Be Ready First.
The RBI named the IT areas in public when it restricted a bank. What a record built from the system opens up, four options weighed, and our recommendation.
Research note 3
A Replacement Plan Needs Stages Someone Can Check. Here Is the Benchmark We Would Set.
One completion date gives a board nothing to check. The benchmark we would set for a staged replacement plan, with evidence at each stage.
Issue study
Ten Months Without New Customers
What the RBI named when it restricted a bank's new business over IT, from its own releases: the options, what we would advise against, and our benchmark.
More from Banking
Dependence on one vendor or shared provider
A Supplier Runs Your System. Here Is the Benchmark for Overseeing It.
Weak patch and change process
The Regulator Now Looks at How You Change Your Systems. Most Old Systems Cannot Show a Change Was Safe.
Business rules buried in code