Written by: Francis Limousy


Even the word itself sounds great. It evokes a complex system; something big and mysterious, capable of so many things. It really is a great marketing tool, and the word has become ubiquitous in solution offerings.

When you spend a bit more time with payment experts however, you often notice an amusing trend: experts tend to avoid the word because of the confusion it creates in their customer mind.

I remember a meeting organized by a major Payment Network in 2014, where was presented their new tokenization-capable specifications to a panel of selected solution providers. At the coffee break, I was pleasantly surprised to see that other solution providers were struggling, as I was, to explain the impact of a somehow simple concept to their issuing customers:
No, you don’t issue and exchange “tokens”; tokenization is just a process to devaluate sensitive data.
No, the token does not replace the personalization or the keys issued on the card.
No, it does not replace encryption … it is just a mean to an end, a new tool in the issuing box but a lot remains the same. The card, digitized or not, still communicate the same way with the terminal, transaction cryptograms are still generated and verified.

As a result, each of these experts came with an inventive and generic term to describe what is issued in a tokenization-capable payment mean. Some called it “blob”, others “bundle”. Personally I liked the term “credentials”.


Aside from these vocabulary frictions, tokenization is considered the spearhead of the digitization revolution that we see taking shape those days. It’s such a simple and elegant solution that we often forget it’s been around for many years, solving issues in sectors where sensitive personal information are exchanged.

In the payment domain, before it reached the issuing side of the equation, it was already widely used on the acquiring side, allowing merchants to collect customer spending habit based on the PAN (Primary Account Number) from the card they use, or manage card-on-file scenarios such as recurring payments, limiting the scope of PCI DSS assessments. Why storing the PAN, when you can use any non-sensitive value (i.e. a token) maintained by a Token Service Provider?


Storing and handling sensitive information is not limited to the payment domain, though. If you live in the US for instance, there are few pieces of information more sensitive than your Social Security Number (SSN). This 9-digit code is assigned once – for life – and, despite the fact that you are encouraged to never share it, it is widely used in the industry as a mean of identification. Opening a debit or credit account, a rental lease or even a utility contract will systematically require to provide your SSN.

As a result, the SSN is widely collected and stored by US corporations, paving the way for identity fraud. The Identity Theft Resource Center (ITRC) in the US reveals that 32.7% of data breaches are compromising Social Security Numbers. Once collected, this information can be used for financial gain; the most common scenarios consist in applying for loans, credit cards or benefits in your name, then leaving you with the bills.

Social Security Numbers management could immediately benefit from features derived from payment-industry tokenization. As a merchant avoids storing the PAN, a health or utility provider could avoid storing the SSN. Storing a token of the SSN, alongside the reason why it is collected and stored (also called “Domain Restriction Controls” in the EMVCo specification for Tokenization) could avoid a lot of fraud scenarios. The SSN token used to open my utility bill can easily be identified as a fraud attempt if used to apply for a credit card for instance.


The health sector can also be affected by fraud. The sensitive information here can bear different names, but more often than not, having access to just two references – a Group and a Plan number – can go a long way. I recently had to visit a specialist in a hospital and, arriving at the registration counter, I realized I did not have my healthcare card with me. The institution accepted to give me care and charge it to my plan, at the condition that:

  • I could provide my Group and Plan numbers, alongside my name
  • The registration counter could verify the plan is active by a call to my health insurance company

Although I was delighted by the convenience – the verification process went through rather quickly and I could have access to care – I could not avoid seeing, taped to the wall close to the receptionist, number of health card photocopies and numbers with the mention “Do not honor! Stolen cards”.I made a mental note to check more regularly my claim reports for fraudulent transactions after this episode.

Tokenization could easily have an application in this domain, in order to protect what is more generally called Protected Health Information (PHI), either in motion such as in the example above, or at rest.
A report from the ITRC (Identity Theft Resource Center) in the US cites that – as of April 19 2016 – 34% of all exposed records from data breaches have occurred in the Health sector this year. That makes for almost 4 million individuals, angry to see their sensitive information compromised and sometimes willing to join class action suits, such as the one against 21st Century Oncology Center in Florida, where 2.2 million accounts were stolen.

There is no equivalent of PCI – i.e an internationally recognized regulation body managing a minimum security level in order to manage information – in the healthcare domain, but the example above shows that risks and costs are well present for corporations managing PHI.Such as our merchants earlier, they could avoid the hard costs (government fines, lawsuit litigation’s) and the soft costs (reputation damage) by deferring management of sensitive PHI to payment-grade tokenization providers.

Until now, it’s up to the healthcare provider to find a Healthcare Information Technology partner, such as Infoguard in order to mitigate the risks cited above.


Also to be stored in the “not-so-new” category is driver license fraud. Having access to a valid driver license number and name has always been valuable to certain criminals.  A common scenario is registering traffic violations on another person record. A forged driver license with valid information can also allow career criminals to pass law enforcement controls undetected or avoid prosecution after an arrest.

However, since the popularization of “point systems” and automatic traffic offense detection (e.g: radars), fraud has taken a completely new dimension.
A practice initiated in Spain saw the creation of unofficial markets for driver license points. An offender at risk of having its license revoked could purchase points from another individual with a healthy driving record, which will in return pretend he was driving the car at the time of the violation.
High rates – demand sometimes pushed a point value well above 1000 euros – even pushed unscrupulous individuals to sell family members points. “Grandma is not driving anymore anyway, it’s a victimless crime …

Whether they are acquired illegally or through doubtful financial transactions, driver license number could be protected more efficiently. At the age of driver license digitization and total car integration, we can easily imagine a system linking the car to its driver; .


The last application example is the long-broken password mechanism. If we think about it, passwords are the most sensitive piece of information we have in today’s version of a digital economy. They protect our bank accounts, emails, phones … etc.

However, the multiplication of accounts (and with that passwords to remember) have destroyed the whole system. Incapable of remembering so many passwords, the general public tends to use one or many of those techniques:

  • Use well-known or easy to remember passwords
  • Use the same password on multiple sites/accounts
  • Saving passwords in their browser / password manager (itself protected by a single master password)

Having a password compromised can then have catastrophic consequences, with potentially several accounts or devices impacted in a single event.

This fact is not new, a study from 1979 in Bell Labs was already showing signs of this “password fatigue” within individuals. Multiple alternatives are being implemented by industry players, such as two-step authentication or biometrics, trying to ally both security and convenience.

Without providing a perfect solution, one implementation  that is particularly interesting is the “App Password” system used by Google. The concept is similar to a token stored on a given device (also known as Token Location in the EMV tokenization specification). A strong password is generated and associated to a device, . With it, your mobile phone can access your Google account but a desktop or a different mobile device cannot.

This implementation reduces the usability of a stolen password (unusable without the attached device) as well as the systemic failure associated with the bad practices above.