The role of authentication in Indian banking has shifted: it is now a material balance-sheet risk.
New regulatory changes by the Reserve Bank of India (RBI) have made it central to both regulatory compliance and fraud liability.
Stronger authentication requirements are already in force, set by the Authentication Directions.
However, starting in January 2027, a broader fraud-liability framework will place those requirements inside a wider system of bank negligence and customer compensation.
That changes the authentication ROI.
Two RBI Rules, One Growing Exposure
Responsible Business Conduct Third Amendment Directions, 2026
On June 24, 2026, RBI issued parallel Third Amendment Directions updating the rules on customer protection in fraudulent electronic banking transactions. The new framework applies to transactions undertaken on or after January 1, 2027.
It identifies several circumstances that can constitute negligence by a bank, including:
-
Failure to implement mandated systems and procedures for secure electronic banking transactions
-
Failure to send mandatory transaction alerts
-
Failure to provide 24/7 channels for reporting fraud or a lost payment card
-
Failure to act promptly after receiving a customer notification
-
System malfunctions, security breaches or internal fraud that result in unauthorised transactions
When a fraudulent transaction happens because of negligence or deficiency on the part of the bank, the customer has zero liability and the transaction must be reversed in full, whether or not the customer reported it.
The burden of proving customer liability also lies with the bank. Each complaint must be examined and classified, with a response issued within 45 calendar days for domestic transactions or 60 calendar days for cross-border transactions.
The framework also gives customers zero liability in cases of third-party breach when the transaction is reported within five calendar days. If the customer reports it later, liability is determined under the specific bank’s policy.
And in cases where customer negligence is determined, there is also a limited compensation mechanism for certain small-value fraud cases. Victims who lose up to ₹50,000 can receive 85% of the net loss or ₹25,000, whichever is lower, provided the transaction is reported to both the bank and the National Cyber Crime Reporting Portal or helpline within five calendar days. This compensation can only be claimed once in the customer’s lifetime and applies to losses occurring during the first year of the framework.
Crucially, the amendment makes a direct connection between fraud liability and the authentication requirements banks are already expected to meet.
RBI Authentication Mechanisms for Digital Payment Transactions Directions, 2025
The Third Amendment Directions explicitly name the RBI Authentication Mechanisms for Digital Payment Transactions Directions, 2025 among the security requirements banks must have in place.
In effect since April 1, 2026, the Authentication Directions require domestic digital payments to use at least two distinct authentication factors. For non-card-present payments, at least one factor must be dynamically created or proven, specifically for that transaction rather than relying on a static credential that could be reused.
If a customer suffers a loss from a transaction completed without compliant authentication, the issuer must compensate the customer in full.
Building on that, the new amendment now places the authentication requirement inside a broader framework for bank negligence, customer compensation and fraud liability.
Authentication Is Now a Balance-Sheet Decision
Banks have traditionally looked at authentication through a mix of security and product metrics.
Does adding another step help reduce fraud? Slow down the transaction? Affect the conversion rates or increase abandonment? Does it generate more support requests?
Those questions still matter, but we now have to look at authentication through a wider lens, beyond the security roadmap.
When authentication falls short, the impact can extend to significant financial losses and compensation, regulatory exposure, and then the cost of strengthening security after the damage has already been done.
The question is no longer only whether a method is secure or easy to use. It is also whether the approach is compliant with RBI requirements and capable of reducing potential liability.
What a Liability-Grade Authentication Stack Looks Like
A liability-grade authentication stack needs to do more than add another verification step. It also needs to combine compliant authentication and real-time fraud prevention intelligence.
This is where IPification fits. Using trusted mobile-network signals, IPification can provide the dynamic possession factor required for non-card-present payments.
The authentication can happen in the background, without asking the customer to copy a code, wait for an SMS or leave the transaction flow. This allows banks to meet the authentication requirement without adding unnecessary friction or relying on SMS OTPs, which remain vulnerable to delays, delivery failures and interception.
But authentication alone does not provide the full picture.
A customer may successfully prove possession of a phone number while the context around the transaction still shows signs of fraud. A recently changed SIM, for example, may indicate an attempted SIM-swap attack. A transaction coming from an unrecognised device may suggest that someone other than the legitimate customer is trying to complete it.
This is where IPification’s #PROTECT capabilities come in.
Signals such as SIM Swap and Device ID give banks real-time information about what is happening around the authentication. Banks can use those signals within their existing fraud prevention systems to decide whether a transaction should continue normally or require further verification or review.
IPification enables banks to meet RBI’s authentication requirements while gaining additional context that can help identify suspicious activity before a payment transaction is completed.
January 1, 2027 isn’t far off so banks should determine:
1. Is compliant dynamic authentication in place across the relevant payment journeys?
2. Are changes in the customer’s context, like SIM or device info, visible to fraud systems before the transaction is completed?
3. And can higher-risk activity trigger additional checks without adding friction to every customer?
Any deficiencies in authentication, fraud intelligence, and response can become a liability gap.
To discuss what a liability-grade authentication stack could look like for your institution, get in touch with our team.
