In short
A single closure percentage is the least useful number in a case operation. It tells you work left the queue, not what happened to it.
Seven named outcomes carry more information than one: closed, partially handled, pending review, failed validation, freeze required, no records, and manual exception. Every exception carries a categorised reason, and every action records what was checked, what was submitted, what was skipped, and why.
Why one closure number misleads
Every NCRP and I4C case operation reports a closure rate. It goes in the MIS, it goes to the management committee, and it is almost always the wrong number to lead with.
A submitted response can still return, stall or create a control gap. So closed can mean the case is genuinely finished, or it can mean a form was filled and the consequences have not arrived yet.
Both look identical in a percentage. Teams need defensible outcomes, not form filling, and a defensible outcome has a name more specific than closed.
Seven outcomes, not one
| Outcome | What it tells you |
|---|---|
| Closed | The case is finished and the response went through |
| Partially handled | Some of the work completed, some remains |
| Pending review | Waiting on a human decision, not stuck |
| Failed validation | The checks did not pass, so nothing was submitted |
| Freeze required | An action is needed that carries real consequence |
| No records | The evidence to resolve it does not exist in the connected systems |
| Manual exception | Genuinely needs a person, with the reason attached |
Look at what separating these gives you. No records is a data access problem. Failed validation is a rules problem. Pending review is a staffing problem.
Collapsed into one not-closed bucket, all three look like the same thing and none of them gets fixed.
Every exception carries a reason
The second rule matters as much as the taxonomy. Every exception is categorised with its reason, so unresolved work stays visible and measurable.
Unmeasured exceptions are how backlogs form quietly. Cases that could not be handled go into a pile, the pile has no structure, and nobody can say whether it is growing because of one fixable problem or fifty different ones.
With reasons attached, the pile becomes a work list. Patterns surface, and the recurring ones get dealt with properly instead of being absorbed again next month.
The 2026 SOP now expects the same discipline on restoration. When a bank cannot complete a police direction to return held money, it records the reasons for non-compliance in the Money Restoration Module.
This is not theoretical. One Indian banking queue held 189 distinct scenarios across 16,736 cases, and 41 of those scenarios had five cases or fewer.
We automate the repetitive parts while preserving control, review, and auditability.
What an audit trail has to contain
Outcomes tell you what happened. The audit trail has to show it.
Every action produces a record of what was checked, what was submitted, what was skipped, and why. Inputs, checks, decisions, timestamps, outputs and exception reasons all stay reviewable. In one deployment that record runs at 98%+ completeness and accuracy.
The part about what was skipped is the one people forget to ask for. A system that logs its successes and stays quiet about the steps it did not perform is not giving you an audit trail. It is giving you a highlight reel.
What this changes in your MIS
A daily MIS built on seven outcomes reads differently from one built on a closure rate.
Instead of a single percentage you get a view of how much work genuinely finished, how much is waiting on a person, how much failed a check, and how much could not be resolved because the data was not there.
Each of those has a different owner and a different fix, and not one of them is visible inside a closure rate.
It also changes the conversation with a regulator or an internal auditor. Saying you closed most of them invites a follow-up question. A categorised breakdown with an audit trail behind each case answers it before it gets asked.
The control that makes it real
None of this works if the vendor defines the categories.
On a CaseLEA deployment the bank retains control over the rules, the data sources, the exception categories and the approval thresholds. The exception categories being on that list is deliberate - how your unresolved work gets classified is a decision about your own operation.
The operating promise underneath all of it is straightforward: higher throughput, fewer manual misses, better consistency and stronger defensibility. The first is what gets bought. The last is what gets you through an audit.
How to start reporting this way
You can do the first version of this without buying anything. Take last month's cases and re-tag them against the seven outcomes rather than closed and not closed.
Count how many of your not-closed cases were waiting on a person, how many failed a check, and how many had no evidence available in your systems. Those three numbers go to three different teams.
If you cannot produce that split from your current records, that is itself the finding, and it is worth raising before someone external raises it for you.
What each outcome tells a different team
The seven states are useful because they route. A single closure rate goes to everyone and actions no one.
| Outcome | Who should see it | What they do about it |
|---|---|---|
| No records | Data and integration owners | A source system is missing or unreachable |
| Failed validation | Policy and rules owners | A rule is wrong, or the input quality changed |
| Pending review | Operations management | A capacity or shift-coverage decision |
| Manual exception | Process design | A scenario needs codifying or escalating properly |
That routing is the practical payoff. Four different teams get four different work lists from the same queue, instead of one number that belongs to nobody.
The trap of measuring outcomes you control
A caution worth stating. Once outcomes are named, there is pressure to make the uncomfortable ones smaller.
Manual exception and no records both look bad on a dashboard, and both can be reduced by reclassifying rather than by fixing anything. The guard is that categories belong to the bank, not the vendor, and that a change in category definitions is itself a recorded event.
If your exception rate improves sharply without a corresponding change in the operation, look at the definitions before celebrating.
Sources
- CaseLEA operating documentation, 2026: seven case outcomes and categorised exceptions.
- Patched data points, 2026: audit trail completeness and accuracy 98%+.
- Scenario breakdown from one Indian banking operation, 2026: 16,736 cases across 189 scenarios.
- Ministry of Home Affairs, Standard Operating Procedure for NCRP-CFCFRMS, Custody, Restoration of Money and Grievance Redressal, 2 January 2026.
