The invisible workload behind every LEA case at an Indian bank

Where the time actually goes on an LEA case

The portal is the last five minutes. Everything before it is the job.

An analyst reads the complaint and works out what kind of case it is. They find the transaction. They check the account status. They establish whether a hold already exists, whether the same customer raised the same issue through another channel, and whether anyone has already responded.

Only then can they write anything. A response depends on finding the right evidence, interpreting the SOP, acting across multiple systems and proving exactly what happened. The submission is the receipt - not the work.

This is why buying speed at the final step changes nothing. The queue tomorrow is the same size, because the cost per case was never in the form.

One case, five systems

Five systems is a counted figure, not a turn of phrase. Handling one case means moving between the core banking portal, the bank's API, the data lake, the internal service desk and the email inbox.

The cases do not arrive in one place either. Some come through the portal, some through an API, some as plain email, each in a different format. There is no single queue to work from, so the first task of the day is building one.

The evidence is scattered the same way. Every case means pulling transaction history, KYC records and logs out of different systems before a response is possible.

None of this is difficult work. There is a great deal of it, it has to happen in the right order, and it all has to happen again tomorrow.

What the analyst's day looks like either way

The right-hand column is not a smaller job. It is a different one. Reviewing a prepared case with the evidence attached uses judgement, which is what an experienced analyst is paid for. Searching five systems does not.

Backlog is the risk, not the individual case

Every hour a case sits open adds SLA exposure, and the Ministry of Home Affairs SOP of 2 January 2026 puts 7 and 15 calendar day clocks on the grievance and restoration work that follows a hold.

The volume behind that queue is national. Between 2023-24 and 2025-26, more than 53,87,905 cyber fraud complaints were filed on NCRP, according to the Ministry of Home Affairs. Every one that involves a bank account ends up in some bank's queue.

It also pulls analysts off higher-value fraud work, and that cost never appears in a spreadsheet. A bank with a backlog is not only late on old cases. It has its most experienced people doing retrieval instead of investigation.

In one Indian banking deployment, complaint response time moved from about three days to under an hour, and analyst hours per case fell by roughly 75%. Turnaround time came down 40%.

The rules keep moving, so the work never ends

None of this holds still. SOPs change. Portal behaviour changes. Validation rules change. Institutional policy changes.

A workflow that ran cleanly last quarter starts throwing exceptions this quarter, because the operation moved underneath it. This is where tooling bought as a one-time project stops earning its keep.

For a sense of scale: across the same deployment, 637 workflow improvements have been deployed against 490k workflow runs. Those are 637 changes to the operating logic itself, not 637 bug fixes.

Published research points the same way. Patched replayed roughly 1,000 production runs against logic frozen 30 days earlier and found 210 of 1,151 comparable executions diverged, a rate of 18.25%. At 60 days it was 288 of 1,294, or 22.26%.

A submitted response is not a resolved case

The gap between submitted and resolved is the problem that turns up in audit. A submitted response can come back, stall, or create a control gap nobody notices until a question is asked about it months later.

So "we submitted it" and "the case is resolved" are different statements, and a team measuring the first will believe it is doing better than it is.

What an operations head needs is a defensible outcome: what was checked, what was submitted, what was skipped, and why. Most tooling produces a submission and stops there.

What changed in one deployment

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

The split matters more than the total. That work breaks down into 15k+ new transaction complaints, 13k+ reassign complaints and 4k+ response-received complaints. Three kinds of work, each handled differently.

What made it hold was owning the surrounding job rather than the submission. Start in draft mode. Keep human approval wherever your policy requires it. Then measure whether the queue is smaller next month, not whether the form got filled faster.

The objection: surely the analysts are the bottleneck

The instinct when a queue grows is to add people. It is the fastest lever an operations head controls, and on this work it buys less than expected.

A new analyst does not reduce the per-case cost. They arrive and start doing the same five-system retrieval as everyone else, at first more slowly. The queue moves because there are more hands on the same expensive task.

The arithmetic makes the point. One person handles roughly 80 emails a day. If a meaningful share of those need document extraction, a five-system lookup and a fixed-format reply, doubling headcount doubles cost and roughly doubles throughput. Nothing about the case got cheaper.

Compare that with removing the retrieval. Between 50 and 60% of cases then run end to end with no analyst time at all, and the cases that still need a person drop from about two minutes of manual handling per transaction to under a minute. The same team covers more without anyone working harder.

What to do first, if you do nothing else

Measure the split between retrieval and decision on twenty real cases. Sit with an analyst and time it, because a self-reported estimate will be wrong in a predictable direction.

If retrieval is most of the elapsed time, headcount is the wrong lever and you now have the evidence to say so in a budget conversation. If decision time dominates, your problem is training or policy clarity, and no tooling will fix it.