White Paper Tokenization: Everything You Need to Know

2

Executive summary 3

1. What is tokenization? 5

1.1 A definition 5

1.2 Tokenization – a brief history 7

1.3 How are tokens used? 8

1.4 What is the aim of tokenization? 9

2. Different types of tokens 10

2.1 How can tokens be used to protect payments? 12

2.2 Tokenization is already here 13

2.3 Tokens…a step further 15

2.4 When tokens are a step too far… 16

3. So who should be the token service provider (TSP)? 18

4. The future of tokenization 23

About the author 25

About Bell ID 26

Contents

2

3

Executive Summary

3

Tokens are used in a number of environments to replace and

protect the underlying value of credentials. In the payments world,

tokenization is primarily used to secure payment card data. This can

be done using EMVCo Tokenization for card payment transactions

or Payment Card Industry (PCI) Tokenization for card-on-file

data, which is stored in merchants’ or acquirers’ systems after a

transaction is completed.

This v is primarily focused on EMVCo Tokenization, although it will

also address the use of the same underlying security mechanisms

and technology for use cases beyond bank payment cards. EMVCo

Tokenization is already a de facto requirement for a number of

card payment environments: card-on-file (at merchants); mobile

near field communication (NFC) payments (any of the OEM Pays,

and all forms of cloud based payments); as well as being used

increasingly for secure remote payments in e-commerce/m-

commerce. Therefore, the critical question for most issuers is not

‘if’ to tokenize, but instead ‘where’ to tokenize. It is important to do

this in the most efficient and effective way to support that issuer’s

short, medium and long term strategic goals.

The critical question for most issuers is not ‘if’ to tokenize, but instead ‘where’ to tokenize.

4

US-based issuers of early payment industry tokenization initiatives

had very limited (or no) deployment options, since their services

were implemented by the payment networks. Now, however,

many issuers want to regain control of their cardholder payments

processing. The opportunity to deepen their understanding of

cardholder transaction behavior, together with the growing number

of payment channels that can be processed as separate token

domains and the enhanced token controls that can now be applied

to the process, are all factors that are driving issuers to establish a

cost effective token processing service before moving to significant

production volumes.

Outside of the US, many issuers can strategically consider

tokenization from day one. This needs to be done quickly given

the accelerating pace of global mobile NFC payments rollout, the

increasing frequency of data breaches at merchants and the growth

in fraud rates in the rapidly expanding e/m-commerce payments

environment.

This white paper looks to inform the reader on the subject of tokenization, specifically. What is tokenization? How can it be implemented? Why is this payment solution getting so much industry attention?

For those still relatively new to tokenization, this white paper

includes valuable references to help readers get to grips with the

subject, including information on token service providers, token

vaults and token domains.

4

55

01 What is

Tokenization?

1.1 A definition

The process of tokenization replaces sensitive data with surrogate

values, i.e. tokens, which remove risk but preserve value to the

business. These tokens are then used in place of the sensitive data

throughout the channel ecosystem, or token domain, until they can

be mapped back (de-tokenized), in a secure environment, to the

original value allowing any subsequent processing or reconciliation

to take place.

In an EMV® payments context and in simple terms, the EMVCo

Payment Tokenization Specification for payment cards requires

the replacement of the card’s primary account number (PAN) with

an alternate unique identification number, or ‘token’. To allow

this token to be processed over the EMVCo stakeholders’ existing

payments infrastructure, the token must be formatted to look like a

PAN. This enables transaction routing and satisfies legacy validation

checks.

PAN Token

0123 4567 8910 1112

3987

5793 6589

9886

5

6

Token

Acquirer Payment network

Issuer

Token Service Provider

TokenToken Token

RealCard

Token

A token request is generated by any third party that needs a token

instead of the original card (PAN). When tokens are required for

specific token domains such as a wallet on an NFC mobile device,

or a merchant to replace a card-on-file for internet purchases. The

exact parameters of the token issued in response to the request

depend on the domain and technology. It could, however, range

from single or limited use, and static token data, through to a fully-

functional EMV payment application populated with a token PAN,

token card data (expiry, etc.) and token EMV keys.

During the tokenization process, the real PAN – also known as the

funding PAN or true PAN – is sent to, and stored on, a centralized

and highly secure server called a token ‘vault’. This PAN is held

in the token vault with information on its relationship to the

one or more unique token PANs that represent it in different

token domains. Whenever one of the token PANs is used for a

transaction, it is identified as a token allowing the token vault to be

consulted to confirm the real PAN so that the transaction can be

authorized.

77

1.2 Tokenization – a brief history

In late 2013 American Express, MasterCard and Visa announced

their intentions to develop specifications for payment tokenization

in response to increasing fraud resulting from merchant data

breaches and growing e-commerce (card not present) concerns.

The responsibility for the development and maintenance of the

payment industry tokenization standards was subsequently

delegated to EMVCo.

In March 2014 EMVCo released its EMV Payment Tokenization

Specification – Technical Framework v1.0 and, later in 2016, will

issue the next version of this document as part of its increased

industry responsibilities for payment standards across tokenization,

mobile payments and 3D Secure 2.0.

The idea of replacing real card data with an alternate PAN or

surrogate card data to deal with fraud is much older, however,

and was initially introduced by several banks over a decade ago

to combat growing card not present fraud. Under this scheme,

bank cardholders could apply for a complementary ‘virtual card’

to be used for e-commerce purchases meaning their plastic card’s

data would not be exposed to the real and perceived dangers of

the internet. Depending on the bank, these virtual card products

could be single use, limited by value or expiry or simply used until

compromised.

Restricted to the e-commerce domain, and easily replaced, the

payment card token was born.

7

88

1.3 How are tokens used?

A token is issued for use in a transaction within its token domain,

and then passed through the card payments infrastructure until

it can be de-tokenized, often by the issuer, their processor, or the

(domestic or international) payment network.

Once de-tokenized, the payment authorization request is passed

to the issuer’s authorization system with the real PAN, plus details

that the transaction originated as a tokenized payment request

within a particular token domain. The authorization response is

then returned to the point of origin.

NFC Payment

E-Commerce/

M-Commerce

POS

Acquirer Payment Network Issuer/Processor

Token Vault

Tokenization interface

8

99

1.4 What is the aim of tokenization?

The process removes the real PAN information from environments

where data can be vulnerable and, if stolen, used for fraudulent

purposes. Tokenization quickly and completely removes the real

PAN from a payment domain and replaces it with a token, while

maintaining backwards compatibility with existing business

processes.

By making tokens domain-specific, secure segregation of payments

data is enabled – for example, a token designated for mobile

NFC payments cannot be used in place of a card-on-file token for

an e-commerce merchant. This segregation allows appropriate

levels of security and domain-specific risk management to be

implemented separately for each domain, and only restricted

by that domain’s limitations. So while a mobile NFC payment

application would support a full EMV implementation, including the

generation of transaction-specific cryptograms (a unique digital

signature for each payment), the token replacing the card-on-file in

an e-commerce merchant’s system would simply be a token PAN

with its own expiry date and verification code (equivalent to the

3-digit number usually read from the back of the card).

Tokenization removes the real PAN

from a payment domain and replaces

it with a token, while maintaining

backwards compatibility with existing

business processes.

Any fraud attempt, or specific data breach, then only impacts a

specific token (or domain), meaning re-issue is only required for

that specific token (or domain). There is no impact to the underlying

plastic card and all other associated tokens.

Given the restricted use of the tokens, and the possibility to define

enhanced security and risk management within each token domain,

the value of compromising a token and the potential window of

opportunity for carrying out fraud with that token, are significantly

diminished. This drastically reduces the fraudsters’ business case

for targeting the card payments ecosystem as the potential value of

an attack is extremely limited.

9

1010

Before discussing the different types of tokens from a business

perspective, it is first important to understand the make-up of a

token. Depending on the payment channel / token domain and the

way in which a token will be used, it could be as basic as the three

options below in orange.

As an example, a simple token comprising only the data below would

be enough to replace card-on-file payment data held on a merchant’s

website for online purchases, e.g. for ‘quick checkout’ mechanisms.

