In 2019, RBI had permitted card networks for tokenisation in card transactions for a specific use case to improve the safety and security of card transactions
Amid the growing debate, the RBI has now extended the tokenisation guidelines to Card-on-File tokenisation services, and said tokenisation of data should be done with explicit customer consent
Neither payment aggregators nor the merchants on-boarded by them can store Card-on-File (CoF) data, according to the central bank
Digital transactions in India have been on a rise, especially since the pandemic began. More and more people have been opting for Unified Payments Interface (UPI) and online banking in an attempt to lower physical interaction which occurs during paper money transactions. In comparison to 2018, where transactions worth Rs 20.7 Bn have ensued, in 2021, over Rs 53 Bn was transacted via digital payments.
With more and more Indians adopting digital payments route to meet their daily needs during the pandemic, the safety and security of customers’ financial data has become paramount amid rising cyber-security incidents in the country.
Although a bit late, the Reserve Bank of India (RBI) has finally started revitalising the rather dull payment transaction security mandates in the country. In one such effort to improve the safety and security aspect of card transactions, the central bank brought into play ‘Tokenisation’ for a specific use case in 2019.
According to the new digital payments guidelines, starting September 30, 2021, RBI requires banks to notify their customers before and after any recurring debit and this requirement is agnostic of the digital payments mode.
Moreover, the RBI also released the Payment Aggregators and Payment Gateways (PAPG) guidelines to address data security and privacy concerns behind storing card-on-file (COF) data that does not allow merchant sites to save customer card details.
What Is Tokenisation?
Tokenisation involves replacing actual card details with a unique alternate code — ‘token’ — that would be novel for a combination of card, token requestor and identified device.
It allows authorised card payment networks to provide card Tokenisation services to third-party app providers to use cases/channels like near-field communication (NFC), magnetic secure transmission (MST)-based contactless transactions, in-app payments, QR code-based payments, and token storage mechanisms (cloud, secure element, trusted execution environment, etc).
The safety mandate for Tokenisation was similar to RBI’s extant rules related to card transactions, which included the additional factor of authentication (AFA) and PIN entry. Besides, tokenisation could take place only through mobile phones and tablets. Also, the transactions were being provided for no cost to the customer availing of the services.
What did it mean for authorised card payment networks?
While the instruction related to card transactions remained akin to tokenised card transactions, the responsibility for Tokenisation services stayed completely with the authorised card networks.
Before offering the Tokenisation services, authorised card networks needed to instil a periodic system, including security audit from CERT-In at frequent intervals, at least annually, of all entities involved.
In addition, card networks had to put in place a mechanism to ensure that the transaction request had originated from an ‘identified device’. In addition, it had to continuously monitor for any malfunction, anomaly, suspicious behaviour or the presence of unauthorised activity, and provide transaction data for each use case enabled by the network.
The RBI’s Second And Third Mandate
Under the second mandate released in March last year, RBI permitted payment gateways to charge a convenience fee, handling fee, etc, from customers which had to be displayed upfront by the aggregator.
Additionally, it prohibited payment aggregators from placing limits on the transaction amounts for a particular payment mode, allowing only a bank/entity to establish the cap.
Also, payment aggregators could not opt for ATM PIN as a factor of authentication for transactions and enable refunds only through the original mode of payment unless the customer agrees to an alternate mode.
It further tightened the noose around payment security by not allowing payment aggregators and payment gateways to store customer data in the same servers or database accessed by merchants.
While security was tightened around transactions, the debate on extending the scope of devices through which the service would be available persisted. So, in an enhancement release in August this year, the RBI extended the scope and authorised the Tokenisation transactions to be available on customer devices such as laptops, desktops, wearables (wristwatches, bands, etc.) and Internet of Things (IoT) devices, among others.
What Does The Latest Enhancement Mandate Say
What the mandate lacked was a Card-on-File Tokenisation/PCI Tokenisation. Even though the scope of devices for transactions expanded greatly, tokens were available only on a payment-to-payment basis, requiring card or UPI details refilling. With PCI Tokenisation, users can save their card numbers or UPI handles and opt for them during recurring online transactions such as paying for your Netflix subscription or home loan.
Each time, before the due date of the transaction, the token service would notify about the deduction and users could opt out of the payment if needed.
Under the new mandate released by RBI, device-based Tokenisation has been extended to Card-on-File Tokenisation. In addition, now, card issuers can also offer card Tokenisation as official ‘token service providers’ (TPS).
Even with the new amendments, neither payment aggregators nor the merchants onboarded can store Card-on-File (CoF), aka card credentials. Although, for transaction tracking and/or reconciliation purposes, entities can store limited data, such as the last four digits of the actual card number and card issuer’s name.
With this, the RBI aims to reinforce the safety and security of card data while continuing the convenience of card transactions.