Why we don't let an AI agent close an LEA case on its own

The actions are not all reversible

Resolving an LEA case is not only writing a response. Depending on the case it can mean putting a hold on funds or freezing an account.

A wrong email is embarrassing. A wrong freeze affects a real customer's money, creates a grievance of its own that enters the same queue you were trying to clear, and is exactly the kind of thing the RBI expects a bank to be able to account for.

So the level of autonomy has to match the consequence of the action, not the confidence of the model. Those are different things and they are easy to confuse when a system sounds certain.

The Ministry of Home Affairs SOP of 2 January 2026 draws the same line. Decisions to lift a hold or restore money sit with the investigating officer or a court. The bank carries them out, inside 15 calendar days, and records what it did.

The cost is measurable. In one deployment, frozen-account cases accounted for 3,755 of 16,736 in the queue, or 22.4%.

Three modes, not one switch

A control model for this work needs three settings, and which one applies should be set by the bank's policy rather than by the software.

1. Draft-first. The system prepares everything and submits nothing. An analyst reviews the recommendation with the evidence already attached and approves the submission.
2. Maker-checker. The familiar control most Indian banks already run on sensitive operations, applied to case resolution.
3. Approved scenario. Specific, named scenarios the bank has reviewed and signed off run end to end. Everything else does not.

The third mode is the one worth dwelling on. It does not mean the system is now autonomous. It means these particular situations, which the bank has looked at and agreed on, can run without a human. Scope is granted - never assumed.

Low confidence should produce a draft, not a guess

When evidence is low-confidence or the case is high-risk, the correct behaviour is to create a draft and escalate.

This sounds obvious and it is the thing most automation gets wrong. A system built to maximise completion rate will produce an answer for every case, because that is what it is measured on. A system built for a regulated operation needs to be able to stop.

On reassign and response-received cases the same logic decides between four outcomes: correct, confirm, hold, or escalate. Escalate is a legitimate result, not a failure, and it should be counted as one in your MIS.

The system has to be able to refuse

Nothing should reach a submission without a separate check standing between the two. If that check fails, the case goes to the operations team.

It does not get submitted with a caveat. It does not get retried until something passes. The path out for work the system cannot do properly is a person.

In practice this matters most on the long tail. One Indian banking queue held 189 distinct scenarios across 16,736 cases, and 41 of those scenarios had five cases or fewer. A system that forces an answer on those is making 41 different unreviewed judgements.

Four things the bank keeps

Control is specific, not a reassurance. On a CaseLEA deployment the bank retains the rules, the data sources, the exception categories and the approval thresholds.

Those four levers cover most of what a control function would want to hold, and none of them sits with the vendor.

Human approval makes the operation faster, not slower

The usual objection is that human approval defeats the purpose. In practice the opposite happens.

An analyst reviewing a recommendation with the evidence already collected works far faster than an analyst searching five systems and writing a response from scratch. The slow part was never the approval. It was the retrieval.

The figures bear this out. In one Indian banking deployment, response time went from about three days to under an hour, and analyst hours per case fell around 75%. Human review stayed in place throughout.

How to get to autonomy honestly

Draft mode gives you something to measure before you commit. Run representative cases, review accuracy, effort and exceptions, then widen the scenarios that earned it.

That is how autonomy gets granted rather than switched on. One scenario at a time, with evidence, instead of a setting somebody enabled on a Friday.

Every action produces an audit trail either way: what was checked, what was submitted, what was skipped, and why. If you cannot produce that, it does not matter how autonomous the system is.

What granting a scenario actually involves

Approved-scenario autonomy sounds administrative until you do it once. In practice a bank reviews the scenario, the evidence it depends on, the rule applied, the failure modes and the reversal path, then signs.

That review is where most of the value sits, because it forces a decision that was previously implicit. Plenty of banks discover during this exercise that nobody had written down the correct handling for a scenario their team had been resolving by convention for years.

In one Indian banking operation, 76 resolution scenarios were codified as workflows. Each of those is a written, reviewable decision about what correct looks like, which is useful to have whether or not anything runs without a person afterwards.

Where the boundary should sit on a first deployment

A sensible starting position is narrow and easy to defend.

• Nothing that moves money or restricts an account runs without a person, on day one or on day three hundred.
• Nothing that leaves the bank goes out unreviewed, because a reply to an agency carries the bank's name.
• Anything with low-confidence evidence produces a draft and an escalation, whatever the scenario says.
• Everything else is a candidate, and it gets granted one scenario at a time with the evidence to support it.

That boundary costs you very little throughput, because the expensive part was the retrieval, and the retrieval is already gone.