Reserve Bank of India : Representation on facilitating compliance with Card-on-File Tokenisation (CoFT)

1. Backdrop

In March 2020, the Reserve Bank of India (RBI) released “Guidelines on Regulation of Payment Aggregators and Payment Gateways” under S. 10(2) of the Payment Systems and Settlement Act, 2007. The Guidelines recognise Payment Aggregators (PAs) and Payment Gateways (PGs) as intermediaries playing a crucial role in facilitating payments in the digital space and ensure that consumers are protected in online space.

The Guidelines lay down a comprehensive list of provisions which the PAs will have to comply with. Of these, Clauses 2.1, 7.4 and 10.4 require PAs and merchants to not store card credentials within their databases or servers. With merchants and PAs not allowed to store card data, there were several industry concerns including – card data security, fraud risks, impact on customer service and product innovation. (Read more about it here)

To address the concerns, the industry had made suggestions to the RBI including considering card-on-file tokenisation (CoFT) as a viable alternative to card-on-file (CoF) in a graded manner. (Read more about it here)

2. What is Card-on-file tokenisation?

In line with industry’s and NASSCOM’s recommendations, the RBI, through a circular dated September 07, 2021, allowed CoFT for merchants and PAs. This step was to reinforce the safety and security of card data while ensuring convenience of card transactions. (Read more about it here) The framework requires merchants and PAs to:

1. Purging card data: No entity in the card transactions/ payment chain, other than the card issuer and/or card network will store actual card data. Merchants and PAs are required to purge card data from their respective systems by December 31, 2021.
2. Storing last four digits of a card: The merchants and PAs are allowed to store last four digits of actual card number, and card issuer’s name.
3. Customer consent: To tokenise card data, it is mandatory to obtain customer’s explicit consent requiring Additional Factor of Authentication (AFA) validated by card issuer.
4. Responsibility of card networks: It is the responsibility of card networks to ensure that all entities involved are compliant with the framework.

3. Avoiding the disruption caused by e-mandate on recurring transactions

The industry unanimously agrees that CoFT is a step in right direction and will ensure consumer safety online. However, there have been concerns about implementational and operational challenges of the framework. To identify the challenges faced by the industry, on December 07, 2021, NASSCOM had organised a closed-door consultation with its members – card networks, PAs, and merchants.  (Read more about it here)

In the consultation, the industry had highlighted that the industry as well as consumers are still recovering from the disruption caused by e-mandate on recurring transactions (e-mandate). The e-mandate has had an adverse impact on the industry, especially the small and medium enterprises (SMEs). This is also evidenced by the information available on the website of many banks which indicates that most of the merchants onboarded by the banks for their Merchant Standing Instructions are large merchants and not the SMEs.[i]

Similarly, Software as a Service (SaaS) companies play a crucial role in offering services globally including mass e-mails, customer relationship management or other important subscription-based software. However, they have been struggling with subscription payment of SaaS products like SalezShark, Atlassian, Invision amongst others, due to e-mandate on recurring transaction. As per our assessment, this has significantly disrupted their services and has led to loss of customer base.[ii]

4. Assessing the state of preparedness vis-à-vis CoFT

The entire ecosystem appears to be operating in the absence of transparency around the coverage of issuer banks which networks have at this point, and the state of readiness of the RBI regulated entities to implement the CoFT within RBI’s proposed timelines. There is uncertainty around readiness of issuer and acquirer banks who are live with all three stages of solutions –

1. Provisioning: From a consumer perspective, provisioning means generating a token to go forward with the transaction. Separate tokens are generated for separate transactions on separate websites.
2. Processing: Token processing refers to the ability of a provisioned token to successfully initiate the lifecycle of a transaction.
3. Scaling up the token infrastructure for use cases: This includes EMI payments, refund processing, offers against card schemes amongst others. Adaptability of the system for use cases forms the last leg of the three-stages.

For merchants to be able to comply with the requirement to delete card data per the RBI’s deadline of December 31, 2021, all the three stages are required to be available. As on date, even the first stage i.e., provisioning is not complete. This means that merchants are not in a position to tokenise card details of all new customers and existing customers, making it impossible for them to comply with the RBI’s deadline.

5. NASSCOM’s representation to the RBI

Based on industry consultation, NASSCOM made a representation to the RBI to ensure a smooth rollout of its CoFT guidelines. The key points include:

1. Consent: The RBI circular dated September 07, 2021, requires explicit consent of the cardholder to tokenise its card data. However, it does not clarify if existing and new customers can take consent ahead of actual provisioning.

Suggestions:

1. Consent ahead of actual provisioning: Permit obtaining consent ahead of actual provisioning to enable merchants and payments aggregators to integrate faster once the solution is ready, integrated and tested.
2. Bulk tokenisation: Permit bulk tokenisation of data of existing customers who have already consented to store card data with merchants. The existing consent of consumers should be sufficient, given that tokenisation is in line with the original purpose of the consent and moreover, it is a step towards higher consumer protection and is a solution approved by the RBI. Users may also be provided with an option to opt-out in case they do not consent to tokenisation.

2. Timeline: 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 regulated entities (REs) i.e., issuer banks, card networks, who offer tokenisation services. In the absence of viable solutions for tokenisation, merchants will be left in a lurch. A viable solution for merchants is 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 face the risk of being required to purge card data from their systems without having access to tokenised data.

Unless regulated entities (REs) are compliant with the circular, merchants cannot be compliant. Therefore, for tokenisation to be effective, it is necessary to follow a sequential compliance process wherein once REs have developed, tested, and integrated their solutions, merchants should be required to integrate into the solutions. This shall ensure that customers are able to transact in a safe-frictionless manner, and there is minimal disruption in business operations of stakeholders, particularly merchants.

Suggestions:

1. Tiered timeline for compliance: Provide a tiered timeline for compliance i.e., requiring issuer banks and card networks to be ready with their integrated solutions, and then requiring merchants to integrate, test and move from legacy rails.
2. RBI monitored compliance: An RBI monitored compliance to 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.

3. Allowing BIN 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. Merchants require first few digits of a card (BIN range) to ascertain the network, issuer, card type for several purposes. Given that BIN ranges are information available publicly and cannot uniquely identify a card, storing of the BIN range does not impinge on the customer security.

Suggestion:

Permit BIN storage by merchants and PAs for the following purposes:

1. EMI and refunds: BIN ranges are required to identify if EMI is supported by a card network or not. Similarly, BIN ranges help in identifying routing of a transaction. With the restriction on storing BIN ranges, merchants/payment aggregators will be unable to provide automated and seamless refunds to customers or offer or process their EMIs. The time taken for issuing refunds and for processing payments will increase. Thereby, causing inconvenience to the customer.
2. Offers: The offers run against specific cards by specific banks. Most of these offers have an aggregation requirement i.e., 2-3 times per card for a given duration or one time per card per merchant etc. For such use cases, a unique identifier (card hash) or BIN is required to apply offer validations, view offers against a specific card, and for processing cashback. Without an option to store BIN number, these offers will cease to exist.
3. Identification of fraud patterns and cyber security risks: Without a BIN range, fraud patterns cannot be identified.

4. Guest checkout: Since merchants are not allowed to store cards, customers who transact online on merchant portals as “guests” may face challenges in case of refunds. Merchants, in such cases, will not be able to ascertain payment instrument against which a refund has to be processed.

Suggestion

Permit storing card data of unregistered customers by merchants till the validity of refund period as offered by merchants.

Alternatively, RBI may clarify that card acquirers can store card data for life cycle of a transaction i.e., dispute resolution, reconciliation, and refunds.

For more information on this, kindly write to apurva@nasscom.in.