The Rules in Your System Were Decisions. The Business Can Make Them Again.

A developer is making a routine change to the penalty calculation and finds a line that makes no sense.

It says that borrowers with certain scheme codes are never charged a penalty. There are fourteen codes in the list. Nobody on the team knows what they are.

It takes a week of asking. The codes belong to a salary scheme agreed with one employer, nine years ago. The firm stopped lending through that employer six years ago. The waiver has been applied to every late payment from those borrowers since.

Nobody decided it should continue. Nobody decided it should stop.

What We Found

We looked at how the rules in an old lending system outlive their reasons, and at what the public record says about customisation.

Customisation is the normal state of a long-lived system. A group of credit unions shared one core system, described as heavily customised. 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 customisation was a decision that made sense on its day.

Rules are added and rarely removed. There is always someone asking for a new exception. Nobody is asked to take an old one out, and no name is attached to a rule once the person who asked for it has moved on.

An out-of-date rule causes no error. It does not crash anything. It quietly produces a slightly different number, for some customers, for years. It is found by accident: in a complaint, in an audit, or by a developer looking for something else.

Developers end up deciding policy. A developer who finds an unexplained condition cannot know what depends on it, so the safe choice is to leave it and add a comment: do not change. A business decision has been made, by default, without the business knowing there was one to make.

What the Business Gets Back When It Decides Again

A forgotten rule is usually seen as a technical oddity. Our reading is that it is a business decision made and forgotten, and that deciding such rules again gives back two things the business has lost.

The ability to change its products quickly. A fee change or a new product variant should be a business decision. When nobody knows which rules a change will touch, it becomes a search, then a risk review, then a slow and careful change. A firm with its rules written down, and decided, starts each change from the page.

The ability to explain its own figures. When every rule has a written line and a recorded decision, a customer’s question about a charge, a finance question about a figure or an auditor’s question about a calculation is answered from the record. Nobody has to say that the system did it.

There is a third, quieter gain. The firm applies terms it chose. A waiver for a scheme that ended, or a fee the firm stopped meaning to charge, is found on purpose and settled, instead of by a customer.

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

Four Ways to Deal With Rules Nobody Remembers, Weighed

Option	When it fits	What it risks
Interview staff and write up what they say	The system is small, and the people who built it are still there	It captures what people remember. A forgotten rule is, by definition, the one nobody mentions
Leave it alone	The system is stable, rarely changed and due to retire	Terms nobody chose keep being applied, and each change is made around rules nobody understands
Re-specify from the old requirements documents	The documents were updated with every change	They show what the business asked for at launch. The forgotten rules were added later
Take the specification from the system itself, then the business decides each rule	The system is old, customised and poorly documented	It takes senior people’s time, and it will turn up rules that were wrong for years

The other options still help: interviews explain why a rule exists, and old documents show what was intended. Neither tells you what the system does today.

This has a price. Deciding takes real time from people in finance, operations, product and compliance, and a few hundred rules are not reviewed in one meeting. Some rules will turn out to have been wrong for years. What to do about past charges is a question for your legal and compliance advisers, not for us. Some rules will stay marked “reason unknown”, because nobody is left to ask.

Where You Are Now, and Where You Should Be

Before the review begins, we would set a benchmark for the decisions themselves.

Measure	Typical starting point	Where it should be	How it is checked
Rules with a written line	A product note from launch; the rest only in the code	Every rule in scope has its own line, in plain words	The specification, confirmed by your own experts
Rules nobody can explain	Left in place under a “do not change” note	Each one listed, with the business’s decision recorded	The decision, recorded against the line
Rules with a named owner	None after the person who asked has left	Each rule has a person in the business who answers for it	The owner’s name on each line
Where a fee change starts	A search through the code	The written rule, and what depends on it	The next change request
Figures that can be explained	”The system calculated it”	Each charge or fee can be explained from a written rule	Figures from recent statements, explained from the record

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.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about the system, the rules nobody can explain, and the product changes that keep waiting. You leave with a short written note of what we found.
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. 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 decided, and a rule the business retires is not carried across. 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. Changing a rule inside the old system stays with your current team or vendor.
5. We review against the benchmark. Before work starts we set the benchmark. After each module 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.

What changes for the business:

Role	What they gain
CEO	Products behave as the firm intends today, not as someone decided twelve years ago.
CTO or CIO	Rules no longer wanted are retired, so the system gets simpler and safer to change.
CFO	Charges and waivers the firm never chose to keep come to light and are settled on purpose.
COO	The special cases staff work around are either made official or removed.
Risk and compliance	Every rule has an owner, a reason and a recorded decision.

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

The case	What IOanyT does
A group of credit unions ran a heavily customised core system, and replacing it meant rebuilding hundreds of screens and hundreds of interfaces.	Our assessment takes the specification from the system itself and lists each rule nobody can explain, so the business decides what a customised system does before anyone rebuilds it.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. Every rule in your system was somebody’s decision; the specification puts each one back in front of the business.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →