Is HCE NFC’s Killer App?

The month of November was ushered in by the Red Sox World Series Parade of Champions in Boston (did I mention that the Red Sox won the World Series this year??!!!), the return of daylight savings time (my favorite day of the year besides Christmas and my birthday) and the news Google had launched a new technology that many report will “finally ignite” NFC by moving it to the cloud.

The announcement made by the GOOG on Friday is that it has created a technology called Host Card Emulation (HCE) that can, as the name implies, emulate an NFC card in the cloud, bypassing the need for a secure element (SE) and TSM (trusted service manager) to enable NFC applications, including payment. With HCE, any app can talk directly to a merchant terminal without having to go through a SE and TSM, and without having to conform to the many card provisioning restrictions often placed on issuers by mobile network operators when SEs are in place. HCE leverages tokenization to ensure data security, moving transacting and the intelligence associated with those transactions to the network and control over authentication to the issuer. The hope is the absence of the middlemen—that is the evil mobile network operators—that imposed restrictions and fees will unleash a wave of developers who will now want to build NFC apps—loyalty, transit, payment—that consumers will want to use and support from issuers and networks that have invested for the last decade in NFC schemes.

Many have written that HCE does three things: finally ignites NFC, narrows the mobile commerce playing field to two big players – Apple (which will now embrace NFC) and Google, and accelerates industry efforts to create a tokenization standard.

I agree with only one of these three statements.

Don’t get me wrong, HCE is an important development on several fronts. If it does what it says it does, it could actually rearrange the NFC ecosystem in a way that eliminates some of the friction that has added cost and complexity to the mix. Let’s ignore the fact that it was Google that first advocated the whole secure element/TSM gig in 2011 when it and Sprint announced a “monumental launch” for Google Wallet on the Nexus S 4G with Citi, MasterCard and First Data. But, hey, kudos to the Google team for moving past that in a way that embraces the technology environment responsible for their massive core business success – software platforms and the cloud.

HCE does embrace tokenization, which provides superior protection of consumer data. Merchants could benefit in a variety of ways, including the potential to reap card present rates for transactions that are processed that way. HCE, and its announcement, I think will only accelerate the efforts of the industry to put a standard in place around tokenization. And it also calls into question the merits of EMV – all of these tokenized, cloud-based solutions only diminish the business case for investing massively in a solution set that solves a problem that we are all massively investing to eliminate in the next 10 years (and sooner if we can) – using physical cards to transact at the point of sale.

So, these two things are goodness and things that Google actually has some control over as it relates to the NFC ecosystem. It’s the stuff that they can’t control that could become problematic.

For instance, HCE still requires an NFC controller to be present to work – which means handsets have to have NFC chips in them – and merchants have to have NFC terminals in place. It’s true that many terminals that shipped in the last couple of years are “NFC ready” (but not activated), and that more handsets are being shipped with NFC chips each year, and that HCE might give merchants a reason to flip the switch. Except that it’s really not that easy, as we know, to flip that switch. In the U.S., certain categories of merchants like food services, hospitality and travel and even large retailers are ripping out traditional points of sale and replacing them with integrated tablet systems that are not NFC enabled in any way. It’s not clear whether this platform can enable other front-end technologies like BLE or bar code, which I suppose could make a difference in the degree to which it could be used to enable other technologies that would be of interest to merchants. Reports also vary on how many handsets have and will ship worldwide with NFC chips, but even the most optimistic forecasts don’t expect the number of handsets with chips to top more than one-third of all smartphones by the end of 2014.

Perhaps most importantly, HCE doesn’t solve for the real fundamental elephant-in-the-room-and-sitting-right-on-your-head problem that at this point is well outside of Google’s ability to control: NFC never ignited because no one ever developed NFC-based solutions that a lot of consumers wanted to use, and therefore merchants never had a reason to go to the trouble of playing with NFC. Nor does HCE solve what I think is NFC’s newest problem: it’s damaged goods now and everyone is moving away from it in droves. It’s hard to see that HCE is going to get the many that have been burned by NFC in the past to turn around and run toward it again. Once burned, shame on you, twice burned, shame on me – and the “me” in this case may be hard pressed to find the patience and money to welcome NFC back with open arms the second time around.

But, that’s not the only reason why I think HCE might get stuck. Google has two another Achilles’ Heels that may keep it from getting the scale – and therefore the ignition potential – that others believe possible as a result of the introduction of HCE.

Achilles Heel Number One: Google doesn’t really own Android.

