Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026: An Overview

Introduction

The Reserve Bank of India ('RBI'), in exercise of the powers conferred under the extant provisions of the Banking Regulation Act, 1949, Chapter IV of the Payment and Settlement Systems Act, 2007, and all other enabling provisions, has issued the Reserve Bank of India (Commercial Banks – Digital Payment Security Controls) Directions, 2026 vide circular RBI/DoS/2026-27/411, DoS.CO.CSITEG.5/31.01.015/2026-27 dated July 31, 2026 ('the Directions'). The Directions consolidate and strengthen the regulatory framework governing security controls for digital payment products and services offered by commercial banks, and come into effect immediately upon issuance.

Applicability

The Directions apply to Commercial Banks, defined to mean banking companies (other than Small Finance Banks, Payments Banks, and Local Area Banks), corresponding new banks, and the State Bank of India, as respectively defined under clauses (c), (da), and (nc) of Section 5 of the Banking Regulation Act, 1949.

The scope extends to any digital payment product or service offered by a bank for financial and non-financial transactions — including balance enquiry, PIN generation/change, mobile banking registration, OTP generation, mini-statements, transaction status checks, and grievance redressal — whether offered directly by the bank or through a system operated by RBI or an RBI-authorised Payment System Operator (PSO), along with the associated IT assets.

Chapter II: Role of the Board

Paragraph 7 mandates that the Board of Directors approve all policies relating to digital payment products and services, with such policies subject to at least annual review by the Board.

Chapter III: General Controls

A. Governance and Management of Security Risks

Under Paragraph 8, banks are required to formulate a Board-approved policy for digital payment products and services addressing payment security requirements from a Functionality, Security and Performance (FSP) perspective. This includes controls to protect data confidentiality and integrity, infrastructure adequacy, secure product rollout following requisite testing, scalability, minimal service disruption, effective dispute resolution, and a swift corrective action mechanism. Foreign banks are exempted from maintaining a separate local policy where these aspects are adequately covered in their global policy.

Paragraphs 9 to 20 further require: Board and Senior Management accountability for policy implementation; a clearly defined digital payment cycle including exception handling and User Acceptance Testing (UAT) protocols; external assessment of application logic, build, and security; integration of compliance and fraud risk into governance programs; performance monitoring through defined product-level risk limits and quantitative benchmarks (e.g., RTO/RPO, transaction failure rates); trained resources and third-party oversight; comprehensive risk assessments covering technology stack, vulnerabilities, third-party dependence, data protection, and business continuity; Risk and Control Self-Assessment (RCSA) exercises; and half-yearly testing of backup recovery capabilities.

B. Other Generic Security Controls

Paragraphs 21 to 26 prescribe secure communication protocols, prohibition on storing sensitive data in HTML hidden fields/cookies/client-side storage, implementation of Web Application Firewall (WAF) and DDoS mitigation, adoption of strong and non-deprecated cryptographic standards, timely renewal of digital certificates, and effective logging/monitoring of user activity across mobile and internet banking applications.

C. Application Security Life Cycle

Paragraphs 27 to 40 mandate a multi-tier application architecture with segregated application, database, and presentation layers, and a 'secure by design' development approach. Banks must define security objectives across the requirements-gathering, design, development, testing, implementation, and decommissioning phases, and adopt threat modelling — including for co-branded/co-developed applications. Source code escrow arrangements are required for third-party licensed applications.

Security testing obligations include Vulnerability Assessment (VA) at least half-yearly, Penetration Testing (PT) at least annually, and compliance with OWASP standards, with additional testing triggered upon introduction of new infrastructure or major changes. Where source code is not owned by the bank, a vulnerability-free certificate must be obtained from the developer, along with penal provisions in third-party contracts for non-compliance. Banks must also monitor for non-genuine or malicious applications on app stores, ensure centralised and robust server-side authentication, and redact sensitive customer information transmitted via SMS/email.

D. Authentication Framework

Paragraphs 41 to 51 mandate multi-factor authentication (MFA) for payments, fund transfers, and ATM/micro-ATM/business correspondent cash withdrawals, with at least one dynamic or non-replicable authentication factor (e.g., OTP, device binding, biometrics, PKI/hardware tokens, or EMV chip with server-side verification). MFA implementation must be risk-based, considering customer type, transaction pattern, and data sensitivity. Alerts and OTPs must identify the merchant name rather than the payment aggregator. Banks must implement safeguards against man-in-the-middle/browser/application attacks, ensure session integrity, and set thresholds for failed authentication attempts with secure reactivation procedures.

