RBI Guidelines on Regulation of Payment Aggregators & Gateways

The Reserve Bank of India (RBI) has been issuing guidelines from time to time on the Regulation of Payment Gateways and Payment Aggregators to regulate the Payment Aggregators (PAs) and Payment Gateways (PGs) in the interest of the consumer as it holds large volumes of consumer data. The new guidelines issued by RBI forbids the PAs and PGs from storing consumer card credentials on their database or server as a financial security measure. RBI has issued norms for regulating payment aggregators and payment gateways through various circulars as amended from time to time and at the request of the industry stakeholders

What are Payment Aggregators (PAs) and Payment Gateways (PGs)?

Payment Aggregators (PAs) and Payment Gateways (PGs) are intermediaries playing an important function in facilitating payments in the online space.

A payment gateway acts as a transaction intermediary between merchants and customers while a payment aggregator facilitates fund transfers between two parties and a bank. A Payment Aggregator can provide a Payment Gateway, but a Payment Gateway can’t offer or provide a Payment Aggregator.

Latest Amendments

With effect from January 1, 2022, no entity in the card transaction / payment chain, other than the card issuers and / or card networks, shall store the CoF data i.e. actual debit card/credit card data. Any previous data stored therein shall be purged. Accordingly, neither the authorized Payment Aggregators (PAs) nor the merchants on-boarded by them can store customer card credentials within their database or server.

All your saved credit and debit card details have to be deleted by 30th September, 2022, and one will need to manually enter all your card details for every online payment. However, your explicit approval will allow merchant authority to work with your bank and card networks to provide you with the same seamless payment experience as it was earlier.

It is observed that considerable progress has been made in terms of token creation. Transaction processing based on these tokens has also commenced, though it is yet to gain traction across all categories of merchants. Further, an alternate system in respect of transactions where cardholders decide to enter the card details manually at the time of undertaking the transaction (commonly referred to as “guest checkout transactions”) has not been implemented by the industry stakeholders, so far. In addition to tokenisation, industry stakeholders may devise alternate mechanism(s) to handle any use case (including recurring e-mandates, EMI option, etc.) or post-transaction activity (including chargeback handling, dispute resolution, reward / loyalty programme, etc.) that currently involves / requires storage of CoF data by entities other than card issuers and card networks

 Example: – While using amazon application one used to save his/her card details on the said application, just he/she while purchasing anything from the app need to input CVV number followed by OTP and then the transaction use to take place successfully. But from September onwards one need to put all the detail manually such as Card Number, Name, Card Expiry Number followed by CVV and OTP. This measure is taken to prevent unauthorized use of Card.

 Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services

 Abstract:

Tokenization refers to replacement of actual card details with a unique alternate code called the “token”, which shall be unique for a combination of card, token requestor and device

To improve the safety and security of card transaction, RBI has permitted card networks for tokenisation in card transactions for a specific use case.

Progress History through RBI notifications:

All Payment System Providers and Payment System Participants authorized card payment networks are permitted to offer card tokenization services subject to the conditions listed in circular DPSS.CO.PD No.1463/02.14.003/2018-19 dated January 08, 2019 on “Tokenisation – Card transactions” to any token requestor (i.e., third party app provider). 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.).

Initially vide circular CO.DPSS.POLC.No.S-516/02-14-003/2021-22 dated September 07, 2021 on “Tokenisation – Card Transactions : Extending the Scope of Permitted Devices” authorised card networks were permitted to offer card tokenization services to any token requestor limited to mobile phones and tablets of interested card holder only, this facility was subsequently extended to include consumer devices -laptops, desktops, wearables (wrist watches, bands, etc.), Internet of Things (IoT) devices, etc., vide our circular CO.DPSS.POLC.No.S-469/02-14-003/2021-22 dated August 25, 2021 on “Tokenisation – Card Transactions : Extending the Scope of Permitted Devices”.

This initiative was undertaken by RBI with an expectation to make card transactions more safe, secure and convenient for the users. The ultimate responsibility for the card tokenisation services rendered rests with the authorised card networks. All other instructions related to card transactions shall be applicable for tokenised card transactions as well. 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.

