Software Secure Element – HCE Breaks the MNO NFC Lock

Visa and MA have both created HCE Apps which will REPLACE the SE based CARD EMULATION apps. This is a FANTASTIC development for BUSINESS and for Android. Now you can create apps that leverage payment, loyalty, … It is also a fantastic development for CUSTOMERS as you will be in control of the TSM and card provisioning. You will be able to load ANY CARD you want.. not just the Chase and Amex cards that are in ISIS.

News Today – WELL DONE GOOGLE!  (Note good comments below)

In my July post Big Changes to NFC: Payments part of OS I outlined the high level view of what is going on. In order for this blog to make any sense let me be a little less obtuse on the next shoe which will drop: Visa and MA have both created HCE Apps which will REPLACE the SE based CARD EMULATION apps. “Replace” is more from a business context than from a technical one. SE based applications (like a door key, or healthcare card) could still survive.. but why would anyone want to pay the MNOs RENT if you don’t need to.

I don’t have much time to delve into the technical details, but there are 3 core elements to NFC: Radio, Controller, Secure Element. They had been all residing on dedicated silicone from companies like NXP. I discussed in Apple and NFC Part 2 how companies like Broadcom have integrated these separate components into a single piece of silicone. In other words the NFC Radio is just another radio alongside GSM, CDMS, Wi-Fi, Bluetooth, … With Android 4.4 Google has now made Payments Part of the OS by enabling an application to bypass the SE and use the radio as directed by a OS. Another way of looking at this: in a world of integrated silicone, there is NO dedicated  controller… (the controller is in the firmware/OS).Exposure: 000 : 00 : 00 . 156 %Accumulated%=0

NFC zealots will HOWL that there is no TSM, or security. But SECURITY has DEGREES.. there is no such thing as 100% non-repudiation.  Visa and MA have both developed controls for how this will work, for example having a “token” that refreshes at a given rate based upon where the phone moves and how the phone transacts.

This model also addresses a key FLAW with NFC. HCE will allow for APPLICATIONS to access payment.. yes I am speaking of mCommerce (buying from an app or a web site). No longer will you have to key in your card information. NFC did NOTHING for this.

This is a FANTASTIC development for BUSINESS and for Android. Now you can create apps that leverage payment, loyalty, …  It is also a fantastic development for CUSTOMERS as you will be in control of the TSM and card provisioning. You will be able to load ANY CARD you want.. not just the Chase and Amex cards that are in ISIS.

I believe that banks had very limited view of this development, and that several of them will be calling V/MA to confirm that they are creating an new CERTIFIED Card Present scheme based on HCE. Bank control (push for credit use) has been as much of a drag on mobile payments (at POS) as telecom control. This approach BREAKS BOTH.

Bank Benefits

No one can fix EMV…. there are too many parties. New token rules together with HCE AND Network Enhancements (ex Wallet ID, Phone forensics, ..)  a much finer grain of control than exists today. For example, new structure will allow for any given issuer to turn off all tokens for any given wallet provider. When comparing EMV to HCE++ we can’t forget WHAT EXISTS TODAY (is mag stripe). No one can suggest that HCE++ is less secure than mag. Most banks realize that payments are NOT about security and authentication.. but about Fraud and Risk management. Not just “are you the person that controls the account”.. but “did you just loose your job and about to enter bankruptcy).

The mobile device has SO much more data on which to manage fraud and risk. For example at Citi, SMS PIN code completely eliminated risk in new transactions. When we saw a new payee, we sent the consumer a PIN code to their mobile that expired in 1 min.. In future HCE environment if bank sees risk they can PIN, or ask for finger print scan (from apple).

HCE actually ALIGNS to bank and network (V/MA) objectives: keep intelligence in network and control with issuers. Today big banks differentiate themselves on ability to manage risk. They have made multi-billion dollar investments here. Complete security and authentication in a platform decreases their competitive edge. Perfect authentication is a NIGHTMARE to banks because then anyone could do their job and ID risk would be eliminated (not credit risk)NFC Change

Big Technical UNKNOWNS

  • Tokenization, Network Enhancements, New Card Present Scheme, New V/MA Emulation App, POS Terminals, Fraud Services, Device Forensics, Authentication, all are needed in this future model. Much is built.. but this is not without challenges
  • Today’s NFC requires issuer keys to generate the dynamic codes required in a contactless transaction. IF this is reused, than issuers will be able to prevent HCE from working.
  • Will V/MA attempt to impose Authentication/Fraud Services standards impact consumer experience or conflict with issuer requirements
  • Who will create the HCE standards by which everyone can use? How long will this take? are we back to ground 0?

Other quick thoughts

  • This is not just PRESS.. HCE is actually all LIVE right now with a Canadian Bank.. RBC and SimplyTap (the Rocket Scientists of HCE). In this model an ISSUER has given its “NFC Keys” to the SimplyTap for use in an HCE model that circumvents NFC controller.
  • I expect that Apple’s iOS will also follow model within next 8-12 months.
  • Very positive for V and MA, Google, Businesses that transact with consumers
  • Very positive for mobile POS payment
  • Could create new differentiators for Android if Apple doesn’t follow quickly (I expect they will)
  • Positive for merchants as consumers can now load debit cards on their phones and you can create apps that incent debit card usage
  • Negative for companies that specialize in providing payment services to mCommerce or NFC
  • Negative for PayPal.. why use them at all? your cards are stored in the phone. If you are a merchant with a mobile store front or app you will integrate with 2 payment service providers: Apple and Google.
  • SEs will be going away. Connectivity and Authentication put data in the CLOUD.. not locked in a device with the carriers holding a key.
  • Google has alignment on HCE. Devices from the top handset OEMs announced in the next week+ with no SE on board, like the Nexus 5
  • Next BIG challenge? Certifying/standardizing authentication methods which provide for finer grained control of payments, cloud data, re-issuance of tokens…. 100s of new companies.
  • HCE actually ALIGNS to bank and network (V/MA) objectives: keep intelligence in network and control with issuers. Today big banks differentiate themselves on ability to manage risk. They have made multi-billion dollar investments here. Complete security and authentication in a platform decreases their competitive edge. Perfect authentication is a NIGHTMARE to banks because then anyone could do their job and ID risk would be eliminated (not credit risk).

Appreciate feedback.

52 thoughts on “Software Secure Element – HCE Breaks the MNO NFC Lock”

  1. Thanks Tom,

    The most important aspect of this entire event is that the doors of commerce are open to everyone now. No longer can a MNO say you can’t do this or you can’t do that. Developers, merchants, banks, etc. can all provide their own value added experiences around the customer and not the payment. This is the way it needs to be and thanks to the guys on the Android Team and those making the decision to go forward with this open approach WE WILL ALL BENEFIT.


    1. Maybe I am displaying my ignorance, there are a couple of questions I seek to understand before embracing HCE as the solution to the issuers security and business concerns.

      First what does this statement mean “No one can fix EMV…. there are too many parties” what is it we are trying to fix? The beauty of EMV is that there are so many parties deploying it globally and that any EMV complaint Card coudl work at any EMV compliant terminal if the application selection processes finds a match.

      Second who will certify the security of a software implementation of ISO7816 is equivalent to the security of a Hardware security module sometimes called a secure element? NIST and the NSA, on several occasions, have demosntrated that a software security solution can be hacked, whereas hacking a hardware security solution is significantly more difficult.

      FInally show me a statement from MasterCard or Visa where they state they will support HCE as a replacement for a Hardware Security Module or Secure Element?

      The idea of not being hostage to the whims of the owner of teh SIM or eSE is exciting. Yet until the security is proven to be comparable and more importantly acceptabled we should be careful about assuming HCE is the solution everyone seeks

      1. Very logical questions from a product/engineering perspective. My blog is more from an investor’s perspective… ( where are key players investing time and energy…?). There are so many people impacted by these changes that I thought I would give my informed analysis and G2. Institutional investors about to take a stake in Gemalto or NXP will have a different read on this than a product manager looking for formalize handset payment architecture.

        From an engineering perspective, it makes complete sense that you would not want to put your hopes in HCE without reviewing how V/MA will support. Given the time that it has taking for NFC to evolve the though of starting all over again is quite frustrating. That is unless you are a payment application provider like CSAM, Gemalto, PayPal, Square, … All have been looking to deliver value, not lock in control.

        With respect to EMV, the intended meaning of “fix” was: replace, evolve, transition, … EMV does not solve every problem, and the contactless payment manifestation of EMV is not taking off the way the industry planned. So it does need to be FIXED.. not necessarily a technology fix, but CERTAINLY a business fix. Several large Issuers are no longer planning to provide support to ISIS for instance, consumers can NOT choose the cards they want, as each card is dependent on issuer keys. This is a design.. we have SE Keys, Card provisioning/token gen keys, POS contactless infrastructure.. very little of which is moving at a pace which would lead one to be impressed.

  2. Tom, great analysis of potential HCE implications (nothing even remotely similar out there yet, you’ve beaten them all to it).

    I wouldn’t class myself as “NFC zealot”, but I do want to cry “Wolf!” We all know how many security holes were uncovered and patched up when it comes to Android. Why do we need “90% safe condom”?.. HCE was done not because it made technical sense, but because SIM-based SE is controlled by MNOs. Why didn’t G went for a fully-blown embedded SE, as Samsung did?..

    Also, EMV has an identity crisis now, caused by dual standards. Why bother with EMV card terminals if you can do HCE to HCE?.. What about PCI?..

    I can see why HCE makes sense for V/MA and G, but not for the rest of the industry. It smells fishy when a single company “colluded” – BEHIND THE SCENES! – with V/MA to rewrite the rules, let alone the definition of “secure”. That’s before we touch the subject of “anti-competitive monopoly”… Essentially, V/MA granted G a waiver and allowed them to disregard EMV specs etc…

    Last, but not least. If I am a customer of a small credit union, how do I add my cards onto HCE?.. I don’t think “any card” is possible without the issuers onboard. Are they?!..

    1. I just spit out my coffee in laughter over the Condom analogy. Host card emulation is a standard that will exist separate from any OS. There is no collusion… There was a panel on it at Money 2020 3 weeks ago. Google is enabling it … and probably isn’t even first.. but is certainly the biggest.

      No one can fix EMV…. there are too many parties. New token rules together with HCE will allow for any given issuer to turn off all tokens for any given wallet provider, a much finer grain of control than exists today. Take this last point WHAT EXISTS TODAY is mag stripe. You can’t be suggesting that HCE is less secure than this. We can’t compare EMV to a new HCE + Token + Network enhancement. Most banks realize that payments are NOT about security and authentication.. but about Fraud and Risk management. Not just “are you the person that controls the account”.. but “did you just loose your job and about to enter bankruptcy).

      The mobile device has SO much more data on which to manage fraud and risk. For example at Citi, SMS PIN code completely eliminated risk in new transactions. When we saw a new payee, we sent the consumer a PIN code to their mobile that expired in 1 min.. In future HCE environment if bank sees risk they can PIN, or ask for finger print scan (from apple).

      HCE actually ALIGNS to bank and network (V/MA) objectives: keep intelligence in network and control with issuers. Today big banks differentiate themselves on ability to manage risk. They have made multi-billion dollar investments here. Complete security and authentication in a platform decreases their competitive edge. Perfect authentication is a NIGHTMARE to banks because then anyone could do their job and ID risk would be eliminated (not credit risk).

  3. Tom, great analysis with great clarity. A couple of follow up questions:
    1. While NFC can still be used as a communication tool with HCE, does HCE make available whichever form of presentment that the app owner wishes to use (i.e. nfc, bar code, qr code, bluetooth etc.)?
    2. Is there an architecture where HCE can be opened “securely” to third parties?

    1. Hi Matt,

      1. Yes, HCE is just a communication channel. So, you can now offer the OS or even application the option of presentation. NFC, QR, barcode, or any other communication channel you can think of.
      2. Your wish for secure HCE does not exist in the OS. However, you can control what is transmitted and how it is transmitted. For example, if you want an application to be able to interact with a hotel room lock you can do that securely. If you want to make your transit application work with NFC and your Bank card you can securely do that too.

      So the real question is how to do you secure the communication channel or send your credentials securely enough through the channel.


    2. implies a new version of “secure apps”. Multiple questions abound 1) who owns security 2) how are they certified 3) how does one secure app talk with another … The 3rd para answers your question 1)

      Apps declare the AIDs they support in their manifest files, along with a category identifier that indicates the type of support available (for example, “payments”). In cases where multiple apps support the same AID in the same category, Android displays a dialog that lets the user choose which app to use.

      Per question 2, it would seem that the HCE architecture is currently proprietary as there exists no standards body I’m aware of. Rumor is that Google licensed the HCE emulation software via GPL, so this could be an early “standard” implementation that surrounds someone else’s IP.

  4. It was only a matter of time before the NFC radio was untethered from the secure element for card emulation. This is fantastic news for issuers and networks.

    Some key points for your consideration.
    1. HCE allows for the virtualization of the secure element. Every mobile app, like a bank’s mobile app, will be able to provision a virtual secure element (VSE) either to local storage on the device or facilitated via cloud, if not both with local as fallback when comms are down or interrupted. The data will be encrypted and will eventually be tokenized and updated frequently.

    2. Each app will control their own VSE and the credentials. The app controls what AIDs are loaded to their VSE, updated, and then made available via NFC.

    3. NFC/EMV is actually more applicable than ever, issuers will provision EMV based credentials to their clouds, with local backup via their mobile apps and can even provision the existing EMV applications from Visa and MasterCard to their VSE.

    4. Now there are tons of implications that with the NFC radio untether that different standards could emerge other than EMV/NFC via HCE that may even be better. They will struggle and take considerable efforts and time and to what end? Build a different network, like Visa but not Visa?

    5. This simplifies US Debit EMV. It is much easier to load and unload each individual debit network application instead of a unified US Debit app to the VSE when you have unlimited storage and I can load and unload apps.

    6. A related but should be a much larger subject, this functionality will be extended to ecommerce payments. This combined with the tokenization of the card numbers will result, eventually, in no merchant being capable of having cards on file.

      1. Thank you. Never done with your blog.

        Two more points for consideration.

        7. HCE can be paired with any communication method, not just NFC, IR, Wifi, Bluetooth, Etc. The challenge, is again, terminal capabilities and merchant allowance, but this should help to remove barriers as anything that affords fast transmission of back and forth communications will be an option. Sorry QR code.

        8. HCE when paired with a merchant acceptance application, think Square App or a Bank App, can load the terminal EMV applications. POS devices and accept both NFC/EMV payments and P2P payments. No dongle required.

    1. I would really love to see you and/or Tom expand on point 6, the idea that merchants will no longer be capable of having cards on file. This is not something merchants will take kindly to, I would imagine. Is the idea that only the consumer and the networks would actually have the “card on file” and every other node in the commerce ecosystem would merely be seeing a temporary token?

      1. Mike, I think “capable” should be “required”. I don’t see this happening for 10 years.. if the entire world only bought on new Google phones and all issuers supported HCE, and tokens worked, and pigs fly…

        The world still does stuff like mail order, telephone order, … I don’t see COF changing anytime soon.

  5. Removing the SE requirement has effectively unshackled NFC from its payment constraints and can hopefully now live up to its promise.

    But while there is now finally a roadmap for non-payment NFC applications, the possibilities for payments are also expanded significantly.

    As you pointed out, the real-time nature and the proximity of the customer to their devices opens up new fraud detection and prevention opportunities. Which also means that if Mobile is sufficient to reduce fraud and is sufficient to replace a card present transaction, a transaction that taps into the HCE for payment should qualify for card present status as there is no longer any significant differentiator.

    (This discussion was begun on Twitter but I thought it best to bring it to the source article)

    1. Thanks again for the comment. This model fits VERY nicely with how banks and V/MA work today.. I think this is going to happen and so do V/MA. There are a number of ways HCE could be deployed. In a SimplyTap model.. the issuers provide the same keys they would in an EMVCO contactless transaction and hence the acceptance mechanics are covered under existing rules. A new scheme may be better.. with the digitally signed EMV transaction replaced with a token.

      This is MUCH less secure, but that is not the point. Plastic/mag stripe are less secure too and they work. As I said back when I ran Channels globally for Citi “If I let my security group design the branch I’d have armed gaurds with Uzis and tellers behind 5 inches of bullet proof glass, with customer’s DNA swapped… it would be very secure.. BUT NO ONE WOULD USE THE BRANCH”. The same thing has happened with NFC.. a GOOD ENOUGH solution wins everyday…. particularly when it already aligns to Bank and Network functions of RISK MANAGEMENT. Risk management and Fraud deal in shades of grey.. not the 0 to 1 of authentication.

      1. A SE is the opposite though. From a user perspective you don’t need a complex security thanks to that. You have your information in a secure space and all the initial security keys are there for you and it can just talk to the TSM without relying on the user in terms of security. No registration, not long passwords to remember, no complex authentication schemes. The only reason you just don’t save your credit card in your phone is because the OS is not secure enough by design; a SE fixes exactly that.
        A Cloud security is your branch with uzis, it comes with a price in terms of user experience. First of all you always need to be connected where NFC could work even if you are out of battery with a SE. It is there to replace your credit/debit card after all, not having a good connection is a show stopper right there. Second you need to authenticate to the Cloud and unlike remembering a simple PIN you need a safe enough password. Third you need to register initially so you can prove you are who you say you are. Fourth, someone manages the Cloud and they don’t work for free. Well, unless you are Google…

        Let us not mix business with technology, removing a SE is a step backwards from a technical standpoint. The only reason it is restricted today is because the device vendors or the carriers don’t allow any developer access to it; that is only for business reasons. Apple for example could offer a SE in an iPhone and allow access to it from any app if they wanted to. They do control the device unlike Google so they are not limited in that sense.

      2. @FutureTech – that’s exactly the problem Google is facing. They only control OS (and even then – to a degree, considering how fragmented Android is). Implementing embedded SE on just some phones does not deliver UX consistency (Apple has that problem with biometrics – e.g. iPad Mini 2 does not have TouchID).

        That’s why cards works so well – they are ubiquitous and easy to use. Google understands that well, btw –

  6. Hi Tom,

    many thanks for your analysis.
    I was intrigued about your last “between-the-lines” suggestion:
    “A new scheme may be better.. with the digitally signed EMV transaction replaced with a token”.
    I’ve recently been aware about “SE in the Cloud” solution from Bell ID, a provider of lifecycle management solutions for tokens (e.g. smart cards, mobile NFC phones) deployed in single and multi-application programmes
    ( ).
    As far as understand, they provide a solution that combine SE Cloud & Tokenization.

  7. Thanks Tom, a very detailed and factual post on a groundbreaking piece of news from Google.

    One basic question from a non technical guy. Will the HCE solution imply some access to the cloud while paying on a POS terminal ?

    – If no, discard the following remarks ?

    – If yes, we may have two issues both in longer transaction process time AND availability of always-on connectivity everywhere. My personal supermarket does not have connectivity of any kind for example and it’s not the only one. Many retailers do not provide connectivity and 2G/3G not always available. We’re back to a 90% solution.


    1. HCE started with cloud SE ( and then “progressed” to what appears to be “s/w-only” (this is how it works – HCE was available on Blackberry and jail-broken Android for over a year (!), yet nobody paid any attention to it, for obvious reasons, until G incorporated it into OS.

      Note that both articles do refer to secure storage of credentials, either in the cloud or TEE. It is not clear from the latest announcement by G whether TEE is part of the equation. If it’s not then bear in mind that emulation is exactly that… Just read the definition –

  8. Hello Peirre,

    Great question. We ran into this issue a few years back when we were testing our remote NFC solution. This was right after we created the HCE patch for the Android OS (now in kitkat 4.4).Tokenization is the way you solve this problem. This sounds simple but the actual implementation of this can be extremely complex and took more than two years to developer.

    This may sound self serving but currently is a young company that provides the only commercialized solution. They also have a self-service developer portal that provides a step-by-step tutorial for building your first mobile application that can transaction using NFC.

  9. Ted,

    Thank you for the answer and link. Let me restate to make sure I understand your answer.

    1st question was “Will the HCE solution imply some access to the cloud while paying on a POS terminal ?” and the answer is YES

    2nd question – does it imply longer transaction process time ? I’m sure you answer that one.

    3rd question – availability of always-on connectivity everywhere ? The answer is NO as you use “Tokenization” to solve the problem.

    Correct ?

    Lastly, you mentionned only commercial solution -> how do you compare with Bell Id proposed solution for a SE in the cloud – From an outsider point-of-view, it seems similar and they mention tokenization also.

    Thanks again.

  10. Tom, great article. There are a lot of parties with vested interests out there that are trying to shoot this down but I’d encourage anyone who wants to know the facts to read your article.

    Pierre, Perhaps I can comment on your last question.

    Bell ID offers a “pure cloud” solution that requires HCE. Until now that has been implemented on BB out of the box and Androids with the Simply Tapp patch to enable HCE. The release of HCE in Android 4.4 enables the pure cloud solution on all Android 4.4 devices in addition to BB and as such is a step change in the market.

    HCE is not in some way a competitor to the Bell ID solution but rather a device OS technology that it already uses.

    Bell ID also has a cloud/SE hybrid model where an SE can be used for authentication and token storage whilst the payment apps are still in the issuer environment (cloud).

    My view is that the market will settle on a cloud solution where apps are in the issuer environment (cloud) whilst the authentication applet and tokens on the device may be in an SE or may not dependent on the issuers view of its security requirements. I wouldn’t consider the lack of an SE as insecure but security is all about degrees and the SE certainly adds something (if the issuer is prepared to pay the SE owner for it’s use). NFC is not only about payment and HCE works for non payment cards too. Non-payment services may not need the SE, low value payments (maybe) the same. Choice is a good thing. High value payments will probably always be in an SE model of some kind. Either standard model or cloud/SE hybrid.

    Bell ID supports all models and we’re very pleased to see Google enabling the pure cloud solution on a huge number of devices. This is a big step in putting choice back in the hands of the issuer.

  11. I’ve read through all the comments etc and at no point has anyone looked at cost here or risk for the poor old merchant, let along real added value…

    Acquirers make money through transactions, card schemes take a small cut and issuers another cut. This is all paid for by the good old merchant, who gets what back for it? For sure no cut in their fees paid by opting for NFC mobile payments. (interchange changes doesn’t mean lower fees for the merchant necessarily). All of these complexities are all caused by the fact that cards in their very nature are not secure in a digital environment, and so there will always be ways of exploiting them.

    NFC has already got lots of issues, what with interception, and people consistently proving they can listen in on transactions, steal card details via NFC and then re-use that card. I’m sorry but security I know is not key to banks, rather its all about risk, but are they aware that todays fraudsters are getting increasingly technical? Using technologies that simply try to manage risk as opposed to deal with real security issues are asking for trouble in the longer term. Risk will dramatically increase with technologies that don’t address real security concerns. If this approach ever took off, I would be very concerned about the levels of fraud rocketing. And though to a consumer you get your money back, again the poor old merchant is left holding the fraud baby and loosing money. As a business owner I would not be happy with that!

    I would also like to ask, where is the added value? Mobile is all about added value, communications and experience. Simply saying loyalty could get added is not quite true is it. Loyalty from who? How did it get added. Google wants you to use and join their loyalty scheme, and that’s not going to happen. How does a business create their own loyalty scheme and get this working? The added value is still missing, we are simply getting a slightly faster check out experience, and I still need my wallet holding my cards in any case….

    The whole approach with NFC based payments simply doesnt stack up for a merchant. Though it may seem compelling to a consumer, it doesnt to a business, and in such cases it will not gain mass traction. All I have seen here is that Google and Visa want to cut the carriers out of the mobile payment arena by redefining their security rules. I would not be surprised to see more banks looking at their own payment solutions or alternatives to card based schemes, joining forces with Wallets that do not require NFC or bringing to the market their own apps ala Pingit from Barclays.

  12. I feel I must add, that there is so much time, effort, investment in trying to work with NFC that for me, people are missing what is on the horizon. NFC is fast becoming the Mini-disc of the payments industry…I think certain tech companies have already spotted that, and that’s why no NFC support from them…

    1. Andrew, I think you’re arguing against contactless payyments in your first point above since all of your concerns are also true with contactless cards. However the penetration of contactless in Europe, Canada and Australia contradicts your view that it’ll never catch on. Using a mobile device instead of a card adds the option of loading additional (or updated) applications (services) without issuing a new card, so there are clear benefits to the issuer.

      Once a merchant has a terminal that accepts contactless (card based) EMV transactions, they can also accept NFC contactless payments. This discussion goes another step down that path in looking at the cloud version of NFC/EMV contactless payments.

      Making the solution cloud based using HCE has no impact whatsoever on the merchant.

      For your second point I assume you’re advocating QR as the VHS over NFC’s Betamax? 😉

      1. Contactless has been around a very long time in Europe, and though I have limited experience of it outside the UK, I have yet to witness anyone make a contactless payment. There is a big difference between contactless devices being available and people actually using them.

        I’m also aware that not all contactless terminals support mobile versions of NFC so I presume yet further investment is required by the merchant to upgrade their hardware.

        I am very curious about the whole cloud version of NFC/EMV especially as (from the last I read) PCI doesn’t like so many things about this. I would also be concerned with card details being stored in the cloud, even token references to cards. As I have said, their very nature is not that secure, nor is the whole open loop implementation of card schemes. People must be concerned with this, especially in light of how many so called secured cards have been stolen from online retailers (Sony springs to mind).

        My second point wasn’t concerning QR codes at all. though they are far more versatile. I believe they have a place in stores, not just for payments but for loyalty, products, promotions, even stock location. Maybe they are the VHS lol. My actual thoughts was other forms of authorisation and identification for payments (bio), something that looks increasingly on the horizon.

  13. Hi Andrew,
    I use my contactless card very frequently in the UK (and even more so on a recent trip to Australia) but I guess personal use (or non use) isn’t statistically relevant. I think 5.3M contactless visa transactions in the UK in March and growing by 22% per quarter indicates at lease some take up.

    One thing worth highlighting is that the card credentials are not floating around in an abstract, insecure cloud, they’re in a server in a secure environment under the control of the issuer. Some might consider that more secure than having a card in our wallets..

    The great thing about a cloud solution for an issuer is that they keep the payment apps in-house and control access to them. The means of communication could indeed be QR or other technologies. Once the cloud is in play even iBeacon starts to look attractive in certain scenarios but that’s another story..

    1. Hi Martin,

      I find it very hard to believe those stats. Often contactless stats include Oyster based payments or usage, and that is very misleading. I know more people who send their contactless cards back to the issuer than even understand how and when to use contactless.

      I am a strong believer in the cloud, and I would argue the cloud is far more secure than plastic in your wallet. My issue is not with security of the cloud, but how vulnerable card payments are full stop. Incidents like Sony just show this, and the stats behind card cloning etc shows its tough and expensive to secure cards. If someone manages to get hold of card details, then making a payment is easy with them. I cannot see the card schemes implementing a completely new model for payments that doesn’t rely on basic card numbers, no matter how its wrapped up (NFC, CloudTokens etc).

      I agree regarding the Cloud, once it’s in play anything is possible. But the issue still comes back to cards inflexibility and the fees associated with them. We must also think of added value here. Even in the cloud, cards are too rigid. A single payment is not going to include deals, vouchers, discounts, gift cards, loyalty through the issuer, so that means the process is not seamless, or requires the consumer to have different wallets on their phones or proprietary mobile apps from stores…That’s not going to fly either…

      As I said, NFC and the investment it has had, and still requires means it is for me, becoming the Mini-disc of payments. An outdated half-way-house that will be surpassed by other technology, consumer demands and expectations in the very near future.

      1. That is why you have EMV cards it is not just plastic. You have a secure chip. A could based solution offers less security because you need to authenticate to the cloud so if you stole the users credentials to authenticate to the cloud you can make a transaction even if you cannot clone the information from the cloud itself. Google Wallet offers fraud protection for that reason so it makes the end user life easier as they don’t need a new credit card they just need new credentials to authenticate to the cloud. By accepting this risk Google tries to close that gap.

        A single payment can include coupons, deals etc and that is the added value of the merchant. It is a way to promote their products. The added value of the user is that it is more convenient to manage their coupons and loyalty programs. Just to have an alternative to pay with a phone than a physical card is otherwise not so big of a deal for the consumer. It can still offer convenience but the adoption is likely to be very slow and maybe not so wide. The way this can be achieved by a single payment is linking everything in the back-end which is what companies like ISIS in the end can offer as a service to the merchants. It is pure digitization, you move away from physical cards, physical coupons and you put them in your phone. A SE based solution is something in between, a cloud based solution goes all the way and is not limited to NFC (can use bluetooth for example) but has the drawback that you do actually need to be connected. I overall agree that I expect the massive amount of payment to be done through mobile NFC with SE or just EMV cards and a much fewer through alternatives. Solutions like Google Wallet that are open to all will likely have a spike eventually when all the different alternatives add up and a common wallet will become key.

  14. The advantage of using the card based approach is that the EMV rails are already in place. Nothing changes on the merchant side, so despite the challenges it’s tough for competitive technologies to get their infrastructure in stores in the same volume.. For closed loop gift cards where the merchant controls the acceptance, plenty of elegant solutions can be put in place but for mass adoption (at least in the medium term) I’m backing EMV.

    This is the source of those stats

    1. Tha’ts not quite right. For a merchant to support mobile transactions / NFC they need to upgrade their hardware. For most small businesses that’s at a cost, and what do they get in return?

      Unfortunately we’ve asked merchants to upgrade to contactless, only to see that after years and years (here in the UK at least) of marketing and pushing contactless not many of us actually use it. Now we are asking those same businesses to re-invest in upgraded contactless technology (because a mobile transactions requires different communications to a standard contactless transaction) and we aren’t offering them anything in return.

      Claiming you can include deals and vouchers is ok, but if that’s included in the NFC based transaction then the system is proprietary to a Google Wallet or ISIS so where is the open loop you are arguing for? So I as a business I am not using the same hardware my end, and as a business i cannot offer that service to everyone who carries a card, or use the same rails to support different wallets…So, your open loop argument doesn’t quite fit because elements are closed, closed back to ISIS or Google or whoever.

      The only open loop true payment is pure payment through EMV / card scheme rails, in which case deals/vouchers etc are disconnected from the actual transaction.

      With this in mind, why would a business opt for these type of solutions as opposed to a true closed loop experience (ala Starbucks) where they save large amounts on transaction fees , provide a seamless experience and don’t confuse matters at the till with forms of payments????

      The future I am afraid is not going to resemble anything we have right now, and nor should it…

      1. Andrew, merchants are bombarded with a plethora of the “next big thing” propositions and are confused. Most importantly, their current solutions for payments and loyalty work reasonably well, hence their reluctance to change anything.

        As Tom has been saying for a long time, it’s not (just) about tech – it’s about value and UX (both for the merchant and the consumer). With the interchange rates being decimated in the EU, the cost of transactions will not be a factor…

        As for the cloud, with the cost of SE around $1 and the current data roaming cost, cloud-only approach makes little sense for a global solution. IMHO.

      2. Hi Alex

        (not sure why I cannot reply to your comment, and am now commenting above it..odd)

        I agree, merchants can find propositions confusing, but NONE more so than the whole card proposition.

        Card based experiences are an utter mess. Different experiences between different stores, different hardware provided by different acquirers, different experiences through different sales channels and even different experiences in store. Contactless card is different to Chip and Pin, and contactless mobile is different to standard contactless, oh and the hardware you get is also different. And to top it off, it’s no cheaper for you. Even with a real drive to a mobile NFC based card transaction world, the experience will still remain fragmented and different depending on providers etc (and providers of wallets).

        I MUST point out that everyone is hopping on this interchange fee dropping in the EU, but that has been coming soon for years almost. In addition, interchange fee is just one part of the fees that are charged back to the merchant. You have issuing fees and acquiring fees that the merchant must pay, and these aren’t being forced down. Reduction in interchange doesn’t necessarily mean a reduction in cost of handling cards for the merchant, especially as interchange is only part of what makes up that cost. So this vision of merchant fees getting cheaper is simply wrong, I would probably bet it will make no difference to an SME.

        Your point re data roaming charges and the cloud doesn’t ring true with me. Most people on a contract never hit their data charges (and many get unlimited data). Also Wi-fi is becoming so wide-spread now that I hardly use 3G/4G on my device, rather it’s constantly connected to Wi-Fi so no fees at all. Throw in Wi-Fi in most stores and there simply is no cost. If we start talking global solutions then the cloud makes more sense than any other option.

        Why are there vast areas in the world where typical cards not that popular? Why has many areas of the globe passed cards by and opted for mobile solutions? How much does it actually cost to run the outdated card infrastructure? The Cloud delivers a true global solution at a fraction of the cost of card rails while at the same time delivering vast amounts of added value, oh and it’s not limited by your phone hardware or hardware of the merchant….

        I strongly believe that NFC has missed it’s chance to have a real impact. Technology has moved on and now consumer expectation has moved on too. IMHO, cards are looking very dated and NFC is the mini-disc of payments just before the iPod and iTunes showed the way…

  15. I have a couple of questions around HCE and stored value closed loop systems, as commonly used in Public Transport.

    Is HCE (as per Android 4.4) secure enough or designed to support a device based stored value?

    Usually this stored value resides in the SE and the requirement for very fast transaction performance (250-500ms) in Public Transport probably means that cloud stored value and authentication is simply not feasible.

    If HCE cannot support stored value and the SE continues to be used then does Android 4.4 natively support access to the SE rather than the current 3rd party SEEK implementation? It is quite complex for carriers and handset vendors to work together on implementing SEEK in handsets matched to Access Controls in UICC.

    Even if there continues to be a role for the SE, the question remains who should own it and therefore provide the capability to provision services on it – Google or handset vendor in case of embedded SE (although even for eSE the carrier may claim ownership if they are purchasing the devices for resale), carrier in case of UICC SE. As soon as you have a gatekeeper to the SE then you have issues of access and scalability.

    1. I would say it is, yes. In such cases you will buying a digital ticket so you can store your ticket in your device.Typically this means that as long as you the user are comfortable with this the transport company wouldn’t care so much because they got their money. For most users my bet is that they wouldn’t worry of their transport tickets getting hacked from their OS and it is not the most appealing target for hackers either. In the end today you store more important information anyway. The way you buy the ticket is what needs to be secured in my opinion.

      Now “digital ticket” means that there is some kind of encryption needed not to actually be able to clone a ticket and have a lifetime free pass. That means that the transport company needs to invest of having a ticket verification in their backend and also their NFC readers to accept this type of transaction. There is also indeed the question of performance, though I wouldn’t expect it to be a blocking point to do some kind of additional decryption/verification. A cloud based solution doesn’t really help on that. An off-line solution like a SE allows to keep they same system they have today with a standalone NFC card. If you would though implement a ticket validation system then you could even go away with a SE and just make your own OS application as a transport company. You can store then your Mifare keys or anything else that is required by the terminals today in an OS app as in the end you don’t care so much as the ticket itself is still encrypted and validated!

      1. As for transit, convincing transit companies that it’s OK to store keys in a non-SE environment AND getting them to certify OS-based solution is FAR from trivial… Multiply the task by the number of transit operators out there…

  16. A hoover is the best of cleaning tools; it may
    also be the more expensive. You’ll find various kinds of hoover with many
    different characteristics. So before you buy a top-rated vacuum cleaner be
    sure you understand what kind of hoover is greatest to your requirements.

    Pick the best vacuum may be confusing. To help make things clearer you should know
    what the different kinds of hoover are, what the
    key characteristics you’ll be able to find on a hoover, and want you sort of floors you’re going to be employing a
    vacuum cleaner on.

  17. Currently it looks like Expression Engine is the preferred blogging platform out there right now.
    (from what I’ve read) Is that what you’re using on your blog?

Leave a Reply

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