E. Fraud Risk Management

Paragraphs 52 to 56 require banks to document configuration rules for identifying suspicious transactional behaviour, covering parameters such as transaction velocity, high-risk MCCs, counterfeit card indicators, new account activity, geo-location and IP anomalies, and behavioural biometrics. Banks must conduct fraud analysis, train fraud-control staff across specified competencies, and maintain updated stakeholder contact details along with incident-specific Standard Operating Procedures (SOPs).

F. Reconciliation Mechanism

Paragraph 57 mandates a real-time or near-real-time reconciliation framework (not later than 24 hours from receipt of settlement files) across all stakeholders in the digital payment ecosystem, along with a mechanism to monitor its effectiveness.

G. Customer Protection, Awareness and Grievance Redressal Mechanism

Paragraphs 58 to 66 require mandatory customer acknowledgment of secure usage guidelines during onboarding and post-update, a clearly defined grievance redressal mechanism with defined response timelines, adherence to the RBI's Online Dispute Resolution (ODR) framework (RBI/2020-21/21 dated August 6, 2020), customer education on device security and digital payment risks, express customer consent for channel activation, and a mechanism enabling customers to flag transactions as fraudulent for immediate bank notification.

Chapter IV: Internet Banking Security Controls

Paragraph 67 prescribes additional controls for internet banking, including adaptive authentication and CAPTCHA against brute-force/DoS attacks, DNS cache poisoning prevention, virtual keyboard availability, automatic session termination on inactivity, secure and time-bound password delivery with mandatory first-login change, and uniform authentication experience across external website integrations.

Chapter V: Mobile Payments Application Security Controls

Paragraph 68 sets out detailed controls for mobile banking/payment applications, including anomaly-triggered reinstallation protocols, device policy enforcement, secure download/installation, time-bound deactivation of older application versions (within six months), remote-access application detection, device/application encryption, minimal data collection, sandboxing, code obfuscation, device binding with multi-channel notification for new registrations, re-authentication on inactivity, unsecured network detection, prohibition on storing sensitive authentication data on-device, secure handling of temporary files, and protections against SQL injection and SSL/TLS certificate errors.

Chapter VI: Card Payment Security Controls

Paragraph 69 mandates adherence to PCI standards beyond PCI-DSS and PCI-SSF, namely PCI-PIN, PCI-PTS, PCI-HSM, and PCI-P2PE, applicable to banks in both issuer and acquirer capacities, with compliance status reported to the IT Strategy Committee under the RBI (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026. Detailed HSM-level controls (tamper-proof logging, clustering for high availability, ACL-based access, secure key management including LMKs) and ATM security measures (BIOS password protection, USB port disabling, anti-skimming, whitelisting, supported OS versions) are prescribed. Banks must also implement card/BIN/bank-level transaction limits at the network switch, 24x7 breach monitoring, and prohibitions on storing card details in plain text. Specific safeguards govern the use of card data scanning tools, including on-premises installation, prohibition on remote scanning, and strict controls on data export.

Chapter VII: Repeal and Other Provisions

Paragraph 70 repeals all existing directions, instructions, and guidelines on Digital Payment Security Controls applicable to Commercial Banks, as communicated vide circular DoS.CO.PPG.66/11.01.005/2026-27 dated July 31, 2026. Paragraph 71 preserves actions, rights, obligations, and liabilities accrued under the repealed framework, along with continuation of any pending investigations or legal proceedings. Paragraph 72 clarifies that the Directions operate in addition to, and not in derogation of, other applicable laws and regulations. Paragraph 73 vests RBI with the authority to issue clarifications for removing difficulties in interpretation, with such interpretation being final and binding.

Conclusion

The Directions represent a consolidated and considerably more granular regulatory architecture for digital payment security, moving several previously advisory practices into binding requirements — particularly around Board-level accountability, application security testing cadence, authentication design, and third-party oversight. Commercial banks will need to undertake a comprehensive gap assessment of existing digital payment policies, application security lifecycles, and card/mobile/internet banking controls to align with the Directions, given their immediate effect.