Android is an open-source platform. Handset manufacturers sign a license to access Android, but that’s about it. Google doesn’t dictate what those handset manufacturers do with Android, what apps they use or don’t use and how it gets deployed. Licensees are obligated, if they make changes to the Android source code, to give them back to the ecosystem, but there is no requirement for anyone to adopt those changes, nor are there any requirements that Android be used in any sort of standardized way. Handset manufacturers can also add a lot of their own stuff on top of Android. That’s why Android has such a fragmentation problem, why developers struggle to monetize apps written for the Android platform and why devices operating Android are not interoperable. What everyone forgets when they report all of the statistics about what a fabulous market share Android has is that the portion of the market attributed to Android is disproportionately lower income individuals (so Android has a much smaller share of spend than it has of handsets) and that the apps ecosystem for Android is much less developed than the iPhone app ecosystem. What they further forget is that, unlike Apple, GOOGLE DOES NOT OWN THAT MARKET SHARE. It has no guaranteed connection to any of those consumers, and the handset makers can make their own decisions on what happens with Android and how the operating system is used.

To put a punctuation mark on that point, the real evidence of this Achilles’ Heel is actually who makes money from Android – and, I’ll give you a big hint, it isn’t Google. In a report published recently on the Motley Fool, it stated that Samsung is the player that actually pocketed nearly 95 percent of all of the profits generated by the entire Android ecosystem. The paltry 5 percent that remains is divided among other OEMs – and not Google. The GOOG makes it money from any ads that it may get to serve on the devices running Android and from having its services accessible to consumers via the mobile device, which is its core business anyway. But, as I said, the money made from the operating system and how it is used is totally at the discretion and decision of the handset manufacturer. And, since Samsung, in particular, has stated an interest in getting more involved in software and services, well, that could be a problem downstream for the GOOG.

Now, I don’t want to overstate this. The GOOG knows that it has this problem and it is trying mightily to reduce the reliance of handset manufacturers on the “open source” Android—its Achilles Heel—and trying to create dependencies on its “closed source” Google Play set of assets. But, compared to Apple, it has far less of an ability to do this. China, for example, only uses the open source part of Android and stays pretty far away from anything else Google. I repeat GOOGLE DOES NOT OWN ANDROID in the usual meaning of the word “own.”

The implications of this environment for payments and HCE aren’t insignificant. Google’s ability to force anyone to leverage anything that its operating system does or is capable of doing today isn’t non-existent, but it is far more limited than Apple (or even Microsoft if they ever got people to use their closed-source operating system). I also wonder how excited mobile network operators are going to be about pushing out Android phones that essentially disintermediate them. They’ll have a preference for handset manufacturers that figure out a way not to install HCE, maybe they’ll even go out and find handset manufacturers to do that, and maybe at the margin, since they are disintermediated anyway, they will start tilting towards Apple.

Enter Achilles Heel Number Two: Google and merchant data

HCE is a clever technology solve. But, it does very little to assuage merchants from their number one fear of the GOOG: taking their customer data and serving it up in some way to the competition. Leveraging HCE will have to be monetized in some way – via a Google Wallet scheme or advertising or some combination of the above. And since it’s hard to hide the fact that Google makes its money from monetizing data, not from the Android platform itself, it may be very hard to convince merchants that their motive is only to eliminate the dreaded NFC middleman for their benefit. That’s a well known, and pretty big hurdle to overcome, at exactly the same time that it is also facing some potential headwinds from one of its biggest customers, Samsung, and possibly others as their operating system becomes more closed.

But, hey, HCE is just one more piece of evidence that the future of mobile commerce will live in the cloud. And there’s now a wide range of cloud-based mobile commerce solutions for merchants to choose from. For merchants that have invested in NFC technologies, HCE could represent the final, finishing blow for ISIS. But, what it won’t likely do, in my opinion, is convince Apple to break down and embrace NFC. There’s still the stark reality that a very tiny, tiny percentage of the merchants in the world are NFC enabled and Apple doesn’t owe anyone the gift of using their desirable installed base to ignite a technology for someone else’s benefit. Remember, Apple’s users control about 70 percent of the spend in the U.S., and Apple certainly knows how valuable its base is. If Apple turned its nose up at carriers and SEs and TSMs, it’s not hard to imagine its reaction to a play that for all intents and purposes, has Google functioning as the SE for its mobile commerce transactions.

HCE also, I think, provides some important clues about what we’ll be seeing unfold around mobile commerce in 2014. In the end, it’s still about the consumer experience and what will compel them to adopt something new, which will, in turn, motivate merchants to enable that experience. If HCE, thrown into the mix as another option, sparks more innovation at the same time it helps to accelerate a standard around protecting cardholder data using tokenization, then that will only raise the game for everyone – and that’s a good thing.

Oh, and if you hear a stampede back to NFC just let me know. Of course I’ll probably tell you it was more likely the sound of your kids running down the stairs to check out the Loch Ness Monster that was spotted frolicking in your swimming pool.

Want more of Webster’s commentary in your inbox? Sign up for the PYMNTS.com daily newsletter here. For more exclusive commentary from Webster, visit our commentary page here.