Your Launch Has Been "Next Quarter" for Two Years. The Blocker Has Never Been Named.
We reviewed the public record on old systems and new connections in financial services. Here is what we found, what waits while the blocker has no name, the options, and the benchmark we would set.
The co-lending partnership was announced to the board two years ago. The partner is ready. The legal agreement is signed. The product team has the pricing.
One thing is missing. The partner needs loan data sent to it, in an agreed format, soon after each loan is approved. The loan system has never sent anything to anyone in that way.
The technology team says it is working on it. On the roadmap, the launch sits where it has sat for eight quarters: next quarter.
The paradox: The business has everything it needs to launch except a way for its own system to pass on what it already knows.
What We Found
Before we suggest anything to a lender, we study its sector. For this article we went through the public record on old systems and new connections in financial services: a payments-industry report on real-time payments, an RBI survey of regulated entities on AI, as a law firm summarised it, and a vendor’s published case study of a core system replacement, from 2024 to 2026.
The institutions themselves name old technology as the obstacle. In one payments-industry report from 2026, about half of financial institutions named legacy technology as an obstacle to modernising real-time payments. Real-time payments are a plain test of whether a system can connect. The report does not give its sample size.
Interest in AI runs well ahead of use. 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. An AI tool is one more new connection, and it meets the same obstacles.
An old core carries far more connections than anyone sees. A group of credit unions shared one heavily customised core system. When it was replaced, the work rebuilt hundreds of screens and hundreds of interfaces to other systems. Each is something a new connection could disturb.
The blocker is usually found after the date is set. This is our own reasoning. A launch date and a budget are fixed first. The technology team opens the system afterwards and finds no clean way to get the data out, data nobody has described, rules that run only in overnight jobs, and connections nobody listed. Each discovery moves the date.
What our review does not show: The payments report gives no sample size and does not say which institutions it surveyed. The RBI survey was read through a law firm’s summary; we did not open the committee’s report itself. The credit union record is a vendor’s own case study, and it says how many interfaces were rebuilt, not what they cost. We found no public case of a mid-size NBFC, broker or insurer whose launch stalled on its system, and no published figure for what a delayed launch costs. We use the record as a lesson. We do not say mid-size firms have had the same events.
What Waits While the Blocker Has No Name
A system that cannot connect is usually discussed as a technology problem. Our reading of the record is that it is a growth problem first.
Launches wait. The co-lending product, the new payment method, the agent app: each needs the old system to share data with something new. Until it can, the launch sits at “next quarter”.
AI plans wait. An AI assistant needs to ask the system for information and get a correct answer back. The system has no way in for a tool, and its data has never been described. So AI stays on a slide, held back by the system and its data, not by the tool.
The gap we see: most firms on old systems know their system is slow to connect. Few can name, for a given launch, what stands in the way and what it would take to remove it. A firm that can name it sets a date with a basis. A firm that cannot keeps promising next quarter.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Connect an Old System, Weighed
| Option | When it fits | What it risks |
|---|---|---|
| Build a custom connection for each new product or partner | One connection is needed, and the data it uses is simple and well understood | Each one is built by hand and adds to the connections nobody has listed. The next launch starts from nothing |
| Buy a connection product to sit on top of the old system | Many new services need the same data, and the old system is staying for years | The product still has to be told what the old data means. It is not something IOanyT offers |
| Replace the whole system in one project | The system is small and well documented | One date carries all the risk, and every launch waits for the new system |
| Rebuild the one module that has to connect, in stages | The system is old and customised, and one part of it holds what the new product needs | It runs over stages, not one quarter. The new module and the old system must be kept in step while both run |
Our recommendation: find what blocks the connection first, then rebuild the one module that has to connect, in stages, while the rest of the system keeps running. We assess first and price afterwards, so the launch date is set once the blockers are known, not before. A connection product can be right for some firms. It is not work we do, and we have not published a financial-sector integration case.
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 |
|---|---|---|---|
| Existing connections | No full list; files and feeds added one at a time | Every file, feed and job that leaves or enters the system listed, with what depends on it | The list is compared with the system’s scheduled jobs and outgoing files |
| What blocks each new connection | Found during the build | Named and ranked before the date is set | The risk register |
| The basis for the launch date | Set before anyone opened the system | A stage in a plan built from what is in the system | The staged plan |
| Manual re-keying between systems | Not counted | Each step where a person carries data across listed, with its volume | A walk through operations, checked against the list of connections |
| A route by which any AI tool reads the old system | None, or a one-off extract by hand | One controlled route that reads what the use needs and nothing more | Reviewed before any tool is connected |
The starting points above are what the public record shows 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 launch, partner or AI use that is waiting, and what the system would have to do for it. 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 that has to connect. 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.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | Launch dates the firm can keep, so partners and the board can rely on them. |
| CTO or CIO | An integration scoped from a map of the system, not discovered halfway through the build. |
| CFO | Integration costs known before the commitment is made, and revenue from new products that arrives when planned. |
| COO | Fewer surprises for operations on the day a new product or channel goes live. |
| Head of digital | A roadmap built on what the system can do, with every blocker named. |
The cases in this article, and what IOanyT does about that kind of problem:
| The case | What IOanyT does |
|---|---|
| A group of credit unions rebuilt hundreds of interfaces to other systems when its shared core system was replaced. | Our narrower part: we do not replace core banking products. For the systems a firm builds around its core, we write down what a module does and rebuild the one that has to connect, while the rest keeps running. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Ask the old system first, and the date that follows is one the firm can keep.
Sources
- An industry survey report, 2026
- A law firm's summary of the RBI report, August 2025
- A vendor's case study
In this issue
Cannot connect to new services
Research note 2
Your System Is "Not AI Compatible". That Is Where the Decision Starts.
Most regulated firms want AI and few use it. What stands between an old system and AI, four ways forward weighed, and the readiness benchmark we would 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