India’s digital payments market is, according to an estimate in a recent PhonePe-BCG study, tipped to touch USD 10 trillion by 2026. The study also says that 40 percent of all transactions in India are now done digitally. Given the sheer pace of the transition from offline to digital payments, framing regulations to govern the digital payments eco-system has been an uphill task that has kept the central bank on its toes. Certain reports in the recent past have also stated that India is among countries with a high rate of online fraud and phishing attacks. Against this backdrop, the Reserve Bank of India (RBI) has taken a variety of steps to safeguard the online payments turf and ensure greater safety of sensitive user data, one such step being notifying the tokenisation norms.
Tokenisation and its Introduction in the Payments Ecosystem
Tokenisation is a process by which card details of a customer will be replaced with an alphanumeric code (called ‘token’) which shall be unique for any combination of a card, a device and a token requester (typically the merchant who operates the application and accepts a customer request for tokenisation of a card and passes it on to the card network). Such token can be used by the customer to make a card payment without entering the underlying card details. Tokenisation aims at creating a much more secure and protected framework for online card payments that provides a safety net around sensitive card details that are currently shared with merchants and other intermediaries.
On January 8, 2019, the RBI issued a circular permitting authorised card payment networks to offer card tokenisation services to any token requester for a wide array of use cases/ channels including near field communication / magnetic secure transmission based contactless transactions, in-app payments, and QR code-based payments. However, these services were limited to certain secured devices such as mobile phones and tablets. Subsequently, the RBI extended these tokenisation services to other devices such as laptops, wearables, internet of things devices, in August 2021.
In March 2020, the RBI issued the Guidelines on Regulation of Payment Aggregators (PA) and Payment Gateways (the PA-PG guidelines) putting in place a licensing regime for the PA and setting baseline technology-related recommendations for payment gateways (PG). The PA-PG guidelines clearly stated that the merchants are not allowed to store payment data, irrespective of whether they are compliant with the Payment Card Industry Data Security Standard, and PAs cannot store customer card credentials within their databases or servers even if such servers and databases cannot be accessed by merchants. Storage of any payments related data by PAs and merchants was only permitted for the limited purpose of transaction tracking, in compliance with the applicable standards. In essence, this resulted in a complete ban on storage of card data even by licensed PA entities. Further, on September 7, 2021, the RBI issued a directive (CoFT Directive) clarifying that no entity in the card transaction/payment chain other than the card issuers and/or card networks will be permitted to store actual card data with effect from January 1, 2022. This timeline was further extended twice by the RBI, most recently to September 30, 2022. The CoFT Directive, inter alia, lays down certain obligations to be followed by token service providers for safeguarding interests of cardholders.
In its latest notification issued on July 28, 2022, the RBI allowed acquiring banks (i.e. merchant’s bank) to store Card-on-File (CoF) data till January 31, 2023, after a review of the issues raised by various stakeholders around card tokenisation. In an attempt to ease the transition to 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”), besides the card issuer and network, the RBI has also permitted the merchant or its PA involved in settlement of such transactions to save the CoF data for a maximum period of T+4 days (“T” being the transaction date) or till the settlement date, whichever is earlier. However, this data can be used only for settlement of such transactions, and must be purged thereafter. Additionally, the RBI directed all the stakeholders, except card issuers and card networks, to purge all CoF data by October 1 of this year.
So, is the payments ecosystem ready to migrate to the tokenisation regime?
Transitioning to the tokenisation regime requires major infrastructural changes at each stakeholder’s end. CoFT is a three stage process, involving token generation, processing and addressing the various use cases of cards which require CoFT. Use cases are unique to each transaction requiring different types of Application Programming Interfaces (APIs) such as for guest checkout, recurring payments, refunds, and installments. For a transaction to be successful, the systems of the card network, issuing bank, acquiring banks, PAs, and merchants have to be integrated. Simply put, the proposed migration to tokenisation requires an infrastructure overhaul for all stakeholders in the payments ecosystem.
The big players in this ecosystem such as Mastercard, Visa and RuPay have indicated that their solutions are ready for card-on file tokenisation. That may not be true, however, for the smaller merchants and other stakeholders.
The Way Forward
The issues faced by the industry due to the payment data localization requirement and the emandate system for recurring transactions have not faded from the memory of the industry. There can be little doubt about the fact that the implementation of the tokenisation framework will aid in improving data security in card transactions without much inconvenience to the customers. However, the RBI may do well to do a reality check on industry-preparedness for transitioning to the new system before the data purging deadline takes effect, to ensure that it does not become a spoke in the wheel of the digital payments bandwagon.