nasscom Community

NASSCOM-Industry consultation on Card on File Tokenisation

3 Mins read

The Guidelines for Payment Aggregators and Payment Gateways (PA/PG) prohibit merchants and payments aggregators from storing card details after December 31. To this effect, on September 07, the RBI allowed Card-on-File tokenisation (CoFT) for merchants and PAs allowing them to store last 4 digits of card number to ensure seamless transactions and user experience.

On December 07, 2021, NASSCOM organised a closed-door consultation with its members- card networks, payment aggregators, and merchants – to identify the challenges in adhering to the card deletion deadline of December 31, and compliance with Card-on-File tokenisation framework.  In the consultation, the industry highlighted the disruption caused by e-mandate on recurring transactions which has particularly impacted customer experience, small and medium enterprises (SMEs), and SaaS companies.

State of preparedness for Card on File Tokenisation

While the industry welcomed tokenisation, they raised concerns with the extant framework including infeasibility of purging card data timeline, consent, and guest check-out. The industry highlighted the absence of transparency around the coverage of issuer banks which networks have, and the readiness of RBI’s regulated entities (REs). It was highlighted that there is uncertainty with regards to the readiness of issuer and acquiring banks vis-à-vis token provisioning, processing and deployment of solutions for various use cases.

To ensure a smooth and seamless rollout of CoFT, the following were discussed in the consultation:

  1. Extension of timeline: The payment ecosystem is an interdependent ecosystem wherein stakeholders are heavily reliant on each other to ensure seamless digital transactions for customers. Merchants rely on readiness of REs who offer tokenisation services. However, in the absence of viable solutions, merchants will be left in lurch wherein after December 31st, 2021. They would not be allowed to store card data and will not have access to tokenised data either. Three-months is too short a time for the players in the ecosystem to be ready with tested systems.

To this effect, it was proposed that a viable solution for merchants would be to where at-least banks issuing 80% cards have integrated and tested the CoFT solution with the networks, and stable APIs are available for the merchants to test and integrate themselves with the CoFT solutions.

For smooth transition and integration of systems, and to ensure that consumer experience is not impacted, it was suggested that tiered implementation of timeline i.e. requiring REs to develop, test and integrate their solutions, and subsequently merchants onboarding into the solutions should be the way forward. This shall ensure that customers are able to transact in a safe friction-less manner, and the disruption is minimal for all the stakeholders.

It was also suggested that to achieve the above-mentioned, and minimally disrupt the ecosystem, the RBI may grant an extension to merchants and PA for purging stored card details.

  1. Compliance by REs to be monitored by the RBI: As of now, there is not clarity if issuer and acquirer banks have integrated their solutions with card networks. RBI monitored compliance shall ensure that the REs adhere to the timeline.

It was also suggested that RBI regularly publish this information on its website to serve as a single and credible source of information for the ecosystem.

  1. Consent: The RBI circular requires explicit consent of the cardholder to tokenise its card data. Considering that the current timeline is insufficient to get consent from all users, a clarification on taking consent ahead of actual provisioning may help merchants and PAs to integrate faster once the solution is ready, tested and integrated.

In addition to this, the RBI could consider allowing bulk tokenisation of data of existing customers who have already consented to store card data with merchants. Their consent could be understood to include consent to tokenise card. It is a step towards enhancing consumer protection considering that such consent shall be in line with the original purpose of consent. The RBI may consider providing customers with an option to opt-out in case they do not consent to tokenisation.

  1. Allowing BIN Range storage by merchants and PAs: The RBI circular dated September 07, 2021, allows storing limited data – last four digits of actual card number and card issuer’s name – for transaction tracking and reconciliation purposes. However, merchants require BIN range to ascertain card type, issuer, network etc. for purposes such as offers, EMIs, refunds, cybersecurity risks and identifying fraud patterns. Since the circular already allows storing card issuer’s name and last four digits of card, the RBI may consider allowing merchants and PAs to store bin ranges.

Considering that BIN range is publicly available information and cannot uniquely identify a card, storing of BIN range does not infringe privacy of a customer.

  1. Guest checkouts: With merchants not allowed to store card data, customers who transact as “guests” without signing up on a platform, may face challenges in case of refunds. In such cases, merchants shall not be able to ascertain payment instrument against which a refund has to be processed. It was suggested that either RBI may allow card acquirers to store card data for life cycle of a transaction or merchants may be allowed to store card data of such customers till the validity of refund period as offered by merchants.

Based on the feedback received, NASSCOM is finalising a submission to the RBI requesting it to extend the timeline to purge card details for merchants and payment aggregators, implement a tiered timeline, allow BIN range storage amongst others.