RBI's 1 October 2026 cross-border CNP deadline: what card issuers must build in 73 days

Summary. The Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, issued on 25 September 2025 as circular RBI/2025-26/79, set a general compliance date of 1 April 2026. That date has passed. What has not passed is paragraph 10, which carries its own deadline of 1 October 2026, exactly 73 days from this article's publication date of 20 July 2026. It requires two distinct things from card issuers, and most implementation checklists list only one. The directions also repealed 8 earlier circulars, including the December 2016 relaxation that let card networks waive the additional factor of authentication on card-not-present transactions up to ₹2,000. The commercial teeth sit in paragraph 9(2): where a loss arises from a transaction effected without complying with these directions, "the issuer shall compensate the customer for the loss in full without demur." No cap, no negotiation, no shared liability. That single sentence is why this is an engineering deadline rather than a policy one.

What paragraph 10 actually requires

The general rules in paragraphs 6 to 9 apply to domestic transactions. Paragraph 10(1) opens by saying so plainly: "The directions outlined above are not applicable to cross-border digital payment transactions." Then it imposes two separate obligations anyway, both dated 1 October 2026.

The first is a validation mechanism. Card issuers must "put in place a mechanism to validate non-recurring, cross-border card not present (CNP) transactions, where request for authentication is raised by an overseas merchant or overseas acquirer." Note the two qualifiers. It covers non-recurring transactions, and it applies where the authentication request comes from the overseas side. To make it work, "card issuers shall register their Bank Identification Numbers (BINs) with card networks."

The second, in paragraph 10(2), is broader: "a risk-based mechanism for handling all cross-border CNP transactions shall also be put in place by card issuers by October 01, 2026." All of them, not just non-recurring ones. The word "also" matters. Two mechanisms, one date.

The definition of the transaction type is precise. A cross-border CNP transaction is "a payment instruction wherein the card, issued by an Indian issuer, is used for undertaking a payment transaction favouring a merchant acquired by an overseas acquirer. For such transactions, outflow of foreign exchange is envisaged." The acquirer's location decides it, not the merchant's website or currency.

Requirement	Who it binds	Scope	Due
Two distinct factors of authentication	All payment system providers and participants	Domestic digital payments, minus Annexure-1 exemptions	1 April 2026
At least one dynamic factor	Same	All except card-present transactions	1 April 2026
Interoperable authentication and tokenisation	System providers and participants	All applications and token requestors in the operating environment	1 April 2026
Validation mechanism for overseas-raised authentication	Card issuers	Non-recurring cross-border CNP	1 October 2026
BIN registration with card networks	Card issuers	Supports the validation mechanism	1 October 2026
Risk-based handling mechanism	Card issuers	All cross-border CNP	1 October 2026

The three principles the domestic rules run on

Even though paragraph 10 sits outside them, the domestic principles set the design vocabulary the rest of the directions use, and cross-border teams should build to the same shape.

Two distinct factors. Paragraph 6(a) requires at least two distinct factors of authentication unless exempted. Factors come from "something the user has", "something the user knows" or "something the user is", and the directions list password, SMS-based OTP, passphrase, PIN, card hardware, software token, fingerprint, "or any other form of biometrics (device native or Aadhaar based)". Issuers may offer customers a choice of factors.

One factor must be dynamic. Paragraph 6(b) is the provision that ends the era of static credentials. For everything other than card-present transactions, at least one factor must be "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." Transaction-unique. A reusable device token that proves possession in general, but not possession for this specific payment, does not satisfy this.

Independence. Paragraph 6(c) requires that "compromise of one factor does not affect reliability of the other." This is the rule that quietly kills a common architecture: OTP delivered to the same handset that also holds the app's device binding and biometric unlock. If one phone compromise takes out both factors, the factors are not independent in the sense paragraph 6(c) means.

The directions were issued under Section 18 read with Section 10(2) of the Payment and Settlement Systems Act, 2007, and follow the RBI's Statements on Developmental and Regulatory Policies of 8 February 2024 and 7 February 2025.

The interoperability rule that constrains your architecture

Paragraph 7 is one sentence and it rules out a whole category of design. System providers and participants "shall offer authentication or tokenisation service that is accessible to all the applications / token requestors functioning in that operating environment for all use cases / channels or token storage mechanisms."

The note that follows defines the operating environment as including "device hardware, operating system, etc.", and imports the meanings of tokenisation, token requestor, use cases and channels from the RBI's tokenisation directions of 8 January 2019.

Read that as a prohibition on exclusivity. If an issuer builds a device-native biometric authentication path, it cannot be offered to that issuer's own app while being unavailable to other token requestors operating on the same device and operating system. The same holds across channels: an authentication service available in-app but not on the web, for the same use case, is a candidate problem under this paragraph.

For engineering teams the consequence is about where the authentication service sits. A method implemented inside a single mobile application, coupled to that application's session and storage, is hard to expose to other requestors later. A method implemented as a service behind a documented interface, with the app as one client among several, satisfies paragraph 7 by construction. Retrofitting the first shape into the second is a rewrite, which is why this is worth settling before the cross-border work starts rather than after.

What "risk-based" means in the text, not in the marketing

Paragraph 8 is short and unusually specific about inputs. Issuers may "identify transactions for evaluation against behavioural / contextual parameters such as transaction location, user behaviour patterns, device attributes, historical transaction profile, etc." Based on perceived risk, "additional checks beyond the minimum two-factor authentication may be resorted to." The directions also suggest issuers "may also explore using DigiLocker as a platform for notification and confirmation for high-risk transactions."

Read the direction of travel carefully. In the domestic rules, risk-based scoring is a mechanism for adding friction above the two-factor floor, not for removing it. Paragraph 10(2), by contrast, requires a risk-based mechanism as the primary control for all cross-border CNP, because the two-factor floor does not apply there. Those are different jobs for the same machinery, and a team that builds one and assumes it covers the other will be wrong in the direction that costs money.

A practical engineering consequence: the four named parameters imply you need per-transaction access to geolocation, a behavioural baseline per cardholder, device fingerprinting, and transaction history at decision time. If your authorisation path cannot reach the historical profile inside the network timeout, the risk engine has to sit on a cached or precomputed profile. That is an architecture decision, and it is the one that usually determines whether the deadline is achievable.

The BIN registration step teams keep missing

The validation mechanism in paragraph 10(1) does not work in isolation. It works because the card networks need to know which BINs belong to issuers that participate. The directions state it as an obligation, not an option: "To ensure compliance, card issuers shall register their Bank Identification Numbers (BINs) with card networks."

This is the item most likely to slip, because it is not a code change. It is a coordination task with external parties, it usually has a lead time the engineering team does not control, and it tends to be discovered late by whoever owns the network relationship rather than the sprint board. If you are inside 73 days, start here, not with the risk model.

What the directions repealed, and why it matters

Annexure-2 repeals 8 circulars going back to February 2009. Most are housekeeping. One is not.

The circular dated 6 December 2016 was titled "Card Not Present transactions - Relaxation in Additional Factor of Authentication for payments upto ₹2,000/- for card network provided authentication solutions". Its repeal removes that relaxation as a standing instruction. If any part of your CNP flow still relies on a sub-₹2,000 waiver inherited from that circular, the basis for it is gone, and the current position is the exemption list in Annexure-1.

Exempted use case	Source instruction
Small-value contactless card transactions	Circular of 4 December 2020
Recurring e-mandate transactions, other than the first	Circulars of 21 August 2019, 4 December 2020 and 12 December 2023
Select prepaid instruments, PPI-MTS and gift PPIs	Circular of 27 August 2021
NETC transactions	Circular of 30 December 2019
Small-value digital payments in offline mode	Circular of 3 January 2022
Travel bookings via GDS or IATA on commercial and corporate cards	Letter of 17 April 2012 to the Indian Banks' Association

