1 Feb 2012
Apple and NFC? I don’t think so.. my bet is 70% against. Great that Apple can keep us all guessing. Why put a 5th radio in the iPhone? AND hand carriers control of SE. There is just no upside for Apple here. NFC would not enhance their wonderful mobile customer experience… it may even kill their Apple/App Store/Apple ID/Payment Instrument advantage.
It would be smarter if they would buy Square… payments belong in the cloud… not locked in the phone. All you really need at a POS is an Irrefutable ID. In a Square scenario, Apple could leap frog everyone in customer adoption and enable every iPhone owner to pay with their voice and GPS location ( Apple has payment instruments tied to every iTunes account). The gap in this scenario is merchant adoption, existing merchant processor agreements/hardware, and retailer reconciliation (if multiple processors). Apple, if I were you I would sit down w/ Square, FirstData, TSYS, … and see what could be done. NFC requires coordination of too many parties.. a late follower would be a much better place to be. Your top risk is that consumers will buy phones based on mobile wallet. Your short term strategy? I pay with my iPhone today (see pic). 
Don’t get me wrong, NFC can work.. but the carriers have proven inept at managing a platform business which would incent the participation of many businesses, allowing all to make money. Instead they operate as a toll bridge, but expect to take a portion of the goods in transit. If you operate as a toll bridge you are a dumb pipe… period. It just does not take much intelligence to run a control business, sure it is complex to build the bridge.. But it even more complex to coordinate the logistics of the world’s commerce. The carriers focus on control is killing the prospects for NFC’s success, as they attempt to act like an orchestrator (requesting a % of goods in transit) but have the ability of a toll collector.
Commerce will find another path… one of least resistance. This is what Apple should do as well. NFC is just a radio… one whos standards are largely controlled by banks, mobile operators and card networks. Why would retailers want to participate here at all? We should not act to enrich the complexity of payment networks, or wireless ones, but rather form new networks that are retailer and consumer friendly. Bluetooth, wifi, gps, voice, facial recognition, sms, .. all can do the job NFC does. We will not see harmony here over the next 20 years, particularly as the only payment instrument in a mobile wallet is a 300bps+ credit card.
Why is Japan successful? because they have a dominant carrier that built a business model.. same in Singapore and Korea… in the rest of world.. chaos will reign until someone delivers retailer and consumer value.
Related Blogs
Update 3 April 2013
My bet on next version of iPhone? Broadcom’s BCM43341 chip
Broadcom has launched the industry’s first quad-combo chip. The BCM43341 combines NFC, Wi-Fi, Bluetooth and FM radio on one chip and, says Broadcom, “offers OEMs unmatched size, power and cost advantages.”
A second new product is a single card solution that pairs a BCM20793 NFC controller as used in the Google Nexus 4 with an 802.11ac (5G) WiFi radio and is aimed at high end mobile phones and devices.
Does that mean the next iPhone will have NFC? yep.. but not in the way we think about it today.
http://tomnoyes.wordpress.com/2011/02/03/isis-platform-ecosystem-or-desert/
http://tomnoyes.wordpress.com/2011/12/05/isis-delay/
http://tomnoyes.wordpress.com/2011/10/26/apples-commerce-future-square/
Tom,
I was directed to your blog today after having wrote a similar point of view in mine here: http://www.droplabs.co/?p=390
Quite surprising (or not) that we are thinking along the same lines on both NFC and a possible Apple-Square partnership.
Tom,
Couldn’t agree more..I think it’s 95% (I said 100%!) in my blog regarding NFC in iPhone 5. And why should they buy Square, its just a mobile card terminal (ok it could work for US only, the “mag stripe country”, and for a few years..).
Tom
Good analysis of the situation. Square would be a good line extension for Apple though the itunes payment credentials really make Square less relevant.
I was kind of hoping iPhone 5 would have NFC. That seemed to be NFC’s best hope. Otherwise, it might just be more of a 2016/2017 play.
Did you notice that KDDI just rolled out NFC in Japan? Aren’t we supposed to believe Japan is a massive NFC market already!
Steve
NFC is just another means of transmitting data. This doesn’t hand carrier’s control of the secure element.
There is nothing that stops applications from storing payment credentials encrypted in general storage or even just access credentials to an online wallet or cloud wallet. NFC could then be used to pass data to the merchant. If the data passed was the online wallet credentials, then the merchant would connect to the online wallet and pull the payment credentials.
The payment would ride the current rails. The interesting aspect is what happens when liability shift happens and what will happen to a merchant’s willingness to accept a 3rd party like PayPal’s online wallet for payment when if it were to ride the card rails either PayPal or the merchant would be on the hook for all card present fraud. Because… PayPal will never be able to keep the Dynamic CVV in sync, so no EMV based transactions for PayPal or any other 3rd party wallets.
Derrick, thanks for your note. What you outline is possible, but it is under the control of “who” owns the keys to the NFC chip (=Secure element + controller/radio). See my previous blog http://tomnoyes.wordpress.com/2011/01/26/apple-and-nfc/, and the excellent RIM developers overview http://supportforums.blackberry.com/t5/Java-Development/NFC-Primer-for-Developers/ta-p/1334857 .
For the software developer.. the specific from RIM (google has not published) is as follows:
We have however introduced a couple of new signing keys, NFCR and RESE. You will need to sign your application with the NFCR key if you are using any of the classes or interfaces in the net.rim.device.api.io.nfc.se package with the UICC resident SE (SIM). Similarly you will need to sign with the RESE key if your application uses the net.rim.device.api.io.nfc.se package with the device embedded SE. Note that these signing keys are only available by application to RIM at this stage.
In this RIM environment, applications cannot access controller without the correct signing keys. For example, the use of the NFC radio in the latest Samsung Galaxy Nexus is not just a matter of google publishing the Gingerbread NFC APIs, but of also having access to the key for that specific chip in that a given phone. Who owns these keys is a battle, with RIM taking the approach of offering multiple SEs.. one they own and another that the MNOs can own.
In your comment, I believe you are assuming that the NFC radio can be used separate from the controller, or that there is no signing keys (or keys are open). This is not the case in any currently phone being manufactured (to my knowledge). NXP (PN65n in Galaxy Nexus) is the leading NFC IC manufacture.. combining all of these elements.. If unsigned applications had access to the controller, it would certainly compromise the integrity of the SE and the overall architecture. Separating the radio from the controller is not a bad idea, but you would need a separate controller for this “open” radio. My hardware friends should stop me before I make an idiot out of myself.
All, Please correct me if I’ve mis-stated anything.
Google API Gingerbread (limited) http://code.google.com/p/ubinfc/
NFC Phones and controllers http://www.nfc.cc/nfc-phones/
http://tomnoyes.wordpress.com/2011/01/19/nfc-who-owns-the-secure-element/
http://tomnoyes.wordpress.com/2011/02/21/iphone-5-nfc-twist/
NFC is a radio technology. I am sure the carriers would love to restrict what programs can use the NFC but they will never pull that off. It is going to be used for to many other non-payment related things. Much can be said for “card emulation” but data is data and will get passed using card emulation and not. Other modes exist from the controllers with far less restrictions. An application then just has to manage the data as it passes.
Too much concern is given to the importance of the secure element. When encryption using generic memory and EMV credentials containing a dynamic key for comparable security.
The notion that you can restrict access when you don’t have physical control is also non-sense that may work to distract an average consumer but a rooted or jail broken device is fair game. This may all be pointless anyway when…
V.me, Paydiant, PayPal are attempting to store credentials in the cloud first and have either the wallet app or the POS terminal call to the cloud to pull the credentials. A key nuance is the consideration for what transaction types result. Card present, card not present, or EMV.
The EMV mandate then does the following. Adds extra security while at the same time, eventually, transferring liability back the merchants. Which, non issuers or issuer partners will not be able of performing an EMV transaction because they will not have the dynamic CVV or CVC.
RIM is a dinosaur that like Kodak resisted change and will have to change and hope to still be relevant. I think it is too late for them but I don’t really care either way.
It is about creating platforms now and letting people take advantage of them this includes the hardware and software of mobile devices.
Apple is a concern but does Apple care about the payment side of the business if they can control the commerce side of the iWallet and just partner with the big payment networks.
Apple also has a stated policy in their walled garden that no commerce payment apps will be approved. Will they enforce it? What happens when mobile banking or merchant apps start doing clear cut payment apps.
Additional comment, newer controllers have been created that can work with multiple secure elements.
Pingback: Apple Passbook: No NFC Here… « FinVentures
Pingback: Apple and NFC – Part 2 | FinVentures
Pingback: Two Major Payments Projects Said to Be Underway at Apple | Bank Innovation