When the System Is the Only Record of the Rules

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. The penalty rule in section 3 is an illustration, not taken from a real system.

Organisation type	A group of credit unions sharing one heavily customised core system, set beside one UK bank’s failed migration
Size band	The credit union group: many branches and a large membership. The UK bank: large
Region	The credit union group: not stated in the source. The bank: United Kingdom
The decision at stake	What to do when the only complete record of a firm’s business rules is the system that applies them
The public outcome	Replacing the credit unions’ core meant rebuilding hundreds of screens and hundreds of interfaces. The UK bank received 225,492 complaints after its 2018 migration, for reasons the regulators found in supplier management
Why it matters to a mid-size lender	Many lenders on an old system cannot state how it calculates a penalty or a fee. That slows every product change and every answer to an auditor

2. The Business Problem, in the Buyer’s Words

“The auditor asked how penal interest is calculated, and after two days we still could not say. Finance says the system does it. Technology says it was set up years ago, and the developer who changed it has left. We want to change our fees this year, and nobody can tell me what else that will touch.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm cannot change its products quickly or explain its own figures, because its rules are written down only in the system.

3. What We Found

Method. We went through the public record on old, heavily customised systems in financial services: a vendor’s published case study of one replacement, and the UK regulators’ notices on one failed migration. The record is thin, so we say which parts are our reasoning.

The scale of a customised system. A group of credit unions shared one heavily customised core system. Its vendor scheduled it to be retired in 2024, and replacing it meant rebuilding hundreds of screens and hundreds of interfaces to other systems. Every screen and every interface carries rules of its own.

What is at stake when a new system behaves differently: a background case. In April 2018, TSB Bank in the UK moved its customers to a new IT platform, and the migration failed. Between 22 April 2018 and 7 April 2019 it received 225,492 complaints. In December 2022 the regulators found that it had failed to manage its outsourcing arrangement with a critical supplier. Their finding was not about unwritten rules, and this study does not claim that buried rules caused the failure. We use the case for one point: when a new system behaves differently, customers notice first.

How one rule gets buried. This illustration shows the pattern.

Year	What changed	Where it went
Year 1	Penalty is a fixed monthly rate on the overdue amount	The application, and the product note
Year 3	A three-day grace period is added	The application only
Year 5	No penalty for borrowers under one employer’s salary scheme	A list of codes in a database table
Year 7	The penalty is rounded to the nearest rupee	Logic stored inside the database
Year 9	If the due date is a holiday, grace starts the next working day	The overnight job that posts penalties
Year 12	The total penalty on small loans is capped	The application. The developer has since left

The table above is an illustration, not taken from a real system.

By year 15 the product note still shows the one sentence from year 1. The real rule has six parts, in four places.

Our reading of why the rules get buried. These four are our reasoning. None is a regulator’s finding.

1. Each change went into the system and nowhere else. Updating the document was nobody’s job.
2. A rule ends up in pieces: in the application, the database, scheduled jobs, tables of codes and rates, and sometimes a spreadsheet adjusted by hand.
3. Rules are added and rarely removed. An out-of-date rule causes no error, so it runs for years.
4. The people who asked for a rule and built it move on. What remains is the behaviour, without the reason.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Interview staff and write up what they say	The system is small, and the people who built it are still there	It records what people remember; the missing rules are the ones nobody remembers	Useful for why a rule exists, not what the system does
Leave it alone	The system is stable, rarely changed and due to retire	Every change is made blind, and a replacement is specified from memory	Right only for a system on its way out
Re-specify from the old requirements documents	The documents were kept up to date with every change	They describe the system at launch, not the years of changes since	Rarely enough for a system customised for years
Take the specification from the system itself, then the business decides each rule	The system is old, customised and poorly documented	Time before anything visible changes; rules nobody can explain, some wrong for years	Our recommendation

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): take the specification from the system itself, write each rule in plain words, trace it to the code, and list every rule nobody can explain for the business to decide. Then use that record for every product change and any replacement.

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
Rules with a written line	One sentence per product, from launch	Every rule in scope has its own numbered line, in plain words	The specification, confirmed by the firm’s own experts
Rules traced to the code	None	Each line points to where the code carries it out	Senior engineers’ review, line by line
Rules nobody can explain	Left in place under a “do not change” note	Each one listed, with the business’s decision recorded on its line	The decision, recorded against the line
Figures that can be explained	”The system calculated it”	A charge, fee or interest figure can be explained from a written rule	Figures from recent statements, explained from the record
Places outside the application where rules may sit	Not considered	Named in the record, each marked as covered or not yet covered	The firm’s own experts confirm the list
Old functions linked to their replacement	No link is kept	Each one linked and compared before its module goes live	The traceability matrix for each module

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about the system, the figures nobody can explain, and the product changes that keep waiting. 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. This study 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. Each rule nobody can explain is listed for the business to decide.
4. If you approve, we build. Where the business decides to replace a module, we build it with each rule as the business decided it. 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. As the work goes on 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: each rule in plain words, traced to the code, and portable to any supplier.
• The list of rules nobody could explain: each one with the business’s decision recorded on its line.
• The traceability matrix: for each module replaced, every old function 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 does not change rules inside the old system, and does not maintain or patch it. The client’s current team or vendor does that.
• IOanyT does not claim to read COBOL, RPG or customisations made inside a core banking product, and does not implement packaged core banking products.
• IOanyT does not advise on past charges or waivers; that is for the firm’s legal and compliance advisers. It offers no regulatory or compliance service.
• The record names the places outside the application where rules may sit. This study does not say the assessment reads every one of them.
• 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
Bank of England, 20 December 2022	TSB’s April 2018 migration and the regulators’ supplier finding
FCA Final Notice, TSB Bank plc, 2022	TSB’s 225,492 complaints
None (invented)	The illustration of one penalty rule in section 3

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. The rules are the firm’s own decisions; the specification puts them back on paper, where the business can read and decide them.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →