A third team emails around a simplified version. The platform gets built against whatever interpretation the developer received last. And then the first batch of decisions goes out.
Those four versions diverge. Quietly, gradually, and usually without anyone noticing until there’s a disputed decision, a regulator question, or an audit request.
We’ve noticed that the cost of remediation almost always tracks the distance between where the eligibility logic is written and where the eligibility decisions are made.
The wider that gap, the more expensive everything downstream becomes.
Disputes. Rework. Exception queues. Regulator correspondence. Manual reconciliation. These are not separate problems. They're all symptoms of the same root cause: eligibility logic living outside the system.
If eligibility logic lives in the system, the change propagates. Decisions made after the update reflect the new rule. Decisions made before it are traceable. You can show which version of the logic applied to which cohort, and when.
If eligibility logic lives in a spreadsheet, the change needs to be communicated to the person maintaining the spreadsheet, then the person entering data, then the reviewer approving outputs. Somewhere in that chain, someone is still working from the old version. And you won’t know which decisions were made under which rule unless someone thought to record that at the time.
Fragmented eligibility logic creates cost in predictable ways. We’ve noticed these showing up consistently across financial services remediation programmes:
When the system can’t apply a rule cleanly because it’s not embedded in the workflow, cases get flagged for human review. At low volume this is manageable. At scale it becomes a backlog. The backlog creates pressure. Pressure creates inconsistent decisions. Inconsistent decisions create disputes.
ASIC’s regulatory guide on consumer remediation is clear: you need to be able to demonstrate how eligibility was determined, not just what the outcome was. If your eligibility logic lives across three systems and two email chains, producing that evidence is a project in itself.
When a claimant challenges a decision, the answer needs to come from somewhere traceable. If it’s coming from whoever remembers why that rule was applied that way, the dispute resolution process becomes slow, inconsistent, and resource-heavy.
If a rule was misapplied across a cohort, fixing it means identifying every affected decision, reprocessing, re-communicating, and updating the audit trail. This is not a one-afternoon problem. It's a programme within a programme.
It doesn’t mean a rigid rules engine that legal can’t touch. It means that the operative rules — the ones that are actually being applied to actual claimants — exist in a controlled, version-tracked, auditable workflow.
When a rule changes, the system reflects that change and records when it changed. The legal team can see the operative version at any point in time. The reviewer applying a decision can see exactly which criteria they’re working from. The audit trail captures the rule version alongside the decision.
The counterpoint is real: legal interpretation still drives the rules. The system doesn’t write policy. But there’s a significant difference between legal interpretation informing a controlled workflow and legal interpretation existing only in a document that the workflow never directly references.
Most remediation teams start small. A pilot cohort. A manageable volume. At that scale, the spreadsheet approach works. It’s fast to set up, easy to adjust, and good enough to get the programme moving.
The problem is that the decision about where eligibility logic lives usually gets made during the pilot. And it rarely gets revisited when the programme scales.
By the time the volume justifies a proper controlled workflow, you’re already mid-programme. Decisions have already been made under the old approach. Rebuilding the logic into the system now means reconciling past decisions against the new structure. Which is expensive. And slow. And the kind of work that shows up in the debrief as “something we should have done at the start.”
The right question isn’t whether you need controlled eligibility logic. You do. The question is whether you build it at the start, when it’s a design decision, or at month six, when it’s a remediation of the remediation.