Your System Is "Not AI Compatible". That Is Where the Decision Starts.
Most regulated firms want to use AI, and few do. Here is what stands between an old system and AI, what readying it opens up, the four ways forward weighed, and the benchmark we would set.
The board has asked for an AI strategy. Every director has read that competitors are using AI for customer service, for underwriting, for collections.
The technology head gives an honest answer. The loan system is fifteen years old. It was not built for this. It is not AI compatible.
The board accepts that. An AI working group is formed. It meets monthly. A year later it has produced a slide deck and one pilot that was quietly stopped.
The paradox: The firm’s most valuable data for AI is inside the one system that AI cannot reach.
What We Found
For this article we went through the public record on AI in regulated financial firms and on what holds old systems back: an RBI survey of regulated entities, as a law firm summarised it, and a payments-industry report, from 2025 to 2026.
Interest is high, and use is low. In an RBI survey of regulated entities, as summarised, “67% of the surveyed entities expressed interest in exploring various AI use cases”, while “20.8% of surveyed entities are deploying AI systems at present”. Two in three want to. One in five has.
Old technology is named as the obstacle to new work. In one payments-industry report from 2026, about half of financial institutions named legacy technology as an obstacle to modernising real-time payments. Its subject is payments, not AI. The obstacle is the same: a system that cannot share its data with something new.
“Not AI compatible” is usually true as stated, and has a workaround. An old system has no door for a tool to come through. That is a real obstacle, and a way in can be built. The statement is usually heard as “not until we replace it”, and that is rarely so.
What more often stops the work is the data. The same customer appears three times with three spellings. A field called “status” means four different things. Nobody has written down what the codes stand for. An AI tool given a table of unexplained codes produces confident answers, and the answers are wrong.
What our review does not show: The RBI survey was read through a law firm’s summary; we did not open the committee’s report, and the summary gives no sample size. It does not say which uses firms tried or what stopped them. The payments report gives no sample size. The third and fourth findings are our own reading of public material, not a measured finding and not a record of IOanyT projects. We found no public case of a mid-size lender whose AI pilot failed on its data.
What Readying the System Opens Up
While the system is “not AI compatible”, two things are lost, and one thing is within reach.
The plans stall. A working group meets, a deck is written, and the board hears the same answer each quarter.
The wrong lesson is learned. A pilot fed by a one-off extract shows what AI could do with clean data. It says nothing about whether the firm can supply that data every day. When it gives wrong answers, staff stop asking, and the firm concludes that AI does not work for it.
The work that readies a system for AI is the work that readies it for anything. A written record of what the system does, and a plain description of what its data means, are what a staff assistant would need. They are also what a partner feed, an agent app or a new payment method would need. That work pays whether or not any AI is switched on.
The gap we see: most firms know they want AI and know their system is old. Few know, for one named use, what the tool would need from the system and whether the system can supply it. The opportunity is to answer that question before buying anything, and to fix what the answer shows.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Bring AI to an Old System, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Build a custom connection from each AI tool to the old system | One tool, one simple use, and data whose meaning is already written down | Each tool gets its own route by hand. If the data is unexplained, the answers are still wrong |
| Buy a connection product to sit between tools and the system | Several tools need the same data, and the old system is staying for years | The product still has to be told what the data means. It is not something IOanyT offers |
| Replace the whole system before any AI | The system is due to be replaced in any case | AI waits for years |
| Understand the system and its data for one named use, then rebuild the one module that use needs, in stages | The system is old and customised, and the business has one or two uses it wants | It is slower to start than a pilot. Cleaning data is work somebody in the business has to own |
Our recommendation: start with one or two uses the business actually wants. Write down what each would need from the system and what that data means, then rebuild the one module the use has to reach, in stages, while the rest keeps running. Settle early where data may go and where AI may run. Indian financial institutions often require AI to run within their own environment, and IOanyT has not stated that it delivers on-premise or self-hosted AI. If you need that, say so in the first conversation. We give no regulatory advice on AI or data protection.
Where You Are Now, and Where You Should Be
Before any tool is chosen, we would set a benchmark for readiness itself.
| Measure | Typical starting point | Where it should be | How it is checked |
|---|---|---|---|
| The AI uses the business wants | A list of ideas from a working group | One or two named uses, each with what it needs from the system | The specification of the parts each use touches |
| What the data means | Codes nobody has written down | Every table and field a use depends on, described in plain words | The written specification, confirmed by your own staff |
| The condition of the data | Not known until a pilot fails | Known for each use before a tool is chosen | A sample of records checked against the description |
| The rules an assistant would need | Only in the code | In writing, in plain words | The written specification |
| A route by which any AI tool reads the old system | One-off extracts by hand | One controlled route that reads what the use needs and nothing more | Reviewed before any tool is connected |
| Where data may go and where AI may run | Not decided | Decided by the firm before any tool is chosen | A minute from the board or its committee |
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
- We listen: a free Reliability Review. A first conversation about the AI uses you want and what has stopped them so far. 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. You get the options and our recommendation.
- If you approve, we build. We replace a system one module at a time while the old one keeps running, starting with the module the use has to reach. 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. Where the use needs it, our engineers also build the AI feature, and our AI security assessment checks what is added.
- 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 | AI plans move from interest to use, on a path the board can follow. |
| CTO or CIO | A clear view of which AI uses are possible now and what data work each of the others needs. |
| CFO | AI spending goes to uses that can work, with fewer pilots that stall. |
| COO | A staff assistant that answers from the firm’s real rules and current data. |
| Head of digital | AI features delivered on top of the existing system, one step at a time. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| This article names no organisation as a case. The survey and the payments report describe institutions as a group. | Our assessment starts with your system, not a tool: what the use needs, what the system does, and what blocks the use, ranked in the risk register. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. An old system does not have to be replaced before a firm can use AI; it has to be understood first.
Sources
- A law firm's summary of the RBI report, August 2025
- An industry survey report, 2026
In this issue
Cannot connect to new services
Research note 1
Your Launch Has Been "Next Quarter" for Two Years. The Blocker Has Never Been Named.
A launch stuck at next quarter usually waits on an old system nobody has opened. What the public record shows, the options, and the benchmark we set.
Research note 3
Your Staff Are the Connection Between Your Systems. Here Is the Benchmark for Ending It.
When lending systems cannot talk, staff re-key data by hand. The benchmark we would set to end it, and the path: rebuild the one module that has to connect.
Issue study
The Product That Could Not Launch
How old systems hold up new products, partners and AI in lending: what blocks a connection, the options, what we would advise against, and our benchmark.
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.
Weak patch and change process