A Supplier Runs Your System. Here Is the Benchmark for Overseeing It.

It is a Wednesday morning, and the branches are calling. ATMs are not dispensing cash. UPI payments are failing.

The technology team checks its own systems. They are fine. The fault is at the provider that hosts the banking platform, a company that serves many institutions like yours.

There is nothing to restart and nobody inside who can fix it. You wait, and the questions begin: which services have stopped, for which customers, and what the firm knew about the provider beforehand.

What We Found

We looked at what the public record says about institutions whose supplier failed or was found wanting, and at how firms usually oversee a critical supplier.

One provider’s bad day can be everyone’s. In mid-2024 ransomware hit a technology provider shared by many small banks in India. It disrupted many of those banks at once, including their cash machine and payment services.

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”.

The RBI cited vendor risk management. On 24 April 2024 the RBI barred Kotak Mahindra Bank from taking new customers online and issuing new credit cards for about ten months. Vendor risk management was among the areas it cited.

Most oversight rests on the supplier’s own evidence. Monthly service reports and a yearly assurance letter, all written by the supplier, filed by the firm and shown to the auditor. That is useful. It is not independent.

What Oversight With Your Own Evidence Opens Up

Our reading is that supplier oversight is also how a firm keeps its own options.

• The firm knows what stops if a supplier stops. Which services, branches and customers rest on each supplier is mapped before the day, not found out one phone call at a time.
• Changes are checked, not only seen. A release can be compared with a written record of what the system did before, and not only with the screens that changed.
• The exit plan becomes real. A plan resting on a specification another firm could use is one that could be carried out.

Be plain about the limit. A document does not make a supplier more reliable, and a specification does not remove the risk that a shared provider fails. A firm on a shared platform stays exposed to that platform’s bad day. What changes is that it knows in advance what would stop, and can show what it checked.

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

Four Ways to Oversee a Critical Supplier, Weighed

Option	When it fits	What it risks
Rely on the supplier’s reports and assurance letters	The supplier is low risk and easy to replace	The evidence comes from the party being checked. On the day, the firm knows only what it was told
Commission an independent audit of the supplier	The contract allows it and the risk team wants a point-in-time view	It looks at the supplier, not at the firm’s own system, and it dates quickly
Move off the supplier or the shared platform	Another provider is clearly better placed	A large move with its own risk. It is a business decision no document makes for you
Hold your own record of the system, map what depends on it, and check each change against it	The system is critical and run or changed by an outside party	It costs money to describe a system someone else is paid to run, and the supplier may see it as distrust

Where You Are Now, and Where You Should Be

This is the benchmark we would set for each critical supplier, and fill in as the work goes on.

Measure	Typical starting point	Where it should be	How it is checked
A specification held by the firm	The supplier’s product overview	A written record of the system as it runs today	The specification, confirmed by the firm’s own experts
What depends on each supplier	Found out on the day	Mapped in advance: services, branches, customers	The map, reviewed with operations
Acceptance evidence for each change	”Delivered as per scope”	What was meant to change, and how it was checked against the record	Signed acceptance for each change
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
An exit plan for the shared provider	”To be developed”	A plan the firm could act on, with what would stop and what it would do	Reviewed by the risk committee
Whose evidence the auditor sees	The supplier’s reports	The firm’s own documents, beside the supplier’s	The supplier review file

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. They are our own targets, not a regulator’s standard.

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

1. We listen: a free Reliability Review. A first conversation about the system, the supplier, and what the board or regulator has asked. 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 the supplier holds the code, arranging that access 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.
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.
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. 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. 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.

This has a price, and limits. Your supplier may not welcome the work. We are not a compliance or audit firm, and what your regulator expects is for your compliance team. We give no legal advice on who owns the code. We do not host, and we do not take over running a system from your supplier. IOanyT holds ISO/IEC 27001:2022 and ISO 9001:2015 certification.

At the end you hold the specification, the risk register and, for any module replaced, the traceability matrix: documents you can show your board, your auditor or your regulator.

What changes for the business:

Role	What they gain
CEO	The board and the regulator can be told how each critical supplier is overseen, with documents to show.
CTO or CIO	What a supplier delivers can be checked against a written record before it is signed off.
CFO	The firm pays for work that has been checked against its own record.
COO	Operations knows in advance what stops if a supplier stops, and has thought through what it would do.
Risk and compliance	Oversight that rests on the firm’s own evidence.

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

The case	What IOanyT does
Ransomware at one technology provider shared by many small banks in India disrupted many of those banks at once.	Our narrower part: no specification prevents a provider’s failure, and we do not claim otherwise. We give a firm a written record of its system and what depends on it, so it can plan before the day.
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 specification, risk register and traceability matrix are the firm’s own documents to check a supplier’s work against.
The RBI cited vendor risk management at Kotak Mahindra Bank.	The same documents let a firm show it understands its own critical systems. How the firm uses them with its regulator is for its compliance team.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. When the questions come, the documents on the table can be your own.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →