From ‘Coupled’ To ‘Decoupled’ Payment Tokenization

The EMVCo Payment Tokenization Specification Technical Framework had set the payment industry in motion about a year (or so) ago. The ability to replace the sensitive payment card credentials with an ‘alias’, called ‘payment token’, which ‘looks and feels’ like the original, but from which the original payment card credentials can not be deduced, even if the alias is stolen, is undeniably very powerful concept.

Shortly after EMVCo published its draft implementation guideline mid 2014, major payment networks in the US announced their own EMVCo ‘compliant’ TSP implementations. The Apple Pay was launched back in September 2014, as the very first commercial mobile wallet taking advantage of those implementations. Android Pay’s and Samsung Pay’s own launch announcements followed several months later, targeting their own launches before the end of this year. All of these mobile wallets will end up using same Tokenization Service Providers (TSPs), which are provided by the payment networks.

Current State Of The Art – ‘Coupled’ Payment Tokenization Framework

All currently commercially available TSPs follow the EMVCo Tokenization guidelines (intentionally not calling it ‘spec’, because it isn’t). The EMVCo Tokenization Framework is an example of the ‘coupled’ tokenization framework. It is labeled as ‘coupled’, because it does not envision that valid payment token can exist (be issued), unless it is ‘linked’ (i.e. ‘coupled’) to the real and legitimate underlying payment card PAN data. Basically no Token Requestor can obtain valid payment token data from the EMVCo ‘compliant’ TSP, unless it provides legitimate PAN data (and Token Assurance Level) in the Token Request message. That’s the real core of the enforced ‘coupling’.

As a consequence, such ‘coupled’ payment tokenization framework vision assumes presence of dynamic messaging capability for token requesting and provisioning. Basically, to be able to use tokenization in proximity payments, the ‘coupled’ payment tokenization framework limits itself only to the use cases with mobile devices (NFC or QR code based). Not surprisingly, all proximity payment use cases presented in EMVCo Tokenization document always assume usage of mobile phones.

However, considering that the mobile payments, despite almost a decade of hard push and significant marketing $$$s spent on their promotion, still represent no more than 5% of all payments, this should be seen as potentially significant business case problem to be solved. Independent research still consistently shows that vast majority of consumers seem quite happy paying with their plastic cards and see no real reason for switching to mobile payments, especially when more secure EMV compliant chip-cards are being rolled out everywhere. Mobile payments are also being pitched as replacement for ‘everyday small value purchases’ for which existing interchange fees might be prohibitively high for majority of merchants, especially those without significant negotiating power. Betting on ubiquity of mobile proximity payments, as a pre-condition for tokenization usage, may be risky strategy. Pushing harder and spending even more marketing $$$s, as seems to be the current approach, may fail to convince consumers to abandon their physical cards. Bottom line is – if the consumers do not massively adopt mobile proximity payments, the benefits of ‘coupled’ tokenization may not be fully realized.

The ‘coupled’ tokenization excludes the physical chip-cards, NFC stickers and NFC fobs as possible tokenized payment devices. That’s why today those still need to be manufactured and personalized (issued) with real PAN data. Although crypto power of chip-cards is successfully used as a protection from card counterfeiting, those cards still keep revealing sensitive payment credentials to POS terminals unprotected during proximity payments - in that respect they are no different than magnetic stripe cards. That is already recognized as a real security exposure, with industry experts constantly warning that fraud will likely shift to ‘card not present’ channel, while and after chip-cards are rolled out. Excluding physical cards from tokenization is definitely not helping the situation.

The Alternative Solution - ‘Decoupled’ Payment Tokenization Framework

Does valid payment token necessarily need to be tightly ‘coupled’ to an underlying payment card PAN data? Many proponents (including myself) of the novel ‘decoupled’ payment tokenization concept, do not agree with such approach.

The core of ‘decoupled’ payment tokenization framework is that it allows issuing valid payment token ahead of linking it to the underlying payment card credentials. The payment tokens in ‘decoupled’ payment tokenization framework can therefore be in two main states:

1. INACTIVE – when linked to a NULL underlying payment card credentials, inside the TSP that is in charge of the linking. In this state they can’t be used for payments, i.e. all transactions initiated with INACTIVE tokens must be rejected.

2. ACTIVE – while linked to the real and legitimate underlying payment card credentials. In this state they can be used for payments, as long as TSP, which is in charge of the linking, confirms and guaranties to the underlying payment card issuer that all payment restrictions, attached to the current linking (i.e. max spending allowance, max number of transactions allowed, etc, including payment token cryptogram validation) are satisfied

‘Decoupled’ payment tokenization therefore offers very clear ‘flexibility improvement’ compared to the ‘coupled’ payment tokenization, because:

1. It makes possible using cheap physical pre-tokenized chip-cards (initially INACTIVE EMV cards, NFC stickers, NFC fobs, etc) as legitimate participants in tokenization ecosystem. Consumers can on-demand (‘after the fact’) ACTIVATE the payment token in the card, by securely linking it to the real underlying payment card PAN data (which also requires proper Token Assurance Level provided). This eliminates the restriction, imposed by ‘coupled’ payment tokenization, that consumers must switch to mobile payments in order to be able to experience benefits of tokenization.

2. It enables MNOs to mass manufacture payment capable SIM cards, which are personalized with static, generic INACTIVE payment tokens. The mobile consumer is empowered with ability for on-demand linking of the static token inside the SIM card to the real underlying payment card credentials and its final ACTIVATION for payments. This fully eliminates need for any kind of over the air provisioning of the payment credentials to SIM cards and can significantly simplify the deployment and eliminate need for MNOs and Issuers negotiating complex deals.

3. It can enable even more radical innovation use cases – like making it possible for independent merchants or their consortia, to offer to their customers cheap pre-tokenized chip-cards and encourage them to link them to their bank account data (i.e. DDA data), instead to underlying payment card data. Available real-time ACH interfaces (like FIS’s InstantFunds ACH Warranty as an example that comes to mind here) can be used to enable this kind of real time ACH based payment rails, preserving EMV capability (contact / contactless) on the front-end, but avoiding Visa and MasterCard rails on the backend altogether. Merchants could promote this payment option to consumers, by incentivizing them via special discounts and integrated loyalty programs all linked to the same card (by plugging-in the TSP into their, or partner’s, existing loyalty engines). The consumers could also be allowed to chose to link underlying payment card credentials (instead of DDA data), but in this case discounts may not apply.

NOTE: In both a) and b) opportunities exist for offering ‘cloud based wallet’ based on extremely cheap proxy payment chip-cards (plastic, sticker, fob or SIM form factor). Those wallets, would allow preloading and guaranteed safe storage of multiple underlying real payment card credentials in the cloud (all backed by their Token Assurance Level), which then can be coupled’/‘decoupled’ to/from the generic static payment card token – under control of the responsible TSP and using convenient wallet management front end (mobile app or web portal).

As it is evident, I strongly believe that move toward adopting ‘decoupled’ payment tokenization would significantly open up opportunities for unrestricted payments innovation and will allow for many use cases, which are simply impossible to be achieved today, with ‘coupled’ payment tokenization approach. Am I boiling the ocean here? Yes probably, since the payment industry has proven many times so far, for being able to protect its turf from significant disruption. But if no one keeps pushing for changes and isn’t challenging the status quo, the cashless society just may keep slipping away and stay as a distant dream.

NOTE: previously described and patent pending concept of ProxyEMVPay cards is an implementation of ‘decoupled’ payment tokenization framework, where supporting ProxyEMVPay TSP can easily be customized and utilized in any of the contexts listed above (and many more, which have already been mentioned in various blogs and articles about it).