Your Staff Are the Connection Between Your Systems. Here Is the Benchmark for Ending It.

A loan is approved in the origination system at eleven in the morning.

At half past eleven an operations officer opens the approval on one screen and the loan system on another, and types the details across. Twenty-two fields.

In the afternoon another officer exports a list from the loan system and uploads it to the collections tool. In the evening a third reconciles the two against the bank statement, and corrects the entries that do not match.

Nobody designed this. It is what the firm does because its systems cannot talk to each other.

What We Found

We went through the public record on how old systems in financial services are connected, and what happens where they are not: a vendor’s published case study of a core system replacement and a payments-industry report, from 2024 to 2026.

Old systems do get connected, one link at a time. 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. Every one of those links was built separately.

Where a link was never built, a person does the job. This is our own reasoning, not a figure. A person can read one screen and type into another without anyone writing a line of code. So the gap is filled the same day, and the fix becomes permanent.

A person in the middle sets the speed of the business. In one payments-industry report from 2026, about half of financial institutions named legacy technology as an obstacle to modernising real-time payments. A process with a person in the middle cannot be real time.

The cost is spread too thin to see. No budget line says “re-keying”. It is a few minutes of many people’s time, every day. Technology sees two systems that both work. Finance sees a staffing number. Only operations sees the gap.

What Re-Keying Holds Back

• Growth costs the same per loan, for ever. Twice the loans means twice the typing.
• Errors are built in. Each mistake becomes a customer complaint, a reconciliation item or a wrong figure in a report.
• Every new channel adds another bridge. Each arrives with its own system, and another person carries data across “for now”.

This is our reading. It is not a measured market figure.

Four Ways to Close a Manual Bridge, Weighed

Option	When it fits	What it risks
Keep staffing the bridge, with checks added	Volume is low and the old system is about to be retired	Cost rises with volume, and nothing moves faster than a person can type
Build a custom link between the two systems	The two systems and the data are simple and well understood	Each link is built by hand and joins the list nobody keeps
Replace the whole old system	It is small, well documented and due to go	Everything moves at once, and the bridges stay until the last day
Rebuild the one module behind the worst bridge, in stages	The system is old and customised, and one part of it has to send or receive	The new module and the old system must be kept in step while both run

Where You Are Now, and Where You Should Be

This is the benchmark we would set before the first module is rebuilt, and fill in as each module is accepted.

Measure	Typical starting point	Where it should be	How it is checked
Manual re-keying steps between systems	Not counted; known only to operations	Every step listed, with its volume and the errors it produces	A walk through operations, signed off by the COO’s team
The order of work	Whichever bridge complains loudest	Ranked by volume, errors and what each one holds up	The ranking, agreed with operations
Existing connections	No full list	Every file, feed and job listed, with what depends on it	The list is compared with the system’s scheduled jobs and outgoing files
The module behind the worst bridge	Unchanged; a person carries its data	Rebuilt with a documented way for other systems to send and receive data	The traceability matrix and signed acceptance for the module
What blocks the next connection	Found during the build	Named and ranked before the date is set	The risk register
A route by which any AI tool reads the old system	One-off extracts by hand	One controlled route, through a rebuilt module	Reviewed before any tool is connected

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.

A small part of the finished list might look like this.

Manual bridge	Stage that closes it	Status
Approved loans typed from origination into the loan system	Stage 1: loan booking module	Closed when the module was accepted
Daily list exported and uploaded to the collections tool	Stage 2: repayments module	Open; closes at stage 2
Evening reconciliation against the bank statement	Stage 2: repayments module	Open; smaller once stage 1 is accepted

The rows above are an illustration, not taken from a real system.

How We Work With You, and What You Are Left With

1. We listen: a free Reliability Review. A first conversation about the manual steps between your systems and what they hold up. 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.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation.
3. 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.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running, starting with the module behind the worst bridge. 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.
5. We review against the benchmark. Before work starts we set the benchmark above. As each module is accepted 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.

This has a price. The new module and the old system must be kept in step while they run side by side. The other system’s supplier has to agree how data will be exchanged. Staff whose days are built around the manual steps will need new work, and they deserve to hear about it early. And the first module will not remove every bridge. It removes the worst one.

At the end you hold the specification, the matrix, a list of bridges with every closed one dated, and the filled-in benchmark.

What changes for the business:

Role	What they gain
CEO	New partners and channels can be added without the old system holding them back.
CTO or CIO	A documented way in and out of the rebuilt module, so the next connection is not custom work.
CFO	Operations cost stops rising in step with volume, and there is less to reconcile.
COO	Staff stop typing the same data into two systems, and spend that time on customers.
Head of digital	The mobile app and the partner portal work from live data, not from yesterday’s copy.

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 rebuild the one module that has to connect, in stages, 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. The next connection starts from a documented way in, not from another person at a screen.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →