RBI two-factor authentication: the 1 October 2026 cross-border CNP deadline and how to retrofit an existing app
Summary. The Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025 were issued on 25 September 2025 under circular RBI/2025-26/79, and every Payment System Provider and Participant had to comply by 1 April 2026. One deadline is still open: by 1 October 2026, card issuers must have a mechanism to validate non-recurring cross-border card-not-present transactions where authentication is requested by an overseas merchant or acquirer, plus a risk-based mechanism for all cross-border CNP transactions, and they must register their BINs with the card networks. That is 57 days from 5 August 2026. The Directions repeal 8 older circulars, including the December 2016 relaxation that waived the additional factor for CNP payments up to ₹2,000. They also set a liability rule with no wriggle room: an issuer must compensate the customer in full for any loss arising from a transaction effected without complying. This is what a retrofit into a live payments or lending app actually involves.
What the Directions actually require
The Directions are short, and three principles in paragraph 6 carry almost all of the engineering weight. The Department of Payment and Settlement Systems states them as follows.
Minimum two factors. "All digital payment transactions shall be authenticated by at least two distinct factors of authentication as defined in paragraph-5(f), unless exempted."
At least one factor must be dynamic. "It shall be ensured that for digital payment transactions, other than card present transactions, at least one of the factors of authentication is dynamically created or proven, i.e., the proof of possession of the factor, being sent as part of the transaction, is unique to that transaction."
Robustness. "The factor of authentication shall be such that compromise of one factor does not affect reliability of the other."
Paragraph 5(f) defines a factor as a credential drawn from "something the user has", "something the user knows" or "something the user is", and lists password, SMS-based OTP, passphrase, PIN, card hardware, software token, fingerprint, or any other form of biometrics, device native or Aadhaar based.
Read those three together and the substance becomes clear. SMS OTP is not mandated. It is one permitted option among several, and the regulator's stated purpose in the introduction is to let the ecosystem "use the technological advancements for implementing alternative authentication mechanisms" rather than defaulting to SMS. The Directions were issued under Section 18 read with Section 10(2) of the Payment and Settlement Systems Act, 2007.
The two dates, and which one is still open
| Date | Obligation | Who it binds |
|---|---|---|
| 25 September 2025 | Directions issued as RBI/2025-26/79 | Reference date for the framework |
| 1 April 2026 | Compliance with the Directions generally | All Payment System Providers and Participants, banks and non-banks |
| 1 October 2026 | Mechanism to validate non-recurring cross-border CNP transactions where an overseas merchant or acquirer requests authentication | Card issuers |
| 1 October 2026 | Risk-based mechanism for all cross-border CNP transactions | Card issuers |
| 1 October 2026 | BIN registration with card networks | Card issuers |
The general framework does not apply to cross-border transactions. The Directions carve them out and then impose a separate obligation on card issuers with a later date, which is the one still ahead. If you issue cards in India and your customers transact with overseas merchants, this is a live piece of work, and BIN registration involves a third party whose timelines you do not control. Start with the registration, not the code.
What "dynamic" means once you have to build it
The phrase that decides most architecture arguments is "dynamically created or proven ... unique to that transaction". A static PIN checked against a stored hash is a valid factor, but it cannot be the dynamic one. The dynamic factor has to bind to the specific payment instruction.
That rules out a surprising amount of existing production code. A one-time password generated per session rather than per transaction does not satisfy it. A biometric check that returns a plain boolean from the device to your server, with no transaction-bound signature, does not prove possession for that transaction.
| Factor option | Category under 5(f) | Can it serve as the dynamic factor? | Practical notes |
|---|---|---|---|
| SMS OTP, generated per transaction | Something the user has | Yes | Delivery latency and SIM-swap risk are yours to manage, and it is the mechanism the Directions were written to move beyond |
| Software token, TOTP or push-approve with transaction detail | Something the user has | Yes, if the approval is bound to the transaction | Removes SMS dependency; needs secure key provisioning and device binding |
| Device-native biometrics with a hardware-backed key | Something the user is, proving something the user has | Yes, if the device signs transaction-specific data | The signature over the payment details is what makes it transaction-unique, not the fingerprint match |
| Aadhaar-based biometrics | Something the user is | Yes | Adds a separate consent and data-handling design under DPDP |
| Static PIN or password | Something the user knows | No | Valid as the second factor only |
| Card hardware at a physical terminal | Something the user has | Not required to be dynamic | Card-present transactions are excluded from the dynamic-factor rule |
The robustness principle is the one teams skip. If your PIN reset flow is completed with an SMS OTP, and your dynamic factor is that same SMS OTP, then a compromise of the customer's SIM defeats both factors. The two factors have to fail independently. Auditing recovery and reset paths, not just the happy path, is where most of the real findings come from.
Which exemptions survive
Annexure-1 of the Directions lists the exemptions still in force from the two-factor requirement. These are worth knowing precisely, because building authentication into a flow that is exempt adds friction for no compliance benefit.
| Use case | Basis |
|---|---|
| Small-value contactless card transactions | DPSS.CO.PD No.752/02.14.003/2020-21, 4 December 2020 |
| Recurring transactions other than the first, under the e-mandate framework | The e-mandate circulars of 21 August 2019, 4 December 2020 and 12 December 2023 |
| Select prepaid instruments such as PPI-MTS and gift PPIs | CO.DPSS.POLC.No.S-479/02.14.006/2021-22, 27 August 2021 |
| NETC transactions | DPSS.CO.PD No.1227/02.31.001/2019-20, 30 December 2019 |
| Small-value digital payments in offline mode | CO.DPSS.POLC.No.S1264/02-14-003/2021-2022, 3 January 2022 |
| Travel bookings through Global Distribution System or IATA on commercial and corporate cards | Letter dated 17 April 2012 to the Indian Banks' Association |
Annexure-2 repeals eight circulars going back to February 2009. The one to check your code against is the last: the 6 December 2016 circular that relaxed the additional factor for card-not-present payments up to ₹2,000 using card network provided authentication solutions. If a threshold like that is still hard-coded in a payments service, it is now a defect rather than a documented exemption.
Two clauses that change your risk register
Paragraph 9 puts obligations on the issuer that reach past the engineering team.
The first is compensation: "If any loss arises out of transactions effected without complying with these directions, the issuer shall compensate the customer for the loss in full without demur." There is no cap, no shared-fault carve-out and no investigation window in that sentence. A non-compliant flow is therefore a direct, uncapped financial exposure, not a compliance finding to be scheduled behind the roadmap.
The second is data protection: issuers "shall ensure adherence to the provisions of Digital Personal Data Protection Act, 2023." Biometric templates, device identifiers and behavioural signals collected for risk scoring are personal data, and the Directions explicitly bind the two regimes together. If your authentication redesign adds behavioural telemetry, the consent notice and retention schedule are part of the same change, not a follow-up ticket. We cover that groundwork in the DPDP Act engineering playbook for Indian startups.
Paragraph 8 is the permissive one. Issuers may identify transactions for evaluation against behavioural or contextual parameters such as transaction location, user behaviour patterns, device attributes and historical transaction profile, and apply additional checks beyond the minimum two factors based on perceived risk. The Directions also suggest issuers "may also explore using DigiLocker as a platform for notification and confirmation for high-risk transactions". Risk-based step-up is allowed. Risk-based step-down below two factors is not, outside Annexure-1.
Paragraph 7 adds an interoperability requirement that is easy to miss in a vendor selection: authentication or tokenisation services must be accessible to all applications and token requestors functioning in that operating environment, across use cases, channels and token storage mechanisms. A proprietary authenticator that only works inside your own app does not meet that bar.
What a retrofit actually involves
Retrofitting this into a live payments or lending application is an architecture change. The parts that take time are rarely the parts teams estimate.
| Workstream | What it covers | Where it usually goes wrong |
|---|---|---|
| Factor inventory | Every flow that authenticates a payment instruction, including web, app, IVR, callback and back-office | Forgotten channels: assisted flows, agent-initiated transactions, legacy IVR |
| Transaction binding | Making the dynamic factor carry data unique to the payment instruction | Reusing a session token or a per-login OTP and calling it transaction-bound |
| Independence review | Reset, recovery and enrolment paths for both factors | SIM-based recovery quietly collapsing two factors into one |
| Exemption mapping | Marking exempt flows against Annexure-1 rather than by habit | Hard-coded value thresholds from repealed circulars |
| Cross-border CNP | Validation mechanism, risk-based handling, BIN registration | Treating BIN registration as an engineering task rather than a network relationship with lead time |
| Risk engine | Contextual signals, step-up policy, and the audit trail behind each decision | No stored rationale for why a transaction was stepped up, which makes disputes unanswerable |
| DPDP alignment | Consent, purpose limitation and retention for biometric and behavioural data | Telemetry collected under a notice that never mentioned it |
| Migration | Moving a live customer base onto a new factor without stranding anyone | No fallback for customers on older devices, and no measured drop-off during cutover |
Migration deserves the last word. In a base of millions, a new dynamic factor that fails silently on a subset of Android builds shows up as a payment success-rate dip that finance notices before engineering does. Instrument authentication success rate by factor, device class and channel before you cut over, not after. Success-rate telemetry is the only honest measure of whether a security change worked, because the compliant path a customer cannot complete is not compliance.
Who this is for
Banks and card issuers have the cross-border CNP obligation and the BIN registration. NBFCs running lending apps authenticate disbursement and repayment instructions, and their obligations sit alongside the digital lending rules covered in the RBI digital lending directions engineering checklist. Payment aggregators and gateways carry the interoperability and tokenisation obligations in paragraph 7. Merchants and platforms are not directly bound, but their checkout conversion moves when their issuers change factors, which makes it their problem in practice.
How eCorpIT can help
eCorpIT is a CMMI Level 5 and ISO 27001:2022 certified engineering organisation in Gurugram, founded in 2021, working with senior-led, multi-disciplinary teams across payments, lending and platform engineering. On this work we start with a factor inventory and an independence review across every channel, then design the transaction-binding layer, the risk engine and the migration plan as one change rather than three. We design applications aligned with the requirements of the RBI Directions and the DPDP Act rather than claiming certification against them, and we say plainly where a decision needs your compliance team rather than ours. Related work includes our fintech payments app development service, the NBFC digital lending app service and the CKYC 2.0 migration and integration service. If the 1 October 2026 date is on your plan, talk to a senior engineer through /contact-us/.
FAQ
When did the RBI authentication Directions take effect?
The Directions were issued on 25 September 2025 as circular RBI/2025-26/79, and all Payment System Providers and Participants, including banks and non-bank entities, had to comply by 1 April 2026 unless a specific provision indicated otherwise. One provision carries a later date: the cross-border card-not-present obligations fall due on 1 October 2026.
Is SMS OTP still allowed?
Yes. SMS-based OTP is listed in paragraph 5(f) as one valid factor among passwords, passphrases, PINs, card hardware, software tokens, fingerprints and other biometrics. The Directions do not mandate any specific factor. Their stated purpose is to let the ecosystem adopt alternative mechanisms rather than defaulting to SMS for everything.
What does the dynamic factor requirement mean?
For digital payment transactions other than card-present ones, at least one factor must be dynamically created or proven, with the proof of possession sent as part of the transaction being unique to that transaction. A per-session code or a plain boolean biometric result does not qualify. The factor has to bind to the specific payment instruction.
Which transactions are exempt from two-factor authentication?
Annexure-1 lists small-value contactless card transactions, recurring transactions other than the first under the e-mandate framework, select prepaid instruments such as PPI-MTS and gift PPIs, NETC transactions, small-value digital payments in offline mode, and travel bookings through GDS or IATA on commercial and corporate cards.
What happens if a non-compliant transaction causes a loss?
Paragraph 9 states that if any loss arises from a transaction effected without complying with the Directions, the issuer shall compensate the customer for the loss in full without demur. There is no stated cap or shared-fault exception, which makes a non-compliant flow an uncapped financial exposure rather than a documented finding.
Is the ₹2,000 card-not-present relaxation still available?
No. The December 2016 circular that relaxed the additional factor for card-not-present payments up to ₹2,000 using card network provided authentication solutions appears in Annexure-2 as repealed. Any value threshold still hard-coded in a payments service on the basis of that circular is now a defect to fix.
Can we use behavioural risk signals instead of a second factor?
No, but you can use them on top. Paragraph 8 lets issuers evaluate transactions against behavioural and contextual parameters such as location, user behaviour, device attributes and historical profile, and apply additional checks beyond the minimum two factors. Risk scoring may raise the bar; it cannot lower it below two factors outside Annexure-1.
What do card issuers have to do about cross-border transactions?
By 1 October 2026, card issuers must have a mechanism to validate non-recurring cross-border card-not-present transactions where an overseas merchant or acquirer requests authentication, and a risk-based mechanism for all cross-border CNP transactions. They must also register their Bank Identification Numbers with the card networks to make that work.
References
- Reserve Bank of India, Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, RBI/2025-26/79, 25 September 2025.
- Reserve Bank of India, Directions PDF, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026.
- Reserve Bank of India, Statement on Developmental and Regulatory Policies dated February 08, 2024.
- Reserve Bank of India, Statement on Developmental and Regulatory Policies dated February 07, 2025.
- Reserve Bank of India, Tokenisation: Card Transactions, 8 January 2019.
- Reserve Bank of India, Card Not Present transactions: relaxation in Additional Factor of Authentication for payments up to ₹2,000, 6 December 2016, now repealed.
- Reserve Bank of India, Processing of e-mandate on cards for recurring transactions, 21 August 2019.
- Reserve Bank of India, e-mandate circular of 4 December 2020.
- Reserve Bank of India, e-mandate circular of 12 December 2023.
- Reserve Bank of India, Contactless card transactions and e-mandate limits, 4 December 2020.
- Reserve Bank of India, Prepaid Payment Instruments master directions, 27 August 2021.
- Reserve Bank of India, National Electronic Toll Collection transactions, 30 December 2019.
- Reserve Bank of India, Small value digital payments in offline mode, 3 January 2022.
- Reserve Bank of India, Press release accompanying the Directions, 25 September 2025.
- IBM, Strengthening digital payment security with RBI's new authentication directions.
Last updated: 5 August 2026.
Top comments (0)