RBI releases the Tokenisation hounds (#57)
Merchants and PA/PGs face multiple new challenges with the card data storage restrictions going live
Welcome to the 57th issue of Unit Economics. RBI’s mandate on cardholder data restrictions went live yesterday. For today’s write-up, I share my thoughts on how it will challenge the merchants, acquirers, and others involved. Dive in!
The RBI has had enough of the extensions. After three shifts to the deadline, on 1st Oct, the guidelines mandating restriction on storage of actual card data went into immediate effect. There is not a lot of noise around, but in the corridors of payments floors – there are rumours of how ugly this could turn.
Before we get to the why, let’s set a bit of context. So, what does the guideline say?
The guideline mandates that the authorised non-bank payment aggregators and the merchants on-boarded by them must purge all existing card-on-file data (CoF) of previously stored cards, and prohibit storing of actual card data for any cards that pass through their systems.
In layman’s terms, Amazon, Swiggy, Flipkart, and any of your favourite merchant apps or websites will now not be allowed to store your debit and credit card details, especially the card number and card expiry. These rules for card data storage also extend to the payment aggregators or gateways that help these online merchants accept payments.
Now, if the merchants and PA/PGs cannot save your card number, how will you complete a card transaction? There are two ways:
You enter the card details each time you do a new transaction. In other words, you bear more friction at the payment checkout. In this scenario, the merchant - due to a worse customer experience - will have to manage a higher drop-off and poorer retention rate, or
You secure or tokenise your card at the merchant app or website, assuming the merchant has built the capability with the PA/PG to allow you to do so, and then use your newly secured card to process any subsequent payments without friction.
But if you can tokenise your card, does that not solve the problem? It partly does. But tokenisation, unlike saving-card-details, is a bit more complicated.
How does tokenisation work?
Firstly, tokenisation involves multiple parties: merchant, the merchant’s acquirer, card payment network, card issuer, and the customer. To allow payment via tokenisation, these parties must come together to:
Create a token: token creation requires that the actual card details be replaced with an alternate code. The merchant and their PA/PG act as token requestors in the process, requesting the card issuing bank or the card network to issue a token against the card details. Once the token is created, the merchant and the PA/PGs may hold the token – along with the issuer name and last four card number digits - as the identifier to the card. However, they must purge other card details and for decryption of the token – rely on the network or the issuer.
Process transactions: Once a token is created, the transaction processing requires that the token be decrypted in real-time at the time of transaction and the transaction be authorized via the issuer. Further, given that the PA/PG would have limited information on the account that must be debited or credited to complete the transaction – the dependency on the network or the issuer that has created the token increases for the fund settlement leg.
Processing transactions on tokenised cards may appear partly incremental and solvable. Reality is stranger, however. Let me explain.
Explicit consent to secure the card; High marketing costs
With the saved card details purged, to improve a customer’s payment experience – the merchants must seek explicit and informed consent for tokenisation, which is guised under the umbrella of securing the card (not-misleading, ofcourse). For merchants that cater to a sizeable chunk of card-transacting users, a customer choosing to not-secure a card will likely lead to a drop in customer LTV. And most merchants do realize that the slightest decrease in retention can significantly submerge their bottom-line. A direct implication: merchants incur high marketing costs via campaigns to push their customers for card tokenisation.
Create token via Network or Issuer; More legalities, integrations, and costs
Once the customer gives consent to secure their card on a merchant platform, the merchant must (a) be registered with networks or issuers as a token requestor (via PA/PGs) and (b) must have completed the integration with their PA/PGs to request tokens. For merchants, this requires that they build systems in place to (a) purge any card data being entered by the customer, (b) integrate APIs that allow them to send the card details to the PA/PG, which then – using the card-BIN – will request token from the recognized issuer bank or card network, and (c) store card token and link that token to customer’s card.
The industry has made considerable progress in building technology for token creation with networks. However, the costs of tokenisation via networks are substantial – and often deferred to the merchants. Further, the non-readiness of issuer tokenisation, i.e. where the token is created directly with the issuer banks and networks are bypassed, remains in the early stages – implying a high dependency on networks for token creation.
Of note, the PA/PGs seem heavily burdened with the responsibility of educating their on-boarded merchants about the new regulatory requirement, and of pushing them to adopt their tokenisation solutions – both cost-heavy measures. While the data is not public, the coverage of merchants that have adopted the tokenisation solution remains in the minority even today.
Lastly, for customers that are card-dependent – it will irk them more that they will be required to do the secure-card process for the same card separately at each merchant platform, irrespective of the PG or card network being the same. Imagine the redundancy.
Now, assume that the merchant and PA/PGs have gone through the hassle to get the token created for a card. Also assume that the customer returns to the website and attempts to use the same secured card for another transaction. What happens next?
Payment via card token; Low coverage, high latency, and more changes
Earlier, with access to the card number, a PCI-DSS compliant merchant would have passed the card details to the PG, who would have then processed the transaction via IMPS or NEFT, which would then get settled within 30 mins.
However, with the reliance on decryption of tokens with the networks and the guideline that prohibits the PA/PGs from simply accessing the card number via the token for IMPS, NEFT – the funds must be settled through the network rails.
This introduces several new headaches. The costs of settling via the networks is exorbitant. Next, the speed of debit or credit to the customer’s card account is slower, since BIN coverage of instant settlement via the likes of Visa Direct, Mastercard MoneySend, etc. is less than 50%. Third, this impacts the already messy accounting and reconciliation practices, which now require adjustments to daily report formats, SOPs, and multiple other parts of the process as more parties get involved and different standards are followed.
With all that is expected to happen, imagine the position of merchants. They bear more costs on TR application, token creation, marketing campaigns, settlements via networks, and after all that - deliver a slower and poorer payment experience during checkout and on fund settlement. But the pain does not end here. For merchants, the impact extends to:
Card Offers: checking the eligibility of a bank offer on the card has traditionally been done using card BIN. With no access to card BIN for the merchant, the offers need an alternate method for eligibility checks. Further, many internal controls of merchants – especially risk rules via velocity checks – have relied equally on card BINs, which will now have to be shifted to another identifier.
EMIs and Recurring transactions: With the card-on-file now stored only in the form of a token, the merchant loses part control of processing automatic recurring payments or EMIs on the transaction amount. These again will require merchants to de-tokenise tokens at the point of subsequent payment and will put the onus on the acquirer to process such payments.
Instant Refunds: back-to-source refunds also lose way with the merchant and PA/PG without access to the customer’s card number. Here again, unless the customer initiates a refund within four days of purchase, the customer will be required to provide an alternate method of receiving the credit or the refund would need to be provided via network rails again. This, if unsolved, would be especially troublesome to e-commerce websites that process returns and refunds in high percentages.
The challenges to merchants should now be more obvious. Market participants had loudly voiced their lack of readiness against the handling of the many payments use cases. The RBI, on their hand, appears to have lost patience and had likely underestimated the technical and operational effort the mandate would force on the industry.
However, it is time now that we are faced with the reality of cardholder data restrictions and the tokenisation solution. The observations over the next few weeks will likely force large decisions for merchants that would do their best to retain customers and for the RBI – which, if things break, might want to reevaluate the timeline.
We can, however, be certain that this would only push cards further back versus the UPI and other payment methods, and as we know, the complexities for cards hardly end with tokenisation. With this, let’s keep an eye out for how merchants handle our card purchases. Until next time!
If you have any views or feedback to share on the topic, feel free to add a response below or to share your thoughts with me over Linkedin. In case you feel your friends or family would be interested in reading about payments, feel free to share the blog with them as well. See you in a couple of weeks!