Small Finance Banks – Digital Payment Security Controls Directions, 2026
RBI notification RBI/DoS/2026-27/420 · 31 Jul 2026
Official title
Reserve Bank of India (Small Finance Banks – Digital Payment Security Controls) Directions, 2026
RBI notification RBI/DoS/2026-27/420 · 31 Jul 2026
Official title
Reserve Bank of India (Small Finance Banks – Digital Payment Security Controls) Directions, 2026
Summary
Check the official recordThe Reserve Bank of India has issued comprehensive directions for Small Finance Banks (SFBs) to strengthen security controls for digital payment products and services. The framework mandates Board-approved policies, robust risk management, and secure application lifecycles, including vulnerability assessments and penetration testing. SFBs must implement multi-factor authentication, real-time transaction reconciliation, and fraud risk management systems. Specific security requirements are detailed for internet banking, mobile applications, and card payment infrastructure, including compliance with PCI standards and ATM security measures. SFBs are required to ensure customer protection through awareness, grievance redressal, and secure usage guidelines. These directions take immediate effect and supersede previous instructions on the subject.
What you must do
Key dates
Who is affected
RBI/DoS/2026-27/420 DoS.CO.CSITEG.14/31.01.015/2026-27 July 31, 2026
In exercise of the powers conferred by extant provisions of the Banking Regulation Act, 1949, Chapter IV of Payment and Settlement Systems Act, 2007, and all other provisions / laws enabling the Reserve Bank of India (‘RBI’) in this regard, RBI being satisfied that it is necessary and expedient in the public interest so to do, hereby issues Directions hereinafter specified.
The following definitions are sourced from Financial Stability Board (FSB) Cyber Lexicon unless explicitly mentioned otherwise. In these Directions, unless the context states otherwise, the terms herein shall bear the meanings assigned to them below. (1) ‘Availability’ - Property of being accessible and usable on demand by an authorised entity. (2) ‘Confidentiality’ - Property that information is neither made available nor disclosed to unauthorised individuals, entities, processes, or systems. (3) ‘Cyber’ - Relating to, within, or through the medium of the interconnected information infrastructure of interactions among persons, processes, data, and information systems. (4) ‘Cybersecurity’ - Preservation of confidentiality, integrity, and availability of information and / or information systems through the cyber medium. In addition, other properties, such as authenticity, accountability, non-repudiation, and reliability can also be involved. (5) ‘Cyber-attack’ - Malicious attempt(s) to exploit vulnerabilities through the cyber medium to damage, disrupt, or gain unauthorised access to assets. (6) ‘Distributed Denial of Service (DDoS)’ - A denial of service that is carried out using numerous sources simultaneously. (7) ‘Framework’ - A framework is a structured set of strategies, policies, procedures, methods, and best practices that guides organisational activities, enables governance, and supports the achievement of defined objectives. (Source: adapted from ISACA glossary) (8) ‘Information System’ - Set of applications, services, information technology assets, or other information-handling components, which includes the operating environment and networks. (9) ‘Integrity’ - Property of accuracy and completeness. (10) ‘Malware’ - Software designed with malicious intent containing features or capabilities that can potentially cause harm directly or indirectly to entities or their information systems. (11) ‘Penetration Testing’ - A test methodology in which assessors typically working under specific constraints, attempt to circumvent or defeat the security features of an information system. (12) ‘Phishing’ - A digital form of social engineering that attempts to acquire private or confidential information by pretending to be a trustworthy entity in an electronic communication. (13) ‘Vulnerability’ - A weakness, susceptibility, or flaw of an asset or control that can be exploited by one or more threats. (14) ‘Vulnerability Assessment (VA)’ - Systematic examination of an information system or product to determine the adequacy of security measures, identify security deficiencies, provide data from which to predict the effectiveness of proposed security measures and confirm the adequacy of such measures after implementation.
All other expressions unless defined herein shall have the same meaning as have been assigned to them under the Reserve Bank of India Act, 1934, or the Banking Regulation Act, 1949, or the Payment and Settlement Systems Act, 2007, or the Information Technology Act, 2000, or the Companies Act, 2013, or any statutory modification or re-enactment thereto or other regulations issued by the RBI or the Glossary of Terms published by the RBI or as used in commercial parlance as used in RBI Directions, as the case may be.
The bank shall formulate a policy for digital payment products and services with the approval of its Board. The contours of the policy, while discussing the parameters of any ‘new product’ including its alignment with the overall business strategy and inherent risk of the product, risk management / mitigation measures, compliance with regulatory instructions, and customer experience, shall explicitly cover payment security requirements from Functionality, Security and Performance (FSP) angles such as: (1) necessary controls to protect the confidentiality of customer data and integrity of data and processes associated with the digital product / services offered; (2) availability of requisite infrastructure such as human resources and technology with necessary backup; (3) assurance that the payment product is built in a secure manner offering robust performance ensuring safety, consistency, and rolled out after necessary testing for achieving desired FSP; (4) capacity building and expansion with scalability (to meet the growth for efficient transaction processing); (5) minimal customer service disruption with high availability of systems / channels (to have minimal technical declines); (6) efficient and effective dispute resolution mechanism and handling of customer grievance; and (7) adequate and appropriate review mechanism followed by swift corrective action, in case any one of the above requirements is hampered or having high potential to get hampered.
The Board and Senior Management shall be responsible for implementation of this policy. The policy shall be reviewed at least annually. The bank may formulate this policy separately for its different digital products / services or include the same as part of its overall product policy.
The policy shall require that every digital payment product / service offered addresses the mechanics, clear definition of starting point, critical intermittent stages / points and end point in the digital payment cycle, security aspects, validations till the digital payment is settled, clear pictorial representation of digital path, exception handling, signing off of the above requirements, mechanism for carrying out User Acceptance Tests (UAT) in multiple stages before roll-out, sign off from multiple stakeholders [post User Acceptance Test (UAT)], and data archival requirements.
The bank shall clearly articulate the need for an external assessment of the entire process including the logic, build, and security aspects of the application(s) supporting the digital product or service.
The bank shall incorporate appropriate processes into its governance and risk management programs for identifying, analysing, monitoring, and managing the specific risks, including compliance risk and fraud risk, associated with the portfolio of digital payment products and services on a continual basis and in a holistic manner.
The Senior Management of the bank shall have appropriate performance monitoring systems / key performance indicators for assessing whether the product or service offered through digital payment channels meets operational and security norms. As part of this process, the bank shall define product-level limits on the level of acceptable security risk, document specific security objectives, and performance criteria including quantitative benchmarks for: (1) evaluating the success of the security built into the digital payment product or service; (2) comparing actual results with projections and qualitative benchmarks on a periodic basis to detect and address adverse trends or concerns in a timely manner; and (3) modifying the business plan / strategy involving the product or service, when appropriate, based on its security performance.