Token Assurance – Updated

28 April

The most interesting aspect of the new EMVCo Token Specification is section 6 – Token Assurance ID&V Methods.

Technical

Tokens must be combined with a form of identity to be useful. The specification outlines a rather ambiguous set of placeholders

• Account verification
• Token Service Provider risk score
• Token Service Provider risk score with Token Requestor data
• Card Issuer authentication of the Cardholder (ie PIN)

Real world examples would be Apple’s score on your fingerprint biometrics (ex 95% match), or Payfone’s device ID information on the phone you are using. Actually, just about any entity could provide this data to the issuer (with issuer agreement). Per the specification

ID&V steps may be performed by the Token Service Provider, the Token Requestor, or a third party. In instances where the ID&V steps are performed by an entity other than the Token Service Provider, verifiable evidence SHALL be provided to prove that the steps were performed and the resulting outcomes were provided. Verifiable evidence may consist of any value provided to the Token Service Provider by the ID&V processing entity that the Token Service Provider may validate. The details of what constitutes verifiable evidence are outside the scope of this specification, but examples include a cryptogram or an authorisation code

In the GSMA NFC world, a card is “provisioned” to the phone through the TSM.  In the token world a card is provisioned as a token to a phone by the Token Service Provider (big issuers will do this internally, V/MA will also offer services). If the card (or token) is presented to the merchant via NFC protocol it is operating within the contactless/EMV pricing. If the card (or token) is presented to the merchant via an iBeacon or QR code then it falls into some unknown TBD pricing.

Business issues

Problem becomes who will pay for great ID&V “Assurance”. For example, Apple could provide biometrics.. but shouldn’t the banks pay for Apple’s score (see Blog Authentication in Value Nets)?

Let me extend the example further. Today Banks are working to extend their mobile applications to add payment capability through HCE (on Android). Who is the TSP? Answer it is the banks themselves…  they generate the tokens and their own Assurance information. Who will deliver “tokens” to Apple? There are only 2 entities that can map tokens to cards: Issuers or Networks (acting as TSP).. wallets can’t do it.

Thus there are 3 ways a payment instrument can be added/stored/provisioned in a phone/cloud/device

1. Consumer enters card number (Google, Apple, Amazon, Paypal, …). Benefit, consumer chooses any card they want. Downside CNP rates
2. GSMA/TSM. Provisioned by Card. Only issuers that provision cards.
3. Tokens. Provision token. Only issuers/TSPs can provision tokens

There are also different mechanisms for card Use/Presentment

1. eCommerce (buying iTunes/App store, Amazon, …)
2. EMV/Card Emulation
3. Token Presentment (iBeacon, QR, eCommerce Token Presentment)
4. …

My view is that there are only 2 areas where tokens will move in next 12 months:

1. Banks are focused on enabling Apple to use tokens later this year (in iBeacon model), so cards will exist in token form both within the Bank mobile application (Android HCE) and
2. Apple’s wallet (IOS) in Beacons + NFC/Card Emulation

Looks like everyone else will be stuck with the “old” NFC/TSM model for quite some time.

Apple

For Apple to receive Card Present rates in a iBeacon model, they must provide information as a TSP to create a high assurance level.  Here is the REAL ISSUE. WHO DECIDES what degree of assurance equals card present rates. Right now only the ISSUER can make this call. Worst of all… the merchant will have NO IDEA of what the cost is. That’s right, Apple must negotiate with each and every issuer not only on ID&V data exchange, but also on the rate. The token specification outlined how the data must flow, but not how the pricing will work. I sure hope Apple is pushing for pricing MUCH better than listed card present rates. Fantastic authentication should lead to risk based pricing. My recommendation to Apple (beyond call Starpoint), is to price in a way that merchant sees card present rates and you are paid for risk reduction. This aligns everyone to reduce risk.

Banks are focused on Apple because: #1 Apple can move the needle in adoption, #2 Increase use of cards in iBeacon model, #3 Apple is dumb container for card and not as concerned about capturing data. Banks may work to restrict Apple’s ability to use tokens in an NFC contactless transaction only. One of my top questions is HOW will apple present these tokens in an EMV contactless scenario? There is no work being done on card provisioning with issuers… so how are the tokens getting into their phone? Will Apple convert their 600M cards on file to tokens?  Will the networks work to simplify and “on ramp” issuers without their technical involvement? This could be a brilliant move, as nothing is more broken about the NFC/TSM model than working with 10,000 bank issuers individually to provision cards.

I hear nothing on Apple Tokens + Beacons. Which means Apple Payment launch is EMV Contactless only (but in a uniquely Apple Way with fingerprint). If Apple is working in an EMV contactless model ONLY, did they certify an application? Who holds the encryption keys if cards are not provisioned by the issuer? the network? (my guess) If this is the case, what do card issuers think about the networks managing their keys?

 

Google

Today Google wallet (POS) wraps all other payment products in a Bankcorp (TBBK) Mastercard. Google is issuer so they provisioned the card (with a few exceptions in Citi/Barclays, …). It is the ONLY wallet where a consumer can load any payment card they want to. Today Google gets card present rates (for the TBBK Debit Mastercard) as they present cards within EMV contactless/card emulation rules. If they switch to tokens, what merchant pricing applies? If merchant accepts card via EMV contactless, contactless rates apply, but what if token rates are “better”? Can Google arbitrage? What if presentment could be based upon merchant preferences? Present token if you have a lower rate (via via QR code or “Beacon”) otherwise present card via NFC/EMV for card present.

I’m getting a headache!! Can you imagine Google would have to store cards/tokens by issuer/presentment mechanism, with different assurance data and provisioning for each. Some cards are provisioned via TSM, others via token, others entered by consumer, cards used for eCommerce on Google store could be tokens, cards used in Chrome autofill would be PANs, cards presented via NFC would be encrypted PANs, cards presented via BLE would be tokens..

In the token model, what is incentive for Google to deliver Assurance data?  What is merchant incentive to accept? Today Google can allow the consumer to use any card.. in a token world they have no control over which cards can be provisioned/stored, nor the rate the merchant will pay. Someone please draw me a picture of options…

Assurance Business Model

Can you imagine playing football where the opposing team also staffs the referee positions and can change the length of the chain whenever they want?  The token specification is a very, very solid document. But the business model is a little crazy. The only place where it will see short term traction:

• Issuer’s own mobile application
• eCommerce (where Apple/Google/Amazon/Paypal directly benefit from CP rates)
• Apple (if they negotiate agreements well)

End result – No POS Merchant Adoption

Obviously, if merchants have no idea of the cost of a payment product.. they will not accept it. I couldn’t imagine anything worse than the ISIS NFC wallet… but a token at a card not present rate could fit the bill. Now you see the reason behind MCX…

eCommerce Merchants DO have a reason to jump on tokenization. As they will benefit from risk based pricing.

Thoughts appreciated.