Laws and sections by number or title, due dates, pages, and updates.
No summary yet. Read the master direction below or open the official pdf.
RBI/2020-21/74 DoS.CO.CSITE.SEC.No.1852/31.01.015/2020-21 February 18, 2021 The Chairman/ Managing Director/ Chief Executive Officer All Scheduled Commercial Banks excluding RRBs/ Small Finance Banks/Payments Banks/ Credit Card issuing NBFCs. Madam/ Dear Sir, Master Direction on Digital Payment Security Controls Please refer to para II (7) of the Statement on Developmental and Regulatory Policies of the Bi-monthly Monetary Policy Statement for 2020-21 dated December 4, 2020 ( extract given below ). The Master Direction provides necessary guidelines for the regulated entities to set up a robust governance structure and implement common minimum standards of security controls for digital payment products and services. Yours faithfully, (T.K. Rajan) Chief General Manager Digital Payment Security Controls Going by the pre-eminent role being played by digital payment systems in India, RBI gives highest importance to the security controls around it. Now it is proposed to issue Reserve Bank of India (Digital Payment Security Controls) Directions 2020, for regulated entities to set up a robust governance structure for such systems and implement common minimum standards of security controls for channels like internet, mobile banking, card payments, among others. While the guidelines will be technology and platform agnostic, it will create an enhanced and enabling environment for customers to use digital payment products in more safe and secure manner. Necessary guidelines will be issued separately. Index Introduction Chapter I - Preliminary Short Title and Commencement Applicability Definitions Chapter II - General Controls Governance and Management of Security Risks Other Generic Security Controls Application Security Life Cycle (ASLC) Authentication Framework Fraud Risk Management Reconciliation Mechanism Customer Protection, Awareness and Grievance Redressal Mechanism Chapter III - Internet Banking Security Controls Chapter IV - Mobile Payments Application Security Controls Chapter V - Card Payments Security Acronyms Master Direction on Digital Payment Security Controls INTRODUCTION In exercise of the powers conferred by the Banking Regulation Act, 1949, the Reserve Bank of India Act, 1934 and Payment and Settlement Systems Act, 2007, the Reserve Bank, being satisfied that it is necessary and expedient in the public interest so to do, hereby, issues the directions hereinafter specified.
CHAPTER – I PRELIMINARY
Short Title and Commencement These directions shall be called the Reserve Bank of India (Digital Payment Security Controls) directions, 2021. These directions shall come into effect six months from the day they are placed on the official website of the Reserve Bank of India (RBI). However, in respect of instructions already issued either by Department of Payment and Settlement Systems (DPSS), Department of Regulation (DoR) or Department of Supervision (DoS) of RBI including those to select Regulated Entities (REs), by way of circular or advisory, the timeline would be with immediate effect or as per the timelines already prescribed.
Applicability The provisions of these directions shall apply to the following Regulated Entities (REs):
CHAPTER – II GENERAL CONTROLS
Governance and Management of Security Risks 4. REs shall formulate a policy for digital payment products and services with the approval of their 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, customer experience, etc., should explicitly discuss about payment security requirements from Functionality, Security and Performance (FSP) angles such as:
REs shall incorporate appropriate processes into their 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 Board/ Senior Management of REs shall have appropriate performance monitoring systems/ key performance indicators for assessing whether the product or service offered through digital payment channels meet operational and security norms.
As part of this process, the REs shall define product-level limits on the level of acceptable security risk, document specific security objectives and performance criteria including quantitative benchmarks for evaluating the success of the security built into the digital payment product or service, periodically compare actual results with projections and qualitative benchmarks to detect and address adverse trends or concerns in a timely manner and modify the business plan/ strategy involving the product, when appropriate, based on the security performance of the product or service.
REs shall have trained resources with necessary expertise to manage the digital payment infrastructure. Wherever the REs are dependent on third party service providers, adequate oversight and controls for monitoring the activities of the third party personnel, in line with RBI guidelines on outsourcing, shall be put in place.
REs shall conduct risk assessments with regard to the safety and security of digital payment products and associated processes and services as well as suitability and appropriateness of the same vis-a-vis the target users, both prior to establishing the service(s) and regularly thereafter. The risk assessment should take into account –
REs shall evaluate the risks associated with the chosen technology platforms, application architecture, both on the server and client side. Further, REs should undertake a review of the risk scenarios and existing security measures based on incidents affecting their services, before any major change to the infrastructure or procedures is made or, when, any new threats are identified through risk monitoring activities. Further, unused or unwanted features of the platform should be closely controlled to minimise risk.
REs shall develop sound internal control systems and take into account the operational risk before offering digital payment products and related services. This would include ensuring that adequate safeguards are in place to protect integrity of data, customer confidentiality and security of data.
REs shall ensure that the digital payment architecture is robust and scalable, commensurate with the transaction volumes and customer growth. The IT strategy of the RE shall ensure that a robust capacity management plan is in place to meet evolving demand. REs shall also put in place review mechanism of IT/ IT Security architecture and technology platform overhaul on a periodic basis based on Board-approved policy.
REs shall have necessary capacity, systems and procedures in place to periodically test the backed-up data, application pertaining to digital products to ensure recovery without loss of transactions or audit-trails. These facilities should be tested at least on a half-yearly basis for digital payment products and services.
Other Generic Security Controls 13. The communication protocol in the digital payment channels (especially over Internet) shall adhere to a secure standard. An appropriate level of encryption and security shall be implemented in the digital payment ecosystem.
Web applications providing the digital payment products and services should not store sensitive information in HTML hidden fields, cookies, or any other client-side storage to avoid any compromise in the integrity of the data.
REs shall implement Web Application Firewall (WAF) solution and DDoS mitigation techniques to secure the digital payment products and services offered over Internet.
The key length (for symmetric/ asymmetric encryption, hashing), algorithms (for encryption, signing, exchange of keys, creation of message digest, random number generators), cipher suites, digital certificates and applicable protocols used in transmission channels, processing of data, authentication purpose, shall be strong, adopting internationally accepted and published standards that are not deprecated/ demonstrated to be insecure/ vulnerable and the configurations involved in implementing such controls are in general, compliant with extant instructions and the law of the land.
REs shall renew their digital certificates used in digital payment ecosystem well in time.
The mobile application 2 and internet banking application should have effective logging and monitoring capabilities to track user activity, security changes and identify anomalous behaviour and transactions.
Application Security Life Cycle (ASLC) 19. REs shall implement multi-tier application architecture, segregating application, database and presentation layer in the digital payment products and services.
REs shall follow a ‘secure by design’ approach in the development of digital payment products and services. REs shall ensure that digital payment applications are inherently more secure by embedding security within their development lifecycle.
REs shall explicitly define security objectives (including protection of customer information/ data) during (a) requirements gathering, (b) designing, (c) development, (d) testing including source code review, (e) implementation, maintenance & monitoring and (f) decommissioning phases of the digital payment applications.
REs (including those partnering with other entities to co-brand/ co-develop applications) shall adopt and incorporate a threat modelling approach during application lifecycle management into their policies, processes, guidelines and procedures.
For digital payment applications that are licensed by a third party vendor, REs shall have an escrow arrangement for the source code for ensuring continuity of services in case the vendor defaults or is unable to provide services.
REs shall conduct security testing including review of source code, Vulnerability Assessment (VA) and Penetration Testing (PT) of their digital payment applications to assure that the application is secure for putting through transactions while preserving confidentiality and integrity of the data that is stored and transmitted. Such testing should invariably cover compliance with various standards like OWASP. If the source code is not owned by the RE, then, in such cases, the RE shall obtain a certificate from the application developer stating that the application is free of known vulnerabilities, malwares and any covert channels in the code. In this context,
REs may also run automated VA scanning tools to automatically scan all systems on the network that are critical, public facing or store customer sensitive data on a continuous/ more frequent basis.
REs shall compare the results from earlier vulnerability scans to verify/ ascertain that vulnerabilities are addressed either by patching, implementing a compensating control, or documenting and accepting the residual risk with necessary approval and that there is no recurrence of the known vulnerabilities. The identified vulnerabilities should be fixed in a time-bound manner.
REs shall ensure that all vulnerability scanning is performed in authenticated mode either with agents running locally on the system to analyse the security configuration or with remote scanners that are given administrative rights on the system being tested. 3
REs shall verify and thoroughly test the functionality (to validate whether the system meets the functional requirements/ specifications) and security controls of payment products and services before its launch/ moving to the production environment.
REs shall institute a mechanism to actively monitor for the non-genuine/ unauthorised/ malicious applications (with similar name/ features) on popular app-stores and the Web and respond accordingly to bring them down.
The server at the RE’s end should have adequate checks and balances to ensure that no transaction is carried out through non-genuine/ unauthorised digital payment products/ applications and the authentication process is robust, secure and centralised.
The security controls for digital payment applications must focus on how these applications handle, store and protect payment data. The APIs for secure data storage and communication have to be implemented and used correctly in order to be effective. REs shall refer to standards such as OWASP-MASVS, OWASP-ASVS and other relevant OWASP standards, security and data protection guidelines in ISO 12812, threat catalogues and guides developed by NIST (including for Bluetooth and LTE security), for application security and other protection measures. Such testing has to necessarily verify for vulnerabilities including, but not limited to OWASP/ OWASP Mobile Top 10, application security guidelines/ requirements developed/ shared by operating system providers/ OEMs.
REs shall redact/ mask customer information such as account numbers/ card numbers/ other sensitive information when transmitted via SMS/ e-mails.
Authentication Framework 33. In view of the proliferation of cyber-attacks and their potential consequences, REs should implement, except where explicitly permitted/ relaxed, multi-factor authentication for payments through electronic modes and fund transfers, including cash withdrawals from ATMs/ micro-ATMs/ business correspondents, through digital payment applications. At least one of the authentication methodologies should be generally dynamic or non-replicable. [e.g., Use of One Time Password, mobile devices (device binding and SIM), biometric/ PKI/ hardware tokens, EMV chip card (for Card Present Transactions) with server-side verification could be termed either in dynamic or non-replicable methodologies.].
The implementation of appropriate authentication methodologies should be based on an assessment of the risk posed by the RE’s digital payment products and services. The risk should be evaluated in light of the type of customer (e.g., retail/ corporate/ commercial); the customer transactional requirements/ pattern (e.g., bill payment, fund transfer), the sensitivity of customer information and the volume, value of transactions involved. Beyond the technology factor, the success of a particular authentication method depends on appropriate policies, procedures, and controls. An effective authentication method should take into consideration customer acceptance, ease of use, reliable performance, scalability to accommodate growth, customer profile, location, transaction, etc., and interoperability with other systems. To enhance online processing security, multi factor authentication and alerts (like SMS, e-mail, etc.) should be applied in respect of all payment transactions (including debits and credits), creation of new account linkages (addition/ modification/ deletion of beneficiaries), changing account details or revision to fund transfer limits. In devising these security features, REs should take into account their efficacy and differing customer preferences for additional online protection. The alerts and OTPs received by the customer for online transactions shall identify the merchant name, wherever applicable, rather than the payment aggregator through which the transaction was effected. As an integral part of the multi factor authentication architecture, REs should also implement appropriate measures to minimise exposure to a middleman attack which is more commonly known as a man-in-the-middle attack (MITM), man-in-the browser (MITB) attack or man-in-the application attack. This is to ensure, among other things, that the data in transit is secured and the transactions are authenticated only by genuine/ authorised source/ process. An authenticated session, together with its encryption protocol, should remain intact throughout the interaction with the customer. Else, in the event of interference or in case the customer closes the application, the session should be terminated, and the affected transactions resolved or reversed out. The customer should be promptly notified about the status of the transaction by email, SMS or through other means. 35. REs should set down the maximum number of failed log-in or authentication attempts after which access to the digital payment product/ service is blocked. They should have a secure procedure in place to re-activate the access to blocked product/ service. The customer shall be notified for failed log-in or authentication attempts. Fraud Risk Management 36. The REs shall document and implement the configuration aspects for identifying suspicious transactional behaviour in respect of rules, preventive, detective types of controls, mechanism to alert the customers in case of failed authentication, time frame for the same, etc. 37. System alerts shall be parameterised and monitored in terms of various applicable parameters. Such parameters, as applicable could be: transaction velocity (e.g., fund transfers, cash withdrawals, payments through electronic modes, adding new beneficiaries, etc.) in a short period, more so in the accounts of customers who’ve never used mobile app/ internet banking/ card ever (depending upon the type of payment channel), high risk merchant category codes (MCC) parameters, counterfeit card parameters (String of Invalid CVV/ PINs indicates an account generation attack), new account parameters (excessive activity on a new account), time zones, geo-locations, IP address origin (in respect of unusual patterns, prohibited zones/ rogue IPs), behavioural biometrics, transaction origination from point of compromise, transactions to mobile wallets/ mobile numbers/ VPAs on whom vishing fraud or other types of fraud is/are registered/ recorded, declined transactions, transactions with no approval code, etc. 38. Fraud analysis shall be conducted to identify the reason for fraud occurrence and determine mechanism to prevent such frauds. 39. The staff, especially in the fraud control function, shall be educated about frauds and trained in the following skills and areas of expertise:
