Why Indian banks keep buying software and still have a complaint backlog

You bought a builder, not an outcome

Look at how automation gets sold to a banking operations team. The demo shows a workflow being assembled. Drag the steps, connect the systems, watch a case move through. It is impressive and it is useful.

Then the contract gets signed, the tool gets installed, and responsibility for producing results sits with your team.

Somebody at the bank now defines every scenario. Somebody handles the exception nobody anticipated. Somebody notices when the portal changes and the workflow silently starts failing. That somebody is usually an operations analyst who has been turned into an automation engineer without anyone saying so.

The vendor delivered what was promised - the backlog is still there.

Every generation has made the same trade

One generation promised that anything a person could do on a screen could be handled for them. It could, until the screen changed.

Copilots promised to sit alongside the analyst and speed them up. They do, for the part of the job that is writing. Not for the part that is checking five systems.

Vertical agents promise to understand your domain, and many genuinely do. The question is still who owns the outcome when a case does not close.

The pattern holds each time. Capability improves. Accountability stays exactly where it was.

The gap shows up as maintenance, not failure

Automation in a live case operation rarely fails loudly. It degrades.

SOPs change. Portal behaviour changes. Validation rules change. Institutional policy changes. Each of those needs someone to update the operating logic, and the volume of that work is larger than most business cases assume.

The clearest recent example is the Ministry of Home Affairs SOP for NCRP-CFCFRMS, issued on 2 January 2026 and running to 98 pages. It rewrote how holds, grievances and restoration work across every bank on the system. Any workflow built before that date needed checking against it.

Across one CaseLEA deployment at a leading Indian payments bank, 637 workflow improvements were deployed against 490k workflow runs. That is the real shape of production automation. Not a build and a handover, but a continuous stream of changes to keep the thing working.

If your vendor is not doing that work, your team is. Check who has been doing it for the last six months.

The measured cost of standing still

Patched published a drift benchmark in 2026 that puts a number on this. Roughly 1,000 production runs were replayed against operating logic frozen 30 days earlier.

At 30 days, 210 of 1,151 comparable executions diverged from what the current logic would have produced, a rate of 18.25%. At 60 days, 288 of 1,294 diverged, or 22.26%. On document validation specifically the divergence was 27.66% at 30 days and 39.58% at 60.

Read that as an operations head. Freeze your automation for two months and close to a quarter of cases start behaving differently from what your current rules say should happen. Nothing broke. Nothing alarmed. The logic simply aged.

What a managed operation changes

Continuous maintenance is why CaseLEA is delivered as a managed operation rather than a platform you are handed and left to run. Keeping the operating logic current as your operation changes is our job, not something handed back to your analysts.

The workflow still belongs to the bank. The rules, the data sources, the exception categories and the approval thresholds stay under the bank's control. What changes is who is responsible for keeping it working on a Tuesday in March when the portal behaves differently.

Five questions that separate a builder from an operation

1. Is the SLA on uptime or on work done? Availability is easy to promise. Cases closed is not.
2. Who updates the logic when the portal changes? If the answer is that you can do it yourself and it is very easy, that is your team's job now.
3. How many changes were deployed on your last deployment? A low number means either a simple operation or one that is quietly degrading.
4. What happens to a case the system cannot handle? Silent failure and a categorised exception are very different answers.
5. Are we paying for seats, for the platform, or for execution? Pricing tells you what the vendor thinks it is selling.

What the numbers look like when the work is owned

Production outcomes at a leading Indian payments bank, starting from a 15,000-case backlog. Source: caselea.com, 2026.

The last number explains the first three. The backlog came down and stayed down because the operating logic kept being updated as the operation changed.

So the question to put to any vendor is not whether their automation works. It probably does. The question is what happens in month seven, and whether the answer involves your team.

How to tell which one you bought

There is a diagnostic that takes an afternoon and settles the argument.

Pull the change log for your automation over the last six months. Count how many changes were made, and by whom. Then count how many of those changes were made by someone on your payroll.

If most changes came from your side, you bought a builder and your team is running it. That is a legitimate choice, but it should appear in your headcount plan rather than being absorbed by whoever is good at it.

If the change count is near zero, that is worse. A live case operation moves constantly, so no changes means either the automation covers a narrow slice or it has quietly stopped matching how the work is done.

The pricing question underneath

Three models get quoted and they distribute risk very differently.

Per-seat pricing assumes the headcount stays, which means the vendor is paid the same whether or not the queue shrinks. Platform pricing charges for capability regardless of use. Execution pricing costs you only when a case is actually handled.

Only the third model gives the vendor a reason to care about your tail scenarios, and the tail is where coverage gets expensive. Ask which one you are being quoted, and ask what happens to the invoice if your volume halves.