Closing the Loop: Defining Dynamic Authentication under RBI’s 2025 Directions

[Pranav is a student at Maharashtra National Law University, Mumbai.]

At a time when INR 24.85 lakh crore UPI transactions were recorded in August 2025, the Reserve Bank of India (RBI) has issued the Reserve Bank of India (Authentication Mechanisms for Digital Payment Transactions) Directions 2025 (Directions), to further the security framework for the rapidly increasing digital payment ecosystem in India. The Directions mandate that every domestic digital payment transaction shall use two different authentication factors, of which at least one is either dynamically created or dynamically proven. This regulatory update replaces the earlier generic requirement of two-factor authentication with a design-based regime so as to promote the adoption of advanced, risk-based, and interoperable authentication methods. RBI's intent is to address increasing incidents of fraud in digital payments while promoting innovation and neutrality on technology use across payment system providers.

Against this backdrop, this article addresses three aspects: firstly, it explains the new Directions and the rationale behind their introduction; secondly, it critically analyses the issue how to define a “dynamic” factor of authentication; and, thirdly, it provides a comparative analysis with similar regulatory regimes in other jurisdictions like the EU and Singapore. It further provides suggestions for policy additions peculiar to the Indian environment to bring clarity, interoperability, and robust consumer protection to the authentication framework set by the RBI.

The 2025 Directions: What Has Changed and Why?

The RBI has, in exercise of powers under the Payment and Settlement Systems Act 2007, published a milestone framework for regulating the authentication of digital payment transactions through its Directions. Para 6 of the directions, mandates the use of at least two different factors of authentication (2FA) for authenticating all domestic digital payment transactions, each falling under one of the following three categories, as defined under Para 5(I)(f): ‘something the user knows,’ ‘something the user has,’ or ‘something the user is.’ Significantly, at least one factor should be dynamic; that is, dynamically created or dynamically proved to ensure that the proof of possession is unique to each transaction.

This shift is rooted in RBI's recognition that the earlier one time password (OTP) based authentication model, though effective in 2011, has become increasingly vulnerable to phishing, SIM-swap, and relay attacks. Digital frauds have increased by five times with a surge of 85% in UPI fraud cases in FY 2024. As India's payment ecosystem now processes billions of UPI, card, and wallet transactions monthly, the reliance on static authentication mechanisms exposes systemic risks. Hence, RBI's intent is to encourage the use of advanced, risk-based, and context-aware authentication methods leveraging device intelligence, biometrics, and tokenization for transaction validation.

Furthermore, the Directions introduce a risk-based authentication principle under Para 8, thus allowing an issuer to assess a transaction based on behavioural or contextual parameters like device attributes, location, and transaction history. Depending upon the perceived risk, the issuers may deploy additional checks beyond the mandatory 2FA or use secure platforms like DigiLocker for the confirmation of high-risk transactions. All payment system providers and payment system participants are mandated to ensure compliance with the directions by 1 April 2026.

Conceptually, this regulatory step changes the nature of authentication from a static, rules-based process to a dynamic and design-based framework that focuses on the specificity of a transaction, interoperability, and assurance in real time.

Identifying the Regulatory Gap

The Directions do not explain precisely what constitutes a "dynamic" factor. This lack of definition invites payment service providers to adopt cursory or inconsistent mechanisms that satisfy compliance formally but do not guarantee actual transaction security. It becomes important to analyse this from the mechanism laid down under Para 6(b), which requires the factor of authentication to be dynamically created or proven alongside Para 5(I)(f), which brings in the three aspects of factors of authentication: something the user knows, has, or is.

Firstly, a dynamically created factor is one that creates a new credential with every authentication, like OTP, time-based passcodes (TOTPs), and more. This has been supplemented by Para 5(I)(f) with the use of independent factor categories. While this takes into consideration factor-based authentication, it doesn’t make authentication transaction bound. In other words, the framework verifies who is initiating the transaction but not what transaction has been approved. The Directions do not require the dynamically generated credential to be cryptographically tied to the transaction amount, payee, or timestamp. Consequently, the system checks only the integrity of the code, but not the integrity of the transaction context. 

