Apple Pay and Android payment eco-systems

It is important to understand what tokenization means in the context of the introduction by Apple on Tuesday.  The word "tokenization" can sound very general, complex, and unknown the way it is being used in payments today.  I think many use the term without really understanding the important details of the concept.  I sort of relate it to when i pick up my 4 year old daughter from sunday school class, I will ask her what she learned, and she knows that if she answers "God", that she is right.

So the point of this blog is to try to understand what tokens are, and how they are used to solve something in payments.  The mis-understood rule of tokens is that people think they change from transaction to transaction, but in reality the cryptogram changes but the token properties (tPAN and tUDK) don't:

• A token may be created once for the life of a credential (card).  

This is easiest to understand with the Apple Pay use case.  The secure element on the phone is programmed at the factory when the iPhone is built to support many different card standards.  At the time when the token data needs to get programmed into the device, Apple requests a token for that device from the card networks.  The networks need to keep track of the token because they need to know how to translate that token into iTunes identity for processing the iTunes selected card during transactions with the payment acceptor.

But the important piece is that this token is a static identifier for the life of the card that was programmed.

A diagram describing this process for iPhone is here:   

Because Android is not a vertically owned stack similar to apple, it is really hard to distinguish who owns the SIM, or SE, or UICC that is on the particular phone.  Because of the ownership argument over the last few years, the idea of HCE was launched to push the ownership of the SE to the cloud so that it could be leveraged on any Android phone from the cloud.  But the important concept that has gotten lost with the Apple announcement is that the concept of "tokenization"  as Apple Pay uses is still the exact plan for tokenization in the android space.  With HCE enabled, however, the equivalent of the one time token "Apple ID" that lives in the iPhone SE, is actually located virtually in the cloud with a bank, or third party vendor like SimplyTapp:

======================AND STOP===================

THE TOKEN HAS NOW BEEN CREATED!!
THE TOKEN REQUESTER CAN USE THIS TOKEN FOR
ALL TRANSACTIONS ON THAT CARD GOING FORWARD
WITHOUT REQUESTING ANOTHER TOKEN FROM THE SERVICE
AGAIN FOR THE LIFE OF THAT CARD IT REPRESENTS

THIS CAN BE TREATED ON PAR WITH TYPICAL PLASTIC CARD
PERSONALIZATION SERVICES TODAY

ONLY WHEN THE TOKEN IS ACQUIRED BY THE MERCHANT
DOES THE NETWORK NEED TO VERIFY THE TOKEN AND ALSO
TRANSLATE THE TOKEN BACK TO THE CARD IT REPRESENTS
SO THAT THE BANK CAN PROCESS IT FOR APPROVAL AS
USUAL

SO ONE TOKEN AND RELATED DATA CAN BE USED FOR
MULTIPLE TRANSACTIONS

==================================================
ok, i think i'm done hammering that characteristic of a token. :)

Another very important thing to understand about transactions using tokens is to understand that the data format of a tokenized transaction is EXACTLY the same as the data format of a non-tokenized transaction from the Point of Sale perspective.  The same basic elements exist and are exchanged from the phone to the POS:
non-tokenized:
1) Personal Account Number
2)  Expiration Date
3)  Service Code
4)  Issuer Discretionary Data
5)  Cryptogram

tokenized:
1) Tokenized Personal Account Number
2)  Expiration Date
3)  Service Code
4)  Issuer Discretionary Data
5)  Cryptogram

because the data format that is exchanged between the phone and the POS is identical in both cases, the tokenized version still has the ability to include dynamic transactional data by using a Cryptogram to do so (adding the "one time number for each transaction" that Tim Cook preached about)

Keep in mind for cryptogram creation and cryptogram validation, there does not need to be a run-time link between the validator and the tokenized card (this is obvious by the apple deployment of a hardened secure element on the phone).

So understanding how tokenized or non-tokenized cryptograms are created and validated is important.  By the way,  the algorithm is identical for tokenized or non-tokenized.  The "tokenized" part of the features is actually out of the scope of cryptogram calculation / validation.

Cryptogram creation requirements:
1) card creation time, the token issuer authority (card network) contains an issuer master key for a "tokenized" BIN.  The master key for the "tokenized" bin is used to create a "tokenized" Unique Derived Key (tUDK) and "tokenized" Personal Account Number (tPAN) for each "tokenized" card when a Token Requestor requests a token on behalf of a card issuer.

2) Also at card creation time, this new "tokenized" UDK and "tokenized" PAN are delivered back to the Token Requestor

3) Now from a token requestor perspective, it is business as usual for tokenized card personalization.  This data is injected to the tokenized card just like a non-tokenized card.

4) A LUK is created PRIOR to transaction time:
   a)  Tokenized UDK in the card + ATC used to create the tokenized LUK (AKA Session Key, or one time use key)
   b) this LUK can be exposed to the mobile device (in apple case, the calculation of the LUK or similar key can be created inside the SE of the mobile device)

5) At transaction time, the cryptogram is created:
   a)  Tokenized LUK + terminal UN (POS data) used to create final cryptogram returned to the POS for processing

Have a look at how the Apple Pay system works during payment time:

And obviously, the mirror transactional sequence for the Android environment:

You will notice that the net result from the reader perspective is identical in both cases; "Tokenized Data" as described above.  The Android app and cloud based secure element, however, must work together throughout the life of the app on the phone to produce this result.


What tokens solve!:

Legacy Processing:  The main thing, in my eyes, that tokenization solves is the backend processing changes.  The HCE side of the equation requires, for some card networks, new Cryptogram calculation specifications to be processed because the cryptogram calculation process is forced to be changed.  i.e. intro to CVN 43!

Believe it or not, this is probably the biggest driver for tokenization because it is faster to build the tokenization engine and allow it to validate and convert the new cryptogram to an older version than it is to go into the old old old old (say it one more time...old) processing houses that are running Commodor 64, pascal, and big tape drives and get them to update the cryptographic algorithms on the HSM.  So, both VISA and mastercard can just as easy validate the CVN 43 CBP cryptogram just before the service de-tokenizes it.

Firewalling Transactions:  When a token is created, it is implied that the tokenization engine will always have to de-tokenize prior to processing the transaction,  with that, obviously coves verification of the token.  This is a perfect opportunity to build in transaction processing rules for that token such as:
1)  Card present only transactions (this token must ALWAYS contain a cryptogram with it)
2)  Use this token at ONLY these particular merchant IDs
3)  This token is ONLY valid for transactions within a 90 day period!

Translating to Card On File:  Major wins for Apple, Google, Amazon, and anyone else who has scores of cards on file buried in their datacenter.  Not only does tokenization allow you to translate to an existing bank account.  As displayed by Apple, it also allows you to translate a token to an account that may then represent one of many Cards On File for a particular google, amazon, or apple account.  Potentially this allows lower than Card Not Present rates for internet based transactions.