Tokenization Explained

What it is, how it works and how you can benefit


Tokenization explained
What it is, how it works and how you can benefit
On the 9th of September 2014 Apple
officially announced the long-awaited
Apple Pay solution. Apple’s
announcement had a huge impact on
everything related to mobile payments; it
basically revitalized the entire ecosystem
and influenced many ongoing discussions.
For example, the fact that Apple Pay uses
Near-Field Communication (NFC) to
communicate to payment terminals was,
in the eyes of many experts, the final
confirmation that NFC is the de-facto
standard for such communication.
Similarly, Apple Pay’s use of an embedded
Secure Element (SE) impacted the ongoing
discussion in the industry on the merits of
SE-based solutions versus ‘cloud-based’
solutions based on Android’s Host-based
Card Emulation (HCE) technology. And
finally, Apple announced that Apple Pay
was going to be the first real-life payment
ecosystem using payment tokens .
On that same day in September,
MasterCard and Visa announced services
called the MasterCard Digital Enablement
Service (MDES) and the Visa Token Service
(VTS). Somewhat later, American Express
followed suit with its American Express
Token Service (ATS). One of the prominent
features of these services is their
capability of replacing sensitive payment
account information found on plastic
cards with a ‘token’. In fact, one of the
page 2 1. The payment industry has used a different form of ‘tokens’ already a long time before Apple Pay. For the difference between these ‘security’ or ‘acquirer tokens’ and the ‘payment
tokens’ used by Apple, see section ApplePay.
White paper - Tokenization explained
main linking pins between Apple’s
announcement and the payment
schemes’ follow-up turned out to be the
use of tokenization. Apple had worked
closely with the payment schemes in
order to ensure quick and easy access to
Apple Pay and a high level of security. Easy
access is ensured by allowing member
banks to outsource their tasks regarding
customer enrollment and transaction
authorization for Apple Pay to the
payment schemes, via the MDES, VTS or
ATS services. And good security, especially
for in-app payments, is ensured partly by
the tokenization services offered by the
payment schemes.
Tokenization, at least in the form used by
Apple, was first specified by EMVCo, in a
document called ‘EMV Payment
Tokenisation Specification - Technical
Framework’ (ref. [1]). This document was
published in March 2014. This means
there were only six months between the
introduction of tokenization and its first
large-scale implementation by Apple,
MasterCard and Visa. This is one of the
fastest times to market for a new
technology.
 White paper - Tokenization explained

However, the pace of developments also

means that many industry players are left
puzzled. UL has noticed a lot of confusion
regarding tokenization. Questions that
have been asked to us include:
• Why do we need yet another security
technology? Does this mean that EMV and
PCI don’t work properly after all?
• How does tokenization work? What is a
token actually, and what does it replace?
• Is there a connection between
tokenization and cloud-based payments
solutions?
• Why does Apple Pay use tokens? It’s
based on Secure Element technology, so
the security of the PAN shouldn’t be a
problem, should it? Figure 1 - Card payment history

• Why all the buzz? Don’t merchants and

acquirers use tokenization solutions for
years already?
• How can I as an Issuer start using
tokenization?
This whitepaper attempts to answer these
and other questions.
Why Do We Need Tokenization?
From card-present to omni-channel
payments
In order to understand tokenization and
the need for it, we need to look at the
history of card payments as it has
unfolded over the last sixty years or so.
This history is summarized in Figure 1. For
a long time, the history of card payments
was actually the history of ‘card-present’
(CP) transactions. Such transactions take
place in a physical shop, where customers
present their cards instead of paying by
cash. Over the years, the underlying card
technology has changed a lot: from paper
cards, via plastic embossed cards, to cards
carrying a magnetic stripe or an
embedded contact chip, and, most
recently, to contactless cards or even
mobile phones. The drivers of these
technological changes were either the
wish to increase ease of use and
transaction speed, or the need for better
security.
This gradual evolution of card technology
was disrupted by the advent of the
internet and its mass adoption over the
last two decades. People started to use the
internet to get access to all imaginable
virtual and real goods and services.
Obviously, a way to pay over the internet
was needed. This is where banks and
payment schemes decided to re-use the
‘card-not-present’ (CNP) transaction. CNP
transactions already existed before the
internet, for example in the form of mail
order or telephone transactions, but now
issuers starting using this type of
transactions also for payments over the
internet. This caused the volume of CNP
transactions to grow much faster than
that of CP transactions. Banks recognize
that CNP transactions potentially carry a
higher risk, since not all card data are
present in the transaction, cardholder
verification (PIN or signature) is not
possible and card authentication as in an
EMV transaction cannot take place (Ref[2]).
In some cases, knowledge of the PAN and
the card expiry date is enough to perform
a CNP transaction.
In the last few years, the rate of change in
the card payment industry has increased
once again, mainly due to the arrival of the
mobile phone and the adoption of
technologies such as Near Field
Communication (NFC), QR codes,
Bluetooth Low Energy (BLE), Secure
Elements (SE), Host-based Card Emulation
(HCE) and more.

page 3 2. Banks and payment schemes have devised a multitude of other ways to increase the security of online CNP transactions, such as the CVC2 code, passwords and dynamic transaction
authorization codes delivered by SMS or generated by a chip card. Solutions based on 3D-Secure also fall into this category. However, transactions protected by such measures are still
considered CNP.

All of these technologies have found
applications in the mobile payment space,
both for payments at the point of sale
(PoS) and for online or in-app payments.
This proliferation of technologies and
associated security solutions means that
the difference between CP and CNP
transactions rapidly loses its significance.
The boundaries between PoS transactions
and online transactions are blurring as
well. In fact, the card payment industry is
moving towards a future where a physical
payment cards may disappear. Instead of a
card as the prime or only identifier of the
customer account, there will be multiple
ways of identification, depending on the
channel used and preferences of both the
customer and the merchant.
The real significance of tokenization can
only be understood against this backdrop
of ‘non-card-payments’ transactions. But
before we move into the question of what
tokenization is, we must first look into
payment card fraud.
Fighting Card Payment Fraud
Threats and Countermeasures: EMV and
PCI
Despite the technological evolution of
payment cards, the main principles of
card-present transactions have changed
little over the decades. The customer
present his card, which directly identifies
the account from which the funds to cover
the payment will eventually be drawn. To
do so, the card carries a Primary Account
Number (PAN), which is linked one-to-one
to the customer’s account. Because the
possibility to spend other people’s money
has always been alluring to fraudsters,
page 4 3. For an overview of payment security standards, their content and the way they interact, please refer the UL whitepaper ‘Meet The Family - Payment Security Standards’,. 4. For a
detailed discussion of possible fraud scenarios in relation to EMV and PCI, see the UL whitepaper ‘Prevention Is Better Than Cure - EMV and PCI’. Both are retrievable from www.ul-ts.
com. 5. For European countries, a nice breakdown of overall card fraud into several categories, including trends, can be found at http://www.fico.com/landing/fraudeurope2013/.
6. Source: FirstData, 2012.
White paper - Tokenization explained
payment cards have been under attack
from their invention. And due to its central
role in identifying the customer’s account,
the PAN has always been at the center of
attention in these attacks, with thieves
trying to obtain PANs and the payment
industry trying to protect them.
On a high level, protection of the PAN can
be done in two ways. We can try to ensure
the authenticity of the card containing the
PAN and the cardholder using it, or we try
to protect the confidentiality of the PAN.
In the first approach, we ensure that the
PAN is coming from an authentic card and
is used by the rightful cardholder. In the
second, we guarantee that only the
rightful cardholder and his bank know the
PAN to begin with.
Over the years, many security standards
have evolved for the payment industry to
achieve these goals (Ref [3]). Examples of
the first approach include cardholder
verification methods such as signature
and PIN. However, also EMV technology
falls into this category. The basic aim of
EMV is that a PAN cannot be used for a
card-present transaction without the
associated physical card being present.
The prime example of the second
approach is formed by the Payment Card
Industry (PCI) Security Standards Council.
All requirements in PCI DSS are aiming to
ensure the confidentiality of sensitive card
data, especially the PAN.
EMV has been proven to be very successful
to combat CP fraud. UL is convinced that
once the US market has migrated to EMV
and the use of magnetic stripe cards can
be abolished worldwide,
CP fraud in brick-and-mortar shops will be
largely solved (Ref. [4]).
However, because the card is not actively
involved in CNP transactions, EMV has no
bearing on CNP transactions. Therefore, as
CP fraud becomes harder, fraud is moving
to the CNP space. In some markets the
bulk of fraud in the card payment space is
already happening with CNP transactions
(Ref. [5]). And since the volume of remote
and in-app payment transactions is
growing dramatically, other markets can
be expected to follow soon. Despite the
multitude of specific measures aimed at
increasing the security of CNP
transactions, at the moment the only
generic defense against CNP fraud is to
keep the PAN secret. Consequently, the
payment industry has put a lot of
emphasis on adherence to the PCI
requirements. Businesses have spent an
estimated 1 billion dollar on PCI
compliance between 2006 and 2009
alone. Despite this, the recent major
security breaches at Heartland, Target,
Neiman Marcus and others exposed tens
of millions of PANs. Statistics show that
89% of the organizations suffering a data
breach were not compliant with PCI DSS at
the time of the breach (Ref. [6]). For the
remaining 11%, clearly the fact that they
were PCI compliant was not enough to
prevent the data breach. It is fair to say
that the goal of a worldwide merchant
and payment industry adequately
protecting PANs at all times is a long way
off.
 White paper - Tokenization explained

Cross-Channel Fraud
The problem of the lack of security for CNP
transactions is made worse by
cross-channel fraud which is a type of
fraud in which card details that were
fraudulently obtained via one payment
channel are used to withdraw money from
the customer’s account via another
channel. For example, payment card data
(i.e. PAN) stolen from PoS devices may be
used to initiate fraudulent CNP
transactions over the internet.
Cross-channel fraud is a major worry for
several reasons:
• First, the possibility of cross-channel
fraud means that the security of all
payment channels is effectively
interdependent. Take ‘PIN-and-chip’, which
makes card-present payment transactions Figure 2 - Fraud risk reducation options
more secure by requiring authentication
of the card and the card holder. This conversely, the designers of the new the PAN secret. 3D-Secure-based
positive effect will be negated to some payment channel need to look to possible mechanisms such as ‘Verified by Visa’ and
extent if it is possible to steal the full cross-channel fraud, in addition to making ‘MasterCard SecureCode’ attempt to
magstripe data and use it to perform a sure their solution is secure on its own. reduce CNP fraud by means of cardholder
‘magstripe and signature’ transaction in authentication.
another part of the world. Tokenization: A New Approach
• Second, the security of CNP transactions Fighting card payment fraud is essentially The real novelty of payment tokens, as
has not been solved in a consistent and a matter of risk management. A basic specified by EMVCo, is the idea to reduce
satisfactory way globally, and it probably approach to risk management is to the impact of fraud instead. Even if a
will not happen anytime soon. Because of quantify risk as the multiplication of the breach occurs and payment tokens get
the possibility to cross-channel fraud, this likelihood of a certain security breach and known, the damage done is limited. This is
means that other payment channels will the impact of that security breach. This is achieved by limiting the value of a token,
remain at risk as well. shown in Figure 2. compared to the original PAN it replaces.
The next chapter will describe in detail
It is clear that cross-channel fraud is a Historically, the emphasis for risk how this works.
threat to the emergence of the reduction in the card payments industry
omni-channel payments experience that has been on reducing the likelihood of
we mentioned above. Every addition of a fraud. EMV and PCI are prime examples of
new payment channel means that existing this. EMV reduces the chance of fraud
channels have to worry about the security happening with CP transactions by
of the new channel and the potential for introducing strong card authentication.
cross-channel fraud that it opens up. And PCI reduces the chance of fraud by keeping

page 5

What is Tokenization?
Token Taxonomy
Tokenization can be defined as the
replacement of a high-value credential
with a surrogate number that can only be
used within a particular context. Since this
definition is quite broad, the word ‘token’
can mean many things to many people.
Figure 3 shows a way to distinguish
different types of token.
Figure 3 - Different types of token
In the context of this whitepaper, the
high-value credential is the PAN. Even
within this context, it is necessary to
properly distinguish between two types of
tokens: security tokens and payment
tokens. The key difference between these
token types is that payment token can be
used to initiate a payment transaction,
whereas security token cannot. The next
two subsections describe these types of
token in more detail.
page 6
White paper - Tokenization explained
Security Tokens
Security tokens are not new, and are also
known as ‘merchant tokens’ or ‘acquirer
tokens’. For a long time already, merchants
and acquirers have stored surrogate values
for PANs, for example in their fraud
management or marketing systems. Apart
from reducing the risk of PANs getting
stolen, a main reason for using security
tokens instead of real PANs is to limit the
burden of PCI DSS compliance. This is done
by ensuring that real PANs are present in as
few systems as possible.
Security tokens cannot be used to initiate a
payment transaction. If a merchant needs
to initiate a payment transaction, the
security token must be de-tokenized to
retrieve the original PAN. Therefore,
security tokenization usually does not
allow merchants to remove the original
PAN completely from their systems,
although it does allow storing the original
PAN in one (PCI DSS-compliant) location
only.
Until recently, there was little or no
standardization for security tokens,
meaning that every vendor of such
systems used their own solution. For
example, security tokens can be generated
using very different methods, such as
random number generation or encrypting
or hashing the original PAN. From a
security point of view, these methods are
very different indeed. Recently,
standardization processes were started by
ANSI in the United States and the PCI SSC
internationally. The main thrust of these
efforts is to guarantee a comparable level
of security between different systems for
security tokenization.
 White paper - Tokenization explained

Payment Tokens
Apart from security tokens, the other type
of PAN tokens is payment tokens. As stated
before, EMVCo described payment tokens
in their Tokenisation Framework.
Payment tokens are fundamentally
different from security tokens. The table
below shows the differences between
payment tokens and security tokens.
The principle difference shown in the table
is that a payment token must be usable for
initiating payment transactions, while
security tokens are not. All other
mentioned differences follow from this
requirement:
• Payment tokens may be short-lived
(dynamic) or long-lived (static). Security
tokens are generally long-lived, as they are
meant to be stored and used for different
purposes later on.
• Payment tokens must be usable globally,
at every location or site where the original
PAN is usable. Note that this does not
mean that every token is usable at each of
these locations, but that (in principle) a
user must be able to obtain a token for
every location at which the original PAN
can be used. Security tokens are used only
within a particular merchant’s site or
system.
• Due to their global reach, payment tokens
cannot be issued by a merchant or acquirer,
as security tokens are. A new role in the
payment ecosystem is needed, called the
Token Service Provider. The Token Service
Provider may be the issuer.
• Payment tokens are generated by a Token
Service Provider, which may be the card
issuer, or a third party on behalf of the
issuer.
• Security tokens are generated by the
merchant itself. It may also be that the
acquirer (or a third-party vendor) offers
tokenization as a service. In that case,
however, the merchant and the acquirer
effectively share one distributed
tokenization system.
• Security tokens may be irreversible,
meaning there is no way to obtain the
original PAN from the token. Whether a
security token is reversible or irreversible
depends on the intended use. For a
marketing system using the token only as
an identifier for a particular customer,
irreversible tokens are fine. For an order
entry system, the token must be reversible,
because in the end the payment
transaction must contain the real PAN.
Payment tokens obviously must be
reversible always.
• Payment tokens are used in the same way
as a real PAN and therefore must have the
same format. In particular, the first digits
of the tokens are used for routing the
payment transaction to the correct issuer,
and payment tokens must pass the Luhn
check. In contrast, security tokens do not
need to be in the same format as the
original PAN. Again, whether or not this is
the case for a particular token depends on
the intended use.
• The properties of payment tokens are
defined by EMVCo and allow the token
issuer to limit the value of the token in
several ways according to the token’s
domain, storage location and assurance
level. The properties of security tokens are
not standardized.

Payment tokens Security tokens

Goal For initiating payment transactions For storage and analysis, e.g. marketing, internet or
customer-facing systems, fraud management
Life time Short-lived or long-lived Long-lived
Usable Globally Locally (in owner’s systems)
Issuer Token Service Provider Merchant or acquirer
Reversibility Always reversible by Token Service Provider Potentially irreversible
Format Always in PAN format (length, BIN range) Potentially in different format than original PAN
Properties Standardized by EMVCo, allowing the Not standardized
limitation of token value.

page 7
 White paper - Tokenization explained

EMVCo Payment Tokenization Token Provisioning

Framework The provisioning process of an EMVCo

Ecosystem
The EMVCo framework for payment
tokenization was designed to be fully
compatible with existing three or
four-party payment schemes. The table
Figure 4 - EMVCo payment token provisioning
below shows the five familiar roles in such payment token is depicted in Figure 4.
a scheme and the impact the introduction
of tokenization has on each of them.
A cardholder interacts with a Token Based on the ID&V information and
The main ingredient that tokenization Requestor and presents his PAN. The potentially further checks done by him or
adds to the payment schemes-as-we- Token Requestor sends a ‘Token Request’ requested from the Issuer, the Token
know-them are two new roles, called the message to the Token Service Provider. Service Provider determines the Token
Token Requester and the Token Service This message may contain so-called Assurance Level. This is basically an
Provider. These parties play important Identification & Verification (ID&V) indication of how trustworthy the new
roles in the lifecycle of a payment token, information, which indicates how sure the token is. We discuss ID&V and Token
which mainly consists of two steps: token Token Requester is about the identity and Assurance Level in more detail below.
provisioning and token transaction authenticity of the cardholder.
processing.

Role Impact of tokenization

Cardholder No changes. The cardholder does not need to know that he uses a payment token.
Merchant Potential changes: the merchant does not need to know that a customer uses a token,
unless he acts as a Token Requester.
Acquirer No changes.
Issuer Performs identification and verification (ID&V) during token issuance. Potentially acts
as the Token Service Provider or a Token Requester. Potentially no longer responsible
for cryptogram validation in transactions using a token.
Payment Network Small changes to authorization request and response messages.Potentially bigger
changes if network is also used for token issuance messages.Potentially acts as the
Token Service Provider.
Token Requester New role, requesting the Token Service Provider to issue a token instead of a PAN.
May be a merchant, a wallet provider, an issuer or another party.
Token Service Provider New role, providing tokens to registered Token Requesters. Maintains secure Token
Vault to be able to perform de-tokenization during a payment transaction initiated
with a token. May perform token cryptogram validation on behalf of the card issuer.
May be a payment scheme, a card issuer or another party.

page 8

The Token Service Provider returns the
token to the Token Requester. Depending
on the use case, the Token Requester stores
the token or forwards it to the Cardholder’s
device. Below, the most important
tokenization use cases are discussed.
Token Transaction Processing
Figure 5 shows the transaction processing
flow in case an EMVCo payment token is
used instead of a real PAN.
In some use cases, such as NFC payments
in a shop, the cardholder will present the
token to the PoS terminal of the merchant.
In other use cases, such as Card-on-File
systems, the merchant already knows the
token.
For mobile payment transactions, the
Figure 5 - Figure 5 EMVCo Payment Token Transaction Processing
page 9 7. Please beware that the word ‘token’ is often used to refer to a token cryptogram, instead of to a surrogate value for the PAN. In discussions between different parties, this can easily
lead to confusion, which can be most easily cleared up by asking or giving a clear definition of what a ‘token’ is.
White paper - Tokenization explained
cardholder’s device will produce a token
cryptogram to authenticate the
transaction. A token cryptogram is a
transaction-unique value generated using
transaction data and cryptographic keys
stored on the device. In the case of an
EMV-based transaction, the token
cryptogram may be a dynamic CVC value or
an ARQC (Ref. [7]).
The payment transaction, including the
token-specific data, is sent from the
merchant, via the acquirer, to the Token
Service Provider. The same protocols and
payment network(s) are used for this as
would be for a transaction using a real
PAN. The Token Service Provider carries
out a number of checks on the token, for
example to make sure the token is valid for
this transaction. These checks are discussed
in more detail further in this document.
The Token Service Provider probably will
also validate the token cryptogram on
behalf of the issuer, although EMVCo leaves
open the possibility that this is done by
the issuer itself. If all checks are correct,
the Token Service Provider will replace the
token by the real PAN, and will send the
transaction to the issuer for authorization.
During transaction authorization, the
Issuer may use the Token Assurance Level
of the token, next to other information,
to decide whether or not to authorize the
transaction.
Token Properties and Token Domains
Payment tokens according to EMVCo have a
number of properties:
• A token expiry date, similar to the Card
Expiry Date for the real PAN. The token
expiry date cannot exceed the Card Expiry
Date of the associated PAN. When a card
expires, all tokens associated to that card
(PAN) must expire as well. The same goes
for other card life cycle events, such as
blocking or termination: these must be
reflected in the associated tokens as well.
• A token location, which indicates the
mode of storage of a token, i.e. whether it
is stored in software on a mobile device,
inside a Secure Element, or on a merchant
server, e.g. for card-on-file transactions.
Since the level of security of these locations
differs greatly, the token location will have
impact on the allowable token expiry date
and/or token domain.
 White paper - Tokenization explained

• A token domain, which indicates the
environment in which a token may
be used. Domains can be based on
parameters such as the merchant where
the transaction takes place, the digital
wallet in which the token is stored and the
channel used to initiate the payment, such
as magstripe card, EMV card, mobile NFC
or card-not-present.
• A token assurance level, which is a
measure of the assurance placed on
the connection between the token and
the rightful cardholder. The different
token assurance levels and the EMVCo
requirements for these levels are discussed
later on.
Token Requester and the Token Service
Provider, and is reflected in the ID&V
information that must be present in the
token request.
Figure 6 shows a number of ID&V
methods identified by EMVCo, together
with an indication of their relative
strength. Note that EMVCo does not
mandate any particular ID&V methods
and gives only a rough indication of how
strong these methods are.
Several parties in the scheme may be
involved in these Identification and
Verification methods. The lower-security
security methods, such as address
verification or a zero-amount
authorization, may be carried out by the
Token Requester, who will report on the
outcome of these checks in the Token
Request message. Risk scoring will be done
by Token Service Providers. In case a very
high trust is needed in the relationship
between cardholder and token, the card

During transaction processing, the Token

Service Provider checks the validity of
these parameters. Depending on the
outcome of these checks, the Token
Service Provider may decline the
transaction or send it to the issuer for
authorization.

ID&V and Token Assurance Levels

A very important property of a payment
token is the token assurance level. The
assurance level measures how sure the
Token Service Provider is that a given
token was issued to the rightful
cardholder. After all, if a fraudster can very
easily convert a stolen PAN into a valid
token, the whole purpose of the Figure 6 - ID&V levels

tokenization mechanism is defeated.

The token assurance level assigned to a
given token is based on the level of
Identification and Verification (ID&V) that
took place during the issuance process of
the token. The expected assurance level of
tokens is agreed upon between each
It is up to the Token Requester, the Token
Service Provider and the Issuer to
determine which measures will be used in
a given ecosystem, and what the exact
relationship is between a given token
assurance level and the liabilities of each
actor.
issuer may carry out cardholder
authentication using its established
methods, such as sending a verification
code via SMS or using a 3-D Secure
method.

page 10

Static and Dynamic Tokens
Although the EMVCo Tokenisation
Framework does not discuss this, a
distinction can be made between static
and dynamic tokens. Static tokens are
tokens that are meant to be used for many
payment transactions. Dynamic tokens, on
the other hand, are meant to be used for
only a limited number of transactions.
Tokens can be made dynamic by setting
the token expiry date to a date in the near
future. Alternatively, the issuer can set
rules in its authorization system so that a
certain token is only valid for a limited
number of transactions, or even for only a
single one.
The more ‘dynamic’ a token is, the shorter
its lifetime and the more effort must be
put in frequently issuing new tokens.
Conversely, a more ‘static’ token needs to
have stricter requirements with regard to
the security of its storage location, unless
other security measures are present to
ensure that a stolen token cannot be used.
Figure 7 - Token Issuance for Apple Pay
page 11
White paper - Tokenization explained
Payment Tokenization Use • Apple uses an embedded Secure Element
Cases on the iPhone 6 to store the token.
• Tokenization is not the only important
ApplePay Token Issuance security feature in Apple Pay. In fact, an
Apple Pay card is an EMV card, using
From the figure below, it is clear that Apple cryptography to ensure that the card used
Pay follows the issuance process for tokens in every payment transaction is authentic.
as defined by EMVCo. The following The cryptographic keys that are stored in
aspects are noteworthy: the Secure Element to allow this are
• Apple itself takes on the role of Token derived by the payment schemes and sent
Requester. securely to Apple together with the token.
• MasterCard, Visa and American Express • Apple Pay tokens are static: the same
act as Token Service Providers for cards token can be used for multiple
carrying their respective brands. For Visa, transactions. Apple refers to a token as a
the platform doing this is Visa Token ‘Device Account Number’.
Service (VTS), for MasterCard it is the
Digital Enablement Service (MDES) and
Amex calls its service the American
Express Token Service.
• The card issuing banks take care of the
Identification and Verification process for
the cardholder.
• Cardholders present their PAN to Apple
either by making a picture of their card, or
by referring to a card that is already
present in their iTunes account.
 White paper - Tokenization explained

Transaction Processing
When looking at the figure, one of the
most promising features of Apple Pay
becomes immediately clear: Apple Pay
allows a customer to pay both in a physical
shop and in an iOS app (Ref. [8]). In a shop,
the phone uses its NFC interface to
communicate with a PoS device, while for
in-app payments the app connects to the
payment provider of the merchant.
This is very powerful, but without the use
of tokenization, it probably would have
been too risky for Apple. Without
tokenization, Apple would have been
forced to store the real PAN of the
customer on its devices, opening up the
risk of cross-channel fraud.
Tokenization allows Apple and the
payment schemes to manage this risk, for
example (Ref. [9]) by:
• Replacing a compromised token without
any effect on other tokens or on the
underlying PAN. This can be done without
the cardholder even noticing.
Other noteworthy aspects of Figure 8:
• Both for NFC transactions and in-app
transactions, Apple Pay generates a token
cryptogram. Depending on whether an
EMV or contactless magstripe transaction
is performed, this is an EMV cryptogram or
a dynamic CVC.
• Apple uses the term Dynamic Security
Code for the token cryptogram.
• The cryptogram is validated by the
schemes, on behalf of their card issuers.
Issuers do not validate any cryptograms
from Apple Pay.

Figure 8 - Token Transaction Processing for Apple Pay

For both payment channels, however, the • Using different tokens for NFC payments
security level is identical. And once the and in-app payments, thus preventing
transaction reaches the acquirer, also the cross-channel fraud between these
way the transaction is processed is the channels.
same. Therefore, Apple Pay closes the gap
between traditional CP and CNP
transactions.

page 12 8. Apple makes a distinction between in-app purchases and Apple Pay purchases done via an app. The first category involves goods and services that are delivered within the app, such
as digital books, subscriptions or bonus levels in a game. The latter category involves real-world goods and services that are bought via an app but delivered via another route. In-app
purchases are not paid for via Apple Pay, but via the App Store. 9. These are merely suggestions; it is not known how Apple deals with this in practice.
 White paper - Tokenization explained

HCE, cloud-based payments and Limited

Use Credentials
Cloud-based payments is the other major
payment change driver in the industry. The
central idea of cloud-based payments, as
shown in Figure 9, is to store the sensitive
data of a mobile payment application in a
remote server, instead of on a Secure
Element. This data may include the PAN
and the cryptographic Card Master Key of
the card. The mobile payment application
itself contains only data with a limited
value, which is regularly updated by the
remote Card Management System. This
architecture is made possible by Google’s
introduction of Host-based Card
Emulation (HCE) technology in Android
KitKat. Before HCE, all incoming
communication to the NFC Controller on a
phone was automatically routed to the
Secure Element. HCE makes it possible to Figure 9 - HCE, Cloud-Based Payments System and Tokenization
route this communication to the Android
OS instead. The Android OS can then At the same time, the reward for thieves to bank, such that limited-use credentials
further route this communication to a break in to a cloud-based payment that are compromised in any way can
specific payment application. Since the application becomes less, so that fewer easily be blocked.
payment application is running on the attempts to do so will occur.
phone OS, it can make use of all remote Tokens versus Limited-Use Credentials
communication possibilities of the phone. Limiting the value of the data stored in the Clearly, the concepts of tokens and limited
payment application is done by the use credentials are related. For both, the
The choice not to use a Secure Element for introduction of so-called limited-use central idea is to replace high-value
storing sensitive card data on a mobile credentials. Limited-use credentials are information with a surrogate that has a
device raises serious questions on the cryptographic keys (Ref. [11]) that can be more limited validity and hence a lower
security of such a solution (Ref. [10]). used by the payment application to value. In theory, the two concepts could
Multiple ways can be envisaged to ensure calculate EMV cryptograms or dynamic even replace each other, with payment
a sufficient level of security without using CVC values. However, the validity of these tokens as defined by EMVCo being used as
a Secure Element. The system chosen by keys is limited, such that one limited-use limited-use credentials in a Cloud-Based
the major payment schemes is to limit the credential can be used for only one (or at Payment system. That would require the
value of the credentials stored in the most a few) transactions (Ref. [12]). use of very dynamic tokens that can be
payment application. Limiting this value used for only a few transactions at most
means that the impact of any breach is Moreover, in a cloud-based payment (Ref. [13]).
minimal. system all transactions must be approved
on-line by the authorization system of the

page 13 10. Interested readers are referred to UL’s whitepaper ‘HCE security implications - Analyzing the security aspects of HCE’ (January 2014). 11. Some vendors of cloud-based payment
systems, as well as other parties such as Google Wallet, use different solutions, such as tokenizing the Application Transaction Counter. 12. Each of the major payment schemes uses a
slightly different name for these credentials and has slightly different methods for limiting their validity. 13. In practice it would lead to problems, because the PAN or token is used to
identify the payment application e.g. in some cryptographic certificates. Using a different token for every payment transaction would require renewal of those certificates for every
transaction.

However, in practice there are a number of
differences between the two concepts:
• A token replaces a PAN; a limited-use
credential replaces a cryptographic card
key.
• A token is usually valid for the entire
lifetime of the virtual card; a limited-use
credential is often cryptographically
limited to only one payment transaction.
• Tokenization is primarily meant to battle
cross-channel and card-not-present fraud,
whereas limited-use credentials solve the
problem of the lack of secure storage for
payment keys in a mobile device. In other
words: limited-use credentials are there to
secure a specific type of card-present
transactions, whereas tokens have a much
broader applicability.
Despite these differences, tokens may be
used in a cloud-based mobile payments
system. The major payment schemes
currently do not have an obligation to do
so, although they usually require that the
issuer can recognize transactions
originating from cloud-based payment
applications by their PAN and does not
authorize transactions using that PAN over
a different payment channel. If
tokenization is used, tokens are used next
to limited-use credentials, not in
replacement of them.
A major reason for the payment schemes
not to require tokenization of the PAN for
cloud-based payment applications is the
fact that these applications currently are
used (almost) exclusively for paying in
brick-and-mortar shops over the NFC
page 14
interface. However, there is no reason why
such applications could not be used for
remote and in-app payments, much in the
same way as Apple Pay does. If that
happens, tokenization will become more
relevant for cloud-based apps as well, for
exactly the same reasons.
Above, we pointed out that MasterCard,
Visa and American Express each have
systems that can act as the Token Service
Provider for Apple Pay virtual cards. Some
of these systems can also act as providers
of limited-use credentials for cloud-based
payment applications. Therefore, banks
can use the services of these systems to
provision virtual payment cards both on
iPhones supporting Apple Pay and on
Android phones supporting HCE
technology.
What is next for Tokenization?
The use of tokenization has only just
begun. Even with Apple Pay being fully
tokenized, the percentage of payment
transactions for which a token is used
instead of a PAN is still tiny. This goes both
for card-present and card-not-present
transactions. So what will the future be
for tokenization?
UL believes the following developments
will gain traction in 2015 and beyond:
• An increasing use of tokenization to
secure both internet payments and
in-shop payments. Partly this will happen
because of the increased percentage of
customers that use an iPhone 6 or Apple
White paper - Tokenization explained
Watch and therefore are able to use Apple
Pay. However, mobile payment systems
using tokenization will be created also for
Android phones.
• Currently, Apple Pay cannot be used for
check-out at online web shops. In the
future, we expect Apple or other mobile
payment systems based on tokenization to
support this use case as well.
• A new rate tier for interchange fees for
tokenized transactions. The concept of
“card-not-present” (CNP) will be soon
outdated. Solutions such as Apple Pay in
combination with the payment schemes’
tokenization services allow a consumer to
pay over the internet with the same level
of security as in a shop.
• Tokenization of other payment cards.
Once tokenization is successful for
‘open-loop’ payment cards, fraud may be
expected to shift to other payment cards,
such as private label, voucher, and benefit
cards. Consequently, tokenization will be
applied for such cards as well.
• Tokenization in other domains, such as
health care and social security.
Tokenization can not only be used for
Primary Account Numbers (PAN) in the
payment industry, but also for other
valuable identifiers, such as social security
numbers, patient numbers in medical
records, etcetera. Also for these identifiers,
the idea of using surrogate values that are
based on the domain in which they are
used can potentially solve many security
problems. In these domains, such
surrogate values are commonly known as
‘privacy-protecting credentials’ or
‘anonymous credentials’.

UL published a white paper on this topic in
April 2012, entitled ‘Comparison of e-ID
solutions with privacy-preserving
characteristics.’
• Solutions for tokenization’s remaining
problems. Dynamic tokenization poses
problems for merchants and loyalty
schemes. Many loyalty implementations
require the PAN to identify the customer
and assign loyalty points. This is not
possible with a dynamic PAN. Future
developments will provide solutions for
that problem.
• Ongoing standardization for Security
Tokens. Although not the main topic of
this whitepaper, security tokens are very
relevant to reduce the risk of card data
comprises in non-payment environments
such as loyalty and fraud analysis. We
expect the PCI SSC and other parties to
come up with standards to achieve a
common and auditable level of security
between tokenization systems offered by
different vendors.
page 15
How UL Can Help
This white paper has shown the reasons
behind the payment industry’s adoption of
tokenization and the benefits that
tokenization has for merchants and
issuers. Eager to explore the possibilities of
tokenization for your organization? UL can
help you!
• UL’s consultants provide expert business
and technical advice and consultancy
services across the mobile, payment,
e-ticketing and government domains. We
help you to develop strategic insight,
setting and reaching your goals, evaluate
vendor proposals or creating your offering.
We understand your challenges and know
how to address them. You can leverage our
extensive knowledge, which goes beyond
mobile payment technology only. UL also
has an outstanding portfolio of training
courses. Whether you need to brush up
your knowledge about Tokenization, NFC,
HCE, TSMs, EMV, SEPA or any other topic
related to your business,
White paper - Tokenization explained
• Our test and certification services ensure
that your (virtual) cards and acceptance
infrastructure is thoroughly tested,
including the interface to any Token
Service Providers. Our wide range of
certification services includes terminal and
host protocol certification and network
interface validations, as well as security
testing and load and performance testing.
• We can also advise you on the latest
security threats and industry
requirements. UL’s security evaluation
services are endorsed by recognized
regulators and certification bodies, such as
EMVCo and PCI, as well as by all major
payment schemes.
• Finally, utilize our test tools allow you to
demonstrate the quality of your products
or systems, or, conversely, to ascertain the
quality of a system that you need to
formally accept. UL has a broad portfolio
of off-the-shelve test tools, including many
tools specific for the mobile payments
domain. Alternatively, we can develop
custom test tools to suit your needs.
Contact details
UL
Transaction Security Division
www.linkedin.com/company/ul-transaction-security
info@ul-ts.com
www.ul-ts.com www.twitter.com/ULTSnews