- Backdrop
The RBI, on December 23, 2021, had granted an extension to merchants and payments aggregators to purge card-on-file data by six months i.e., till June 30, 2022. After this, the merchants and payment aggregators, in accordance with the PA/PG guidelines, will be required to purge stored card data and implement card-on-file tokenisation. In this regard, we made a representation to the FinTech Department and Department of Payment and Settlement Systems of Reserve Bank of India (RBI) highlighting the existing concerns of the industry on the implementation of Card-on-File tokenisation (CoFT).
We informed the RBI that progress has been made on token provisioning and that according to our conversation with the industry, most card schemes are ready with the same. For token processing and use-cases, there has been progress vis-à-vis token-based authentication, checkout, EMI etc. However, certain concerns remain which if not resolved in a timely manner, may cause disruption in the digital payment ecosystem and on consumer experience.
We emphasised that for merchants and payment aggregators to be able to able to comply with the requirement to purge stored card data per RBI’s deadline of June 30, 2022, all three stages of tokenisation i.e., token provisioning, processing and use-cases need to be available. As on date, only token provisioning has reached testing stage. Despite an extension and RBI’s interactions with relevant stakeholders, the ecosystem appears to be operating in the absence of transparency around the coverage of issuer banks which networks have at this point, and on the readiness of these issuer banks.
Prior to this, we had had made a representation to RBI in January and had organised an industry consultation with RBI on the challenges faced by merchants and payment aggregators (PAs) in transitioning to CoFT. You can read about our representation here.
- Challenges faced by the industry
In our representation, we highlighted a few challenges faced by merchants and payment aggregators in transitioning to CoFT:
- Time taken for token provisioning or token synchronicity: Currently, entire lifecycle of a transaction including time taken to make a payment takes approximate 3-6 seconds.
However, it is taking approximately 10-45 minutes to generate a token. This will be particularly challenging because multiple tokens will have to be issued against multiple merchants against a same card. This is not synchronous with lifecycle of the transaction which expires by the time a token is generated for the first time or when an expired card is renewed or replaced. In practice, this would mean that when a customer or any merchant seeks to tokenise their card and make payment simultaneously, they would not be able to do so. It needs to be made sure that token provisioning and processing are synchronous and take place within 3-6 seconds. While these may be considered as teething issues, every merchant across the industry will be impacted by this which may lead to transaction timeout for them.
- Number of transactions per second (TPS): As of the date of writing, the transactions per second are maximum 2-8 i.e., number of tokens created per second. This may lead to significant challenges for merchants as successful and timely token provisioning is a precursor to all online payment transactions including e-commerce. For example- some merchants, during annual sale on their website, see approximate 1600-1900 payment transactions per second. Of these, significant number of transactions would entail token provisioning for the first time or renewal of expired card. Maximum 2-8 transactions per second will be unfeasible for them and will impact their business if system is not scaled according to their needs. This may also lead to system failure in the absence of any stress testing.
- Clarity on 2FA for e-mandate and token creation: Both CoFT guidelines and circular on e-mandate on recurring transactions require two-factor authentication (2FA). Asking a customer to undertake 2FA twice for token creation, and e-mandate generation or modification in the same transaction call will reduce the user experience.
Therefore, clarity is required from RBI if both token creation and e-mandate creation or modification can be undertaken through one 2FA in the same transaction call.
- Standardisation and interoperability: As of now, there is no standardisation between different card schemes in terms of use cases. For instance, a solution for EMIs developed by one card scheme will not work for cards associated with other card schemes. This means that other stakeholders such as payment aggregators will have to adopt one specific solution for one use case for one card scheme, and another for different card scheme. On magnification, this will translate into approximately over 52 solutions for over 52 use-cases for 5 card schemes.
It has been suggested that a standardised platform may be created to ensure that there is interoperability between use cases developed by different card schemes. This will make the solutions scalable which is missing in the current setup.
As per industry inputs, globally there is interoperability and standardisation in tokenisation because merchants can connect directly with card networks for tokenisation. However, in India, merchants have to go through payment gateways (PGs) wherein payment gateways become blockers for interoperability for business reasons and merchants have no way out. In this regard, we would suggest that RBI could consider mandating PGs to offer interoperability.
- Use-cases: Token processing is heavily dependent on availability of solutions for use-cases. There are certain use-cases where the industry is facing challenges:
- Guest checkout: There is no solution for this as of now. There are practical challenges with this in case a customer chooses not to tokenise her card. For instance, in the absence of card credentials being available, the customer shall not be able to raise grievances, request refunds, track requests amongst others, and merchants shall not be able to process refunds or support customer grievances.
We suggested that it may be considered to allow acquirer banks to store permanent account number (PAN) i.e., card number of a user, for a limited period for transaction tracking purposes after the payment is made, till efficient, synchronous, at-scale transaction per second, end-to-end solutions for tokenisation have been operationalised. We understand that the RBI may have concerns associated with card security if acquirers store card numbers.
To assuage these concerns, we suggested that acquirers are RBI regulated entities, and in most cases, would be issuers as well, it will be feasible to allow them to store customer card credentials. RBI can consider mandating these acquirers to adhere to security safeguards applicable on issuers and card networks.
We recommended this only as a temporary measure only till card-based processing in this new environment is fixed for guest checkouts, and until end-to-end solutions for tokenisation have been fully operationalised and have demonstrated consumer readiness i.e., successful token-based transactions at scale across use-cases including guest checkouts, first transactions, recurring payments, and life-cycle management such as refunds, chargebacks etc. We also recommended that card acquirers be allowed to store card details only for the purposes of transaction tracking and for a limited period i.e., till the refund period.
- Recurring mandate: While payment aggregators are working on it, there is no clarity as to readiness of these use-cases. Absence of a recurring mandate solution may be particularly challenging for subscription-based services offered by SaaS companies, and merchants offering products on a subscription basis etc. So far, no APIs have been received by merchants on this.
As stated above, first transaction of a recurring transaction will be impacted due to absence of viable tokenisation solutions. For this as well, we recommended allowing acquirers to store PAN details for a limited period till efficient end-to-end solutions for tokenisation have been operationalised.
- No single identity of a customer/card to do aggregation – Harmonisation of transactions undertaken through same tokenised and plain cards: Till now, because merchants and PAs were allowed to store card details, they could identify risks such as fraud patterns, AML-CFT concerns, number of EMIs, refund, discounts availed by a card holder.
While use cases for EMIs, refund etc. are being developed, a few concerns remain. For example: A card scheme may offer discounts on a certain card on an e-commerce website. When this offer is applied, payment aggregators run aggregation on that card to check if this offer has already been used by the customer or not.
From system’s perspective, in tokenisation, a plain card transaction and a tokenised card transaction are two different transactions. Though these are run by same person. Since payment aggregators are not allowed to store card data, they will not know if an offer has been utilised through tokenised card and then through plain card or not.
- International transactions: Since network tokenisation is not supported in every country, international transactions will be impacted for services which use single application and payment services globally. In this case, we highlighted the challenges which would be faced by services such as cab aggregators which have one application across the globe.
In such cases, payment is made after delivery of service i.e., after the ride. Therefore, only stored cards can be used for payment processing since the payment takes place post-delivery of service. However, since merchants are not allowed to store card on file data, they would no longer be able to provision services to Indian cardholders when they travel abroad. The only exception to this is in few countries, where there are vendors who have capability to support token-based transaction processing. However, this is not a long-term solution as it is limited to only a few countries and the capability is limited to only a few payment service providers.
In the absence of a viable solution, an Indian cardholder will be required to enter card details on such application every time it has to avail such service. For instance, an Indian corporate card holder travelling to abroad for business purposes would not be able to avail cab services due to this.
In this regard, we recommended that that RBI may consider coming up with a PAN retriever policy to close this gap. This policy can be limited for users travelling abroad only, and mandate purpose and time-limitation as safeguards so that purpose of CoFT is not defeated.
- Absence of specific datasets on readiness of issuer banks and card networks has led to challenges in assessing readiness of industry. For example, time taken to generate tokens by each network is different, but no datasets are present on this.
In this regard, we recommended that RBI monitored compliance to ensure that the REs adhere to the stipulated timeline, and the transition to CoFT does not adversely disrupt the ecosystem like e-mandate on recurring transactions.
- NASSCOM’s suggestions
We made the following suggestions related to transparency around readiness to RBI to ensure smooth transition to CoFT by the industry:
- The payments ecosystem is an interdependent ecosystem wherein various stakeholders – card networks, card issuers and merchants – rely on each other to ensure seamless digital transactions for customers. Merchants are dependent on readiness of REs i.e., issuer banks, card networks, who offer tokenisation services. In the absence of timely viable solutions for tokenisation, merchants may again be left in a lurch at the time when the current deadline for compliance expires. A viable solution for merchants would be one where at-least banks issuing 80% of the cards have integrated and tested the CoFT solution with the networks and stable APIs are available to the merchants for them to test and integrate themselves with the CoFT solutions. Without this, they will face the risk of being required to purge card data from their systems without having access to tokenised data.
- In the recent past, when RBI had extended the timeline for e-mandate on recurring transactions in March, 2021, issuer banks were still not ready by September 30, 2021, thereby resulting in disruption for the merchants and consumers. To ensure smooth transition and integration of the respective systems, and to ensure that consumer experience is not impacted, we suggested:
- RBI monitored compliance of regulated entities: As stated above, there is no clarity about how many issuer banks and acquirer banks have integrated their solutions with card networks. RBI monitored compliance shall ensure that the REs adhere to the timeline and the transition to CoFT does not adversely disrupt the ecosystem like e-mandate on recurring transactions.
- This information should be published by the RBI on its website and updated weekly or at an appropriate frequency to serve as a single and credible source of information for the entire ecosystem.
- Acquirer banks be allowed to store permanent account number (PAN) i.e., card number of a user, for a limited period for transaction tracking purposes after the payment is made, till efficient, synchronous, at-scale transaction per second, end-to-end solutions for tokenisation have been operationalised. Since acquirers are RBI regulated entities, and in most cases, would be issuers as well, it will be feasible to allow them to store customer card credentials.
We recommended this as a temporary measure only till end-to-end solutions for tokenisation have been fully operationalised and have demonstrated consumer readiness i.e., successful token-based transactions at scale across use-cases including guest checkouts, first transactions, recurring payments, and life-cycle management such as refunds, chargebacks etc.
For more information, kindly write to apurva@nasscom.in.
