The Payment Instruments industry which consists of many of the mobile wallet operators have raised objection to the recent Master Guidelines issue by RBI on several counts such as
a) KYC requirement made more or less mandatory for all Semi Closed and Open system PPIs
b) Phased introduction of interoperability
c) Restriction of peer to peer fund transfer in Semi KYC wallets
Out of these, KYC requirements are essential to prevent frauds and is non negotiable. Funds transfer for KYC done PPIs provide for transfer “Back to Source” and “Own Bank Account” and hence should not be an issue beyond that it is a little inconvenient for customers.
Transfer from one PPI to another actually creates a problem in understanding the usage pattern and creates double counting for statistical purposes. If both accounts are KYC enabled, RBI can consider relaxing this provision and managing its statistical problems by tweaking its system.
Interoperability is a technology issue and would perhaps introduce some costs. It may require a discussion at technical levels but it is desirable in the long run.
I presume that more than the above publicly expressed grievances of the PCI, (Payment Council of India) what has made them squirm is the reiteration of
a) Security and Fraud Prevention Management Framework
b) Customer Protection and Grievance Redressal Framework
c) Information System Audit
in the Master Directions.
Let’s now look deeper into these provisions as contained in the Master Directions.
a) Security and Fraud Prevention Management Framework
The Security measures envisaged in the guidelines include development of a “Board Approved Information Security Policy” which should be the starting point. The security measures need to be reviewed on an ongoing basis but atleast once a year, after any security incident or breach and before/after a major change to their infrastructure or procedures.
Apart from the usual security measures such as monitoring invalid log in attempts, time out, beneficiary creation alerts, cooling period etc the guideline requires that
“Issuers shall introduce a system where every successive payment transactions in wallet is authenticated by explicit customer consent”
Presently the OTP is used more as a pre-transaction second factor authentication. Will this double up as “Explicit Customer Consent”? needs to be discussed.
“Cards (physical or virtual) shall necessarily have Additional Factor of Authentication (AFA) as required for debit cards, except in case of PPIs issued under PPI-MTS.”
Some PPIs at present donot have second factor authentication at the time of usage transaction though they may have authentication at the time of loading. This may require some modification of the system.
” Issuers shall provide customer induced options for fixing a cap on number of transactions and transaction value for different types of transactions / beneficiaries. Customers shall be allowed to change the caps, with additional authentication and validation.”
This is an important requirement that was first suggested by the Damodaran Committee on Customer relations way back in 2011 and has not been fully implemented. This is an important risk control measure and should be welcome. However it requires some support since hackers can easily modify it once they have access to the system.
“Issuers shall put in place a mechanism to send alerts when transactions are done using the PPIs. In addition to the debit or credit amount intimation, the alert shall also indicate the balance available / remaining in the PPI after completion of the said transaction”
This “Alert” is also a requirement under the “Zero Liability Circular of July 6, 2017. Some PPI issuers have not incorporated the “Balance” aspect and need to incorporate it now.
“Issuers shall put in place mechanism for velocity check on the number of transactions effected in a PPI per day / per beneficiary.”
This is an important aspect of “Adaptive Authentication” which many have ignored. It however requires a proper system for identifying a risk and responding to it appropriately.
“Issuers shall also put in place suitable mechanism to prevent, detect and restrict occurrence of fraudulent transactions including loading / reloading funds into the PPI.”
This is an open ended requirement that requires a proper risk assessment including threats and vulnerabilities in the environment. Adequacy of this should be seen through the IS policy.
” Issuers shall put in place suitable internal and external escalation mechanisms in case of suspicious operations, besides alerting the customer in case of such transactions.”
This needs to be addressed through the Grievance Redressal Mechanism which was also part of the Section 79-ITA 2008 requirement which many of these PPI issuers did not recognize and implement. Now they cannot ignore the requirement.
” PPI issuers shall establish a mechanism for monitoring, handling and follow-up of cyber security incidents and cyber security breaches. The same shall be reported immediately to DPSS, RBI, Central Office, Mumbai. It shall also be reported to CERT-IN as per the details notified by CERT-IN.”
This is the most annoying requirement as far as the PPI issuers are concerned. But this is the only control that will ensure that PPI issuers take the directions seriously. It will also retain the hold of CERT-IN on the PPI issuers as envisaged in the ITA 2008.
b) Customer Protection and Grievance Redressal Framework
The guidelines are supported by a stringent Customer protection and Grievance Redressal Framework.
The framework includes “Disclosure” of important terms and conditions, creating awareness on secure use of PPIs and conform to the RBI’s “Zero Liability Circular”
It is interesting to note that the directions indicate that “In case of PPIs issued by banks, customers shall have recourse to the Banking Ombudsman Scheme for grievance redressal.”
Otherwise the grievance redessal framework needs to include:
a formal, publicly disclosed customer grievance redressal framework, including designating a nodal officer to handle the customer complaints / grievances, the escalation matrix and turn-around-times for complaint resolution. The complaint facility, if made available on website / mobile, shall be clearly and easily accessible. The framework shall include, at the minimum, the following:
a) PPI issuers shall disseminate the information of their customer protection and grievance redressal policy in simple language (preferably in English, Hindi and the local language).
b) PPI issuers shall clearly indicate the customer care contact details, including details of nodal officials for grievance redressal (telephone numbers, email address, postal address, etc.) on website, mobile wallet apps, and cards.
c) PPI agents shall display proper signage of the PPI Issuer and the customer care contact details as at (b) above.
d) PPI issuers shall provide specific complaint numbers for the complaints lodged along with the facility to track the status of the complaint by the customer.
e) PPI issuers shall initiate action to resolve any customer complaint / grievance expeditiously, preferably within 48 hours and resolve the same not later than 30 days from the date of receipt of such complaint / grievance.
f) PPI Issuers shall display the detailed list of their authorized / designated agents (name, agent ID, address, contact details, etc.) on the website / mobile app.
These are areas in which lot of action is still required for many Mobile wallet operators.
c) Information System Audit
The Master directions has also included a detailed guideline on the Information Security Audit requirements for the PPI issuers.
The directions make reference to the “Cyber Security Framework” which is a comprehensive guideline which even the best of Banks are struggling to meet. PPI issuers who are banking on Mobile Apps will find meeting these guidelines challenging.
The Audits need to be conducted by CERT-IN empanelled auditors within two months of the cose of their financial year and submit reports to RBI.
In particular, the master directions indicate that
All PPI issuers shall, at the minimum, put in place following framework:
a) Application Life Cycle Security: The source code audits shall be conducted by professionally competent personnel / service providers or have assurance from application providers / OEMs that the application is free from embedded malicious / fraudulent code.
b) Security Operations Centre (SOC): Integration of system level (server), application level logs of mobile applications (PPIs) with SOC for centralised and co-ordinated monitoring and management of security related incidents.
c) Anti-Phishing: PPI issuers shall subscribe to anti-phishing / anti-rouge app services from external service providers for identifying and taking down phishing websites / rouge applications in the wake of increase of rogue mobile apps / phishing attacks.
d) Risk-based Transaction Monitoring: Risk-based transaction monitoring or surveillance process shall be implemented as part of fraud risk management system.
e) Vendor Risk Management:
(i) PPI issuer shall enter into an agreement with the service provider that amongst others provides for right of audit / inspection by the regulators of the country;
(ii) RBI shall have access to all information resources (online / in person) that are consumed by PPI provider, to be made accessible to RBI officials when sought, though the infrastructure / enabling resources may not physically be located in the premises of PPI provider;
(iii) PPI issuers shall adhere to the relevant legal and regulatory requirements relating to geographical location of infrastructure and movement of data out of borders;
(iv) PPI issuer shall review the security processes and controls being followed by service providers regularly;
(v) Service agreements of PPI issuers with provider shall include a security clause on disclosing the security breaches if any happening specific to issuer’s ICT infrastructure or process including not limited to software, application and data as part of Security incident Management standards, etc.
f) Disaster Recovery: PPI issuer shall consider having DR facility to achieve the Recovery Time Objective (RTO) / Recovery Point Objective (RPO) for the PPI system to recover rapidly from cyber-attacks / other incidents and safely resume critical operations aligned with RTO while ensuring security of processes and data is protected.
Obviously these are the matters that non Banking PPI issuers may not be prepared. It will also involve expenditure and management attention.
I suppose that these are the issues that is making PCI uncomfortable.
However, we welcome the stringent regulations which are in the interest of the general public. If only they had specified a mandatory Cyber Insurance aspect, it would have been even better.
Anyway let us now watch and observe how these guidelines are implemented by the industry and how RBI will enforce them.
Interesting days are ahead for Cyber Security professionals.
Naavi
Earlier Articles:
New RBI Norms for Prepaid Instruments make Digital payment Companies squirm
The PPI Ecosystem and the Power of the industry to lobby
Understanding the types of Prepaid Instruments under Payment and Settlements Act