If the website is compromised, e.g. a merchant data breach, then

the token is stolen but the underlying card data is safe. Also, even

basic static tokens are only able to make payments within the one

single token domain (for card-on-file tokenization, and at that single

merchant). So, with tokens allowing channel-specific risk management

any fraudulent activity can be easily detected, allowing the payment

token to be easily revoked (without impacting other channels) and

replaced.

A static token PAN

a token expiry date any token-related static token verification code

02 Types of Tokens

10

1111

This experience is simple, customer-friendly and cost effective

when compared to managing a mail delivery of new plastic

payment cards after each new merchant breach is announced.

Tokens, however, can also be more complex. For example, they can

include their own keys and certificates for full EMV authorization,

enabling tokenized mobile payments that only work for contactless

EMV transactions.

Using EMV means the token is not only specific to a single domain,

and to a single mobile device, but also that each transaction is

cryptographically signed and unique.

Whether the make-up of the token is simple or complex, they must

be formatted to pass all standard checks used for routing and

validation. This ensures that token transactions can pass through

the existing card payment infrastructure, and be processed through

existing clearing and settlement platforms.

11

1212

2.1 How can tokens be used to protect payments? As context, the PAN information can currently be found on an

EMV debit or credit card. It is embossed onto the front of the

card, encoded into the magnetic stripe, embedded into the EMV

chip for contact transactions, and (from the EMV chip) can be

transmitted over the contactless interface. This information needs

to be protected from fraudsters and tokenization can be used in

a number of ways and domains to significantly limit the use of

the data if obtained, reducing its perceived value and therefore

discouraging hacking attempts:

Plastic payment cards

The PAN printed on the front of the card is

the real account number and then, trusting

EMV, the same PAN is embedded into the

EMV chip with its own keys, certificates

and verification values to protect that

channel. Tokens could potentially be used

in the magnetic stripe to limit use of the

data to only magnetic stripe transactions.

Additionally, the contactless interface

could feature a contactless-only PAN

which would only work with contactless

terminals.

Mobile NFC payments

For mobile near field communication (NFC)

transactions, a trusted NFC application

is stored on the device. This could be

something like Apple Pay in an iPhone

or a cloud based mobile payment app

in a Samsung, or any other Android,

smartphone. The token within this

application would be device-specific

and designated for use with contactless

payment terminals.

eCommerce /

mCommerce

Existing card-on-file details or

spontaneous e-commerce/in-app

transactions could both be secured with

tokens. For card-on-file tokenization, the

real payment card data will no longer

be held by the merchant, limiting the

impact of a merchant data breach. For

e-commerce/in-app transactions the token

would be restricted to the device and

domain (remote payments). Increasingly

a payment application on a consumer’s

smartphone, tablet or laptop is able to

perform secure remote payments with full

EMV transaction capabilities.

12

1313

Any PAY The OEM mobile wallets, usually supporting both NFC and

in-app payments and are in various stages of global roll out:

Android Pay – Google’s own wallet for Android smartphones,

supporting HCE/cloud based payments. Android Pay was released

at Google I/O 2015 as a successor to Google Wallet which was

released in 2011. It also uses technology from the carrier-backed

Softcard, which Google acquired in February 2015.

Apple Pay – The service was announced at Apple’s iPhone 6 event

on September 9, 2014. Apple Pay is founded on an embedded

secure element (eSE) to perform secured iPhone payments with

support from the device’s biometrics service, Touch ID.

Samsung Pay – Samsung’s wallet was launched in South Korea on

August 20th, 2015. It features a bundle of technologies supporting

NFC and MST (Magnetic Stripe Transmission) mobile payments

implemented using a trusted execution environment (TEE) –

Samsung KNOX) and eSE, depending on the individual needs of

each market.

2.2 Tokenization is already here When we talk about tokenization, it is not theoretical or in pilot

phase. It’s real. Here is a non-exhaustive list of existing payment

tokenization implementations of payment specifications and

vendor solutions.

13

1414

Card-on-file

Specified and implemented by some payment

schemes, this form of tokenization allows

merchants to replace card data they hold on

file – for periodic (installment) and repeat

visit transactions – with payment tokens.

The data held is static, but the domain is

limited to a single e-merchant, significantly

reducing the impact of any merchant or

acquiring processor data breach.

Cloud based payment

specifications

Host card emulation (HCE) enables NFC

mobile payments on Android smartphones.

This technology has been specified by most

of the international, and some national,

payment schemes globally and is often

deployed by individual issuers or their

processors as a bank owned wallet.

Others

Stretching the payments tokenization

envelope, these include:

- Chase Pay

- MCX / CurrentC

- Capital One

14

1515

2.3 Tokens…a step further

Closed loop and prepaid payment cards, such as gift and loyalty

cards, also face challenges when securely migrating from less

secure plastic cards (e.g. magnetic stripe or barcode) to support a

digital and mobile world. Tokenization can support these kinds of

implementations in any form factor: as a physical card; in an app or

mobile wallet; or as a virtual card or voucher for e-commerce.

Depending on the merchant acceptance infrastructure, these tokens

will be subject to format requirements, but will not necessarily

need to adhere to the PAN structures used in the financial industry.

Regardless of the format of the credential, however, many of the

underlying use cases, requirements and benefits of tokenization

will apply.

15

1616

2.4 When tokens are a step too far…

It’s possible to tokenize any formatted credential. There may also

be benefits to segregating different domains where a credential

could be used. As an example, a service provider may have

different levels of trust (or enable different levels of service) for

environments where the original credential (let’s say a contact

chip card) is presented, versus the mobile device in-app tokenized

version of the credential.

There are, however, challenges with tokenizing some credentials

that might not make it the silver bullet it initially appears to be.

Only the token service provider (TSP), via access to the token

vault, can see the relationship between the original credential

and all of its related tokens. This means that any parties involved

downstream of tokenization may find it difficult to gain an

aggregated view of the single credential, due to the presence of

its many seemingly unrelated tokens. Equate this to a merchant

trying to capture data on a consumer who uses multiple payment

cards, or an access control administrator trying to monitor the

movements of an individual who has a number of anonymous

access cards. Unless additional information is presented as part

of each transaction to prove a relationship, the link may remain

unknown.

There are challenges with tokenizing

some credentials that might not make

it the silver bullet it initially appears to

be.

In the EMVCo Tokenization case, a suggested new mechanism called

the payment account reference (PAR) is under discussion. This is a

new data item which would provide a common reference back to

the underlying funding PAN. While more details on PAR and its use

cases are expected in the next release of the EMVCo EMV Payment

Tokenization Specification, it’s unlikely that any key questions on

who allocates the PAR can be defined at the standards level. The

payment card issuer, their processor, or the payment network

– all of which could legitimately be a TSP – could all take on this

responsibility.

16

1717

Equally, issuers are well placed to manage customer-level risk

management and fine tune individual token domain controls in

the context of the wider consumer relationship as they are well

placed to have an understanding of multiple payment cards (PANs)

which may potentially be across multiple payment brands. This

does, however, devalue both PAR as a mechanism and, potentially,

undermines the value of consolidating token services at the

individual payment scheme level.

The jury is still out on PAR. It is seen to have negligible benefit to

merchants when considered against the significant investment

required to change their systems to accommodate it. On top of this,

most of the other potential use cases can (and often are already) be

much more powerfully and efficiently carried out at the issuer level.

While PAR remains optional at the EMVCo standards level – it is

currently down to acquirers and their merchants as to whether

they implement and support it – it has no business case for TSPs.

Conversely, if individual payment networks choose to mandate

it – particularly if used to restrict TSP competition to benefit their

own service – it will likely be subject to challenges from impacted

players in the token ecosystem and result in unwarranted costs for

little benefit and, potentially, regulatory issues.

17

1818

A TSP is an entity within the payments ecosystem that is able to

provide surrogate PAN values (payment tokens) to any registered

token requestors. Token Requestors could include OEM Pay

Wallets, and e-commerce Merchants with card data held on their

systems.

The issuance and remote management of the payment credentials

provided by TSPs must comply with specifications defined

by EMVCo and the global paymentschemes; supporting all

technologies including cloud based payments (HCE), embedded

secure elements, etc.

03 So who should be the token service provider

(TSP)?

Token Requestor Token Service Provider

18

1919

1. Tokenization

Replacing the PAN with the token.

2. Detokenization

Converting the token back to the PAN using the

token vault.

3. Token Vault

Establishing and maintaining the payment token

to PAN mapping.

4. Domain Management

Offers additional security by restricting tokens to

use within a specific (retail) channel or domain.

5. Identification and Verification

Ensures that the payment token references a

legitimate PAN from the token requestor.

6. Clearing and Settlement

Ad-hoc detokenization during the clearing and

settlement process.

TSPs have the ability to issue and manage the entire lifecycle of

payment credentials, implement tokenization to reduce payment

card fraud and manage transactions to integrate with the existing

authorization host by converting or validating cryptograms as well

as performing processing checks.

TSPs are also responsible for a number of other functions. They

oversee the ongoing operation and maintenance of the token vault,

deployment of security measures and controls, and the registration

process of allowed token requestors.

19

Responsibilities of the Token Service Provider

2020

So who can become a TSP? There is already a well-defined

list of candidates which are already recognized in the EMVCo

Tokenization standards.

The IssuerIssuers are the best placed party in the ecosystem to deliver the

most powerful levels of token and domain level control across the

entire breadth of their consumer relationship. They can offer this

regardless of which international or national payment brands they

issue cards for, in addition to overall consumer risk management,

etc. From the issuer’s perspective, this approach also provides the

best security, control and tailored use of tokenization to meet their

own strategy.

On the downside, tokenization is a technology which offers both

economies of scale, and some minimum scale requirements

for some interfaces. For smaller issuers or those that already

outsource most of their issuer processing activity, for example, it

may not be cost effective to implement in-house. Equally some

token requestors may be unwilling to directly connect to every

single issuer, looking instead to interface with national or regional

aggregators for token requests and token provisioning.

The Issuer ProcessorProcessors could potentially offer tokenization as part of an overall

bundle of processing services for multiple issuers. Partnering with

an issuer processor may represent a cost effective choice for some

issuers to process tokenized transactions.

Equally an issuer processor might be large enough to enable some

scale-dependent interfaces, for example, the provisioning interface

to one or more ‘OEM Pay’ wallets.

Most issuer processors provide a single point, or at least a reduced

number of points, of integration for an issuer supporting multiple

payment brands. They may also provide stand-in and other related

transactional and customer services for the issuer.

20

2121

Other Third Party ProcessorsOther third party processors may provide consolidated services

to issuers, or even issuer processors, such as token vaults and

provisioning interfaces. As such they offer efficiencies in terms of

cost, security and economies of scale, in addition to services (such

as provisioning) outside of the traditional payment transaction

routing and processing ecosystem.

NetworksCovering both domestic and international payment networks,

these entities may enable issuers to consolidate some or all of their

transactions, for transaction-based tokenization services.

Given economies of scale, and wider commercial opportunities, the

network may also provide issuers with issuer processor (on behalf

of) transactional services – including stand in, etc., – and even

third party processor aggregator services – such as provisioning

interfaces to OEM Pay Wallets. The pricing of these services, or

potential cross pricing of these with transaction service fees, will

depend on the commercial nature of the network. As an example,

a for-profit incorporated company must legally act and price

for profitability, whereas a bank-owned or nationally-regulated

network may have other goals such as cost reduction or providing

a utility service.

21

2222

Wherever an issuer chooses to source and pay for their

tokenization services will be dependent on many factors, including

its issuer-specific culture and any ongoing strategies relating to in-

house versus outsourcing. For example;

A large multi-national issuer – which supports a number of

international and domestic brands, across multiple networks

and multiple regulatory environments, and potentially needs to

offer merchant choice of network routing – will clearly benefit

from eventually bringing all tokenization in-house, or at least

working with a strategic issuer-processor partner.

A large national issuer – with investment in a domestic

network or third party processor – will benefit from sourcing

tokenization services from that shared, cost effective, entity.

