The Product That Could Not Launch
A study of how old systems hold up new products, partners and AI in financial services, from the public record: what blocks a new connection, 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. Everything about the organisations described here comes from the public record.
| Organisation type | A group of credit unions sharing one core system, set beside two surveys of financial institutions: one on real-time payments, one by the RBI on AI |
| Size band | The credit union group: many branches and a large membership. The surveys: institutions as a group, sample sizes not stated |
| Region | The credit union group: not stated in the source. The RBI survey: India |
| The decision at stake | How to make an old system connect to the new products, partners and AI tools the business wants |
| The public outcome | Replacing the group’s core meant rebuilding hundreds of screens and hundreds of interfaces to other systems. Across the sector, institutions name legacy technology as an obstacle, and interest in AI runs well ahead of use |
| Why it matters to a mid-size lender | Every new product, partner or AI tool is one more connection to the old system. The question is whether the blockers are found before the date is promised, or after |
2. The Business Problem, in the Buyer’s Words
“The partnership was signed two years ago and it is still next quarter. The partner needs loan data the moment a loan is approved, and our system has never sent anything to anyone. The board wants AI too, and we told them the system is not AI compatible. Meanwhile my operations team types every approved loan into a second system by hand. Every new idea becomes a project, and every project finds something nobody knew was there.”
These words are imagined. They describe the problem as the research shows it, not a real conversation.
The firm has the product, the partner and the ambition. What it does not have is a system that can pass on what it already knows, or a list of what stands in the way.
3. What We Found
Method. We went through the public record on old systems and new connections in financial services: a vendor’s published case study of a core system replacement, a payments-industry report on real-time payments, and an RBI survey of regulated entities on AI, as a law firm summarised it, from 2024 to 2026.
How much an old core is already connected to. 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.
| What | Figure |
|---|---|
| Institutions sharing the system | A group of credit unions |
| Their size | Many branches and a large membership |
| The system | Heavily customised |
| What the replacement rebuilt | Hundreds of screens and hundreds of interfaces to other systems |
Old technology is named 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. The report gives no 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”.
Our reading of why new connections are hard. These four are our reasoning from the record above and from public material on old systems. None is a regulator’s or a survey’s finding.
- Nobody has the full list of what the system connects to today. Connections were added one at a time, so a new one is built without knowing what the others depend on.
- The system has no clean way in. Every connection is built by hand, and what one team learns is not written down for the next.
- The data is the usual real blocker. Most claims that an old system is “not AI compatible” are true as stated and have a workaround; what more often stops the work is data whose meaning nobody has written down.
- The date is promised before the system is opened. The launch date and the budget are set first, and the obstacles are found during the build.
What this record does not show. The credit union source is a vendor’s own case study; it does not say where the institutions are, what the interfaces cost, or how many manual steps they replaced. The payments report gives no sample size. The RBI survey was read through a law firm’s summary; the committee’s report itself was not opened. We found no public case of a mid-size NBFC, broker or insurer whose launch stalled on its system, and no published figure for the cost of re-keying data by hand.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Build a custom connection for each new product, partner or tool | One connection, simple data, well understood | Each is built by hand and joins the list nobody keeps; the next starts from nothing | Right for a single simple need, and only with the list kept |
| Buy a connection product to sit on top of the old system | Many services need the same data, and the system is staying for years | It still has to be told what the old data means | Can be right for some firms. 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; every launch waits | We would advise against this for an old, customised system |
| Find the blockers first, then 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 | Several stages, and the new module and the old system kept in step for a time | Our recommendation for the systems around the core |
What we would have advised against: for a firm in this position, promising a launch date before anyone had opened the system, and buying an AI tool before anyone had checked what it would read.
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 find what blocks the connection the business wants, then rebuild the one module that has to connect, in stages, while the rest of the system keeps running. Assess first, price afterwards. For AI, start with one or two named uses, and write down what each needs from the system and what that data means before any tool is chosen.
The decision it asks of the board: approve a fixed-price assessment before the next launch date is announced. Then approve each stage on its own evidence, with the freedom to pause after any accepted module. The board stops hearing “next quarter” and starts approving a plan with a basis.
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 |
|---|---|---|---|
| Existing connections | No full list | 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 | Every step listed, with its volume, and closed in order | A walk through operations, signed off by the COO’s team |
| What the data means | Codes nobody has written down | Every table and field a new use depends on, described in plain words | The written specification, confirmed by the firm’s own staff |
| 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 |
7. How IOanyT Would Work
- 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. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
- 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 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, starting with the module that has to connect. We never do a single cutover. A traceability matrix links every old function to its replacement. 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.
8. What the Client Would Own
- The map and the specification: what the system does, in writing and portable to any supplier.
- The risk register: what blocks the connection the business wants, ranked before any price is set.
- The traceability matrix: every old function of a rebuilt module linked to its replacement, with how it was checked.
- The code: the new modules are the client’s. No runtime or platform fee.
- The filled-in benchmark: each measure, where it started and where it stands.
9. What This Approach Does Not Cover
- IOanyT has not published a connection layer or integration product, and has no published financial-sector integration case.
- IOanyT has not stated that it delivers on-premise or self-hosted AI, which Indian financial institutions often require. A firm with that requirement should raise it in the first conversation.
- IOanyT gives no regulatory or legal advice on the use of AI or on data protection.
- IOanyT does not maintain or patch the old system while it is being replaced. The client’s current team or vendor keeps it running.
- IOanyT does not replace or implement core banking products. This study is about the systems a firm builds around its core.
- 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 |
|---|---|
| A vendor’s case study | The credit union group, its screens and interfaces |
| An industry survey report, 2026 | About half, and real-time payments modernisation |
| A law firm’s summary of the RBI committee report, August 2025 | The RBI survey: 20.8% and 67% |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The next launch date can come from what is in the system, not from hope.
Read the research notes on 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 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.