3-May-2019: RBI imposes fines on PPIs for violating norms
The Reserve Bank of India has slapped monetary penalty on five pre-paid payment instrument issuers including Vodafone m-pesa and Phonepe, for violating regulatory guidelines.
A penalty of ₹3.05 crore has been imposed on Vodafone m-pesa and ₹1 crore each on Mobile Payments, PhonePe and G.I. Technology Private Ltd. Also, a penalty of ₹5 lakh has been imposed on Y-Cash Software Solutions.
In a separate statement, the central bank said it had imposed a penalty of ₹29.67 lakh on Western Union Financial Services Inc., USA., and ₹10.12 lakh on MoneyGram Payment Systems Inc, USA, for non-compliance of regulatory guidelines.
The penalties on Western Union and MoneyGram had been imposed by the central bank under the provisions of the Payment and Settlement Systems Act, 2007, for compounding of the contravention.
RBI also imposed a penalty of ₹11.25 lakh on private sector lender Yes Bank for violation of norms pertaining to issuance and operations of PPIs.
RBI has identified certain violations of RBI circular on Issuance and Operation of Prepaid Payment Instruments (PPIs) in connection with certain product features of an open loop prepaid card (co-branded) previously issued by the bank. The bank had launched this product as a pilot program from September 13, 2017, and had later discontinued this product with effect from March 14, 2018.
26-Feb-2019: RBI extends deadline for completion of KYC by 6 months for mobile wallets
In a much needed respite to e-wallet companies, the Reserve Bank of India extended deadline for completion of Know Your Customer (KYC) norms for prepaid payment instrument (PPI) issuers by six months. As per RBI directions, PPI issuers were required to complete the KYC process by February 28, 2019.
Prepaid payment instruments are those which facilitate purchase of goods and services against the value stored on such instruments. Value stored on them is paid by the holder using a medium (cash, debit card, credit card etc.).
These are generally issued in the form of smart cards, mobile wallets, paper vouchers, internet accounts/wallets.
Prepaid payment instruments (PPIs) come with a pre-loaded value and in some cases a pre-defined purpose of payment. They facilitate the purchase of goods and services as well as inter-personal remittance transactions such as sending money to a friend or a family member.
These payment instruments are licensed and regulated by the Reserve Bank of India. There are three types of PPIs—closed system PPIs, semi-closed system PPIs and open system PPIs.
The most common example of a closed system PPI is a brand-specific gift card. Such cards, physical or otherwise, can be used only at specific locations, and cannot be used to transfer funds from one account to another.
16-Oct-2018: Prepaid Payment Instruments (PPIs) – Guidelines for Interoperability
A reference is invited to the Master Direction DPSS.CO.PD.No.1164/02.14.006/2017-18 dated October 11, 2017 (updated as on December 29, 2017) on Issuance and Operation of PPIs (M.D.). As per the road-map laid down therein, interoperability of all KYC-compliant PPIs was to be enabled in three phases - (i) interoperability of PPIs issued in the form of wallets through Unified Payments Interface (UPI), (ii) interoperability between wallets and bank accounts through UPI, and (iii) interoperability for PPIs issued in the form of cards through card networks.
In order to prepare better for implementation of interoperability, consolidated guidelines for enabling all phases are enclosed. Participating PPI issuers, who choose to adopt interoperability shall ensure adherence to the enclosed guidelines, in addition to the instructions on KYC, security for transactions and application life cycle, cyber security, fraud prevention and risk management as in the M.D.
Furthermore, all participating PPI issuers shall be guided by the technical specifications / standards / requirements for achieving interoperability through UPI and card networks as per the requirements of National Payments Corporation of India (NPCI) and the respective card networks. NPCI and card networks shall facilitate participation by PPI issuers in UPI and card networks.
These guidelines are issued under Section 18 read with Section 10(2) of the Payment and Settlement Systems Act, 2007.
1. Introduction
1.1 Interoperability is the technical compatibility that enables a payment system to be used in conjunction with other payment systems. Interoperability allows PPI Issuers, System Providers and System Participants in different systems to undertake, clear and settle payment transactions across systems without participating in multiple systems.
2. Requirements
2.1 The requirements mentioned herein, with respect to interoperability, are in addition to the provisions of Master Direction on PPIs.
2.2 PPI issuers shall have a Board approved policy for achieving PPI interoperability.
3. Requirements for achieving interoperability: Common to Wallets and Cards
3.1 Where PPIs are issued in the form of wallets, interoperability across PPIs shall be enabled through UPI.
3.2 Where PPIs are issued in the form of cards, the cards shall be affiliated to the authorised card networks.
3.3 All PPI issuers intending to implement interoperability through UPI and / or card networks shall adhere to the instructions contained in these guidelines. PPI issuers operating exclusively in specific segments like Meal, Gift and MTS may also implement interoperability.
3.4 The interoperability shall be facilitated to all KYC compliant PPI accounts and entire acceptance infrastructure.
3.5 Technical requirements: PPI issuers shall adhere to all the requirements of card networks / UPI including membership type and criteria, merchant on-boarding, adherence to various standards, rules and regulations applicable to the specific payment system such as technical requirements, certifications and audit requirements, governance, etc.
3.6 Reconciliation, customer protection and grievance redressal:
PPI issuers shall ensure adherence to all guidelines / requirements of card networks / UPI in terms of reconciliation of positions at daily / weekly / monthly or more frequent basis, as the case may be.
PPI issuers shall adhere to all dispute resolution and customer grievance redressal mechanisms as prescribed by the card networks / UPI.
4. Requirements for achieving interoperability through card networks
4.1 Card networks are allowed to onboard PPI issuers to join their network. Non-bank PPI issuers are permitted to participate as members / associate members of authorised card networks.
4.2 Settlement: For the purpose of settlement, a non-bank PPI issuer can participate directly or through a sponsor bank arrangement as the case may be. Non-bank PPI issuers shall adhere to the requirements of respective card network’s settlement system.
4.3 Safety and security:
As non-bank PPI issuers will issue interoperable cards in association with card networks for the first time, the cards issued by these entities shall ab initio be EMV Chip and PIN compliant.
Banks shall ensure that all new PPIs issued in the form of cards are EMV Chip and PIN compliant.
Banks shall ensure that all reissuance / renewal of PPIs in the form of cards are EMV Chip and PIN compliant.
PPI issuers operating exclusively in Meal segment shall issue EMV Chip and PIN compliant cards, if they opt for interoperability. Gift cards and MTS, may however, be issued with or without EMV Chip and PIN enablement.
5. Requirements for achieving interoperability through UPI
5.1 PPI issuers shall facilitate all basic / standard features of interoperability of UPI.
5.2 PPI issuers shall act as Payment System Providers (PSP) in the UPI. NPCI will issue handle to the PPI issuers as per its policy / guidelines taking risk management aspects into consideration. Since *99# USSD is part of UPI, non-bank PPI issuers are also allowed to participate in the same.
5.3 PPI holders shall be on-boarded for UPI by their own PPI issuer only. PPI issuers shall only link their customer wallets to the handle issued to them. PPI issuers as PSP shall not on-board customers of any bank or any other PPI issuer.
5.4 Authentication will be completed by the PPI holder as per his / her existing wallet credentials. In other words, a transaction will be pre-approved before it reaches the UPI.
5.5 Settlement: For the purposes of settlement, a non-bank PPI issuer shall participate through a sponsor bank. Non-bank PPI issuers shall adhere to the requirements of sponsor bank arrangement in UPI as also meet all requirements of NPCI in this regard.
7-Mar-2019: White Label ATMs (WLAs) in India – Review of Guidelines
RBI has decided to allow the WLA Operators to : -
- buy wholesale cash, above a threshold of 1 lakh pieces (and in multiples thereof) of any denomination, directly from the Reserve Bank (Issue Offices) and Currency Chests against full payment.
- source cash from any scheduled bank, including Cooperative Banks and Regional Rural Banks.
- offer bill payment and Interoperable Cash Deposit services, subject to technical feasibility and certification by National Payments Corporation of India (NPCI).
- display advertisements pertaining to non-financial products / services anywhere within the WLA premises, including the WLA screen, except the main signboard. It shall be ensured that the advertisements running on the screen disappear once the customer commences a transaction.
The permission to WLA Operators to source cash from retail outlets stands repealed.
Banks may issue co-branded ATM cards in partnership with the authorised WLA Operators and may extend the benefit of ‘on-us’ transactions to their WLAs as well.
All guidelines, safeguards, standards and control measures applicable to banks relating to (a) currency handling, and (b) cyber-security framework for ATMs, shall also be applicable to the WLA Operators.
This directive is issued under Section 10(2) read with Section 18 of Payment and Settlement Systems Act, 2007 (Act 51 of 2007).
8-Jan-2019: Tokenisation – Card transactions
Continuing the efforts to improve safety and security of card transactions, Reserve Bank of India had permitted card networks for tokenisation in card transactions for a specific use case.
It has now been decided to permit authorised card payment networks to offer card tokenisation services to any token requestor (i.e., third party app provider), subject to the conditions listed in Annex 1. This permission extends to all use cases / channels [e.g., Near Field Communication (NFC) / Magnetic Secure Transmission (MST) based contactless transactions, in-app payments, QR code-based payments, etc.] or token storage mechanisms (cloud, secure element, trusted execution environment, etc.). For the present, this facility shall be offered through mobile phones / tablets only. Its extension to other devices will be examined later based on experience gained.
All extant instructions of Reserve Bank on safety and security of card transactions, including the mandate for Additional Factor of Authentication (AFA) / PIN entry shall be applicable for tokenised card transactions also.
All other instructions related to card transactions shall be applicable for tokenised card transactions as well. The ultimate responsibility for the card tokenisation services rendered rests with the authorised card networks.
No charges should be recovered from the customer for availing this service.
Before providing card tokenisation services, authorised card payment networks shall put in place a mechanism for periodic system (including security) audit at frequent intervals, at least annually, of all entities involved in providing card tokenisation services to customers. This system audit shall be undertaken by empanelled auditors of Indian Computer Emergency Response Team (CERT-In) and all related instructions of Reserve Bank in respect of system audits shall also be adhered to. A copy of this audit report shall be furnished to the Reserve Bank, with comments of auditors on deviations, if any, from the conditions listed in Annex 1, along with the compliance thereto. Further, a report on the details provided in Annex 2 shall be submitted at monthly intervals to the Chief General Manager, Reserve Bank of India, Department of Payment and Settlement Systems, Central Office, Mumbai and by email.
This directive is issued under Section 10 (2) read with Section 18 of Payment and Settlement Systems Act, 2007 (Act 51 of 2007).
Card tokenisation services: Tokenisation refers to replacement of actual card details with an unique alternate code called the “token”, which shall be unique for a combination of card, token requestor and device (referred hereafter as “identified device”).
Conditions
Tokenisation – de-tokenisation service
i. Tokenisation and de-tokenisation shall be performed only by the authorised card network and recovery of original Primary Account Number (PAN) should be feasible for the authorised card network only. Adequate safeguards shall be put in place to ensure that PAN cannot be found out from the token and vice versa, by anyone except the card network. Integrity of token generation process shall be ensured at all times.
ii. Tokenisation and de-tokenisation requests should be logged by the card network and available for retrieval, if required.
iii. Actual card data, token and other relevant details shall be stored in a secure mode. Token requestors shall not store PAN or any other card detail.
Certification of systems of card issuers / acquirers, token requestors and their app, etc.
iv. Card network shall get the token requestor certified for (a) token requestor’s systems, including hardware deployed for this purpose, (b) security of token requestor’s application, (c) features for ensuring authorised access to token requestor’s app on the identified device, and, (d) other functions performed by the token requestor, including customer on-boarding, token provisioning and storage, data storage, transaction processing, etc.
v. Card networks shall get the card issuers / acquirers, their service providers and any other entity involved in payment transaction chain, certified in respect of changes done for processing tokenised card transactions by them.
vi. All certification / security testing by the card network shall conform to international best practices / globally accepted standards.
Registration by customer
vii. Registration of card on token requestor’s app shall be done only with explicit customer consent through Additional Factor of Authentication (AFA), and not by way of a forced / default / automatic selection of check box, radio button, etc.
viii. AFA validation during card registration, as well as, for authenticating any transaction, shall be as per extant Reserve Bank instructions for authentication of card transactions.
ix. Customers shall have option to register / de-register their card for a particular use case, i.e., contactless, QR code based, in-app payments, etc.
x. Customers shall be given option to set and modify per transaction and daily transaction limits for tokenised card transactions.
xi. Suitable velocity checks (i.e., how many such transactions will be allowed in a day / week / month) may be put in place by card issuers / card network as considered appropriate, for tokenised card transactions.
xii. For performing any transaction, the customer shall be free to use any of the cards registered with the token requestor app.
Secure storage of tokens
xiii. Secure storage of tokens and associated keys by token requestor on successful registration of card shall be ensured.
Customer service and dispute resolution
xiv. Card issuers shall ensure easy access to customers for reporting loss of “identified device” or any other such event which may expose tokens to unauthorised usage. Card network, along with card issuers and token requestors, shall put in place a system to immediately de-activate such tokens and associated keys.
xv. Dispute resolution process shall be put in place by card network for tokenised card transactions.
Safety and security of transactions
xvi. Card network shall put in place a mechanism to ensure that the transaction request has originated from an “identified device”.
xvii. Card network shall ensure monitoring to detect any malfunction, anomaly, suspicious behaviour or the presence of unauthorized activity within the tokenisation process, and implement a process to alert all stakeholders.
xviii. Based on risk perception, etc., card issuers may decide whether to allow cards issued by them to be registered by a token requestor.