Only Your Vendor Understands the System. Here Is What the Public Record Shows.

A director asks a simple question at the board. If our software vendor closed tomorrow, could someone else take over the loan system?

The technology head pauses. The vendor built the system ten years ago and has made every change since. There is no document that says how it works. Nobody is certain the firm holds the latest source code.

The honest answer is: not quickly, and perhaps not at all.

What We Found

Before we suggest anything to a lender, we study its sector. For this article we went through the public record on financial firms that depend on one vendor or one shared provider: RBI enforcement reported in the press, UK regulators’ findings, reports of an attack on a shared provider in India, and a vendor’s case study, from 2018 to 2025.

Four findings stand out.

The RBI cited vendor risk management. On 24 April 2024 the RBI barred Kotak Mahindra Bank from taking new customers through its online and mobile channels and from issuing new credit cards. Among the areas the RBI cited was vendor risk management. The restrictions lasted about ten months.

A regulator’s finding on supplier oversight. On 20 December 2022 the UK’s Financial Conduct Authority and Prudential Regulation Authority fined TSB Bank £48.65 million in total after its 2018 migration failed, and the bank paid £32.7 million in redress to customers. The regulators found that “it failed to manage the operational risks arising from its IT outsourcing arrangements with its critical third-party supplier”.

One shared provider can stop many institutions at once. In mid-2024 ransomware hit a technology provider shared by many small banks in India. It disrupted services at a large number of cooperative and rural banks, including cash withdrawals and UPI payments.

A vendor can retire the system on its own date. A group of credit unions shared one heavily customised core system. Its vendor scheduled it to be retired in 2024. Replacing it meant rebuilding hundreds of screens and hundreds of interfaces to other systems.

What Waits While Only the Vendor Knows

Our reading of the record is that vendor dependence limits what the business can decide at all.

The firm cannot negotiate, because nobody inside can judge a price or a date. It cannot switch, because there is nothing in writing to hand a new supplier. It cannot check the work, because it has no record to check it against. And when something goes wrong, it has no record of its own to explain the failure from.

Every change widens the gap. Each new rule and connection is added by the vendor’s people, and the managers who specified the original system move on.

This is our reading of the evidence. It is not a measured market figure.

Four Ways Forward, Weighed

Option	When it fits	What it risks
Negotiate harder with the current vendor	The relationship is sound and the firm wants better terms	With no second firm able to quote, the firm cannot walk away. The terms may change; the dependence does not
Switch everything to a new vendor	The current vendor is failing or leaving	The new vendor starts from nothing, and the firm can end up depending on it in the same way
Bring the work in-house	The firm can hire and keep people for this system	The team must learn the system from the vendor, and the knowledge can leave with people again
Own a written specification first, then get a second quote or move in stages	The system is old, customised and understood only by its vendor	Writing the record costs time and money before any quote changes. The vendor may not welcome it

Where You Are Now, and Where You Should Be

Before any work begins we set a benchmark: a few measures taken from your own position, each with a target.

Measure	Typical starting point	Where it should be	How it is checked
A written record of the system	None; only the vendor’s knowledge	A specification the firm holds: rules, data, reports, connections and scheduled jobs	The specification, confirmed by the firm’s own experts
Who can explain how the system behaves	Only the vendor, by ticket	The firm’s own team, from the record	Questions answered from the record at each review
The firm’s access to its own code	Not known	Read-only access arranged, or the gap stated in writing	The firm’s own check of its contract and its access
Suppliers able to quote	One	More than one, working from the same specification	Quotes received for the same piece of work
An exit plan for each critical supplier	”To be developed”	A plan another firm could carry out from the record	Reviewed by the risk committee

The starting points above are what the public cases show 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

1. We listen: a free Reliability Review. A first conversation about the system and the vendor. 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. Where your vendor holds the code, arranging that access with the vendor is your firm’s own job.
2. 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.
3. We read the system and propose: the Legacy System Specification Assessment. It produces a written specification of what the system 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. The specification is yours, and you can take it to any supplier, including your current one.
4. If you approve, we build. Where a system has to be replaced, we replace a system one module at a time while the old one keeps running. 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.
5. We review against the benchmark. Before work starts we set the benchmark. After each step 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 give no legal advice on who owns the code, and we do not recover code, accounts or contracts from a vendor. We do not host, and we do not take over running the old system from your vendor.

What changes for the business:

Role	What they gain
CEO	The business no longer rests on the goodwill of a company it does not control. Changing supplier becomes a real choice.
CTO or CIO	The firm’s own team understands the system, and another supplier could take it over from the written record.
CFO	Knowledge of the system becomes something the firm owns, not something it rents each year.
COO	Questions about how the system behaves are answered in-house, without waiting for a ticket.
Risk and compliance	The firm can show that it understands its own critical system, from a document it holds.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
The RBI cited vendor risk management among its reasons for restricting Kotak Mahindra Bank.	We write a specification the firm owns and can take to any supplier. How the firm uses it with its regulator is for its compliance team.
UK regulators found in December 2022 that TSB Bank had failed to manage the operational risks of its IT outsourcing arrangements with its critical supplier.	Our narrower part: the specification and risk register are the firm’s own documents. We are not a compliance or audit firm.
Ransomware at one technology provider shared by many small banks in India disrupted many of those banks at once.	Our narrower part: a specification does not remove the risk that a shared provider fails. It records the firm’s system and what depends on it.
A group of credit unions had their shared core retired on the vendor’s date.	Our staged plan lets a firm start leaving before a vendor’s date, one module at a time.

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 we write is yours, and it answers the director’s question.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →