2.2 Tokenisation Definition and Overview

Tokenization is the process of protecting sensitive data by replacing it with an algorithmically generated number called a token.

For example, a customer's primary account number (PAN) is replaced with a series of randomly-generated characters, called the "token".

The same card can have many tokens as the end-user has enabled devices, such as smartphones and wearables or digital wallets etc.

These tokens can be used for in-store, in-app or online payments.

The are secured and stored "inside a vault", outside the device.

For every transaction, then token must be coupled with a cryptogram.

2.2.1 What is a Cryptogram?

Cryptogram: In fintech, a cryptogram is a unique, one-time code generated during a secure payment transaction, typically for card payments. It's used to authenticate the transaction and ensure that the payment information is genuine and hasn't been tampered with.

Key points about cryptograms:

2.2.2 "Inside a vault"

The term "vault" in this context is a metaphor used to describe a secure, encrypted database where the original sensitive data is stored. Here's what it means:

Using the vault metaphor helps non-technical people understand that their sensitive information is kept in a separate, highly secure location, much like valuable items would be stored in a physical vault.

3.3 How Tokenisation works in Digital Payment

The cardholder must use a device that supports the digital wallet application and registers a card.

The application stores the generated token as:

The could be two formats of tokens:

3.3.1 Elaborating on the Token Requestor and Token Service Provider

3.3.2 An example walkthrough

Example: Sarah wants to add her credit card to her smartphone's digital wallet.

Now, when Sarah uses her phone to make a purchase:

Throughout this process, Sarah's actual credit card number is never exposed to the merchant or transmitted over any network. Only the token is used, providing an extra layer of security.

This example demonstrates how tokenisation protects sensitive payment information while still allowing for seamless transactions. The TR (the digital wallet app) and the TSP (the token service) work together to create a secure system for digital payments.

In the scenario of using non-format preserving tokens, the token Sarah gets back could be a randomised value and not a 16-digit value.

3.3.3 Secure Element (SE) and Host Card Emulation (HCE)

These are two different methods for storing sensitive payment information (like tokens) on a mobile device. Let's look at each:

Secure Element (SE):

Key benefits:

Host Card Emulation (HCE):

Key benefits:

In practice:

Both methods aim to protect the tokenized payment information, but they do so in different ways. The choice between SE and HCE often depends on the device manufacturer, the payment system, and the desired balance between security and flexibility.

3.4 How to add a card for Tokenisation

Each network token is exclusive to both a digital wallet and a device. E.g. a network token requested by Apple Pay on an iPhone cannot be used by a Google Pay digital wallet or an Apple Watch. It can only be used by Apple Pay on the particular iPhone on which it was requested.

3.4.1 Examples

For an analogy, think of your digital wallet like packing for trip:

3.5 Registration and Tokenisation

This video walks through the process of tokenising a card.

It walks through the important relationship between the Token Requestor, the Token Service Provider and the Issuer.

3.6 Tokenised Transaction Flow

For the tokenised transaction flow, it will start with a payment happening (for example from a device) at the merchant (could be a POS system).

The merchant will talk to the acquirer who talks to the payment network.

That payment network will talk to the TSP, then talk to the issuer bank.

3.6.1 Elaborating on the above

Here's a more comprehensive view of the process:

Key points to note:

This flow demonstrates how tokenisation adds a layer of security to the transaction without significantly changing the overall payment process. The token serves as a stand-in for the card number throughout most of the transaction, reducing the risk of card data being intercepted or stolen.

3.6.2 Elaborating on the cryptogram

In most cases, it is indeed the device (such as a smartphone or a payment-enabled smartwatch) that generates the cryptogram. However, the process is a bit more nuanced:

It's worth noting that while the device generates the cryptogram, it does so using protocols and keys that were set up when the card was first tokenised and added to the digital wallet. This setup ensures that only the legitimate TSP or issuer can validate the cryptogram, maintaining the security of the system.

This process allows for a high level of security in mobile payments, as each transaction is authenticated with a unique, device-generated code that can only be validated by the appropriate parties in the payment chain.

The Cryptogram is generated based off information provided by the TSP during the tokenisation process:

4 Network Based Tokenisation

4.7 Network based tokenisation continued

The participants:

4.8 VISA Tokenisation

This is a diagram to explain how Visa tokenisation happens.

The important parts of the diagram were that Visa shares the token request with the account issuer and then with their approval, replaces the consumer's PAN with a unique digital identifier (the token).

6 Apple Pay Tokenisation

This did an overview from the Apple Pay perspective.

7 Encryption vs Tokenisation

7.1 Encryption and Tokenisation Definition and Difference

A few differences:

7.2 Risk and Security - Use Both

7.2.1 Explaining encrypt, then tokenise

Explanation:

This two-step process ensures that even if the token database is compromised, the actual data remains protected by encryption.

Real-world example:

Let's say a customer, Alice, is making a purchase at an online store.

Here's a simplified pseudo-code example to illustrate this process:

# At the merchant's point of sale
def process_payment(card_number):
    # Step 1: Encrypt the card number
    encrypted_card = encrypt(card_number, encryption_key)
    
    # Step 2: Send encrypted data for tokenization
    token = tokenization_service.get_token(encrypted_card)
    
    # Step 3: Use token for transaction and store for future use
    process_transaction(token)
    store_token_for_customer(token)

# At the tokenization service
def get_token(encrypted_data):
    # Generate a random token
    token = generate_random_token()
    
    # Store the encrypted data with the token
    token_vault[token] = encrypted_data
    
    return token

# When needing to use the token (e.g., for a refund)
def use_token(token):
    # Retrieve the encrypted data
    encrypted_data = token_vault[token]
    
    # Decrypt the data (only done when absolutely necessary)
    original_card_number = decrypt(encrypted_data, decryption_key)
    
    # Use the original data as needed
    process_refund(original_card_number)
copy

Key points:

This approach provides several benefits:

In a real-world scenario, the encryption and tokenization processes would be much more complex and would follow strict security standards like those set by PCI DSS (Payment Card Industry Data Security Standard).

7.2.2 The cloak room and the treasure chest

This analogy works well because it illustrates several important points:

To extend the analogy a bit further:

7.2.3 Hardware Security Modules (HSM) for Encryption of Decryption

A physical/cloud computing device that safeguards and manages digital keys, performs encryption and decryption functions for digital signatures, strong authentication and other cryptographic functions.

Can be used for:

8 PCI DSS on Tokenisation

8.1 PCI DSS on Tokenisation Explored

8.2 Components of Tokenisation in PCI DSS

1. Tokenization System Components

A. Token Characteristics

B. Token Generation

2. Token Mapping

A. Process

B. Functionality

3. Card Data Vault

A. Purpose

B. Security Considerations

4. Cryptographic Key Management

A. Functions

B. Security Measures

5. Deployment Considerations

Key Takeaways

8.3 Tokenisation Deployment Models

Examples of common deployments:

For outsourced or hybrid, responsibility for ensuring some components comply with PCI DSS may be partially transferred from the merchant to the TSP.

Components of the tokenisation system that are managed by the service provider and are outside the control of the merchant should be certified by the PCI DSS.

8.4 Merchant Responsibilities in PCI DSS Tokenisation process

The merchant should:

9 A brief overview of Open Authorisation OAuth and Tokens

Access tokens and refresh tokens.

OAuth is for machines "logging into" machines on behalf of humans. It's authorisation, not authentication.

10 Benefits of Tokenisation and Conclusion