A person can intercept an OTP or TOTP and use it to perform a modified or unauthorized payment, as the system will have simply checked for the validity of the code and not whether it was indeed against the transaction intended by the user. These are inter alia in the form of a Man in the Middle attack wherein the attacker intercepts and relays communication between two parties. This was observed in the case of a Pune based company where the attackers altered details of payment of INR 6.49 crore after authentication.

Secondly, a dynamically proved factor generally involves verification of an element that demonstrates possession or control, such as PIN-codes, SIM identifiers, or in-app tokens. They can be easily reproduced via SIM swapping, virtual device emulators, or malware that can emulate a trusted device environment. In the absence of any per-transaction proof of possession required by the Directions, a person can trigger valid approvals from compromised devices. This was reflected in the Digital Threat Report 2024 by CERT-In, indicating how attacks using cloned mobile apps and spoofed devices in the digital payment ecosystem are one of the anticipated attacks for 2025. 

Comparative Perspectives and Policy Recommendations 

Two regimes, herein, become particularly relevant: the European Union under the Commission Delegated Regulation (EU) 2018/389 and the Monetary Authority of Singapore (MAS) under its Technology Risk Management (TRM) Guidelines. Both make clear, in different ways, that “dynamic” is not just “new every time”; it is “new and bound to this transaction.” 

Firstly, Article 4 of the regulation provides for generation of an authentication code. Payment service providers are required to ensure (a) no information pertaining to knowledge, possession, and inherence of the transaction can be derived from the authentication code; (b) no new authentication code can be generated on the basis of knowledge of a previously generated authentication code; and (c) no authentication can be forged. This is explicit in the Regulatory Technical Standards on Strong Customer Authentication (SCA) and Common and Secure Communication. The net result is that cryptographic code integrity is established as the authentication functions as a one-time, non-derivable cryptographic output rather than a reusable credential. 

In addition, Article 5 of the regulation provides for "dynamic linking", i.e., (a) the authentication code to be specific to the amount and payee and to become invalid if either changes. Payment service providers shall also ensure that (b) the authentication code is specific to the amount of the transaction; (c) authentication must correspond to original values; and (d) any change to the amount or payee results in invalidation of the authentication code. 

RBI allows "dynamically created" factors such as OTP/TOTP but does not insist that the factor carry any security parameters as seen above. In the EU, where the user authenticates, but a fraudster or scammer alters the beneficiary, the transaction would still fail as the changed payee would have invalidated the SCA token. Concretely, an explanatory note to Para 6(b) can help incorporate transaction-bound authentication, stating that a factor will be considered "dynamically created" only if it is cryptographically tied to: (i) amount, (ii) payee, and (iii) time window. 

Secondly, the 2021 TRM Guidelines direct financial institutions to use strong authentication, secure credential storage and to protect mobile apps and devices against cloning/emulation. They stress that credentials stored on end-user devices must be protected in secure hardware or equivalent controls and that authentication should be stepped up based on context. That speaks to the Indian problem of SIM-based or app-level identifiers being used as "possession." MAS would treat a SIM number or soft device ID as insufficient unless it is backed by secure storage and runtime protections. 

India can mirror this without becoming prescriptive. RBI can add a schedule on levels of possession assurance, for example, Level 1: soft identifier; Level 2: TEE/secure element-backed key; Level 3: FIDO2/WebAuthn attestation. Only Level 2 and above should qualify as "dynamically proven" for Para 6(b) purposes.

Conclusion 

The Directions mark an important shift away from static authentication to stronger, risk-aware controls. In mandating dynamically created or dynamically proven factors, the Directions recognize that traditional OTP-based mechanisms are insufficient in today’s fraud environment. How effective this shift will be, however, depends on how “dynamic” is defined and enforced in practice.

The central gap revealed by this blog is not the absence of multi-factor authentication but the absence of a clear, enforceable requirement that authentication be transaction-specific. Though the Directions ensure that the correct user has been authenticated, they do not always guarantee that the transaction ultimately executed is, in fact, the one the user approved. In the absence of cryptographic transaction binding, even valid dynamic credentials can be misused in relay, interception, or man-in-the-browser attacks.

The way forward for India is to clarify the operational meaning of "dynamic" under Para 6(b) through focused guidance or an explanatory note. This would ensure that dynamic authentication secures not only user identity but also the integrity of each transaction, thereby closing the loop envisioned by the Directions.