The question at hand
Your fraud team faces a familiar challenge: customers want instant payments, but authorized push payment (APP) fraud is on the rise. The Reserve Bank of India's proposal to introduce a one-hour hold on peer-to-peer transactions over 10,000 rupees raises a critical question: does slowing down payments actually stop fraud, or does it just frustrate legitimate users while attackers adapt?
The stakes are high. UPI now processes more than four out of five real-time transactions worldwide, and APP fraud losses in India have surged between 2021 and 2025. When a payment system reaches this scale, any friction affects millions of transactions daily. Yet, ignoring rising fraud losses isn't an option.
The case for transaction delays
Delays can disrupt an attacker's timeline. APP fraud often relies on creating urgency, with scammers impersonating bank officials or family members to pressure victims into quick transfers. A mandatory hold breaks this rhythm. Suzanne Sando, Lead Analyst of Fraud Management at Javelin Strategy & Research, notes that delays give banks time to investigate transactions and allow consumers a moment to reconsider.
Operationally, a one-hour window lets your team perform enhanced checks on flagged transactions without halting the entire payment flow. You can verify the customer through secure channels, check the recipient against known mule accounts, or apply behavioral analytics that aren't feasible in real-time. This converts a binary decision into a more nuanced response.
Delays also provide an opportunity for additional authentication. The RBI proposal includes verification through a trusted contact for transactions over 50,000 rupees. This is easier to implement during a hold period than in an instant payment flow.
The case for keeping payments instant
Instant payments are now the standard, not a luxury. Delaying them has consequences. High-value P2P transfers are common, including rent payments, medical expenses, and business transactions. A one-hour hold on a 10,000-rupee threshold affects routine transactions in many markets.
Delays don't eliminate social engineering; they shift it. Attackers can coach victims to expect delays and maintain contact during the hold. Sophisticated APP fraud operations already use multi-day grooming periods. Adding an hour doesn't change their approach.
Operationally, delays create uneven burdens. Large institutions can manage the monitoring and investigation workflows required, but smaller banks can't. This leads to inconsistent fraud prevention or disadvantages smaller players who can't afford the overhead.
There's also a substitution risk. If high-value transfers become inconvenient, users might split transactions to avoid thresholds, use alternative rails, or turn to informal systems. This doesn't reduce fraud; it pushes it into less visible channels.
Where practitioners actually land
Most fraud teams don't choose between instant payments and blanket delays. They use risk-based holds that apply friction selectively.
JPMorgan Chase's approach on the Zelle network illustrates this: they cancel payments flagged as high risk, especially those tied to suspected scams on social media. This isn't a universal delay; it's targeted intervention based on specific risk signals.
Effective strategies combine behavioral analytics with conditional friction. Most transactions process instantly, but a hold triggers when multiple risk factors align: first-time recipient, unusual transfer amount, device or location anomalies, velocity patterns, or flagged recipient accounts.
During the hold, you're not just waiting. You're running deeper checks, contacting the customer through verified channels, and possibly requiring step-up authentication. The delay isn't the control; it's the window that lets other controls operate.
Biometric authentication and trusted contact verification work better as part of a dynamic response framework rather than blanket requirements. Apply them when risk scores cross thresholds, not on every transaction.
Our take
A mandatory one-hour delay on all P2P transactions above a fixed threshold is the wrong tool. It applies maximum friction to legitimate high-value users who transact frequently and have clean histories.
But dismissing delays entirely misses the point. Fraud prevention in real-time payment environments requires the ability to slow down specific transactions when risk signals warrant it. The question isn't whether to delay; it's which transactions to delay and what you do during that window.
Build your fraud prevention architecture to support variable holds based on transaction risk scoring. Invest in behavioral analytics and entity resolution capabilities to distinguish between a customer paying their landlord for the tenth consecutive month and a customer sending money to a newly created account after an unsolicited call.
If you're going to implement delays, make them meaningful. A hold without investigation is just an annoyance. Use the time to run checks you can't complete in real-time, contact the customer through verified channels, and apply enhanced authentication when justified. Measure both sides: track fraud prevented during holds, but also track legitimate transactions delayed and customer complaints.
The RBI proposal addresses a real problem. APP fraud is climbing, and instant payment rails facilitate certain attack patterns. But the solution isn't to make all payments slower. It's to make your fraud detection smart enough to know when speed is the risk.
