In short
An auditor does not ask whether your bank has a policy. They can read the policy. They ask what was checked on one specific case, on one specific date, and what was not checked.
Answering that requires six things in the record: inputs, checks, decisions, timestamps, outputs and exception reasons. In one Indian banking deployment that record runs at 98%+ completeness and accuracy, including the steps that were skipped.
The question that actually gets asked
Policy review is the easy part of an audit, and it is the part banks prepare for. The document exists, it says the right things, and it gets approved.
Then the reviewer picks a case. Usually not a good one. They ask what was done, in what order, by whom, and on what basis.
That is where case operations fail audits, and it is almost never because the decision was wrong. It is because nobody can show how it was reached.
Six things the record has to contain
| Element | What it answers |
|---|---|
| Inputs | What the case arrived with, and from which channel |
| Checks | Which systems were consulted and what each returned |
| Decisions | What was concluded, and under which rule |
| Timestamps | When each step happened, not the general sequence |
| Outputs | Exactly what went out, in the format it went out in |
| Exception reasons | Why anything unresolved was left unresolved |
Five of these are standard. The sixth is the one that separates a real audit trail from a highlight reel.
Why what was skipped matters most
A system that logs its successes and stays quiet about the steps it did not perform is telling you a partial story.
If a KYC lookup timed out and the case proceeded anyway, that is the fact a reviewer needs. It is also the fact most systems do not record, because nobody designed for it.
The practical version: every case should be able to say which checks ran, which did not, and why not. Without that, a clean record and an incomplete one look identical.
Indian regulation now writes some of this down. Under the Ministry of Home Affairs SOP of 2 January 2026, a bank updates the status of each interim custody on NCRP-CFCFRMS with the indemnity bond and certificate of custody attached, and records its reasons whenever it cannot comply with a direction.
We automate the repetitive parts while preserving control, review, and auditability.
Closure rates do not survive this question
A closure percentage tells a reviewer that work left the queue. It does not tell them what happened to it.
On a CaseLEA deployment every case ends in one of seven named states: closed, partially handled, pending review, failed validation, freeze required, no records, or manual exception.
Those distinctions matter in a review. No records is a data access finding. Failed validation is a rules finding. Pending review is a resourcing finding. Collapsed into one not-closed bucket, all three read as the same problem and none gets fixed.
The four controls that have to be the bank's
A record is only defensible if the bank set the terms it was produced under.
On a CaseLEA deployment the bank retains the rules, the data sources, the exception categories and the approval thresholds. Read that list from a control perspective: what the system may conclude, what it may look at, how failures get classified, and when a human has to sign.
If a vendor defines your exception categories, your unresolved work is being classified by someone with an interest in how it looks.
What the deployment itself has to satisfy
Auditability is not only about the case file. It is about where the work happened.
CaseLEA deployments in India run RBI SAR compliant and SOC 2 certified in the Mumbai region on GCP or AWS. No transaction or user data is logged or stored on our server, data is accessed read-only, and it is deleted immediately after processing.
Those are the facts a technology risk reviewer will want in writing before they look at a single case.
The number, and why it is not perfect
Figures from one Indian banking deployment, 2026.
A figure in the high nineties, still rising, is an honest number for a live operation. Any vendor quoting perfection is quoting a target.
The useful follow-up is what sits in the remaining share, and whether those cases are identifiable rather than merely missing.
The test to run before anyone audits you
Take one closed case from last month and hand the file to a colleague who did not work it.
Ask them to write, in five sentences, what the bank did and why. If they have to ask anyone a question, the file failed - and an external reviewer will not ask, they will simply write it up.
Run it on five cases and you will know more about your audit exposure than a policy review will ever tell you.
Why records built after the fact never hold
The common failure is not an absent record. It is a record assembled later from things that happened earlier.
Somebody reconstructs a case for a review, pulling emails, screenshots and system exports into a folder. It looks complete. It cannot show what was checked at the time, only what can be found now, and those differ in exactly the cases a reviewer cares about.
A record has to be produced by the work rather than about it. That is an architectural property, not a documentation discipline, and no amount of effort after the fact substitutes for it.
The practical test is whether your record would look the same if it were generated a year from now. If it would look better, it is a reconstruction.
What a reviewer does with a sample
Understanding the method makes the preparation obvious.
A reviewer takes a small sample, often fewer than twenty cases, and traces each one against the stated procedure. Findings are written where the trace breaks, not where the outcome was wrong.
So a bank with good decisions and poor traceability fails, and a bank with an unremarkable decision and a complete record passes. That asymmetry frustrates operations teams and it is the rational design. The reviewer can assess a process they can see and cannot assess one they cannot.
Sources
- Patched data points, 2026: audit trail completeness and accuracy 98%+.
- CaseLEA operating documentation, 2026: seven case outcomes, six record elements, four bank-retained controls.
- CaseLEA deployment architecture documentation, 2026: RBI SAR and SOC 2, Mumbai region, read-only access.
- Ministry of Home Affairs, Standard Operating Procedure for NCRP-CFCFRMS, Custody, Restoration of Money and Grievance Redressal, 2 January 2026: status updates, indemnity bond, certificate of custody and recorded reasons for non-compliance.
