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

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.

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.

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.

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

References

1. Reserve Bank of India, Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, RBI/2025-26/79, 25 September 2025.

1. Reserve Bank of India, Directions PDF, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026.

1. Reserve Bank of India, Statement on Developmental and Regulatory Policies dated February 08, 2024.

1. Reserve Bank of India, Statement on Developmental and Regulatory Policies dated February 07, 2025.

1. Reserve Bank of India, Tokenisation: Card Transactions, 8 January 2019.

1. 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.

1. Reserve Bank of India, Processing of e-mandate on cards for recurring transactions, 21 August 2019.

1. Reserve Bank of India, e-mandate circular of 4 December 2020.

1. Reserve Bank of India, e-mandate circular of 12 December 2023.

1. Reserve Bank of India, Contactless card transactions and e-mandate limits, 4 December 2020.

1. Reserve Bank of India, Prepaid Payment Instruments master directions, 27 August 2021.

1. Reserve Bank of India, National Electronic Toll Collection transactions, 30 December 2019.

1. Reserve Bank of India, Small value digital payments in offline mode, 3 January 2022.

1. Reserve Bank of India, Press release accompanying the Directions, 25 September 2025.

1. IBM, Strengthening digital payment security with RBI's new authentication directions.

Last updated: 5 August 2026.