What India’s Cross-Border CNP Authentication Rule Means for Issuers and ACS Providers

Since 1 October 2026, card issuers in India have had to put in place a mechanism to validate non-recurring cross-border card-not-present (CNP) transactions when an overseas merchant or overseas acquirer asks for authentication. They also had to register their Bank Identification Numbers (BINs) with card networks and introduce a risk-based mechanism for handling all cross-border CNP transactions.

The requirement comes from the Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025, issued on 25 September 2025. Most of those Directions applied to domestic transactions from 1 April 2026. The cross-border provision had a later date and is written in a single short paragraph, which leaves issuers and their Access Control Server (ACS) providers to work out the operational detail.

This article sets out what the Directions say, what they do not say, and the implementation questions an issuer should be able to answer for its ACS.

What the RBI Directions require

The Directions define a cross-border CNP transaction as one where a card issued by an Indian issuer pays a merchant acquired by an overseas acquirer, with an outflow of foreign exchange envisaged.

Direction 10 then makes three points:

• the domestic authentication directions do not apply to cross-border digital payment transactions
• by 1 October 2026, card issuers must have a mechanism to validate non-recurring cross-border CNP transactions where a request for authentication is raised by an overseas merchant or overseas acquirer, and must register their BINs with card networks to ensure compliance
• by the same date, card issuers must have a risk-based mechanism for handling all cross-border CNP transactions

The RBI’s press release at issue described the change as mandating card issuers to validate an additional factor of authentication (AFA) in non-recurring cross-border CNP transactions whenever the overseas merchant or acquirer requests it.

What the Directions do not say

Three gaps matter for implementation.

They do not name a protocol. The Directions refer to a ‘request for authentication’ from an overseas merchant or acquirer, not to EMV 3D Secure. In practice, the established route for an overseas ecommerce merchant to request issuer authentication of a card payment is EMV 3DS, where the merchant’s 3DS Server sends an authentication request through the card scheme’s Directory Server to the issuer’s ACS. That is an interpretation of how the requirement operates in card-scheme practice, and issuers should confirm scheme-specific expectations with each network.

They do not prescribe the authentication factor for cross-border transactions. The domestic principles, including two factors with at least one dynamic factor for CNP transactions, are expressly not applied to cross-border transactions. The cross-border text requires a validation mechanism but leaves its design to the issuer.

They do not cover transactions where no authentication is requested. The validation mandate is triggered by a request from the overseas merchant or acquirer. Cross-border CNP transactions without such a request still fall under the separate risk-based mechanism requirement, which the issuer applies on its own side.

ACS implementation questions for issuers

The following questions translate the Directions into checks an issuer can run against its ACS configuration and operating model. They are not a compliance checklist, and issuers should confirm their interpretation with their own advisers and card networks.

Are every relevant BIN and card range enrolled with each scheme?

The Directions tie compliance to BIN registration with card networks. For EMV 3DS, an overseas 3DS Server can only route an authentication request to the issuer’s ACS if the card range is enrolled in that scheme’s Directory Server. Issuers should reconcile their full BIN inventory, including debit, prepaid and co-branded ranges, against what each scheme shows as enrolled, and repeat the check whenever new ranges are issued.

Can the ACS distinguish non-recurring from recurring transactions?

The validation mandate applies to non-recurring cross-border CNP transactions. Recurring transactions fall under the risk-based mechanism instead, alongside India’s separate e-mandate framework for domestic recurring payments. EMV 3DS messages carry indicators that describe the transaction type, such as the 3DS Requestor Authentication Indicator, and 3DS Requestor Initiated (3RI) messages cover certain merchant-initiated cases. The ACS rules should use these indicators deliberately, and the issuer should decide how to treat requests where the indicators are missing or inconsistent.

What does the cross-border challenge actually use?

Because the Directions leave the factor to the issuer, the choice is a design decision with real consequences. A cardholder buying from abroad, or travelling, may not receive an SMS one-time password reliably on a roaming connection. App-based out-of-band authentication or other methods supported by the issuer may perform better in exactly the situations cross-border transactions create. The ACS should support the methods the issuer intends to offer and fall back predictably when the preferred method is unavailable.

How does the risk-based mechanism decide between frictionless and challenge?

The requirement for a risk-based mechanism across all cross-border CNP transactions gives issuers room to approve low-risk requests without a challenge and to step up higher-risk ones. That depends on the ACS risk engine having cross-border-specific inputs: merchant country, transaction amount and currency, device and browser data from the request, and the cardholder’s own travel and purchase history. Rules tuned only for domestic traffic are likely to over-challenge legitimate international purchases or under-challenge risky ones.

What happens to requests carrying overseas exemption or preference indicators?

Overseas merchants may send indicators that reflect their own market’s rules, such as a request for no challenge under a European exemption. Those indicators express the requestor’s preference. The issuer still decides the outcome, and its ACS rules should treat such indicators as inputs to the risk-based mechanism rather than as instructions.

Can the issuer evidence what happened?

An issuer should be able to show, for any cross-border CNP transaction, whether authentication was requested, how the ACS responded, which method was used and why. ACS transaction logs, rule versions and challenge outcomes are the raw material for that evidence, for internal assurance and for any supervisory review.

Has capacity been planned for the new volume?

Cross-border authentication requests reaching the ACS add load that may not have been sized for. Peak shopping periods in other markets do not line up with Indian ones, so capacity and latency testing should use realistic cross-border traffic patterns.

Testing before and after the deadline

The deadline has passed, but most issuers will still be refining their configuration. Regression testing of cross-border flows, including challenge fallbacks, missing or unusual indicators, and timeouts, will show whether the ACS behaves as intended under conditions that are hard to reproduce in production.

Frequently asked questions

When did the cross-border CNP requirement start?

Card issuers had to have the validation mechanism, BIN registration and risk-based mechanism in place by 1 October 2026. The rest of the RBI Directions applied to domestic transactions from 1 April 2026.

Does the validation requirement cover recurring transactions?

The validation mandate applies to non-recurring cross-border CNP transactions where the overseas merchant or acquirer requests authentication. All cross-border CNP transactions, including recurring ones, fall under the separate risk-based mechanism requirement.

Does the RBI require EMV 3D Secure?

The Directions do not name a protocol. In card-scheme practice, EMV 3DS is the usual route for an overseas merchant to request issuer authentication, so it is how most requests are likely to reach the issuer’s ACS. Issuers should confirm scheme expectations.

Must issuers use an SMS one-time password for cross-border transactions?

No factor is prescribed for cross-border transactions. The domestic two-factor principles do not apply to them, so the method is an issuer design decision.

How GPayments can help

ActiveAccess is GPayments’ Access Control Server for issuing-side EMV 3DS authentication, used by issuers and issuer processors. Issuers working through the questions above can discuss their cross-border configuration, authentication methods and risk-based rules with GPayments’ 3DS specialists.

Explore ActiveAccess or speak with a 3DS specialist about your cross-border CNP authentication set-up.