A single payment brand or small-to-medium-sized-issuer that is

already reliant on its international payment network partner for

services, may automatically view tokenization as just another

network-on-behalf-of service.

In reality, most issuer scenarios will likely be less straight forward

than any of the above simple examples. They might need multi-

partner tokenization strategies across different payment brands

and regions, mixing some or all elements of in-house, processor

and network-level tokenization activities to deliver tokenization

across all channels and token form factors.

At a standards level, the choice remains with the issuers. Even

though the complete specifications and related mandates from

the individual payment networks are yet to be fully disclosed,

when an issuer or their processor is using existing allocated (bank

owned) PAN ranges for tokens – as many already are for cloud

based payments and other tokenized new payments – tokenization

is already taking place and can be transparent to the payment

network.

Many issuers continue to progress their own tokenization

strategies independently, where they see brands or networks as

potential costly, or even in competition with their own strategic

aims. Meanwhile MCX has already shown that, at the other end

of the ecosystem, merchants are willing to consider alternative

approaches. Beyond that, there is little to stop new disruptive

payment technologies from potentially adopting the benefits of

tokenization, without being tied to legacy network commercial

strategies.

Wherever tokenization is carried out, it still needs the right

solutions to securely and flexibly support all elements of this

evolving and diverse ecosystem.

 

22

2323

Later in 2016, EMVCo is expected to issue the updated and

expanded second version of its EMVCo EMV Payment Tokenization

Specification – Technical Framework. EMVCo has brought this

forward to expand the number of defined tokenization use cases,

clarify some points from the original 2014 version and add potential

new implementation considerations such as PAR.

Going forward, the expanding remit of EMVCo means that there

will be tighter integration between tokenization and other EMVCo

standardization across mobile and e-commerce security. This

may include an expanded scope to try to catch-up with alternative

formats for presenting or reading tokens, such as QR codes and

other mechanisms that individual payment brands and competing

third parties are already looking at.

04 The Future of Tokenization

23

2424

For now, payment card token-based services have already moved

beyond the initial USA implementations, and while there might

be some rapid rollouts in territories that will accept incumbent

network TSPs as a day-one solution to get to market, there

are already alternative TSPs coming into play. This aligns with

the differing issuer strategic needs both in the USA and other

territories.

Given the diversity of existing and emerging partners and

service providers in the tokenization ecosystem, it is set to be an

interesting few years. The industry will adapt over time to the

eventual survivors of the ‘wallet wars’, OEM Pay mobile market

share changes and the ability for differing TSP models to fit

with longer term issuer needs. One thing is sure, while it is in no

stakeholder’s interests for there to be millions of TSPs, there may

well be hundreds. This will bring sufficient competition to ensure

service pricing and quality and give issuers the choice to match

their individual needs for security, ownership and levels of control

while also meeting national and regional requirements for security

and competition.

24

25

About the Author David Worthington joined Bell ID in 2011 to advise the company

and its major clients on strategic opportunities in the application of

new payments, mobile and chip technologies.

With over 20 years in the smart card, certification authority

and payments industries, David has significant experience

from previous management roles at HSBC, NatWest, Mondex

International/MasterCard, Keycorp EMEA, and as the advisor for

banking technology to the Saudi Arabian Monetary Agency.

25

26

About Bell IDBell ID is the mobile payments company for card issuers to safely

bring cards onto the mobile devices of their customers. Its certified

and award-winning management software integrates with Mobile

Pay solutions and independent mobile wallets to allow end-users to

‘tap & pay’ via NFC smartphones and wearables.

Whether cards are stored on the device or in the cloud using host

card emulation (HCE), Bell ID adapts to any mobile payments

ecosystem and ensures security through tokenization; it enables

customers to fulfil the role of a token service provider (TSP),

securing transactions by removing vulnerable card data from the

payment network.

Bell ID is a division of Rambus (NASDAQ: RMBS) Cryptography

Research and has offices in Rotterdam, Boston, Toronto, Sydney

and Singapore.

For more information, please visit www.bellid.com or follow us on

LinkedIn, Twitter and Facebook.