Skip to main content
Reserve Bank of India

RBI authentication and app-security requirements.

How financial institutions in India meet them with Fortanixor — banks, exchange houses, payment providers, microfinance and fintechs supervised by the Reserve Bank of India.

Regulation refs: Reserve Bank of India (Authentication mechanisms for digital payment transactions) Directions, 2025 (RBI/2025-26/79); Master Direction on Digital Payment Security Controls (RBI/2020-21/74, 2021); Master Direction on Information Technology Governance, Risk, Controls and Assurance Practices (RBI/2023-24/107, 2023); Master Direction on Outsourcing of Information Technology Services (RBI/2023-24/102, 2023); Commercial Banks - Responsible Business Conduct Third Amendment Directions, 2026 (RBI/2026-27/167); FREE-AI Committee Report (August 2025); Digital Personal Data Protection Act, 2023 and DPDP Rules, 2025

India has required two factors on every digital payment for years. No factor was ever mandated, and SMS OTP became the default second factor. The Reserve Bank's Authentication Directions of 25 September 2025 change that. They open by saying the ecosystem has primarily adopted SMS-based OTP and that the directions exist to let payments use alternative authentication mechanisms. Every Payment System Provider and Participant, banks and non-banks, must comply by 1 April 2026. Paragraph 6 sets three principles: at least two distinct factors, drawn from something the user has, knows or is, including device-native biometrics; at least one factor dynamically created or proven, so the proof sent with the transaction is unique to it; and factors robust enough that compromising one does not affect the other. SMS OTP is still a permitted factor. It is no longer the only one the rules contemplate.

The directions put the liability on the issuer. Paragraph 9 requires the issuer to ensure the mechanism is robust before deployment, and to compensate the customer in full, without demur, for any loss on a transaction that did not comply. From 1 January 2027 the June 2026 customer-protection amendment for commercial banks also places the burden of proving customer liability in fraud complaints on the bank. Underneath sit the 2021 Master Direction on Digital Payment Security Controls, which requires device binding of the mobile app and tells banks to consider alternatives to SMS OTP where the code and the app share a phone, and the 2023 IT Governance Master Direction, which requires audit trails fit for non-repudiation. On AI, RBI's August 2025 FREE-AI committee report recommends that customers always be told when they are dealing with AI, and always be able to reach a human.

What Reserve Bank of India requires

01 / 06

Two distinct factors, one of them dynamic, from 1 April 2026

All domestic digital payment transactions must be authenticated by at least two distinct factors, from something the user has, knows or is, unless a listed exemption applies. Factors can include a PIN, passphrase, software token, card hardware, SMS OTP, or fingerprint and other device-native biometrics. For everything other than card-present transactions, at least one factor must be dynamically created or proven, so the proof sent with the transaction is unique to it. The factors must be robust, meaning the compromise of one does not affect the reliability of the other. Issuers may give customers a choice of factors. Payment System Providers and Participants, banks and non-banks, must comply by 1 April 2026.

Authentication Directions 2025, paragraphs 3, 4, 5(I)(f) and 6(a) to 6(c)

02 / 06

Risk-based step-up, and full compensation when authentication falls short

Issuers may assess transactions against behavioural and contextual signals such as location, user behaviour, device attributes and transaction history, and apply checks beyond the two-factor minimum where risk is higher. RBI suggests DigiLocker as one channel for notifying and confirming high-risk transactions. The issuer must ensure the mechanism is robust and sound before deployment, must comply with the DPDP Act, and must compensate the customer in full, without demur, for any loss on a transaction made without complying with the directions.

Authentication Directions 2025, paragraphs 8 and 9(a) to 9(c)

03 / 06

MFA, device binding and alternatives to SMS OTP in the mobile app

Banks and card-issuing NBFCs must use multi-factor authentication for electronic payments and fund transfers, with at least one method dynamic or non-replicable. RBI's examples include device binding, biometrics and PKI. MFA and alerts apply to all payments, to adding, changing or deleting beneficiaries, to changes of account details and to changes of transfer limits, with measures against man-in-the-middle and man-in-the-browser attacks. The mobile app must be device-bound. Where several devices are allowed, every new registration is notified and the customer can disable any device. Because the extra factor and the app may sit on the same phone, banks should consider alternatives to SMS-based OTP.

Master Direction on Digital Payment Security Controls, paragraphs 33, 34, 60 (with footnote 5) and 61

04 / 06