Key Highlights:

1. In reference to  circulars DPSS.CO.PD.No.1810/02.14.008/2019-20 dated March 17, 2020(as updated from time to time) and DPSS.POLC.No.S33/02-14-008/2020-2021 dated March 31, 2021 on “Guidelines on Regulation of Payment Aggregators and Payment Gateways”, advising that neither the authorised Payment Aggregators (PAs) nor the merchants on-boarded by them shall store customer card credentials [also known as Card-on-File (CoF)]

2. Token Service Provider (TSP) refers to the entity which tokenises the actual card credentials and de-tokenises them whenever required. The TSP shall put in place a mechanism to ensure that the transaction request has originated from the merchant and the token requestor with whom the token is associated.

3. The device-based tokenisation framework has exended to CoF Tokenisation (CoFT) as well

4. Card Issuer are permitted to offer card tokenisation services as Token Service Providers (TSPs). Earlier only card networks were allowed to act as TSPs.

5. TSPs shall offer the facility of tokenisation only for the cards issued by / affiliated with them.

6. The ability to tokenise and de-tokenise card data shall be with the same TSP

7. Tokenisation of card data shall be done with explicit customer consent requiring Additional Factor of Authentication (AFA) validation by card issuer.

8. For Card on File Tokenisation (CoFT) Services, the token shall be unique for a combination of card, token requestor and merchant. Merchant here refers to end merchant. However, in case of an e-commerce marketplace entity, merchant refers to the said e-commerce entity. Further, token requestor and merchant may or may not be the same entity.

9. If card payment for a purchase transaction at a merchant is being performed along with the registration for CoFT, then AFA validation may be combined

10. The merchant shall give an option to the cardholder to de-register the token. Further, a token requestor having direct relationship with the cardholder shall list the merchants in respect of whom the CoFT has been opted through it by the cardholder; and provide an option to de-register any such token.

11. A facility shall also be given by the card issuer to the cardholder to view the list of merchants in respect of whom the CoFT has been opted by her / him, and to de-register any such token. This facility shall be provided through one or more of the following channels – mobile application, internet banking, Interactive Voice Response (IVR) or at branches / offices.

12. Whenever a card is renewed or replaced, the card issuer shall seek explicit consent of the cardholder for linking it with the merchants with whom (s)he had earlier registered the card.

Conclusion

In the interest of clarity, the following points may be noted

• With effect from September 30, 2022, no entity in the card transaction / payment chain, other than the card issuers and / or card networks, shall store the actual card data. Any such data stored previously shall be purged.
• For transaction tracking and / or reconciliation purposes, entities can store limited data – last four digits of actual card number and card issuer’s name – in compliance with the applicable standards.
• Complete and ongoing compliance with the above by all entities involved, shall be the responsibility of the card networks.

Reference:

1. Reserve Bank of India (RBI) circulars DPSS.CO.PD.No.1810/02.14.008/ 2019-20 dated March 17, 2020

2. DPSS.POLC.No.S33/02-14-008/2020-2021 dated March 31, 2021 on “Guidelines on Regulation of Payment Aggregators and Payment Gateways”,

3. DPSS.POLC.No.S-516/02-14-003/2021-22 dated September 07, 2021 on “Tokenisation – Card Transactions: Permitting Card-on-File Tokenisation (CoFT) Services”

4. circular CO.DPSS.POLC.No.S-1211/02-14-003/2021-22 dated December 23, 2021 on “Restriction on storage of actual card data [i.e. Card-on-File (CoF)]”

5. RBI/DPSS/2019-20/174 DPSS.CO.PD.No.1810/02.14.008/2019-20 Guidelines on Regulation of Payment Aggregators and Payment Gateways (Updated as on November 17, 2020)

6. circular DPSS.CO.PD.No.1102/02.14.08/2009-10 dated November 24, 2009 on ‘directions for opening and operation of accounts and settlement of payments for electronic payment transactions involving intermediaries’.

10. RBI/2018-19/103 DPSS.CO.PD No.1463/02.14.003/2018-19 Tokenisation – Card transactions dated January 08, 2019