Cross-Border Card Authentication: RBI's 1 October Deadline Is a Switch, Not an OTP on Every Purchase

On 1 October 2026 a clause in the Reserve Bank of India's Authentication Mechanisms for Digital Payment Transactions Directions, 2025 became enforceable. Most of the commentary around it reads as if every overseas card purchase now carries an extra OTP. That is not what the text says, and the difference matters if you pay AWS, OpenAI, Figma or a hundred other foreign vendors on an Indian card. This piece covers cross-border card authentication as it actually works under the rule, and where Indian finance and ops teams are likely to feel it.

What the cross-border card authentication rule requires

RBI issued the directions on 25 September 2025. The headline obligation, two distinct authentication factors on domestic digital payments, started on 1 April 2026. Cross-border card-not-present (CNP) payments got a longer runway to 1 October 2026, and the obligations are narrower. As summarised by MediaNama and Lexology, issuers need three things in place:

• A mechanism to validate an additional factor on non-recurring cross-border CNP transactions when the overseas merchant or acquirer requests authentication.
• A risk-based mechanism covering all cross-border CNP transactions.
• Registration of their Bank Identification Numbers (BINs) with the card networks, so the networks can route those requests to the right issuer.

Read the first item again. The trigger is a request from the other side of the border. India can regulate its own issuers, not a merchant in Dublin or Seattle, so the clause is built as a capability: when a foreign merchant asks, the Indian issuer must be able to answer with a verified second factor.

Who decides when your card gets challenged

Three parties can cause a challenge, and only one of them is new. The overseas merchant or its acquirer can request authentication. The card network can apply its own rules. The issuer's risk engine can step up or decline on its own. The new rule formalises the first path and makes the third mandatory for every cross-border CNP transaction.

In practice, a merchant requests authentication through the card networks' existing 3-D Secure style flows, which is the usual channel for asking a cardholder to prove themselves. The deadline makes sure the Indian issuer can complete that request.

Why the risk-based clause matters more than the headline

The merchant-request path is predictable: you see an OTP or app approval prompt, complete it, the payment goes through. The risk-based path is not, because the directions require a mechanism but do not publish a scoring formula. Each issuer decides what looks suspicious. A first-ever charge from a new foreign merchant, a large amount, a new corporate card or an unusual merchant category are the sort of signals any risk engine weighs.

That is where a finance team will see the effect. Not as a new prompt on every checkout, but as a higher chance that an unfamiliar overseas charge is stepped up or declined, and a lower tolerance for the sloppy case where the cardholder's registered mobile number is a former employee's phone.

Where Indian teams will feel it

The e-mandate exception is the one to plan around. Recurring overseas charges are reported to sit outside fresh validation, except at the first occurrence. So a steady AWS bill is unlikely to change, while the day you sign up for a new tool, upgrade a plan that creates a fresh charge, or move to a replacement card is when a challenge is most likely.

An engineering lead buying a new developer tool at 11 pm on the company card is the realistic victim. The payment fails or hangs waiting for an approval the cardholder never receives, and the vendor's trial lapses.

A checklist before your next overseas renewal

• Confirm the mobile number and app registered with the issuer for every company card. Authentication prompts go to that registration, not to whoever uses the card.
• Ask the bank whether the card is enabled for international online use and for the authentication flow the overseas merchant will request.
• Keep a second card from a different issuer for critical vendors, so a decline on one does not stop a production dependency.
• Stagger first charges for new tools; do not buy five new overseas subscriptions in an hour on one fresh card.
• Note which vendors bill monthly through card-on-file versus invoice. Vendors that offer invoicing or bank transfer remove card authentication from the path altogether.

What nobody knows yet

Three things are open. First, how many overseas merchants will actually request authentication on Indian cards; that is a commercial choice shaped by conversion rates and fraud losses on their side. Second, how aggressively each Indian issuer tunes its cross-border risk engine. Third, whether the first-charge friction hits personal and corporate cards equally. Analysts at Ecorpit frame the work as an issuer-side retrofit across channels, which suggests the visible behaviour will vary by bank for a while.

The first month of declined-payment data from finance teams will say more than any reading of the clause. If you see a pattern on your own cards, record the issuer, the merchant and the amount; those three fields are what your bank will ask for.