LEA notices and court orders: the email queue Indian banks never staff for

What actually lands in the inbox

Three kinds of thing, mostly. Requests for information. Requests for action. Notices and court order drafts that need a response in a specific format.

None of them can be answered from the email alone. Each one means interpreting what is being asked, collecting statements and KYC documents, and preparing a response in whatever fixed format the requesting agency expects.

That last part is where people underestimate the work. The information is often easy to find. Getting it into the required shape, with the right attachments, is not.

The source of this correspondence is large. Between 2023-24 and 2025-26, cyber fraud complaints on NCRP led to more than 1,81,271 FIRs, according to the Ministry of Home Affairs. Each investigation that touches an account sends questions to a bank.

LEA requests are not a side queue

Across 16,736 cases in one Indian banking deployment, seven distinct scenarios were specifically about law enforcement instructions, accounting for 2,413 cases, or 14.4% of everything in the queue.

Read the top row again. Matching an LEA instruction through the API is the largest single scenario in the whole queue, at 9.9% of all cases. Larger than any customer complaint type.

The instruction turns up in three different places

Notice the second and third rows. The instruction arrives through the API, sits on the portal, or is buried in an older email thread.

An analyst does not know in advance which, so they check all three before they can say anything useful. That is three lookups on every case, most of which return nothing.

The bottom rows are the uncomfortable ones. A freeze code with no matching instruction, or a case where no instruction can be found at all, means somebody has to work out what happened before they can answer anyone.

Why one request takes so long

Answering a single LEA email means touching five systems: the customer CRM, the API, the data lake, the internal service desk and the email inbox itself.

Attachments have to be read before anyone knows what is being asked, because the request often sits inside a scanned document rather than the message body.

For scale, one person handles roughly 80 emails a day. When a meaningful share of those need document extraction, a five-system lookup and a fixed-format reply, the arithmetic stops working long before the queue does.

What changes when it is handled properly

The measure is not how fast a reply goes out. It is what the person handling it is doing with their time.

Today they are reading, searching, assembling and formatting. In a well-run operation they are reviewing a prepared response with the evidence already attached, and deciding whether it is right. That is a different job, and it is the one their experience is worth paying for.

On LEA information requests specifically, CaseLEA removes 84% of that effort.

Two things have to hold for it to be safe. The evidence has to be complete before a human sees it, so review is not secretly retrieval. And nothing goes out without a check standing between the draft and the send.

Why the stakes are different here

A check between draft and send matters more on LEA correspondence than anywhere else in the operation.

A wrong number in a reply to a customer is a service failure. A wrong number in a reply to a law enforcement agency is a different category of problem entirely, and it is the sort of thing an RBI systems audit will ask about.

This is why CaseLEA prepares and a person confirms. The approval threshold is set by the bank's policy, not by the software.

Court orders now arrive with a clearer expectation attached. Under the Ministry of Home Affairs SOP of 2 January 2026, orders on held money are served on the bank for compliance, and the bank implements them and updates NCRP-CFCFRMS.

Why this stays on email, and should

There is a recurring instinct to move LEA correspondence onto a portal or a ticketing tool. It usually fails, and the reason is worth understanding.

Email is the only channel that is a conversation and a paper trail at the same time. Written, threaded, timestamped, addressable and searchable. When a case is reviewed eighteen months later, the thread is the record.

Email also gives you the one thing a live channel cannot - time. Time to check, to route, and to get the answer right before it goes out.

So the goal is not to move the work off email. It is to stop the retrieval, the document reading and the formatting from consuming the person sitting in front of it.

What makes this queue different from customer email

Both arrive as email and the resemblance ends there.

A customer email is a service interaction with a recoverable failure mode. If the reply is unclear, the customer writes back. A law enforcement request has a fixed format, an external expectation and a reader who will not clarify on your behalf.

The evidence standard differs too. A customer wants an answer. An agency wants statements, KYC documents and transaction records in a specific shape, and an incomplete pack usually means the request is reissued rather than returned with a note.

That is why blending the two queues into one inbox rota quietly degrades both. The customer queue rewards speed and the LEA queue rewards completeness, and whichever is measured harder will win the analyst's attention.

How to staff it without a dedicated team

Most Indian banks cannot justify headcount for a queue that is 14.4% of case volume, so the realistic answer is not a new team.

It is to take the retrieval and the formatting off the person who already has it, so the residual work fits inside an existing role. Where evidence arrives assembled, review takes minutes rather than the better part of an hour.

Then measure the one thing that matters here: how many replies went out complete on the first attempt. Reissued requests are the real cost, and they never appear in a turnaround figure.