The RBI recently released a whitepaper for public consultation on tackling digital payment fraud. The paper presents pre and post-transaction strategies for P2P fraud prevention that safeguard against Authorised Push Payment (APP) frauds i.e. frauds where the victim consensually transfers money to the fraudster. In this blog, we focus on one particular strategy: lagged credit for authorised push payments.

Context: Two Key Trends

Authorised Push Payment (APP) Fraud is the largest category of fraud.

Relying on emotional and psychological exploits, these frauds can bypass traditional fraud detection tools designed to detect suspicious login attempts and prevent unauthorized access through identity theft attempts including phishing, smishing, etc. Our study in collaboration with Aapti Institute, based on analysis of 298 I4C (Indian Cybercrime Coordination Centre) helpline complaints, found that UPI-related APP frauds (impersonation, investment frauds, etc.) accounted for the highest share among all fraud categories examined i.e. 109 of 298 complaints.

Fraud is now seen as an infrastructure problem, not just a customer awareness problem.

Frauds are no longer seen as an issue to be dealt with only through customer awareness and preventing unauthorised use of accounts, but through stronger preventive blocks in the payments infrastructure itself. Highlighting the slowness of recourse, our study found that out of the total 298 complaints received, only 3% resulted in FIRs and only 8% of the amounts were frozen or marked as de-frauded amounts.

Account Credit Lag: A Way to Reevaluate Payment Decisions?

The paper presents the idea of a mandatory lagged credit. Imagine sending a new contact INR 12,000 or any amount over INR 10,000  via UPI. Once this transaction is initiated, the credit to the payee is lagged for an hour, during which you can cancel it at any point. Below we outline what works about this idea, what doesn’t, and what might be a better alternative.

What RBI Is Proposing

What Is Proposed?

A mandatory 1-hour lag is applied to all APP transactions above INR 10,000. The payer’s account is provisionally debited, but the transfer does not settle for one hour. The payer can cancel for any reason during this window.

Who Will Implement It?

The payer’s bank applies and manages the lag. The payee’s bank receives the deferred credit. Payment Service Providers (PSPs) operating on UPI, IMPS, and NEFT rails are also involved in the implementation.

How Will It Be Implemented?

A transaction queuing system is built across all bank core banking systems and PSO infrastructure. The payer’s bank holds the debit in a provisional state. After one hour, if not cancelled, the transaction settles. Payers can whitelist specific payees or transactions to bypass the lag.

Why Is It Being Proposed?

APP fraud exploits the instantaneous nature of digital payments. Fraudsters maintain psychological pressure on victims until funds move. A mandatory pause disrupts this by giving victims a window of calm deliberation, breaking the urgency exploit. The rationale for targeting transactions above INR 10,000 comes from them accounting for 45% of fraud cases by volume and 98% by value.

How Will It Work in Practice?

The lag is applied uniformly to all APP transactions above INR 10,000. The payer’s bank monitors queued transactions and may seek reconfirmation if the transaction appears suspicious. The payer retains a cancel option throughout the lag window.

Exceptions

The following are exempt from the mandatory lag: all merchant transactions (UPI, cards, net banking); recurring payments such as e-mandates and NACH; cheque-based payments; and payees whitelisted by the payer.

Our Alternative Proposal: Risk-Triggered Lagged Credit

What Are We Proposing?

A risk-triggered lag applied only when a combination of fraud signals is detected on the beneficiary’s account, not a flat, amount-linked mandatory pause on every transaction. Instant payments remain the default. The lag is the exception, not the rule. The lag should be triggered only when risk signals are present on the beneficiary’s account.

Why Are We Proposing This?

A mandatory lag will create friction in payments that can otherwise be strategically placed, where instant settlement is compromised only in specialised cases. Further, a lag linked to a fixed amount can be bypassed easily with reduced incremental frauds to achieve the same net fraud value.

Secondly, realising the potential of shared intelligence, RBIH’s Digital Payments Intelligence Platform (DPIP) provides a much better use case for flagging risk once it is developed and operational. There is useful information from PSPs, gateways, banks, and shared intelligence on the beneficiary that can be leveraged. Signals from the beneficiary’s bank provide the key insight on flagging risk that can help a payer re-examine their decision to pay. This will be key in preventing digital arrests and other types of APP frauds where additional time given to the payer might be enough to prevent fraud.

How Will It Be Implemented?

Powered by Digital Payment Intelligence Platform (DPIP)

The Digital Payment Intelligence Platform (DPIP), being built by RBIH, is the central infrastructure that makes this proposal viable. The DPIP’s stated role is: “To a remitting bank, the platform is envisaged to provide information about the beneficiary’s profile through a risk score generated on a real-time, transaction-by-transaction basis, even before the transaction is executed.”

While the DPIP is still being developed, it could potentially gather intelligence from law enforcement (I4C), banks, all types of payment service providers, and telecoms to create a shared intelligence layer. This layer can then be used to generate a score for the beneficiary’s account, aggregating risk signals and returning a real-time beneficiary risk score to the payer’s bank i.e. transaction by transaction, before execution. The lag is only triggered when this score crosses a defined threshold.

Two-Step Function

We propose two steps in which this will function: First, the beneficiary’s bank generates a riskiness score based on PSP, Tech Service Providers (TSP), and its own intelligence. Second, this score is shared confidentially with the payer’s bank, which then decides whether to apply the lag.

Risk Signals That Trigger the Lag (Not Exhaustive)

Account-level signals: Aadhaar and PAN flagged; other documentation flags.

Device and geographical signals: Net banking app switched on multiple new devices; phone number registered and switched on multiple devices; PSP apps (PhonePe, GPay) switched to multiple devices across geographies (shared by PSP).

Behavioural signals: Low digital savviness of the beneficiary (low frequency of transactions or logins); repeated changes in critical account details; irregular credits into the account and instant disbursals; other tags as determined necessary by banks.

Who Will Implement It?

The beneficiary’s bank collects the score from the DPIP and augments it based on its assessment of the beneficiary. The payer’s bank receives the score and applies the lag. PSPs (PhonePe, GPay, etc.) share device and behavioural signals. TSPs contribute transaction intelligence. The TRAI Digital Intelligence

Platform contributes telecom-layer signals. RBIH operates and maintains the DPIP.

Exceptions

The following are exempt: all merchant transactions (UPI, cards, net banking); recurring payments such as e-mandates and NACH; cheque-based payments; and repeat transactions to the same payee with no new risk flags. 

Note: We do not recommend a whitelisting mechanism, each beneficiary should be assessed per transaction.

How Will It Work in Practice?

Imagine a fraudster posing as a law enforcement officer convincing a victim to transfer money. The beneficiary’s bank notices multiple logins across devices, large unusual deposits, and rapid outward transfers. It generates a low score and shares it via DPIP with the payer’s bank. The payer’s bank lags the transaction, giving the victim time to reconsider. The same intelligence flags the beneficiary account for further investigation as a potential mule account.

 
 
Published June 2026. Authored by Rohan Atrawalkar.