1 November 2026 • 5 min read
On 25 September 2025 the Reserve Bank of India issued the Reserve Bank of India (Authentication Mechanisms for Digital Payment Transactions) Directions, 2025. The press release sets one deadline for the whole framework: the directions "shall be complied with by April 01, 2026, unless indicated otherwise for any particular direction."
The core rule is short. Every domestic digital payment must be authenticated by at least two distinct factors. A factor can be "something the user has", "something the user knows" or "something the user is". For example, a card plus a PIN pairs a "has" factor with a "knows" factor. Two factors of the same kind do not meet the word "distinct".
For payments where the card is not present, at least one of the two factors must be dynamically created or proven. In plain words: a fixed password alone does not meet it. The proof must change with each transaction, as an OTP or a device signature does.
The directions apply to "all domestic digital payment transactions, unless specifically exempted otherwise." Cross-border payments are outside the main framework, with one exception covered in section 4.
Many teams read the news as "RBI is killing SMS OTP". That is not what the text says. The press release states that the framework "does not call for discontinuation of SMS based OTP as an authentication factor." RBI's Payment System Report (half-year to December 2025, published May 2026) repeats that the directions continue to treat SMS-based one-time passwords as a valid factor.
What RBI does is encourage newer factors. The same report says the directions encourage "new, technology-driven authentication factors, including biometrics and device-based credentials". The press release adds that issuers may go beyond the minimum: they can apply additional risk-based checks "based on the fraud risk perception of the underlying transaction."
So the practical change is not a ban. It is a floor (two distinct factors on every domestic transaction), a dynamic-factor rule for card-not-present payments, and permission to add checks when a transaction looks risky.
The directions spell out the issuer's duty. The notification says "An issuer shall ensure the robustness and integrity of the authentication mechanism before deployment." It also says that if a loss arises from transactions effected without complying with the directions, "the issuer shall compensate the customer for the loss in full without demur."
If you are a fintech app and not the issuer, read this as a contract question. Your bank or card partner carries the compensation risk, so expect them to ask you for proof that your checkout flow meets the rule. The same notification also requires system providers and participants to "offer authentication or tokenisation service that is accessible to all" applications and token requestors, which is RBI's interoperability point.
Issuers may also "offer a choice of authentication factors to their customers" at their discretion. That is the opening for a product team: the second factor can be the one your users already tolerate, such as the phone's biometric, instead of a code typed from an SMS.
Annexure 1 of the notification lists exemptions that were already in force. They include:
| Exempted case | As listed by RBI |
|---|---|
| Small-value contactless cards | "Small-value Contactless Card transactions" |
| Recurring e-mandates | "Recurring transactions (other than the first) under the e-mandate framework" |
| Some prepaid instruments | "Select Prepaid Instruments such as PPI-MTS and Gift PPIs" |
| Toll | "NETC transactions" |
| Offline small payments | "Small value digital payments in offline mode" |
| UPI tap and pay | "Tap and Pay UPI Payment on Near Field Communication enabled Point of Sale machines" |
Note the first-payment wording for e-mandates. The exemption covers recurring transactions other than the first, so the first debit still needs full authentication. That affects subscription and autopay flows directly.
For cross-border card-not-present payments there is a separate, later date. Card issuers must, by 1 October 2026, put in place a mechanism to validate an additional factor of authentication when the overseas merchant or acquirer asks for it. The press release describes this as validating the additional factor "whenever such a request is raised by the overseas merchant or acquirer."
Run this with your engineering and your partner bank. It is a working list, not legal advice.
Authentication changes show up in payment success and drop-off, not in a dashboard called compliance. Track checkout completion by authentication method, time between payment start and approval, and failures by reason code. If you add a biometric option, compare it with SMS OTP on the same user groups before you make it the default. Use the payment success rate for your own traffic, not an industry average, as the baseline.
No. RBI's press release says the framework does not call for discontinuation of SMS based OTP as an authentication factor. It only requires two distinct factors and encourages newer ones.
They cover all domestic digital payment transactions unless exempted. The only UPI case on the exemption list is tap and pay on NFC-enabled point-of-sale machines.
The issuer. The notification says the issuer shall compensate the customer for the loss in full without demur when the loss arises from transactions effected without complying with the directions.
Not under the main framework. Card issuers do have a separate duty from 1 October 2026 to validate an additional factor for cross-border card-not-present payments when the overseas merchant or acquirer requests it.
This page explains public RBI documents. Check with a compliance professional or your issuer before you change a live payment flow.
Nine stories, every morning at 09:15 IST.
Get the brief free →