28 April 2014
I must get 10 calls a week on Apple/NFC. I’m quite concerned that Apple’s new capability will be completely mis-understood by the press, so i thought I would preempt all the NFC zealots out there with my own tag line.. So far I have a 100% success rate in predicting Apple and NFC (blog). Don’t know if I can keep it up as I read the tea leaves. Let me start with facts, then give you my informed opinion
Facts
- There are 2 aspects to NFC: 1) the communication protocol as defined by the NFC Forum (this stays as is), #2) The GSMA’s construct and standards for how NFC can be deployed in a handset (things like TSM, SE, SWP, …). See http://en.wikipedia.org/wiki/Near_field_communication
- Neither Google, Apple, Merchants nor Bank Issuers are in favor of the GSMA’s NFC platform. This is a fact in my mind… particularly in the US.
- Host card emulation has created a way for all Android 4.4 and above phones, with and NFC compliant radio, to provide application access to the NFC radio. Phones cannot be certified for 4.4 unless they demonstrate support for HCE. See blog HCE – Now the Preferred Contactless Approach
- The new card present scheme “Tokenization” was announced Oct 2013 at Money 2020, with the specification out last month (see EMVCO details). See my blog Payment Tokenization.
- HCE and tokenization play together well. Tokens must be coupled with something else (Device ID, Bometrics, PIN, …). For those that have been MIS informed by Gemalto… there is NO NETWORK connectivity requirement for HCE/Tokens. A token representing a card is in software on the phone. It can be stolen.. but it is a worthless piece of information without the other identity/device information. HCE gets around the EMVCo Contactless encryption requirements.. and operates under the TOKEN specification. But there is much grey area here.. as “acceptance” of token is not clearly defined (including pricing). Thus the only “covered” presentment method from a phone to a POS is through a card emulation application. Token acceptance will be coming later, but “assurance levels” are making this a cracy space (tomorrow’s blog).
- Update – I see that the smart card alliance has already responded to my blog here. The need for a trusted execution environment.. blah blah blah. Did you know that in an EMV contactless transaction that the PAN is sent in the clear? Yep… the need for the TEE is around signing a cryptogram (to verify where the card came from). Obviously I would much rather hide the PAN in a token, and enhance with phone information than give the PAN in the clear and sign something. There is no need for a TEE in payments, just as I access my bank through my browser on my PC without a TEE.. I can also do so with a phone. arghhh…
- Tokens align well to banks and payment network dynamics and investment. US Banks had been working on a tokenization initiative for the last 3-4 years in the Clearing House (blog).
- In both HCE and Tokenization scheme, the ISSUER IS IN COMPLETE CONTROL of their card. Issuers generate the token, and authorize the transaction. US issuers have their own token infrastructure in place from the TCH initiative (above). I wish I could emphasize this more. With HCE, issuers control which application(s) can present a card.. just as they did with within the TSM provisioning model.
- There are HCE pilots that are live and functional. So much for not being “viable”. The issues are not around technology, but rather validating fraud controls and device ID. Issuers can be up and running with either Mastercard or SimplyTapp in weeks.
- Perfect authentication and security is a nightmare to Banks.. Banks make money on ability to manage risk. There is no risk in a world of perfect authentication. Or as Ross Anderson says “if you solve for authentication in payments… everything else is just accounting”. See Blog – Perfect Authentication is a Nightmare for Banks.
- MNO led payment schemes (the GSMA’s platform) are failing in OECD 20 (mature markets, but are leading the way in Emerging Markets). I have seen the transaction numbers… Reasons are multifaceted (see blog for reasons). The technology works.. it is beautiful.. problem is business/consumer value proposition and consumer behavior.
- Historically, new POS payment instruments and POS payment behaviors are established through frequency of use. There are 3 categories: Grocery, Gas, Transit. Transit is the global success story (Docomo, Suica, Octopus, …)
- 4 Party Networks have a limited ability to change rules, Issuers dominate in influence. Amex is 3-5 years ahead of every US issuer in terms of capability, strategy and execution.
Opinion
- Apple’s biggest asset is their ability to change consumer behavior (blog).
- Apple’s iPhone 6 will be coming out in October (my best guess) with payment capability. It will have the capability to communicate in the NFC protocol.. but nothing about the new iPhone will be compliant with the GSMA’s architecture
- Apple’s new capability is NOT ABOUT PAYMENT, but about Commerce (see blog) as they act as a CONSUMER CHAMPION (see blog).
- Tokens play very, very well into an iBeacon model. Given that tokens are worthless “keys” that refer to a card.. these keys can be exchanged in the open with BLE. There is no need for near field if the information is worthless.
- -Update- From my perspective I would not refer to Apple’s efforts as HCE. Where Google’s HCE repurposed an existing chipset to create a new software model. Apple has designed a new hardware model. Apple will be using bank issued tokens. Banks will look at using these delivered tokens in combination with: 1) Apple derived authentication score, or 2) MNO device ID from Payfone, 3) Bank mobile application information, 4) combination of above.
- Authentication is key to Apple’s role in consumer trust and commerce. Per my blog Authentication in Value Nets, Apple is 3 years ahead of Google and everyone else in integrating software and hardware level security (ex Secure Enclave). Google has a path for a secure execution environment through Arm’s Trustzone, but this is more challenging as Google does not mandate hardware architecture (yet).
- Apple’s new POS payment method will involve finger print on phone, and token presentment to retailer. It can be transmitted via NFC, BLE, QR Code.. or whatever the merchant and consumer can agree on.
- How does Apple make money on this? I don’t think they will make money on payment, but rather on #1 Authentication (charging the card issuers for an authentication score), or #2 Marketing (charging merchants for consumer insight/ability to reach consumer).
- Gemalto continues to cast stones, and miss revenue targets. Mobile Communications revenue of €225mn (-5.7% YoY growth, -1.0% constant currency) came in below consensus of €245mn (2.7% YoY). This is the second consecutive disappointing quarter for Mobile Communications, with revenue down 4% YoY in 4Q13. Why would any MNO invest in a secure vault on a Android handset when any application can go around it. That’s right.. there is no lock on the capability. This tremendously impacts the willingness of MNOs to “invest” in incremental features.. when their “investment” can be used without their permission.
- What will REALLY impact Gemalto is a VIRTUALIZED SIM. Don’t think this is coming in iPhone 6.. but is it coming (see Viritualized SIM).
- The next 2 years will see mobile payments as a “1000 flowers blooming”. Top card issuers will extend their mobile banking applications to enable card emulation (BLE, NFC, QR, … whatever).
- Payment Networks will be working to expand the 16 digit PAN to something much larger to support dynamic tokens. They will be working to transition Cards on File to tokens.. with perhaps a card present value proposition.
- MNOs will realize that they have a unique ability to create a device ID that competes with Apple’s biometrics. Payfone is the leader in the US, Weve in the UK. Beyond this, they may also begin to realize the $5B KYC opportunity I outlined 5 years ago.
Thanks for your view on this really complex matter. Do you believe Apple will be opening up a fingerprint API similar to what Samsung did with its S5 fingerprint API, given your assumption “I don’t think they will make money on payment, but rather on #1 Authentication (charging the card issuers for an authentication score)”
Best regards, Martin
Wow… EXCELLENT QUESTION.. are you reading my mind!? I do NOT think they will open this up, as authentication is core to their role as “orchestrator”. See my blog on Stage 4 value shift. Authentication is a core Apple service through which almost everything else revolves around. I believe you will be able to ask Apple for their biometric score (assurance level).. My view is that Apple will make this a consumer centered service. Do you want your phone to manage your credentials? As the trust service they will be able to provide you (3rd party) with your credentials and their score of consumer identity. It is a great question.. don’t know if they have anyone over there running it yet.
How do you feel this article / this question has been effected with the iOS8 Touch ID opened up?
For frequency of use it seems like we might have to add “coffee” or, more specifically, “Starbucks” to the list of drivers for new POS behaviors:
http://blogs.marketwatch.com/behindthestorefront/2014/03/20/nevermind-your-cup-o-joe-starbucks-mobile-payments-system-may-be-its-next-hot-product/
Grocery, Gas, Transit.. and Starbucks.. I stand corrected (and highly caffeinated).
Very clear views. I had one doubt. Don’t you think that it makes sense for payment network to maintain token infrastructure instead of each bank creating its own token infrastructure. I will be much more efficient/cost effective and faster to implement HCE based payments that way.
Thanks
Vipul
Agree… but just as DNS directories are replicated.. so to will tokens. Banks created their token infrastructure with the goal of leaving V/MA out of it. Thus there are multiple authorized token creators, and an agreement to update and share a common directory. One of the reasons for this.. and this is very key… is that banks want to UNIQUELY hold the ability to resolve a token to a consumer. This is to prevent anyone else (visa and MA) from identifying consumer spend patterns. Tokens are unique to merchants/users/card and change constantly. If V/MA hold the directory they could translate and identify consumer spend patterns.
This distributed issuance is also aligned to how cards/BINs work today. Issuers own the bin range.
EMVCo’s tokenization spec advocates static tokens with small cryptograms (just like card emulation), in order to satisfy one big issuer’s problems with its antiquated authorization system. Everyone else wants dynamic tokens (they are better, safer, but do require more work). Ironic that Visa tells everyone it can that it doesn’t support PINs because they are static identifiers…. And Visa is doing nothing to make sure tokens are not obstained in the ‘front-end’ with stolen card credentials. Letting the banks design the tokenization scheme (as the The Clearing House is doing) and maybe the merchants (MCX?) would undoubtedly do a much better job than the networks–which, after all, thrive on fraud and inefficiencies (e.g., charge-backs) in their business models!
How does apple leverage the 600mn cards-on-file? Does Apple directly connect to banks token platform, get the token and put it in the Secure enclave? In that case, the retailers just needs to have their apps (maybe on Passbook) integrate with Touch ID APIs and rest would be taken care by Apple… Passbook would serve as wallet with all the receipts, coupons, etc.
This is where i thought that if V/MA or some 3rd party or Bank consortium is taking care of the token infrastructure, it would be much easier… otherwise Apple will have to integrate with each of the banks to make such kind of payments possible
What you outline makes intuitive sense for Apple.. but certainly not the banks. To get card present rates the BANKS or their designated TSP must tokenize. The only carrot: Card present rates. What is funny is that banks are willing to make this all work for POS transactions.. but there is NO WAY they want to give up on CNP revenue (and assume fraud) for eCommerce transactions. I tell you that it is just plain stupid. For example, can you imagine Visa going to BigEcomRetailer and describing tokenization.. BigEcomRetailer says “what is my upside”. Visa says we can shift liability… and make this a replacement to VBV… BigEcomRetailer asks “what about rates”.. Visa responds “you have to go to each issuer to work that out”.. I’m not kidding..
Tom- great blog, as always.
Here are my 2 cents.
I think the merchant centric, 4 party model will most likely evolve as you predict with GSMA/GP model further marginalized, NFC used for what is meant to be, authentication reinvented on the handset side and used to strengthen the value to tokenization.
I just think that the very merchant centric model in which data flows from the consumer to the merchant and the merchant drives the transaction via ACQ and IX to the Issuer, has outlived its usefulness all together.
Yes, we will have new ways of authentification of the consumer but it’s going to be used to empower him not just to limit the fraud.
The id data will flow from the merchant to the authenticated consumer and the consumer will drive the transaction. There will be no need to transfer any account (security sensitive) information from the “other side of the network” to the handset. The sources of transaction funding will be managed on the server/cloud side and the traditional value chain will be collapsed to the payer, payee, and the PSP. The custodians of the electronic accounts that are used for transaction funding and funds receiving/storing do not need to be in the transaction path.
New business models will be introduced without the IX fee in the equation and finally make it possible for electronic payments to start seriously displacing cash in the LVP and micro transaction markets. Those business model will focus on enabling merchants to make more money not just pay less in fees. Ultimately, the payment transactions fees will converge to near-zero.
All of that is already happening in in parts.
After reading the comments below… one more thought.
Why do we have to discuss payments in the context of cards?
Electronic accounts – yes. But why cards?
Yes, I fully understand the legacy issue.
But if any one of you were given a chance to design a new payment system today with the internet, mobile networks, available consumer electronics and all the advances in technology since 60ties and 70ties… would anyone of you started with a card… and an interchange networks, and acquirers, etc, etc?
What is inescapable are electronic accounts, institutions that operate them on behalf of the consumers, methods to access them, legally and securely, and methods to identifying parties and authenticate them. All of these are already in place to various degrees in various markets.
It’s only a matter of time when we will move away from dealing with address space of card numbers and card holders to a world with account numbers and user ids (whatever they happen to be). A payment will eventually be reduced to an authenticated user giving an instruction to the payment cloud to move funds between accounts associated with him and another user living in the same address space.
Imagine Viber allowing users to link their assorted electronic accounts to their profiles and being able to access them in real time to clearing and/or fund authorization.