Audit trails that settle disputes, with the burden of proof on the bank

Every IT application that can access or affect critical or sensitive information must keep audit trails detailed enough to support audit, serve as forensic evidence and help resolve disputes, including for non-repudiation, and these must be monitored for unauthorised activity. For commercial banks (other than small finance, payments, regional rural and local area banks), electronic banking transactions on or after 1 January 2027 fall under a new regime. The bank must have the safety systems that the Digital Payment Security Controls Master Direction and the Authentication Directions require. In fraud complaints, the bank carries the burden of proving the customer is liable. Failing to put those mandated systems in place counts as bank negligence, which leaves the customer with zero liability.

IT Governance Master Direction, paragraph 15; Responsible Business Conduct Third Amendment Directions 2026, new paragraphs 4(20B), 76B(1), 76K and 76L

05 / 06

Outsourced technology the bank still answers for

Outsourcing does not reduce the bank's obligations: its Board and senior management remain ultimately responsible, wherever the provider is located, and the arrangement must not impede RBI supervision. Agreements must give the bank effective access to all data, records, logs and alerts, store data only in India where extant rules require it, and disclose what data the provider captures, processes and stores. The bank remains responsible for the confidentiality and integrity of customer data the provider can see. Under the DPDP Act the bank, as Data Fiduciary, answers for its processors' processing. From 13 May 2027 the DPDP Rules require safeguards including encryption, access control and access logs kept for one year.

Outsourcing of IT Services Master Direction, paragraphs 4(a), 4(b), 16(b), 16(g) and 17(c); DPDP Act 2023, section 8(1), 8(2) and 8(5); DPDP Rules 2025, rules 1(4) and 6(1)

06 / 06

AI that tells customers it is AI, with a way to reach a human

RBI's FREE-AI committee recommends that customers be explicitly told whenever they are interacting with an AI system and always be able to switch to a human. It also recommends that voice AI operate only through verifiable channels such as verified 1601-series phone numbers, and that customers have grievance redress for AI interactions and decisions. AI models should be governed across their lifecycle, with documentation, validation, drift monitoring and human oversight for medium- and high-risk uses. These are recommendations in a committee report RBI has published, not binding directions.

FREE-AI Committee Report (August 2025), paragraph 4.4.54 and Recommendations 16 and 18

Control mapping

