When a Supplier Holds the System: Dependence in Financial Services
A study of supplier dependence in financial services from the public record: an attack on a shared provider, a regulator's finding on supplier oversight, a core retired by its vendor, 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. None of the organisations named here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.
| Organisation type | A technology provider shared by many small banks in India, set beside a UK bank fined over its supplier, an Indian bank restricted by the RBI, and a group of credit unions whose shared core system was retired by its vendor |
| Size band | The banks served by the provider: many small cooperative and regional rural banks. TSB and Kotak: large. The credit union group: many branches and a large membership |
| Region | India and the UK. The credit union group: not stated in the source |
| The decision at stake | What a firm should do when one outside supplier holds the knowledge of its system, the code or the platform it runs on |
| The public outcome | One attack on one provider disrupted many small banks at once. One bank was fined, and the regulators’ findings included how it managed its critical supplier. One bank’s restrictions cited vendor risk. One group replaced its core on its vendor’s date |
| Why it matters to a mid-size lender | Most lenders depend on at least one supplier they could not replace quickly. In December 2022 the UK regulators’ findings against one bank included how it managed a critical supplier |
2. The Business Problem, in the Buyer’s Words
“Our loan system was built by a vendor ten years ago, and they still make every change. Nobody here can explain how it works. When we ask for a price, there is no second quote. When the auditor asks how we oversee them, we show their own reports. And part of our banking runs on a platform we share with other banks, which we cannot see inside at all.”
These words are imagined. They describe the position as the research shows it, not a real conversation.
The firm cannot negotiate, switch or check its supplier’s work. When something fails, it has no record of its own to explain the failure from.
3. What We Found
Method. We went through the public record on financial firms that depend on one vendor or one shared provider: reports of the attack on a shared provider in India, the UK regulators’ published findings, the RBI’s enforcement actions as reported in the press, and a vendor’s published case study, from 2018 to 2025.
One shared provider, many banks. In mid-2024 ransomware hit a technology provider shared by many small banks in India.
| What | Figure |
|---|---|
| Where the attack happened | One shared provider |
| When | Mid-2024 |
| Institutions disrupted | Many small banks |
| Services named as affected | 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”. This study uses TSB for that one finding; the migration itself is covered in the study for issue 01.
The RBI cited vendor risk management. On 24 April 2024 the RBI barred Kotak Mahindra Bank from taking new customers online and from issuing new credit cards. Vendor risk management was among the areas it cited. The restrictions lasted about ten months.
When the vendor sets the timetable. 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.
Our reading of the forms dependence takes. These four are our reasoning from the cases above. Only the point after them is a regulator’s finding.
- The vendor holds the knowledge: nobody inside can say what the system does.
- The vendor holds the code: the firm cannot hand the system to anyone else.
- The vendor holds the timetable: the product can be retired, and the firm moves when the vendor says.
- The provider holds the platform: many firms share one provider, and all are affected together.
In the TSB case the regulators’ finding adds a fifth point, in their own words: the bank “failed to manage the operational risks arising from its IT outsourcing arrangements with its critical third-party supplier”.
What this record does not show. The account of the attack on the shared provider rests on one summary source, which gives no timeline for the disruption; we do not go into how the attack was carried out. The Kotak record gives only the headings the RBI cited. The credit union source is a vendor’s own case study, and it does not say the institutions lacked documentation. We did not review the RBI’s rules on outsourcing and say nothing about what they require. We found no public case of a mid-size NBFC, broker or insurer with this problem, and no public case of a lender overcharged by a vendor.
4. The Options a Firm in This Position Had
| Option | When it fits | What it risks | Our view |
|---|---|---|---|
| Negotiate harder with the incumbent | The vendor is good and the firm wants better terms | With no second firm able to quote, the firm cannot walk away | Worth doing, but it changes the terms, not the dependence |
| Switch everything to a new vendor | The current vendor is failing or leaving | The new vendor starts from nothing, and the firm can become as tied to it | We would advise against this as a first move, with nothing in writing to hand over |
| 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 again | Right for some firms, once the knowledge is written down |
| 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 | The record costs money before any quote changes; the vendor may not welcome it | Our recommendation |
What we would have advised against: for a firm in this position, treating the supplier’s own reports as its oversight, carrying an exit plan that reads “to be developed” year after year, and moving to a new vendor with nothing in writing to give it.
A specification does not remove the risk that a shared provider fails. For a firm on a shared platform, whether to stay on it is a business decision that no document makes.
5. Our Recommendation, and the Decision It Asks of the Board
For the systems a lender relies on a supplier for, around its core (loan origination, collections, agent and branch portals, reporting): first own a written specification of what the system does, map what depends on each supplier, and check each change against the record. Then get a second quote, or where the system has to be replaced, move it in stages while the old one keeps running.
The decision it asks of the board: approve a fixed-price assessment of the most critical supplier-run system, and ask the firm’s own team to arrange read-only access to its code. Then decide, on the evidence, whether to stay, bring in a second supplier or replace in stages. The board stops accepting “only the vendor can” as an answer, and starts holding its own evidence.
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 |
|---|---|---|---|
| A specification held by the firm | None; the vendor’s knowledge | A written record of the system as it runs today | The specification, confirmed by the firm’s own experts |
| Suppliers able to quote | One | More than one, from the same specification | Quotes received for the same piece of work |
| 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 |
| Acceptance evidence for each change | ”Delivered as per scope” | What was meant to change, and how it was checked | Signed acceptance for each change |
| What depends on each supplier | Found out on the day | Mapped in advance | The map, reviewed with operations |
| An exit plan for the shared provider | ”To be developed” | A plan the firm could act on | Reviewed by the risk committee |
7. How IOanyT Would Work
- 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 vendor holds the code, arranging that access with the vendor is your firm’s own job.
- 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 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.
- 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.
- 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.
8. What the Client Would Own
- The specification: what the system does, in writing, portable to any supplier, including the current one.
- The risk register: the risks found in the system, listed before any price is set.
- The traceability matrix: for any module replaced, every old function linked to its replacement, with how it was checked.
- The code: any new modules are the client’s.
- The filled-in benchmark: each measure, where it started and where it stands.
9. What This Approach Does Not Cover
- A specification does not remove the risk that a shared provider fails. A firm on a shared platform is still exposed to an event like the 2024 attack on a shared provider.
- IOanyT gives no legal advice on who owns the code, and does not recover code, accounts or contracts from a vendor. Arranging read-only code access with a vendor is the firm’s own job.
- IOanyT does not host applications, and does not take over running the old system from the vendor.
- IOanyT is not a compliance or audit firm. What the regulator expects of the firm’s supplier oversight is for its compliance team.
- IOanyT does not implement packaged core banking products.
- 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 |
|---|---|
| CyberPeace, 2024 | The attack on a shared technology provider, 2024 |
| Bank of England, 20 December 2022 | TSB fine, redress and the finding on supplier oversight |
| RBI press release, 24 April 2024; RBI press release, 12 February 2025 | Kotak Mahindra Bank restrictions, the areas cited and their end |
| A vendor’s case study | The credit union group and its vendor’s sunset date |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The specification we write is yours, so the evidence the firm shows about its supplier can be its own.
Read the research notes on this issue
Dependence on one vendor or shared provider
Research note 1
Only Your Vendor Understands the System. Here Is What the Public Record Shows.
What the public record shows on lenders that depend on one vendor or shared provider, what it leaves out, the options, and the benchmark we would set.
Research note 2
Only One Firm Can Quote for Your System. A Second Quote Starts With a Document.
When only your vendor can change your system, it sets price and timetable. What that costs, what a second quote opens, four options and a benchmark.
Research note 3
A Supplier Runs Your System. Here Is the Benchmark for Overseeing It.
Supplier oversight often rests on the supplier's own evidence. The benchmark we would set for overseeing a critical supplier with your own evidence.