The annexure also notes that "any subsequent additions / modifications made, from time to time, will also be applicable", so treat this list as a live reference rather than a snapshot.

The liability clause is the real deadline

Paragraph 9 puts three obligations on issuers. The first is to ensure "the robustness and integrity of the authentication mechanism before deployment." The third is to ensure adherence to the Digital Personal Data Protection Act, 2023, which matters because a risk engine built on device attributes, location and behavioural baselines is processing personal data at scale.

The second is the one to put in front of a CFO: "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."

Two words carry the weight. "In full" removes any cap or excess. "Without demur" removes the investigation-and-negotiation step that ordinarily sits between a disputed transaction and a refund. The clause does not require the customer to have been careless or careful; it keys on whether the transaction complied with the directions. That converts a compliance gap into an uncapped, per-transaction liability, which is a very different thing from a penalty.

The practical implication is about evidence. To show a transaction complied, you need a durable record of which factors were used, that at least one was transaction-unique, and what the risk decision was and why. If your logs record only "authenticated: true", you cannot discharge that burden. Build the audit trail as part of the mechanism, not as a later observability project.

A build order for the remaining 73 days

Sequencing matters more than effort here, because two of these items have external dependencies you cannot compress.

1. Start BIN registration with the card networks now. It is external, it has lead time, and nothing else in paragraph 10(1) works without it.
2. Inventory your cross-border CNP flows. Use the definition, not intuition: card issued by an Indian issuer, merchant acquired by an overseas acquirer. Subscription and marketplace flows are the ones most often misfiled.
3. Split recurring from non-recurring. Paragraph 10(1) covers non-recurring only. Paragraph 10(2) covers all. If your systems cannot tell the two apart at decision time, that classification is the first thing to build.
4. Decide where the risk decision executes and whether it can reach the historical profile inside the authorisation timeout. If not, design the precomputed profile now. This is the long pole.
5. Build the validation path for overseas-raised authentication requests, including the failure modes: what happens on timeout, on an unregistered BIN, and on a risk engine outage. Fail-open and fail-closed are both defensible; undefined is not.
6. Instrument for the liability clause. Log factors used, which one was transaction-unique, the risk score, the inputs that produced it, and the decision. Retain it long enough to answer a dispute.
7. Run the DPDP review over the risk engine's inputs before it goes live, not after.

The most common failure we see on deadlines of this shape is not a missing feature. It is a feature that exists and cannot be evidenced.

India-specific considerations

Teams building for Indian issuers are used to UPI's rulebook, where NPCI publishes prescriptive API behaviour and the compliance surface is largely the integration itself. These directions work differently. They set principles and leave the mechanism to you, which is more freedom and more risk: there is no reference implementation to point at when a regulator or a customer asks whether your approach met paragraph 6(b).

That difference shows up in review. For UPI work, our note on NPCI API rate limits and app architecture covers a world of published limits. Here you are documenting your own reasoning, which means the design document is part of the deliverable.

The DPDP overlap deserves its own attention rather than a checkbox. Device attributes, transaction location and behavioural baselines are personal data, and paragraph 9(3) makes DPDP adherence an explicit obligation inside a payments circular. Notice, purpose limitation and retention all need answers before the risk engine holds a behavioural profile on every cardholder. Our DPDP engineering playbook for Indian startups covers the mechanics.

FAQ

What is due on 1 October 2026?

Two things, both binding card issuers. A mechanism to validate non-recurring cross-border card-not-present transactions where an overseas merchant or acquirer raises the authentication request, supported by registering Bank Identification Numbers with card networks. Separately, a risk-based mechanism for handling all cross-border CNP transactions, not only non-recurring ones.

Do the two-factor rules apply to cross-border transactions?

