©2019 by Paydeology

  • Milos Dunjic

Decoupled Tokenization (Revisited)

Updated: Mar 18, 2019

Several years ago, I wrote an article about the concept of Decoupled Tokenization. At some point I even had patent pending on it, which in the meantime expired 🙁. In the original post I have discussed how payment tokenization could be creatively extended to passive (i.e. not connected to Internet) payments form factors, like ordinary plastic EMV cards and ultra cheap passive NFC capable wearable devices.

In addition, in several follow up blogs, I have explored potential use cases where I described how this concept could be applied to tokenizing simple, non-connected, fully EMV / NFC compliant tokenized 'proxy' payment devices, like wearable rings, cheap rubber bracelets, corporate business cards, international remittance cards, sponsored children cards, etc.

These types of devices are currently being offered mainly using underlying prepaid accounts. As such, they work, but require users to link their funding bank account to the prepaid account, to move funds between the funding account and the prepaid account, to keep track of the prepaid balances, take care of the unspent leftovers, etc. Decent amount of friction involved.

However, by using decoupled tokenization, an issuer could offer same experiences to customers, on top of existing credit or debit rails. No need for new prepaid account, it can significantly reduce UX friction and can also be much more cost effective solution to implement. I have been invited to present my thinking on several conferences, which I enjoyed very much back then.

My original idea was to have permanent payment token personalized in a secure element of the passive payment device, where the payment token could be linked to:

  • NULL PAN (nPAN) - when form factor is INACTIVE and can't be used for payments

  • Funding-PAN (fPAN) - when form factor is ACTIVE and can be used for payments.

Users would be provided with mobile application by their FI, to securely control the payment token's state (ACTIVE or INACTIVE), which in the background meant either linking it to nPAN (INACTIVE) or fPAN (ACTIVE), inside payment network's Tokenization Service Provider (TSP) vault.

However, there was a little challenge with the original vision. I quickly learned that all of today's TSPs require that the payment token is always linked to an existing issuer's PAN. They do not recognize concept of NULL PANs. Basically, the record inside TSP must always have some PAN value linked to a token.

In the end, asking for functional changes to be made to the existing TSPs in order to support NULL PAN (i.e. empty fPAN field), however simple at the surface, would likely be prohibitively expensive and unrealistic in reality. Payment networks do not move fast. Unfortunately, that meant that my original idea was a non starter, unless I could find a way to rely on the existing TSP implementations. So I parked it for a while.

Evolution Of Original Thinking

Since then, I have done more research and had many interesting brainstorming discussions with relevant experts. Here is what we landed on. Do we need NULL PAN? Turns out the answer is NO, not at all. The concept is entirely possible to be implemented using the current payment network TSPs.

All TSPs today have Token Lifecycle Management APIs in place, available for the card issuers. One of such Token Lifecycle Management APIs is 'Replace PAN' (both Visa and MasterCard offer it, but may call it differently). That API is currently available for issuers to replace the OLD fPAN with the NEW fPAN, when OLD fPAN either naturally 'expires' or when underlying funding card is reported 'stollen'. The fPAN replacement happens seamlessly, all behind the scenes, initiated by the issuer, without bothering the consumer to re-provision new payment token into their payment device (mobile phone, smart watch, etc).

But how can we take advantage of such an existing API, to implement new 'decoupled tokenization'?

New Decoupled Tokenization

The new idea is very similar to the original, with the slight (but important) twist. We still have permanent payment token personalized in a secure element of the passive payment device. However, this time the device's payment token can be linked, inside TSP vault, to:

  • zero balance PAN (debit card case) OR zero credit limit PAN (credit card case) - called zPAN - when device's token is INACTIVE and can't be used for payments, OR

  • customer's real funding PAN (fPAN) - when device's token is ACTIVE and can be used for payments.

So both zPAN and fPAN are now REAL and legitimate PANs, not empty (NULL) values. It is just that account behind zPAN is a generic issuer's account that is always 'empty / void' of any available funds and therefore all transactions initiated while the device token is linked to zPAN will always be DECLINED, simply due to the Non Sufficient Funds (NSF) condition. Effectively token linked to zPAN is INACTIVE.

Similar, to the original thinking, every tokenized passive 'proxy' device would be originally personalized with its unique static token, and all devices' tokens are linked to the same zPAN inside payment network's TSP vault. To accomplish this, card issuer's personalization bureau acts as Token Requestor during personalization, gets unique token that is linked to zPAN inside TSP, and personalizes token into the device. That mens that all proxy payment devices are manufactured as INACTIVE.

If user obtains such device and wants to use it for purchases they simply need to activate device's token (after being properly authenticated by the issuer), using issuer's mobile application. Activation effectively securely re-links token, inside TSP, from zPAN to fPAN. If user wants to later de-activate token, they use the same mobile application, which effectively re-links token back from fPAN to zPAN. This switching of device token's linking between zPAN and fPAN is easily accomplished by issuer invoking payment network's EXISTING 'Replace PAN' Token Lifecycle Management API.

Voila! No changes required on the payment network TSP side this time. The funniest thing is that this simple technical solution was in front of my eyes all this time and I did not see it. Good thing I never abandoned it in the first place. Happy moment.

Last but not the least, special thanks to several of my current and former TD payment innovation comrades (David Tax, Keith Ajmani and Kushank Rastogi), who enthusiastically got involved and helped me with out of the box thinking and fresh prospective. Their help was crucial in evolving the original idea toward something that's easily implementable with the current technology.