Originally published on BusinessReporter.com
A payment on an instant rail settles in seconds and is final the moment it lands.
A dispute over that same payment runs on a clock measured in weeks. Regulation E gives a bank ten business days to put provisional credit back in a customer’s account and up to 45 days, sometimes 90, to investigate.
The payment moves instantly. The dispute process does not.
I’ve spent about a decade building software for that slower timeline, and what stands out in conversations with banks is how differently the two sides are treated. Nearly everyone can walk me through a payments modernisation roadmap. Fewer can explain what happens when a payment goes wrong, which is where the work still depends on spreadsheets, shared inboxes and a queue that doesn’t shrink.
Disputes were never built as infrastructure
The reason has more to do with architecture than operations.
Authorisation got treated as a system, so it was given throughput targets, latency budgets, redundancy and capacity planning. Resolution got treated as a queue, so it got staffing models, escalation paths and a generous tolerance for backlog.
That held up while volumes stayed modest. But it came apart once payment volume started compounding, because the two halves scale in completely different ways. Dispute volume rises with transaction volume on its own, without anyone deciding anything. Resolution capacity rises with headcount, which needs a decision, a budget cycle and a co-operative hiring market. Those two lines separate further every year the business grows.
This is why hiring has such a short half-life as a strategy. A team that doubles clears the current backlog and then meets a bigger one a year later. You cannot staff your way out of an architecture problem.
Every modernisation program of the past decade inherited this. ISO 20022, real-time rails, core replacement and cloud migration all improved how money moves and left resolution where it was, because resolution never appeared on the architecture diagram. It lived on the org chart.
The clock has started
Resolution speed used to be a service metric that made you look bad when it slipped.
That has changed from several directions at once. Regulation E has always been a statutory clock, but it now runs against case volumes and a regulator that has grown noticeably less patient about consumer redress. Instant rails took away the recovery window that used to absorb operational slack. And the UK’s mandatory reimbursement rules for push payment scams turned resolution outcomes into a funded liability, which tells you the international direction of travel.
Every item on that list shortens the time an institution has, and none of them reduce the volume it receives.
Customers apply their own version of that pressure. Our 2026 consumer research found 70 per cent say their trust in an institution is shaped more by how a fraud or scam claim gets resolved than by the fraud itself, and 72 per cent say a fraud experience changes their confidence in that institution’s other services.
Resolution now carries statutory deadlines, quantifiable liability and regulatory attention, and those are the same characteristics that made payment rails an operational priority years ago. Very few institutions have mapped resolution into that, and a process depending on individual judgment and a spreadsheet only two people understand looks to me like risk that is yet to translate to failure.
What resolution should look like
My view is that resolution deserves the treatment authorisation already gets: a dedicated layer with its own architecture rather than a workflow attached to the side of something else.
It should behave as a system of record, capturing every action and decision as structured data in real-time, so nobody reconstructs the story from case notes when an examiner asks.
The part I would argue hardest about is automated decisioning. Building automation that reaches the right answer is one engineering problem. Building automation whose reasoning you can defend to an examiner months later on a specific case is much harder. Explainability has to be a constraint you accept before writing any code, because accepting it changes the architecture. Anyone evaluating automated resolution should ask which of those problems the system in front of them was built to solve.
The payoff runs further than efficiency, which is usually how this work gets funded. Pulling resolution into one system turns dispute activity into a data asset, because repeat behaviour and first-party abuse become obvious together.
Payments have been accepted as critical infrastructure for years, and resolution is the half still carried as overhead, despite its statutory deadlines, real liability and volume that grows whether or not anyone budgeted for it. Money moves in seconds now, so making problems right again should not take weeks.