The Invisible Workload of Cybercrime Investigation

There is an incredibly ambitious initiative by i4c to centralize and streamline the world's largest cybercrime response program handling 6,200+ complaints worth INR 62+ crore (USD 6.5+ million) per day (going by the Home Ministry's 2024 figures). But to make it a reality, banks and FIs need operational excellence that is humanly impossible.

On its surface, the process is simple. When cybercrime fraud is reported, the complaint routes through i4c's National Cybercrime Reporting Portal (NCRP) and lands on the institution as a formal case: identify the relevant accounts and transactions, assemble the evidence, respond to law enforcement with the required details, take corrective action where needed, and do all of it against a 24-hour SLA. Follow-ups arrive from the portal, via a centralized API, from investigating officers over email, and from customers themselves.

There is no dedicated box on most financial institutions' org charts for this. So the work goes to the nearest teams that look qualified (fraud and risk operations, sometimes customer support and sometimes IT), teams designed and staffed for a different job. The result is familiar to anyone running one of those teams: a growing backlog, SLA risk, inconsistent response quality, and skilled analysts spending their days assembling evidence for law enforcement while the rest of their queue waits.

The standard diagnosis is a throughput problem: the team needs more people, or the people need to move faster. We think that diagnosis is wrong. The teams drowning in LEA cases aren't slow. They're the wrong shape for the work. And the interesting question (the one this post is about) is what the right shape looks like.

Requests arrive everywhere. Data lives everywhere else.

To see the mismatch, look at what a single case actually demands.

Intake. Complaints and follow-ups come through the NCRP portal, through API, and through email, from law enforcement agencies (LEAs) and from customers. Three channels, one case. A team handling this manually is watching a government portal, an inbox, and an internal queue at once. Where the API does not yet reach, the portal is a browser dashboard someone has to sit in.

Evidence. The information needed to answer a complaint is never in one place. Transaction records sit in one system; KYC (know-your-customer) documents in another; account details and logs in a third and fourth. An analyst working a case is collecting more than investigating: logging into systems, exporting records, cross-referencing details.

Response. What goes back is a formal answer to law enforcement with required details, and it carries actions with it: putting the reported amount on hold, suspending digital banking services on repeat-reported accounts, seizing accounts on lawful direction, escalating internally, each spelled out in i4c's Standard Operating Procedure for NCRP-CFCFRMS. Consequential actions, taken on real customers' accounts, under time pressure.

The record. Every step needs an audit trail (what was checked, what was sent, what was frozen, when, and by whom) because any case can be revisited later by an auditor, a regulator, or a court.

Now multiply by every case that arrived today. And the multiplier is compounding. Complaints registered on the NCRP have grown fivefold in three years, from 452,000 in 2021 to 2.27 million in 2024, per the Ministry of Home Affairs' December 2025 statement to Parliament. Reported losses have grown faster still, from INR 2,290 crore (USD 240 million) in 2022 to INR 22,845 crore (USD 2.4 billion) in 2024, a tenfold rise in two years. The queue more than doubled between 2022 and 2024. The teams working it did not.

Why this work stayed manual

On paper, LEA case handling is exactly what automation is for: high-volume, repetitive, deadline-bound. So it's worth being precise about why it stayed manual.

It sits in the worst spot for classic RPA (robotic process automation). Rule-based automation needs structured data and stable interfaces, and LEA cases offer neither.

A scripted bot that expects the same field in the same place breaks the first time a complaint is phrased differently.

Hiring doesn't solve it either, at least not durably. Headcount scales linearly with volume at best, and the people best at this work are exactly the experienced fraud and risk analysts a bank least wants spending their days exporting records. The work converts scarce judgment into abundant clerical effort.

It's also a poor fit for free-form AI. We've written before about why autonomous agents fail in regulated workflows: errors compound silently, and "the model decided" is not an explanation regulators accept. This is a workflow whose outputs go to law enforcement and whose actions include blocking a customer's account. There is no version of this work where silent failure is acceptable.

So institutions chose the third option: keep humans on every case. It was the responsible choice. It's also how a structural mismatch ends up on a dashboard, disguised as a productivity problem.

The structured version

The alternative isn't autonomy. It's structure: the same discrete-steps-with-checkpoints architecture we've argued for before, applied to this workflow.

Incoming complaint (NCRP portal / API / email)
          ↓
        [Ingest] capture complaints and follow-ups across all channels
          ↓
        [Process] retrieve and validate: transactions, KYC documents,
                  account records, internal systems
          ↓ (incomplete or ambiguous → human review)
        [Respond] compliant response with required details; corrective
                  actions such as freeze/blocking; escalate edge cases
          ↓
        [Track] audit trail, case status, reporting, intake through closure

Validation is the step that separates this from drafting assistance. Extracted details are checked against internal records before anything is written. A response built on validated data can be defended line by line; one built on a model's reading of an email has to be re-verified by a human, which quietly puts the manual work back.

And the uncertain path is designed in. When a case is incomplete, ambiguous, or unusual, it routes to human review with the data already gathered and the reasoning logged. The workflow automates the obvious cases and concentrates people on the ones that need them. That is the difference between automation a bank can defend to a regulator and automation it has to explain away.

Deployment is the other half of the design. The workflow runs in a dedicated VPC (virtual private cloud) or on the bank's own premises, built in accordance with RBI guidelines, with role-based access and complete logging. It sits on top of the case management systems, databases, and approval processes already in place.

What the numbers look like

Turnaround is the headline number, but the second-order effect is the one risk teams notice first. "False positives dropped while escalation quality improved, which is exactly what risk teams need," as one fraud and risk lead put it. When evidence assembly is automated and consistent, the cases that reach humans are precisely the ones that deserve humans.

Speed here is not an efficiency metric; it is the control itself. The government's own numbers show why: the national financial fraud reporting system (CFCFRMS) reports more than INR 7,130 crore (USD 750 million) saved across 2.3 million complaints, and the Suspect Registry has flagged 2.47 million mule accounts, with declined transactions worth INR 8,031 crore (USD 845 million), per the same parliamentary answer. Money that is not held within hours is money that is gone. Every one of those crores was saved or lost inside a bank ops queue.

The honest summary

What structure doesn't fix is worth stating plainly. Edge cases still need people, by design; a workflow that claimed to resolve every case without review would be a red flag, not a feature. Accountability doesn't transfer either; the institution owns every response, which is exactly why every action has to be traceable. And the upstream problem is untouched: structure changes how fast and how consistently complaints are handled, not how many arrive.

In fact, the workload is set to grow. API integration covered 62 banks as of December 2025, and the government plans to onboard every bank and financial institution, including cooperative banks, by the end of 2026, per the Home Ministry's February 2026 announcement. The e-Zero FIR mechanism now converts high-value complaints into First Information Reports (FIRs) automatically. The new Money Restoration Module lets victims apply online for refunds of amounts put on hold, requests that banks will have to verify and act on. And the grievance redressal mechanism gives account holders a formal, time-bound path to contest holds and suspensions, another queue landing on the same teams. Each of these is good policy. Each is also more work for a function that most institutions have still not made anyone's explicit job.

Patched builds structured workflow AI for regulated operations. CaseLEA is that system, built for LEA case handling: complaints across portal, API, and email, handled end-to-end. If your team is working an NCRP queue and wants to compare notes, we're easy to find.