How Fortanixor maps to RBI requirements.
RequirementFramework referenceHow Fortanixor addresses itProduct
At least two distinct factors, with at least one dynamically created or proven and unique to the transactionAuthentication Directions 2025, paragraphs 5(I)(f), 6(a) and 6(b)A FortAuth passkey combines something the user has, a private key held in the secure hardware of the registered phone, with something the user is or knows, the device-native biometric or PIN that unlocks it. Both factor types appear in RBI's definition. Each approval signs a fresh challenge issued by the bank for that transaction, so the proof of possession is unique to it, which is what paragraph 6(b) asks for.FortAuth
Robust factors, where compromising one does not affect the other, and alternatives to SMS OTP when code and app share a phoneAuthentication Directions 2025, paragraph 6(c); Digital Payment Security Controls MD, paragraph 61With SMS OTP, malware or a SIM swap on the phone that also runs the app can take both the code and the session. A passkey's key cannot be exported from secure hardware, so a stolen PIN or a stolen phone is not enough on its own. The authenticator checks the biometric locally and nothing is sent over SMS. Both factors still live on one device, so the bank's robustness assessment under paragraph 9(a) should record why they stay independent.FortAuth
Risk-based checks beyond the two-factor minimum, using device attributes, location and behaviourAuthentication Directions 2025, paragraph 8FortAuth lets the bank's risk engine call for a fresh passkey step-up on any transaction it flags. Optional device fingerprinting and VPN detection add the device attributes paragraph 8 lists. For the highest-risk cases, FortAgent can call the customer on the bank's own telephony, say it is an AI agent, and ask them to confirm with FortAuth on their registered phone. The risk policy and its thresholds remain the bank's.FortAuthFortAgent
Issuer liable in full for losses on non-compliant transactions; bank bears the burden of proving customer liabilityAuthentication Directions 2025, paragraph 9(b); Responsible Business Conduct Third Amendment Directions 2026, paragraphs 76B(1) and 76KEach FortAuth approval leaves a signed record showing which registered device and credential approved which transaction, and when. With Secure Payment Confirmation, the amount and payee shown to the customer are part of the signed data. When a complaint arrives, the bank holds evidence that the authentication met the directions and what the customer saw, rather than only a log showing that an SMS was sent.FortAuth
MFA for adding, changing or deleting beneficiaries, changing account details and revising transfer limitsDigital Payment Security Controls MD, paragraph 34Each of these changes can require a passkey step-up in the app or on the web. Where the request comes through the contact centre, FortAgent sends a FortAuth confirmation to the customer's registered device rather than accepting details read out on the call. The alerts paragraph 34 also asks for remain the bank's SMS and email channels.FortAuthFortAgent
Measures against man-in-the-middle, man-in-the-browser and phishing, so that only genuine sources can authenticate a transactionDigital Payment Security Controls MD, paragraphs 30 and 34A FIDO2 passkey is bound to the bank's real domain or app. A look-alike site cannot ask the device to sign, and there is no code a customer can be talked into reading out. Signatures are checked on the bank's server, which is the centralised, server-side check paragraph 30 describes.FortAuth
Device binding of the mobile app, notice of every new device, a record of registered devices and a way for the customer to disable oneDigital Payment Security Controls MD, paragraph 60 and footnote 5Each registered device holds its own passkey, which is device binding in hardware. The bank's credential list is its record of registered devices: it can notify the customer on every new registration, cap the number of devices, and let the customer disable any one from the app. Optional device fingerprinting adds the software and service signals the footnote prefers.FortAuth
Audit trails detailed enough for forensic evidence and dispute resolution, including non-repudiationIT Governance, Risk, Controls and Assurance Practices MD, paragraph 15(a) to 15(c)FortAuth signatures can be checked by anyone holding the public key, so the bank can prove an approval without relying on its own logs. FortAgent transcribes, QA-scores and audit-trails every call. FortVoice records each transcribed command alongside the customer's on-screen confirmation before it executes. All of these records can feed the bank's existing log monitoring.FortAuthFortAgentFortVoice
Telling customers they are dealing with AI, a way to reach a human, verifiable voice channels, and AI governed across its lifecycleFREE-AI Committee Report, paragraph 4.4.54 and Recommendation 16 (recommendations, not directions)FortAgent tells every caller they are speaking to an AI agent, and a person can take over at any point. It runs on the bank's own telephony, so calls can go out on the bank's verified 1601-series numbers. Every call is transcribed and QA-scored, and the bank can choose and change the model it governs. FortVoice shows each command on screen for confirmation, so no voice instruction acts unseen.FortAgentFortVoice
Bank access to all data and logs held by an IT service provider, data stored in India where required, and security safeguards over processorsOutsourcing of IT Services MD, paragraphs 4(a), 16(b), 16(g) and 17(c); DPDP Rules 2025, rule 6(1)All three products deploy on-premise in the bank's Indian data centre, in an Indian cloud region, or hybrid. Authentication records, speech and call recordings therefore stay in India and in the bank's control, which leaves less material outsourcing to govern. FortAuth stores only public keys, which reveal nothing if breached. Logs are the bank's to keep for the one year rule 6(1)(e) requires.FortAuthFortVoiceFortAgent
What this mapping does not claim

