Real-time NCRP API integration: what the RBI's December 2025 advisory changes for a bank's case queue

What the advisory asks for, and why now

The advisory, dated 5 December 2025 and titled Onboarding on NCRP-CFCFRMS and API Integration thereof, asked banks to complete both. It followed years of banks acting on complaints through the portal, where every notification waited for someone to collect it.

The case for speed is on the government's own numbers. The Suspect Registry that I4C launched with banks on 10 September 2024 had, by 30 June 2026, shared 32.08 lakh Layer 1 mule accounts with participating institutions and declined transactions worth ₹25,698 crore. Stopping money is a race measured in minutes, and an API is how a bank runs it.

What a real-time channel actually removes

The obvious gain is latency. A case that arrives as a batch file sits until somebody collects it, and that waiting is pure loss.

A real-time channel removes that. It also removes format drift, because a structured intake is consistent in a way an exported file rarely is.

In one deployment, straightforward cases arriving this way are handled in real time. That is a genuine improvement and it is worth having.

What it does not remove is the evidence problem. A case arriving instantly still needs transaction history, account status and KYC records pulled from systems that were not part of the intake.

Two channels, and both stay

Treating the API channel as a replacement for portal work is tempting. The volumes say otherwise.

The API row is the largest single scenario in a queue of 16,736 cases, at 9.9% of everything. It is also not the only row.

An analyst still checks all three places, because there is no way to know in advance which one holds the answer to a given case.

Why the complex cases do not follow

Complaint handling splits cleanly. Straightforward cases can run in real time. Complex fresh cases, along with reassign and response-received cases, cannot.

Those are the cases carrying a correction, a mismatch or something incomplete. The work is validation before action: check the case against the available evidence, then decide whether to correct, confirm, hold or escalate.

Speeding up intake on that band changes nothing, because intake was never where the time went.

In one deployment, reassign cases accounted for 13k+ of the 32k+ complaints closed. Nearly half the work sits in the band a faster channel does not help.

What a faster channel changes about risk

There is a control point worth naming. When cases arrive in batches, there is natural slack between arrival and action, and that slack has been quietly acting as a review window.

Remove it and the approval model has to be explicit instead of accidental. Which scenarios may run end to end, who approved that scope, and what happens when confidence is low.

The honest answer is narrow and set by the bank. On a CaseLEA deployment the bank retains the rules, the data sources, the exception categories and the approval thresholds - and real-time intake does not change any of those.

What to measure on each channel separately

• Resolution rate by channel. A blended figure will be carried by the straightforward real-time cases.
• Time to outcome, not time to acknowledgement. Fast intake with a slow resolution is a worse experience, not a better one.
• Exception rate on each channel. If the API channel produces fewer exceptions, it is handling easier work rather than handling work better.
• Evidence retrieval time. This should be identical on both channels, because it is the same five systems.

The number that tells you it worked

Production outcomes at a leading Indian payments bank. Source: caselea.com, 2026.

A real-time channel improves the first column. Only handling all three bands to one operating standard improves the total, and the total is what the backlog is made of.

So the question to ask about any intake project is not how fast cases arrive. It is whether the resolution rate holds when they do.

What an integration project should include

The channel is the easy part. The work sits in what surrounds it, and a scope that covers only the connection will disappoint.

• Evidence sources. The case arrives in seconds and still needs transaction history, account status and KYC records.
• Exception routing. A case that cannot be handled needs a categorised reason and a named destination.
• Reconciliation with the other channels. Instructions still arrive on the portal and in email threads.
• Approval thresholds. Faster arrival narrows the window in which a person would have intervened by default.
• The record. Inputs, checks, decisions, timestamps, outputs and exception reasons, regardless of channel.

A project that delivers the first item and none of the rest has moved the arrival time and nothing else.

Why the portal work will not disappear

Banks are tempted to plan for a future where everything arrives over the API and the portal becomes a legacy channel.

The volumes argue against it. In one operation, instructions were found on the portal in 302 cases and inside older email threads in 307, against 1,660 matched through the API. Those are not rounding errors, and an analyst still checks all three.

Plan for both channels permanently. A design that treats the portal as temporary will quietly leave a fifth of the work unhandled, and it is the harder fifth.