Token Assurance – Updated

28 April

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

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)

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.

3 thoughts on “Token Assurance – Updated”

  1. Tom, great articles as as always. Thank you for your insights.

    1. Issuer’s Mobile Banking App for Android and Apple will become “Wallets” or payment devices capable of being provisioned with EMV payment credentials by the Issuer.

    2. The PAN will be tokenized by the Issuer to dynamically change with each transaction that only the Issuer can resolve to the “Natural” PAN. The tokenized PAN will be a 16 digit number with the original BIN, that the merchant won’t even be able to tell it is a tokenized PAN.

    3. The additional form of identity that will be employed by most Issuers, is the username and password or pin that is required when a consumer launches their Issuer’s Mobile Banking App. Has nothing to do with Apple or Android doing anything for authorization, between the data the app will send back to the issuer and the payment data the Issuer will want for almost nothing else.

    4. Apple doesn’t even need to support HCE, it would be nice if they did or some derivative of it at least, for the banks to use an Issuer’s Mobile Banking App to facilitate storage and transmission of EMV credentials or Tokenized PANs as part of an EMV transaction.

    5. Transmission is the KEY. NFC, iBeacon, Bluetooth, BLE, Infrared, Etc… It doesn’t matter as long as the following are true…
    A. The transmission protocol has to be dynamic for the exchange of keys. (Sorry QR you are a long term loser for this reason)
    B. The devices, the Mobile Phone and POS Terminal, support any one of the communication protocols jointly.

    6. EMV = Card Present Rates = No Changes

    So the questions I have are…

    Will Apple finally include something like NFC, that the Issuer’s Mobile Apps can leverage?

    How long can Merchant’s hold out from NFC or iBeacon or whatever from enabling it in their stores? When banks will be using their mobile apps to accept payments too, no Square dongle required. Hell, no Square required.

    As for online commerce, EMV credentials will eventually be used to give merchants Card Present rates because the transaction will function and have the same security/risk as a Card Present EMV transaction. Think dongles for EMV acceptance that interface to online sites or the Issuer’s Mobile Phone App being leveraged during a transaction at an online merchant to transmit the EMV credentials.

    Derrick

Leave a Reply

Your email address will not be published. Required fields are marked *