Where a requirement belongs to the bank’s own operations, or where the regulator has published no rule to map to, we say so rather than stretch a row to cover it. This is the boundary of the table above, not a gap in it.

  • Mandatory SMS and email transaction alertsResponsible Business Conduct Third Amendment Directions 2026, paragraphs 76D to 76F, require instant SMS alerts for every electronic banking transaction above ₹500 and email alerts where an address is registered, in addition to any in-app alert. Not sending mandatory alerts is bank negligence under new paragraph 4(20B). Passkeys replace SMS as an authentication factor, but SMS alerts stay.
  • Storage of payment system data only in IndiaStorage of Payment System Data circular (6 April 2018), paragraph 2(i): system providers must store the entire data relating to the payment systems they operate, including full end-to-end transaction details, in a system only in India. This is the bank's or system provider's obligation, and RBI's later FAQs on it were not read. Our role is to deploy in India so no authentication or call data leaves the country.
  • Interoperable, open-access authentication and tokenisation servicesAuthentication Directions 2025, paragraph 7, requires System Providers and Participants to offer authentication or tokenisation services that every application or token requestor in that operating environment can use. It is an ecosystem obligation on the bank and network. FIDO2 is an open standard supported by the major mobile operating systems and browsers, but we do not claim that this meets paragraph 7.
  • Validating cross-border card-not-present transactions by 1 October 2026Authentication Directions 2025, paragraph 10: card issuers must validate non-recurring cross-border CNP transactions where an overseas merchant or acquirer raises the authentication request, and register their BINs with card networks. That runs through card-network authentication and is outside our products.
  • Fraud reporting channels, complaint timelines and the compensation mechanismResponsible Business Conduct Third Amendment Directions 2026, paragraphs 76G to 76U: 24x7 reporting channels, the National Cyber Crime Helpline (1930) advice, resolution within 45 or 60 days, and one-time compensation for small-value fraud losses. This is the bank's customer-protection process. Our signed records help establish the facts; they are not the process.
  • Transaction monitoring and fraud-detection rulesDigital Payment Security Controls MD, paragraphs 36 and 37, require rules and parameterised alerts on velocity, geo-location, IP origin, behavioural biometrics and mule-linked beneficiaries. That is the bank's fraud programme. FortAuth supplies device and authentication signals to it but is not the programme.
  • DPDP consent notices, breach intimation and Data Protection Board obligationsDPDP Rules 2025, rules 3 and 7, and the DPDP Act 2023 duties of a Data Fiduciary sit with the bank. Recording and transcribing calls needs a lawful basis that the bank must establish; we make no claim about which applies. The Act's own commencement notification was not read.
  • RBI model risk management guidance for AI and ML modelsNot cited. RBI is reported to have issued draft guidance on model risk management on 24 June 2026 that covers AI models. We could not obtain the RBI text, so we make no claim about it. The FREE-AI report cited above is a committee report, not a direction.
Sources

Every clause cited on this page was read in the document below, on the regulator’s own site.

This mapping is provided for guidance and must be validated by the bank's compliance function against the current version of each framework.

Deployment options in India

Served from our UAE and Pakistan offices with in-country deployment: on-premise, Indian-region cloud, or hybrid.

Deployment shapes

On-premiseIn-region cloudHybrid

Runs on

Amazon Web ServicesMicrosoft AzureGoogle Cloud

Deployed into your own account and your own region on any of the three, or on-premise where the data must not leave your estate at all.

RBI questions, answered.

They fit it closely. Paragraph 6 of the Authentication Directions 2025 requires two distinct factors, from something the user has, knows or is, and paragraph 5 lists device-native biometrics among them. For anything other than card-present transactions, one factor must be dynamically proven, unique to the transaction. A FortAuth passkey pairs a device-bound private key, something you have, with the phone's biometric or PIN, something you are or know. Each approval signs a challenge unique to that transaction. The Digital Payment Security Controls Master Direction names device binding, biometrics and PKI as examples of non-replicable methods. RBI does not name FIDO2, so the bank should record its own assessment under paragraph 9(a).

Not by rule. The 2025 directions still list SMS OTP as a valid factor. What they do is end its status as the default: RBI notes that no factor was mandated and the market settled on SMS OTP, and the directions exist to make room for alternatives. The 2021 security Master Direction already asked banks to consider alternatives where the OTP and the app share a phone. Two things do not change. SMS transaction alerts remain mandatory, for every transaction above ₹500 under the 2026 amendment. And the issuer, not the customer, carries the loss when authentication falls short.

Yes. All three products run on-premise in the bank's data centre, in an Indian cloud region, or hybrid. On the rules: RBI's 2018 circular requires the entire data relating to payment systems, including end-to-end transaction details, to be stored only in India. The IT outsourcing Master Direction requires agreements to provide for storage only in India where extant rules require it, and to give the bank access to all data and logs. From May 2027 the DPDP Rules add encryption, access logging and one-year log retention. An in-country deployment answers all of these most simply.

It cites RBI's own paragraph numbers, links to RBI-hosted texts, and keeps what the product does separate from what stays with the bank. The India mapping covers Authentication Directions paragraphs 6, 8 and 9, Digital Payment Security Controls paragraphs 30, 33, 34, 60 and 61, IT Governance paragraph 15, IT Outsourcing paragraphs 4, 16 and 17, and the 2026 customer-protection amendment's paragraphs 76B and 76K. It names what is out of scope: SMS alerts, payment-data storage, interoperability, cross-border CNP validation and the fraud and complaints process. It treats FREE-AI as recommendations, not rules. FortAgent discloses AI and hands over to a person anyway.

Get the RBI control mapping

The full control-by-control mapping for FortAuth, FortVoice and FortAgent, as a document your compliance function can review.

Other markets