No. Paragraph 10(1) states the directions outlined above are not applicable to cross-border digital payment transactions. The domestic two-factor floor, the dynamic-factor rule and the independence requirement bind domestic payments from 1 April 2026. Cross-border CNP instead gets the two specific mechanisms due on 1 October 2026.

What counts as a cross-border CNP transaction?

The directions define it as a payment instruction where a card issued by an Indian issuer is used for a transaction favouring a merchant acquired by an overseas acquirer, with an outflow of foreign exchange envisaged. The acquirer's location determines classification, not the merchant's apparent location, website domain or billing currency.

Is the ₹2,000 CNP authentication relaxation still available?

The circular of 6 December 2016 that provided relaxation in the additional factor of authentication for card-not-present payments up to ₹2,000 for card-network-provided authentication solutions appears in Annexure-2 as repealed. Current exemptions are those listed in Annexure-1, plus any subsequent additions or modifications the RBI makes.

What happens if a transaction is not compliant?

Paragraph 9(2) states that 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 stated cap and no investigation step, so a compliance gap becomes an uncapped per-transaction liability rather than a fixed penalty.

Does an SMS OTP still satisfy the requirements?

An OTP is listed as a valid factor and is dynamic. The difficulty is paragraph 6(c), which requires that compromise of one factor does not affect the reliability of the other. Where the OTP arrives on the same handset that holds the app binding and biometric unlock, a single device compromise can defeat both.

Which transactions are exempt from two-factor authentication?

Annexure-1 lists small-value contactless card transactions, recurring e-mandate transactions other than the first, select prepaid instruments including PPI-MTS and gift PPIs, NETC transactions, small-value digital payments in offline mode, and travel bookings through Global Distribution System or IATA on commercial and corporate cards.

Does DPDP apply to the risk engine?

Paragraph 9(3) requires issuers to ensure adherence to the Digital Personal Data Protection Act, 2023. A risk-based mechanism built on transaction location, user behaviour patterns, device attributes and historical transaction profile processes personal data, so notice, purpose limitation and retention need answers before the profile is built for every cardholder.

How eCorpIT can help

eCorpIT builds payments and authentication systems for Indian issuers, fintechs and ecommerce platforms from our Gurugram base, and our senior engineering teams work on exactly the parts of this deadline that tend to slip: classifying cross-border CNP flows correctly, getting a risk decision inside the authorisation timeout, and instrumenting the audit trail that paragraph 9(2) makes valuable. We design applications aligned with RBI and DPDP requirements. If 1 October 2026 is on your roadmap and the scope is still fuzzy, talk to us about a payments architecture review, or see our fintech and payments app development work.

References

1. Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, RBI/2025-26/79, 25 September 2025.
2. Directions PDF, CO.DPSS.POLC.No. S 668/02-14-015/2025-2026, Reserve Bank of India.
3. Statement on Developmental and Regulatory Policies, 8 February 2024, Reserve Bank of India.
4. Statement on Developmental and Regulatory Policies, 7 February 2025, Reserve Bank of India.
5. Tokenisation - Card Transactions, 8 January 2019, Reserve Bank of India.
6. Card Not Present transactions - Relaxation in Additional Factor of Authentication for payments upto Rs 2,000, 6 December 2016, Reserve Bank of India, since repealed.
7. Processing of e-mandate on cards for recurring transactions, 21 August 2019, Reserve Bank of India.
8. Card transactions in contactless mode, 4 December 2020, Reserve Bank of India.
9. Processing of recurring transactions, 4 December 2020, Reserve Bank of India.
10. Processing of e-mandates for recurring transactions, 12 December 2023, Reserve Bank of India.
11. Prepaid Payment Instruments, 27 August 2021, Reserve Bank of India.
12. National Electronic Toll Collection transactions, 30 December 2019, Reserve Bank of India.
13. Framework for small value digital payments in offline mode, 3 January 2022, Reserve Bank of India.
14. Digital Personal Data Protection Act, 2023, Ministry of Electronics and Information Technology, Government of India.

Last updated: 20 July 2026.