August 2, 2012
Yesterday I covered the winners… today I cover the flip side.
Mobile Operators
Most obvious is mobile operators payment efforts, at least those bent on controlling the NFC SE in a walled garden strategy. I covered this topic last month (Carriers as dumb pipes). As a refresh.. 5 years ago carriers were going to charge applications each and everytime they accessed the GPS.. you can see how that worked out…
Its really a shame.. Operators have tremendous distribution, brand, cash…. What they don’t seem to have is anyone that knows how to run a platform business (related blog). Running a platform is about creating a “sandbox where everyone can play and make money”.. Apple has it.. of course they also have 75% of mobile profits (related blog). Most of my frequent readers already know what I’ll say next: Control is NOT a value proposition.
The big problem with payments? There aren’t any problems (and margins stink). Why focus on it? The mobile handset has the opportunity to do so much more. Google has an ad business which will greatly benefit from added payment information. It will be in a position to help retailers and consumers and deliver value (note I didn’t say banks). The MNOs don’t have a business that can leverage payments, and they are not the greatest at partnering. They couldn’t even work with Google… a company that built Wallet and Android for free. Just what were they trying to win? (related blog)
My STRONG recommendations to carriers: go partner w/ Google now.. If you thought Apple was a one time event you are sorely mistaken, google has more commerce assets (virtual and physical) than anyone in the world. Another recommendation? Focus where you can win easily, AND DELIVER VALUE (see KYC a $5B opp)
Big Banks
(At least the credit card divisions). Most of card teams were trying to position mobile as a “premium” payment service. Its not a total wash for you, given that Google is charging merchants regulated pre-paid rates while having to pay most of you full interchange… perhaps even CNP interchange. But while you see a quick win here remember that incentives can be tied to a card. If you don’t play nicely my guess is that you will see customers shift spend, particularly for small items. Of course one big weakness of the Google wallet is the refund/return process. Additionally, Google Mastercard consumer purchases will be covered under Reg E, vs the greater protections afforded consumers with a credit card under Reg Z.
The biggest bank loss however is Data.. not much of a problem today given the number of Samsung Nexus phones are in the market (.. with google wallet). But what if Google does issue their own contactless sticker.. like I have on the back of my iPhone? Why NFC at all… just a Google card to swipe would allow you to have all of the functionality. In the new Google wallet world, they will see all transaction data.. just like Paypal does. Difference Google knows how to use it in advertising.
Card Linked Offers
It just a guess.. but now I can have offers linked to any card I use.. For merchants TXVIA could create virtual pre-paid cards for you at no cost and let the “value” of the offer reside there. Basket level, or item level with POS integration. The writing is on the wall..
NFC Ecosystem
There are pros/cons here. If the carriers supported Google wallet it would be mostly a win.. We may actually see NFC handsets be common place… but not if people have to root their phone to install Google Wallet. Apple will eventually put some sort of new combined SIM/NFC/BT radio in its phone (related blog). In this future Apple Passbook world I can guarantee the carriers won’t be keeping any version of the iPhone in a Garden.
Short term impacts with Google Wallet? The First Data TSM operates with Google as the SE owner and service provider, no SWP UICC chips, no OTA provisioning, …
Comments appreciated.
TSM’s as a whole will have a tough conversation ahead with issuing banks in building a business case. Their myriad costs are enough to give many a bank pause in whether they should be investing on NFC today vs building out a mobile presence that compliments the plastic before replacing it. And in my experience, the latter conversation always wins out. The complexity of orchestrating the delicate dance between an SP TSM and an SE TSM will keep many a bank away from dipping their toes, even after Carriers manage to flood the market with NFC equipped phones.
As for Apple, I am still not convinced they will embrace NFC, and even if so – that they will bundle it with an SE or simply not enable card emulation. Each of those three options end with Carriers being cut out of the game and calls to question the long term viability of Isis.
I think Google might want to start looking around at solutions that bring about deeper control over what they do best, “Gather and sell information”, because if they do not you will give Apple to much time to fortify their walls. Right now they are vulnerable. Not because they are weak but because they are strong. They no longer have the element of surprise on their side. Google still does because they still hold the mad scientist persona. Yes, that to is waning but they are still have the potential lurking in there corner. Moreover, if Google were to come out with some open or new way of enabling users to use google wallet now Apple would already have made the commitment to not include NFC in their phone…this would enable google to put even space between them and the other payment players before they even came out of the blocks.
I do not know, it is just a thought. Maybe things will change. Maybe google will send out a press release next weeks saying they are closing down their google wallet division and refocusing on search only!!!! Maybe, they will give in to the players that are still stretching…(apple like Casey up to Bat)
Google put a sticker!! Doesn’t make any sense. How does google control comsumers put that on their wallet enabled phone and not on their corporate badge or another card? Why not just issue a plastic prepaid mag stripe card tied with the virtual wallet id? Use google wallet on all terminals. Way better than a sticker and no dependence on NFC. But they wont do that. They are not interested in payments. Google wants people to use the app, which is how they convince advertisers to put their ads so that click charge revenue would start flowing. If they would enable people to use the google wallet to work without getting the eyeballs in the app, the entire long term plan here would go waste…
Google is going to eventually do both, release a mag stripe card and make NFC stickers available, what ever the consumer wants they can get if not both. For Google the questions is not why, but rather why not.
Additionally, what do you think is stopping Google from releasing Google Wallet to more phones, or even into the iPhone App Store? If they took NFC away or it was a non consideration then the app is really just a management app for the cloud.Apps like this exist today including PayPal apps. Call it Google Wallet Lite… but I am going to be able to use an iPhone to manage the credentials in my Google Wallet eventually.
Also, there is nothing that is stopping PayPal from looking at this model and doing this themselves. They have the platform, credentials, and networks to run the same model using a mag stripe card, nfc sticker, etc…
What I am waiting for is for the other shoe to drop, what is Visa going to do in response? Has anyone considered that this could be a violation of their operating rules or any of the litany of regulations from E to Z.
In other words Visa will move quickly to be a proxy card option for stored visa credentials, or they could react by telling Google, no, thank you and good bye. Maybe not so blatant but all of a sudden timeouts start causing declines or Google to have to stand-in for a transactions as this is not two transactions instead of one.
Consider the implications for acquirers or merchants if this concept were to gain real momentum. An acquirer or merchant wouldn’t need to have connections to Visa, Amex, or Discover. With this model they would only ever need MasterCard and Google will take care of the rest.
Don’t get me wrong, what Google is doing is game changing but it is crazy expensive aswell.
Google is eating costs associated with two transactions. Assuming fraud liability because from the issuers perspective the transaction is in fact CNP and Google is eating the interchange differences between the first transaction being card-present to Google and the second transaction being card not present, in addition to the Google proxy card being debit, unsure if regulated I need to research Bancorp’s assets size and the card program that are paying in the wallet. Business Debit, Credit, Amex, or Discover rates, etc.
It is going to continue to be both fun and interesting.
Great comments Derrick.. Issuing banks are much more likely to react than Networks. Visa “allows” this for many applications today.. Paypal’s debit card is a prime example. I saw the press on Amex. My guess is that the authors spoke to someone that didn’t go up the chain. I just did a purchase today using my Nexus S and my Amex Card. Does Amex not want to allow online purchases on Chrome? Playstore? the new tablet? Amex does not own me.. I am also a google customer. If they make a decision to not let their customer’s pay because they don’t like the technology it wouldn’t sit well with us. They can make the case its fraud they are concerned about, but does that mean I shouldn’t use my Amex card online? What happens for me is that I will just use another card that supports it and Amex will loose transaction volume.
What Amex probably HATES is the idea that Google will see all of their customers transaction volume.. it drives every bank bonkers at the thought. If google is able to deliver “benefit” to Amex card customers INDEPENDENT of Amex.. they are worried. I look at this as a new kind of arbitrage.. google is taking on costs and risks .. all to deliver better customer experience, help the retailer and deliver advertising.
Amex could do this.. lower their interchange … but they can’t touch the cash cow.
Google Wallet has made the wallet more appealing by moving it to the cloud and freeing up the SE and also the TSM over the OTA process. There are still doubts over the wallet id being mapped to the cards, how the transaction process will be for online transactions and the rates applicable to the merchants (online & retail). As pointed above in one of the comments they may go ahead with NFC stickers and / or a mag stripe card as well. But today GW is an option that stands out promisingly for customers to link all their cards without having to rely on their banks or the carriers. Having said that PayPal may be thinking that they have something like this already.
Tom,
Your comment at the end of the article about no TSM and no OTA provisioning is not exactly right. Google Wallet 2.0 still makes use of a PayPass credential on the secure element. This credential is provisioned over-the-air by the TSM. And the TSM continues to manage the secure element, as it has since launch. In this case, First Data is the TSM.
Christopher Cox
Mobile Solutions Product Development
First Data
Good point Chris… don’t know if you can publicly agree.. but FirstData is operating in a “Quasi” TSM role in wallet 2.0. For readers background on page 4 of FD whitepaper (http://www.firstdata.com/downloads/thought-leadership/fd_mobiletsm_whitepaper.pdf) and also in the GSMA reference architecture page 29. http://serving.webgen.gsm.org/5926DA9A-2DD6-48E7-BAD4-50D4CD3AF30A/assets/gsmanfc2wp.pdf
Provisioning
1) Wallet 2.0. FD provisions the very first Google Mastercard Card in a TSM role, however Google knows the card number (it is issuer), phone number, and maintains ownership of the SE Key. In this manner FD is providing very limited TSM services primarily to one party: Google, not between an MNO, Bank and Platform. No UICC mgmt, no App management or installation, Google knows all card numbers and user account information.
2) Citi card (legacy). limited TSM role: Sprint, Citi, Google. As an ex Citi exec, I understood there were concerns surrounding FD’s implementation of TSM (a non-standard model). This may have been related to SE key ownership and control. Obviously if Google developed the platform and subsidized the phones they should own the keys and hence services requesting access must interface with a key management function. This is certainly not a hit on FD.. but a point on the “uniqueness” of requirements across different platforms. I’m sure we will see something similar when/if apple does anything.
I’m not disagreeing with your comment, just clarifying “TSM continues to manage the secure element, as it has since launch”.. you manage the SE for Google, and Google keeps ownership of the keys.. this is a little “atypical” when compared with the GSMA reference architecture.
If this has all changed, then please correct me.
For readers, please know I’m firmly behind Google’s approach here. They built the OS for free, the wallet for free, and subsidized the Nexus phones… they should control the embedded SE key. Someone has to make sure all of the software and HW work together. This is why we don’t see hacks of the Nexus phones that use the SE… no one has the keys.
Tom –
Thanks for the opportunity to clarify. Don’t worry, I didn’t read your comments as a hit on First Data. And keep in mind that I can only comment on the services First Data currently provides, and not anyone else’s strategies or product roadmaps.
Our current setup is actually a fairly typical TSM implementation. We manage the SEs using a key shared by the SE owner, doing all of the typical over-the-air SE management functions (SE memory management, key rotation, SSD setup, application loading, etc.). This is generally referred to as “MNO TSM” services, but relates to the services we provide to the SE owner.
On behalf of the issuer, we provide service provider TSM (“SP TSM”) services, including chip data prep, over-the-air application personalization and lifecycle management. The fact that one entity is filling the role of both SE owner and service provider does not change the TSM services we provide or how we deliver them. We set up the issuer like we would any other SP on our TSM platform.
It happens in this case, we’re providing both SE management (“MNO TSM”) and SP TSM services. But our TSM is architected such that we can provide each service separately to different entities. And we can integrate our SP TSM services to third-party MNO TSMs when required.
TSM implementations can vary depending SE type (e.g. UICC or embedded) and by GlobalPlatform security mode (e.g. simple mode, delegated mode, etc.). But as a full-service TSM, we’re ready to support all of the those models when our clients need them.
So there’s really nothing “quasi” or limited in terms of the TSM services we’re providing.
Chris C.
First Data
Very useful. Thanks. I will remove the quasi. First Data is clearly capable (and certified) to work in many models.
My inclination it to label this “non standard” as compared to the original GSMA “vision” as you provide “MNO TSM” services to Google and SP TSM services to Google’s card issuer. In the case of Google Wallet 2.0 the “T” in TSM is somewhat of a misnomer. There is no other party that you are providing services for.. hence no need for a trusted intermediary… FD has “capability” to take on other SPs but that is TBD.
So I will take out the Quasi… and focus on the differences from a “standard” MNO model .. although given market adoption, there seems to be few operational standards.
Hello Chris,
Is there any official document from First Data, Google, or Bancorp clarifying the role of First Data? It would be quite useful, since most observers believe there is no more OTA provisionning in Google Wallet V2.
Thank you for your answer,
Karl