EASE 9.0 · Risk & Resilience · Cybersecurity & Fraud Resilience

Fewer Frauds, Bigger Ones

Real-time fraud detection and response, backed by an auditable decision trail.
Acting inside the transaction window, not after it closes.

A fraudulent transaction has a window of a few seconds before settlement makes it nearly impossible to reverse. Traditional fraud systems run rule-based checks in batch, hours after the transaction clears, and flag suspicious activity for a human analyst to review the next business day. By then, the money has moved.

Why Batch-Based Fraud Detection Fails

Fraud patterns change faster than quarterly rule updates can track. A ring of coordinated mule accounts can move funds through a dozen intermediary accounts within minutes, long before an overnight batch job would even see the pattern. Every hour of detection lag is an hour a bank's fraud-loss provision grows.

The Path to Progress

The Scale of the Problem, in RBI's Own Numbers

The numbers make the case on their own. RBI's own data shows overall bank fraud cases nearly halved in FY2025–26 to just over 10,000, even as the value involved climbed to a three-year high of roughly ₹48,021 crore; public-sector banks alone accounted for ₹35,709 crore of that figure. Fewer, larger, faster frauds is exactly the shift real-time, network-aware detection has to answer. A rule-based system tuned to catch many small frauds is not automatically tuned to catch fewer, larger, faster ones.

RBI has not left this to individual banks alone. The Reserve Bank Innovation Hub built MuleHunter.AI, an AI/ML model trained on nineteen distinct patterns of mule-account behaviour, specifically to catch the coordinated mule-account networks that move stolen funds through a chain of intermediary accounts within minutes, the exact pattern this page's walkthrough describes. It was piloted with two public-sector banks before wider rollout, which makes it a directly relevant precedent for this guide's audience, not a private-sector-only capability.

Sources: RBI fraud data as reported by Business Standard, “Bank fraud cases halve but value climbs to ₹48,000 crore” (2026); IndiaAI/Reserve Bank Innovation Hub coverage of MuleHunter.AI.

The Business Case

Fraud-loss avoidance is inherently counterfactual: a bank cannot cite a clean, defensible rupee figure for fraud that did not happen, and a number invented for that purpose would not survive scrutiny. The business case here is operational: real-time, multi-signal scoring lets a bank narrow in on anomalous behaviour instead of triggering on any single rule breach, which is what actually reduces both fraud losses and the customer friction of blocking legitimate transactions, a cost banks feel directly in complaint volumes and account attrition.

Catching fraud is the easy half of real-time detection. Not blocking legitimate transactions in the process is the hard one.

Where AI Agents Fit

The same Sense-Decide-Act pattern behind this guide's other named agents applies naturally to fraud. A fraud detection agent built on it would run real-time anomaly detection, score a transaction against behavioural and network signals in under 200 milliseconds, and apply policy-aware blocking, holding or releasing the transaction itself rather than merely flagging it for a human to review later. A customer would never see this agent directly. What they would experience is the outcome: a legitimate transaction that clears without friction, or a fraudulent one stopped before it settles. Getting that scoring right is what would keep the experience invisible in the best sense.

Walk through how the mule-account pattern from the opening of this page would play out. Such an agent would perceive a first-time high-value transfer landing seconds after a fresh account opening, then a second transfer out to an unrelated account within the same minute: a network shape, not a single suspicious number, that a rule keyed to transaction size alone would miss entirely. It would decide against policy that this sequence exceeds the bank's tolerance for velocity-plus-freshness risk, and act by holding the outbound transfer and routing a step-up verification to the customer, all inside the settlement window rather than in a report someone reads the next morning. It would release the hold the moment verification clears, or escalate to a human fraud analyst if it does not, keeping a human in the loop at the point where judgment is actually needed rather than at every transaction.

The Skeptic's Answer

A system that can hold a transaction and demand step-up verification within 200 milliseconds is also a system that can wrongly hold a legitimate one, and a wave of false declines on genuine transactions does exactly the reputational damage this page is trying to prevent, just from the opposite direction. A rules-based system that catches less fraud but annoys fewer real customers can look, to a risk committee, like the safer choice.

That comfort misdiagnoses where false positives actually come from. A single-rule trigger (transaction size alone) is what produces most of them, because it cannot distinguish a large legitimate purchase from a large fraudulent transfer. Network- and behaviour-based scoring, the same approach behind RBI's own MuleHunter.AI, looks at the pattern (velocity, freshness, relationship to other flagged accounts) rather than a single number, which is precisely what lets it hold fewer legitimate transactions while catching more coordinated fraud. And such an agent would still escalate to a human the moment its own confidence drops, rather than blocking unilaterally on a borderline case.

Fraud Defence Inside the Bank's Own Perimeter

Fraud detection is one of the most commonly outsourced functions in banking, with a bank's transaction data flowing through third-party fraud-scoring infrastructure it does not control. A fraud detection agent following the architecture pattern in this guide would run the other way: data and decisioning logic stay inside the bank's own perimeter, on the same sovereign-infrastructure model Appice's other agents already use. When a new fraud pattern emerges, that puts the update in the bank's own team's hands directly, in hours, rather than on a vendor's scheduled model refresh.