apple – Page 2 – Noyes Payments Blog

Apple Pay- eCommerce – Disruption

30 September 2014

ApplePay/eCommerce/Tokens/Card Not Present

Quick blog, based on Apple Pay in eCommerce.. following on to my March Blog Tokens and Card Not Present (NOT the POS NFC stuff). I won’t do this topic justice, but hey half the fun is getting comments. I’m heads down on a few things.. so this will be my last post for at least 3 weeks.. and I want to make a few key points prior to money 2020.

Summary

So much for Paypal being acquired.. wow!! Dan Schulman is the right guy here, and I must congratulate the eBay BOD. This thing can NOT survive without a major change. Dan is a “direct to consumer” Innovation Superstar: Priceline, Virgin mobile, Serve/Bluebird, .. etc. He knows how to run a global organization, he knows mobile, he knows payments, he knows retail. His biggest challenge will be rebuilding a house on fire during a Hurricane.
Apple and eCom: No change in CNP rates with Tokens.. Tokens in Apple Pay are used for both POS and eCom, but the issuers revolted at the prospect of a CNP revenue loss. I do see “next phase” where we will see A NEW RATE TIER for tokens in eCommerce.. for any online merchant replacing their Cards on File (99% confident). Funny battle here is “who” will lead this. Visa/MA have the TSP up and running now. 3-5 issuers should have theirs running in next 5-7 months. Can you imagine having to work with each and every issuer separately to tokenize? NO WAY. But they just don’t get it..
Big issuers are concerned that the Apple Pay launch was a watershed “freedom” moment for V/MA. However Issuers did win a very important battle.. keeping a primary control point: token binding (deciding when and where their cards can reside), and the also have the ability to create their own token authority.. but they have work to do.
ApplePay’s focus is 1) POS $15-$20B and 2) “in app” payments $5B 2015 GDV.. US eCommerce payments will remained locked in the status quo battle among the giants of Amazon, Visa/CYBS, Paypal.. with Google, Off Amazon On Click and Alipay as 3 of the new challengers here.
Apple Pay Tokens: Visa and Mastercard did 90% of the work to get this scheme from concept to reality in 12 months. The fastest time to market for a new scheme IN HISTORY. It is a thing of beauty.. seriously. I believe the networks learned many lessons here (like build it first then bring the Banks on board to tweek it).
There will likely be a new rate tier for tokens in eCommerce with liability shifting back onto the banks, but issuers must support in order for this to gain traction and merchants learned from VBV that you don’t get into a scheme where issuers don’t support (ie declines matter more than interchange).
iPhone 6 is a revolutionary product, which will impact identity, trust, retail, banking and payments. I see the revolution beginning outside of payments, where value can be created.
eCommerce wallets are an aggregation function. There are only 4-5 companies that can possibly make this work, each having a different value proposition. Visa and Google are the leaders here.

What did I get wrong on Apple Pay?

I did not see the NXP SE. I thought that Apple would encapsulate the SE functionality within the Secure Enclave. While the Secure Enclave has secure storage, it did not have secure execution, nor did it have a way for a third party to update applications and data in secure storage/execution. Hence the SE, with First data running the “TSM” function.
The tokens within Apple Pay are NOT provisioned at time of manufacture (not burned). They are provisioned by the Visa/MA after a binding process. The token issuance/binding process is just fantastic, leveraging the existing AUTH message set to avoid network changes. Issuer process to ApplePay: sign an agreement, turn on the Visa services (most are not EMV enabled), decides who’s BINs you want (your own or Visa’s), and prepare to respond to auth requests for binding/tokenizing cards.
There does not seem to be a beacon/BLE experience within Apple Pay (yet). My guess is that there is a 3 phase road map. Phase 1 traditional NFC, Phase 2 Merchants enhance the checkout process with Beacon at the POS to improve application “wake up” and perhaps another loyalty app that can interact, Phase 3 All BLE, with perhaps an NFC handshake to “sign”.
Issuers giving up 15bps. I can’t believe they went for this.. Issuers only sustainable business case for this is around shifting spend to credit cards.
Visa and Mastercard did and amazing job in this token design. Getting all this done from concept to production in 12 months is just incredible. There is much to celebrate here, and it could be the most successful network accomplishment in 20 years. There are major implications here, shifting roles of control, managing consumer identity, and of course a new “model” process for change in the future (no design by committee, let the banks comment after it is complete).
Paypal was thrown out of the Apple Pay deal… They were in, but they were thrown out. My guess (and this is purely an informed guess) is that the Issuers and V/MA gave Apple an ultimatum: you can launch with us, or with them.. your choice.. Enabling Paypal allows Apple and consumers to end run the card network.

Apple Pay and eCommerce

This Custora blog provides an excellent economic view of Apple Pay’s eCommerce impact. Today I wanted to comment on a few additional items which influence the dynamic:

Macro Environment – eCommerce
In app vs browser
Future: What if Tokens in eCommerce had card present rates/Liability Shift
Tokens + Identity kill fraud, but they also create a whole new biz strategy for CONTROL
Wallet = Trust
Platform: Partners and acquirers for acceptance
Other Strategies

Macro Environment – eCommerce

What is eCommerce? eCom is normally defined as buying physical goods in a browser. However, if your browser is an iPad or phone, this is typically categorized as mCommerce. I break mCommerce down into 3 major categories:

Physical goods/services in a browser,
Physical goods/services in an app, and
Digital goods (songs, armor, movies).

eCommerce sales in the US are around $185B, while all mCommerce sales are about $20B. In a perfect world I would love to label ALL browser, and in-app purchase of physical goods/services as “eCommerce” and just track the consumer preferences in the app/browser that led to purchase.. but I might be alone in that quest.

The Apple Pay buy button is only available within approved iOS 8 applications (on iStore). This means that Apple will be focusing within the rather small “in-app” sub-segment of overall mCommerce market. This means that Apple Pay will have minimal impact Paypal, Visa Checkout/Cybersource , Masterpass, Checkout by Amazon, Google Wallet or any of the other eCommerce payment specialists .. …at least not in 2015 (estimate is $5-10B max). Apple is the dominant mobile platform for “purchase” even though it represents only 18% of handsets), accounting for over 70% of purchases.. wow talk about a great consumer base!! Of course this “in app” only could all change in 2 ways: 1) IF most retailers shift “sales” to APPs (like Target and Amazon) that exceed the functionality of browser based experience (ie App vs HTML 5), and #2 if Apple creates an eCommerce Apple Pay Button for the Safari Browser.

If online Fraud costs were the only justification for card not present (CNP) interchange, then logically the new EMVCo token process should eliminate the “barrier” between card present and card not present rates. But CNP rates are not based upon fraud, for example Google, Apple, Amazon, Paypal all have fraud rates hovering around 3bps, whereas the CNP to CP delta can be over 100bps. If you were in the room with one of these big eCom guys you would hear them tell issuers they want risk based interchange (aligning costs of acceptance to ability to manage risk). However, aligning the cost of payment acceptance to the cost of payment (and credit) provision is the crux of the merchant issues with card payment networks, particularly when the costs include loyalty schemes that do not deliver loyalty for the merchant (even though they pay the cost).

Banks are not keen to support Apple in creating great consumer experiences which they can’t control. For example, if tokens in eCommerce were treated at card present rates, they could be transmitted and exchanged in many different protocols (QR Codes, BLE, Wi-Fi, …). Tokens + authentication enables uncontrolled innovation in presentment and acceptance, thus destroying MERCHANT Incentives to support the bank driven uniform NFC contactless acceptance (ie BLE vs NFC) and uniform behavior (credit card, tap and pay), and limiting Banks ability to influence consumer behavior.

eCommerce Wallet?

eCommerce in US is a lumpy business where the big 3 rule over 60% of spend and processing: Amazon, Cybersource (Visa), Paypal/GSI (eBay). To re-emphasize, Apple Pay does NOT impact the battle for a ubiquitous eCommerce wallet, which explains why we see all those cool Visa Checkout commercials on the NFL games this week. The INDUSTRY’s eCommerce problem is eliminating card numbers stored in 100s of locations.

With respect to eCom wallet.. most consumers just scratch their head.. “Why do I need one of those”. Amazon’s one-click, Chrome’s auto fill, Paypal checkout, iTunes buy.. it just works. Why do I need something that spans across merchants when 90% of my spend is with one of these 4 already? Additionally, consumers don’t really care about security, because they don’t bear the costs of fraud. So we have a situation where Banks want to solve for cards stored everywhere, and consumers won’t take part. This means that banks must develop a merchant value proposition to TOKENIZE their cards on file (COF). Hence the prospect of a new rate structure for tokens in eCommerce.

Merchants may RUN toward tokenizing Cards on File if the recipe is right, however tokens by itself may not be enough to overcome the terrible history of VBV/MSC launch in EU (see my blog Authentication in Value Nets for detail). In addition to rates, Google has potential to bundle eCom payments with advertising (consumer acquisition), Amazon could do the same, and Apple.. . Consumer win for eCom tokenization? Anonymity, consistency, security, ease of use, more targeted advertising. A funny battle over tokenizing cards on file is taking place right now. Each issuer is trying to work with Amazon, Google, Apple, WMT… to tokenize. Can you imagine trying to do deals with each issuer? with seperate proprietary “on ramps”.. This issuers are concerned that Visa and MA will take this token issuance/binding process away from them .. but I don’t see another way.

Who else could win the eCom “wallet” war? Visa! Their advantage? Brand, reach, marketing, Cybersource assets, rule making and acting as one of the only TSPs. Their challenge? signing up consumers.. and they seem to have the marketing muscle (and intent) to do it (V.me blog). Innovating in a 4 party network is normally next to impossible (see blog), but they have gained tremendous momentum in learning a “new way” to innovate through the Apple Pay experience.

This is a very, very major point.. and should lead V/MA investors to take a new fresh look at what these networks could accomplish beyond their traditional switching role. These are my largest personal holdings, so I am a little biased here.. there is so much upside.. but most of the future is dependent on tilting toward consumer and merchant. In emerging markets, I expect these network will assess their regulatory structure: do they become a bank? An MSB? An acquirer? in OECD 20 markets.. An advertisers? A merchant friendly loyalty provider?… YES!!. This is the YEAR for a network pivot away from issuers toward consumers and merchants.

Strategies in eCommerce

I think about eCommerce with the context of an acquisition funnel. Where did the consumer start? Where did they finish? Today more product purchases start with Amazon than with Google. Does anyone really thing Amazon wants to let another brand come in and help them (Sorry Chase Wallet). Where can anyone add value here? Amazon and Google may position that same day distribution of goods is far more important than payment (and I would agree). But perhaps the barrier for every mom and pop shop having their own self managed eCom sales site is fraud and payment acceptance. If Tokens solve for this, and help broker identity/preferences.. then EVERYONE could compete with Amazon, online retail becomes disrupted by taking away the advantages of scale. This model would be a huge boon to Google and Alibaba (they see a world of a million merchants and billions of products).

Payment Networks are working to take risk out of payment acceptance, solve for consumer anonymity and improve on their only weakness: no direct consumer relationship. Thus they endeavor to directly enroll consumers in a direct service offering to serve the eCommerce wallet role (see Battle of Cloud Part 3). I am very high on these efforts. Why? Because they have ability to create a new value proposition when coupled with their tokenization efforts. I predict within 2 years that we will see a new rate structure for use of Tokens in eCommerce .. something near CP rates.
Issuers are working to improve value to card holder and keep consumers within a Branded experience. JPM has created a new data division and purchase a card linked offer company. Banks are working to create their own “wallets” (Why on earth would a Amazon add a Chase Wallet button.. just plain stupid). Banks love the NFC and ApplePay token model where cards must be “provisioned” into a wallet. Banks thus control of which wallets to “authorize” and hide purchase data from the wallet provider. Why would any merchant accept this? EXACTLY!
Apple, Google, Samsung, Microsoft working to make payments part of the OS (see blog). Payments in OS will impact “In App” first, eCommerce “browser” next.. authentication removes risk. This enables unstructured retail and disrupts marketplace concentration. I moved their strategy to the next section below (brokering trust)
Marketplaces like Amazon, Rakutan, Alibaba have integrated payment into their platform and are not keen to exchange Cards on File (COF) for tokens without a liability shift and risk based pricing. I’m slowing down here.. should be able to put a few more things in..
Paypal? Well.. let’s give Dan a little time here.

Brokering Trust (Platform strategy)

The ability of a mobile handset to authenticate consumers, and allow the consumers to delegate trust to 3^rd parties (identity and secure data) will have major implications to retail, loyalty, payments, healthcare, social, MNOs, government, access management (see Brokering Identity). To understand the different strategies in this area, we must look at how tokens impact the existing model, who controls platforms/OS, who sees the data, where do consumers begin their product search (ie Amazon), who bears the cost of fraud, who is regulated?, what restrictions does entity have in collaboration/data? what is the consumers current behavior?, and who does the consumer trust to manage identity (see Who do you Trust?, Perfect Authentication – Nightmare for Banks, Token Assurance, KYC – $5B Opportunity, Authentication – Core to monetizing mobile).

Banks have historically played the central role in brokering commerce. They created the payment networks, and are central to many commercial payment processes we don’t see. Perfect authentication of consumers will completely disrupt payments, as the many new intermediaries can participate in risk (ex clearing and settlement). This is all happening at a time where retail banking is being turned upside down (WMT/GDOT Checking, Future of Retail Banking). The winner in this risk/identity battle will have the trust of the consumer and the ability to broker it against all possible market participants. Merchant “trust” can NOT be won without a merchant friendly value proposition.. hence the problem for any of the eCom wallet providers. My view is that Apple and Google are better placed to execute here, not because they are more trusted, but because they know how to partner and move more quickly.

Paypal at Crossroads (? buying Blackhawk)

25 June

Big things are in store for my favorite eCommerce payments company. Really, I do like Paypal. I may ding them on their POS strategy… as it makes no sense at all… but I love Paypal online.. the “original” ecommerce payments solution that adds value to merchant and consumer. In 98/99 Thiel and Levchin were the first to dream up digital wallets, and first to solve a REAL problem of card acceptance online for small retailers. Perhaps even better than the great Paypal PRODUCTS, were the great PEOPLE that grew out of PayPal.. that have done soooo many great things: Peter Theil, Max Levchin, Elon Musk, Keith Rabois, Premal Shah, Osama Bedier, Amy Klement, Steve Chen, .. (list too long sorry to those I left off).

As its early leaders went on to do great things, the company “evolved” from an innovative start up to take on a bank flavor. Scott Thompson came from Visa and all his direct reports had bank backgrounds… the top tier of the organization led to a culture change (in a bad way) and it went from the coolest company in the valley… to … errrr… something else. Pierre and the BOD recognized this and tried to get the mojo back with putting David Marcus in at the helm. They wanted to recapture what made Paypal great (people).. to reset the culture. David is a great guy, as he says this week he was an innovator.. but one that never ran a team larger than 200.. and certainly not a global one which was highly regulated. It didn’t help that eBay’s CEO essentially undercut David by allowing Don Kingsborough and Gary Marino end run and make decisions directly with John. How could any CEO make it in that kind of environment!?

Now that David is gone (see Venture Beat) who can lead them (today) and what is their new strategic imperative.. their vision for growth beyond eCommerce?

Next 12 months

I believe Paypal will see competition in its core business like never before, As I stated previous Payments are moving into the OS… and Paypal doesn’t have one. Apple, Amazon, Google are new competitors in core eCommerce… all with an OS.

Paypal’s new competitors?

Apple will own payment presentment and authentication on all iOS devices.
Amazon will begin to get off Amazon traction (example today is Gogo wireles)
Google’s massive success in Shopping Express (Free shipping and payments). Google also just launched wallet in iOS (see google’s blog)
Bank Token Schemes and forthcoming rules for cards on file

As a side note, Paypal did squeeze itself into the Apple wallet (for NFC/POS transactions), but Apple will be expanding the iTunes buying experience very soon, and it won’t be looking to drive Paypal merchant adoption, as it is in the process of negotiating card present rates for CNP transactions (See my Apple blog).

Paypal at the POS is a complete joke (see blog). The business guys that have been running the show (or end running David) are focused on a Visa/Mastercard like strategy… not on one that delivers value to their core constituents (merchants and consumers). Paypal was the company best positioned to execute on a Braintree/Stripe product 5 years ago (remember X.com) and also the best company to have built a Square/Clover like solution. They missed all these things because their business heads were focused on quick transaction volume deals and solutions.. NOT ON VALUE.

POS – Buying Blackhawk?

This is my big theory today. With eBay repatriating $9B and taking a 30% tax hit, we all know that acquisitions are planned. But what?

Obviously Carl Icann, David Marcus and the BOD have had some disagreements. Rather than guess the strategy, lets take a look at WHO is staying at Paypal. Don Kingsborogh is the former CEO of Blackhawk and head of Paypal’s POS strategy, and Discover Network strategy/relationship.

Paypal has promised its institutional investors progress at the POS.. and they have NONE. Jamba Juice and Home Depot numbers are terrible. The Discover partnership did nothing for them, as MCX merchants REFUSED to accept Paypal (routed as a Discover Card) or new processor agreements (that ran as high as 210 bps). Paypal has “learned” it cannot sneak in payment products within an existing network (Discover), nor can it deliver enough value to push merchants toward a new agreement. Few eBay investors realize that the Discover relationship is yielding NO FRUIT. Even IF they could convince a merchant to TRY paypal at POS.. they first have to line up the Processors to support, and big ones like First Data were not playing (WSJ Article). This Paypal was paying $50k-$250k+ for merchant to SWITCH to Vantiv just to do a pilot.

Paypal at POS needs a ubiquitous merchant acceptance solution and a physical connection to all major merchants. They also have learned how both Google and Apple have developed strategies to end run the traditional payment terminal and integrate directly with the POS (see the brilliant Google/TXvia Patent US 8676709 B2. )

Blackhawk may fit the bill, as it has a merchant network and POS integration solution today. Every time you pull one of those pre-paid cards off the shelf the SKU bar code is tied to the card Primary Account Number. The Retailer’s POS system sends the SKU to Blackhawk upon payment and Blackhawk activates the card.

Blackhawk is working to leverage this transaction flow to create its own scheme to fund the transaction.See Blackhawk’s patent US8676709 B2. An item in the shopping card becomes a payment instrument. This could be “THE” enabler to someone like Apple too.. a new payment “gateway” that end runs the traditional payment stream. For Apple, all they would have to do is get a secure “TOKEN SKU” to the POS and the POS would leverage Blackhawk to route. Of course items in a basket usually have a cost, but settlement could be accomplished through a 100% discount, or by capturing the merchant ID and terminal ID to push the payment back through their current processor.

I think this is THE most brilliant scheme EVER!! I love it.. If implemented via ACH.. and MCX. I just don’t love Paypal delivering it because of “cost” and ability to coordinate/execute in delivering value from all merchant data.

I’m only 50% confident here.. just put a small $10k bet along these lines for fun. But at a $1.4B market cap.. this would not be a bad bet for PayPal.. problem is that merchants will never go for it.. this does NOT solve the VALUE problem (for consumers or retailers).. it only solves the network acceptance problem. This approach continues the “we will sneak it in” approach. It may “solve” a short term problem of Processors.. but it creates a new one for the merchant in having to deal with multiple processors (one for swipe one for … something else).

IF the merchants would go for this, it may be the best payment design on the planet.. as it would give a way to provide discounts and rebates within the POS system. Integrating with the POS would completely disrupt the processor/payment terminal process, and we would begin to realize the “power of tokens”.

Apple iBeacon Payment Experience

14 May 2014

Last week I outlined what was coming out in the iPhone 6 from a capability/payment perspective. Today I will cover my best guess at the user experience, a 50% confidence guess…

Beacons

First a little about Beacons: Qualcomm is the technology behind Beacons and they just spun out Qualcomm Retail Solutions last week with external investors to form Gimbal. My bet is that Apple was in the mix, as Apple’s iBeacon is the brand and handset side of what QCOM developed and owns. Apple’s iBeacon appears to be dependent upon QCOM license (see Patently Apple). You can see the similarity in Apple’s patented logo with QCOM’s logo.

Think of beacons as proximity devices with context. From QCOM

Gimbal proximity beacons complement GPS by allowing devices and applications to derive their proximity to beacons at a micro-level not currently afforded by GPS technology on consumer devices. A user’s mobile app can be enabled to look for the beacon’s transmission. When it’s within physical proximity to the beacon and detects it, the app can notify the customer of location-relevant content, promotions, and offers.

Here is a fantastic blog by beekn outlining how beacons operate and the advantages of the QCOM Gimbal platform. Beacons only transmit…they do not listen. Beacons can operate in a private mode where the UUID is dynamic and resolvable only within the Gimbal cloud, be public (Static UUIDs) where any application can read them, or registered as iBeacons (see Gimbals as iBeacons).

Apple Patents

In January, the USPTO published a new Apple patent application: Method to send payment data through various air interfaces without compromising user data (see Patently Apple). PCT/US2013/049622. US20140019367

[0002] Devices located in close proximity to each other can communicate directly using proximity technologies such as Near-Field Communications (NFC), Radio Frequency Identifier (RFID), and the like. These protocols can establish wireless communication links between devices quickly and conveniently, without, for example, performing setup and registration of the devices with a network provider. NFC can be used in electronic transactions, e.g., to securely send order and payment information for online purchases from a purchaser's mobile device to a seller's point of sale (POS) device.

[0003]Currently, payment information such as credit card data in mobile devices is sent directly from a secure element (SE) located in a device such as a mobile phone through proximity interfaces, such as near field communications (NFC), without an associated application processor (AP), such as an application program in the device, accessing the payment information. Preventing the AP from accessing the sensitive payment information is necessary because current payment schemes use real payment information (credit card number, expiration date, etc.) that can be used to make purchases through other means, include online and via the phone, and data in the AP can be intercepted and compromised by rogue applications.

[0004] Thus, there exists a need for a secure method of executing a commercial transaction that is both secure and user friendly.

I believe the patent above describes what Apple is going to market with this October. There are several potential payment experiences depending on the merchant integration and the consumer handset. Specifically the patent seems to be written broadly enough where NFC is NOT a requirement for the “secure commercial transaction” referred to as the second secure link. As I stated Payment via BLE/Beacons will Still Happen, the issues are around:

Issuer certification of tokens,
bluetooth as the transport in the new EMVCo spec
who will provide token assurance information and how will they be compensated, and to what degree will interchange be discouneted
Treatment of token in Card Not Present (interchange)
Merchant Adoption of NFC, Beacons and BLE

In the scenario of a new BLE capable point of sale, with a “second secure link” operating as BLE with the POS there is no need for a payment terminal at all.. and all iPhones with Bluetooth could interact directly with the POS (think Micros/Starbucks). Here is my short list of customer experience use cases

Optimal Payment Experience

Here is my best guess and what Apple would like to have happen:

Set up

Consumer has BLE capable phone
Consumer enables Apple wallet and permissions payment with physical merchant
Banks have loaded tokens into Apple wallet for each registered card (see blog)
Merchant installs iBeacons near multi lane checkout, and registers location with apple merchant application. Another option would be to allow payment terminals to broadcast MID/TID beacons.
Merchant installs POS Bluetooth capability to receive consumer identifier and send total amount due, as well as eReciept.
Merchant payment terminals are upgraded to receive tokens through Bluetooth or other “Air Interface”

Experience

Consumer walks up to cash register, beacons determine close proximity and wake up Apple payment application,
Consumer preferences are checked and approved merchants receive apple identifier, consumer loyalty card information, applicable discounts/coupons to the point of sale
Merchant scans goods for purchase and processes loyalty, coupon, discount information
Merchant POS (or payment terminal) sends total amount due to consumer phone directly via BLE based upon apple identifier
Consumer receives notice on phone “Pay $100 to Merchant? Please confirm with fingerprint”
Consumer validates transaction with fingerprint biometric
Phone submits Card token to Payment Terminal via Bluetooth (not happening in October.. it will be NFC)
Merchant processor routes token to payment network which translates and routes to bank for authorization
Payment is authorized (as happens today).

October Launch Experience

Since Banks won’t support tokens over Bluetooth, Apple is stuck with NFC. The process is very similar to above, but my guess is that merchants will not be prepared to support the exchange of consumer information.. so it is iBeacon plus NFC only.

Consumer walks up to cash register, a payment terminal beacon provides information to Apple payment application that it is close proximity to payment terminal ID xxxxx (TID),
Merchant scans goods for purchase. No mobile processing of loyalty, coupon, discount information
Merchant payment terminal cannot send total amount due since it does not have Apple handset information/UUID. So how will Apple do it? My guess is Apple will provide UUID to the Payment Terminal via BLE at application wake up to perform a “lite” checkin with payment terminal. Good news is that there would be no data connectivity requirements, but it requires a new payment terminal… For everyone else.. there is no total amount due (99% at launch).
Legacy NFC. At application wake up, phone asks “pay merchant with Apple wallet”?
Consumer validates transaction with fingerprint biometric
Consumer taps phone (NFC) and Card token presented Payment Terminal via NFC Merchant processor routes token to payment network which translates and routes to bank for authorization
Payment is authorized (as happens today).

Apple’s biggest challenges?

Merchant NFC adoption. Much of it is caught up in the fact that there are no debit cards in the mobile wallets (see blog Forces against NFC)
Merchant adoption of Beacons and new payment terminals. No wonder Verifone is excited.. big merchants know this can all work without ANY payment terminal.. this is the big leap. The decision on payment terminal is now just nuts. EMV, EMV+PIN, EMV + PIN + BEACON, EMV+ PIN + BEACON + BLE…
No business case for Apple in payments. Perhaps one of the reasons they are struggling to get an exec to lead this over there. Apple’s product people should ensure that their Treasury guys aren’t going to kill this thing. Banks know if consumers can’t choose their payment product that wallets will die. Apple should be focused on getting every single one of their 800M cards on file into the wallet, and ensuring the debit cards are added. This is key to making this work
Organizational. No one leading
Bank certification of Tokens in a Bluetooth transfer
Token assurance information
Merchant POS integration (see the optimal example above)

That is how I see it… comments welcome

Another good article on the overall Beacon/Retail Experience.

http://www.pcmag.com/article2/0,2817,2425052,00.asp

Secure Element, NFC, HCE, EMV, Tokens and Cards

7 May 2014

This blog is for my non-techie, non payment friends.. helping to make sense of all these acronyms.. experts may want to pass on this one.

The GSMA/NFC community is quite stirred up at the moment. This is quite understandable… after all they spent 8 years perfecting their vision of NFC only to have it thrown under the bus by Apple and Google. I’m not knowledgeable enough to go into the depths of the protocol, or EMVco 4.3 Book 3. I’m giving the quasi technical business explanation of what is going on. There is room for disagreement here, as there is substantial interpretation, as well as understanding of what is REALLY happening vs the specifications. Remember this is not my day job… so your comments/corrections are welcome. By far the most useful reference/summary page I have found online is located here http://www.nfc.cc/2012/04/02/android-app-reads-paypass-and-paywave-creditcards/

It’s easiest for me to explain all of this in the context of an example. Credit cards are the easiest example as they are in the market today, with a few different implementations of contactless and touch the areas above.

EMV

EMVco has a contactless specification which I challenge any non-techie to read. For this short blog, the key point I wanted to make is that the Credit card number (PAN) is given to the POS unencrypted, in the clear. That’s right… don’t believe me? See:

Analysis from viaForensics.
Forbes Article on cloning of RFID creditcards
And a detailed Tutorial from this Blog
Great Overview from CryptoMathic

Your next question is probably “Where is the security?” the answer is that that along with the card information, the device sends a cryptogram that is uniquely signed. In other words there is a digital payload that rides along with this credit card primary account number (PAN). This digital payload uniquely identifies the device that EMULATED THE CARD. Think about is as someone validating your SIGNATURE on the document with your social security number on it… Your number is there.. but they make sure it is you by validating the signature.

So why is the SIMAlliance extolling the virtues of a Trusted Execution Environment (TEE) and SIM/UICC? After all we seem to live without this capability quite well in the PC world. Mobile operators want the ability to SIGN and AUTHORIZE more than access to mobile towers. That SIM card in your GSM phone signs and authorizes access to the mobile network, much as MNOs envisioned doing for payments. That is how the GSMA’s version of NFC evolved.. “hey we do this for network access.. lets do it for payments”. To be clear there is nothing technically wrong with the GSMA NFC approach.. it is beautiful… but there are substantial business model issues (see Payments part of the OS).

Apple and Google are both moving aggressively to act as Commerce Orchestrators as handsets become commodities and data moves to cloud, enabling the mobile phone to be the key services platform at the confluence of the virtual and physical world is critical. It is not about payment. Authentication is core to this orchestration role.. authentication is not something that can be given away to MNOs or to Banks.

TOKENS

It makes most sense to jump to TOKENS now. You can imagine that Banks don’t exactly like having their card numbers sent in the clear. In fairness they were involved in the specification, but the EMVCo contactless model is essentially a card number plus authentication. There is more than one way to achieve this, and improve on it by hiding the PAN… this is what tokens are (a few examples described in Money 2020: Tokens and Networks, Apple’s Plans and Google/TXVIA).

Tokens are not new (see Tokens… 10 Approaches). However Tokens are now an official EMVCo specification as of March 2014, with the major issue of Token Assurance outstanding. In this token model, the issuer chooses at Token Service Provider (or does it themselves) and creates a number to replace the PAN. This takes your PAN out of the open… and makes it useless. To be used the Token must be presented by the right party, with the right assurance information. All of this aligns VERY WELL to how banks and networks work today, which is why it is so popular (see blog on HCE). In the GSMA NFC model, the a cryptogram goes along with a PAN in the clear with the PAN stored in the phone in a secure element. In the token/HCE model a Token representing the card is stored in a less secure space, and presented with device and network information for translation by the TSP to the actual PAN. There are substantial Business Implications of Payment Tokens (blog) which I won’t go through again here, but clearly it cuts the mobile operator out of the “signing” role and they become dumb pipes.

My Gemalto friends will howl at how unsecure this is, or how it won’t work if the device has no network access. They are wrong. It is working today, and is secure enough. There is no connectivity requirement, that software token in the phone can change every 10 seconds, 10 minutes or 10 days. The TSP and Issuer can decide whether or not to accept an “old” token based upon the transaction. In other words the intelligence sits IN THE NETWORK.. NOT IN THE PHONE. This is why V/MA/AMEX love it so much. It cements their position (See Perfect Authentication… A Nightmare for Banks?)

Host Card Emulation

emvco token

This is an Android construct (see Software Secure Element – HCE Breaks the MNO NFC Lock) that allows any application to access the NFC Radio. Without Tokens, HCE would be useless for payments, as payment information can’t be securely maintained without an SE. Think of HCE as dependent on tokens, now a card emulation application can be certified to run outside the secure element. I don’t like to put Apple in the HCE boat, as they have a proprietary secure architecture using tokens. This is a uniquely apple construct where the networks seem to have certified Apple’s card emulation application(s) as well. It is important to note that they use none of the GSMA’s architecture (to my knowledge) and have embedded the TEE in the apple processor (see Apple Insiders note on Secure Enclave and Authentication in Value Nets).

Secure Element

Is it needed? Certainly it is needed for at least 2 functions: Mobile network access (SIM/UICC) and Biometrics. Fingers and Eyes are very hard to reissue.. so the actual information must be highly protected. Apple is handling biometrics in the A7 Secure Enclave (oddly enough has the same “SE” acronym) and Google is a tad bit behind but handling in ARM’s trustzone. Trust zone is largely a hardware construct, and much is made of Gemalto’s marketing announcement here. My view is that there are many more than on software solution for ARM.. and ARM is much more tied to Google and OEMs than Gemalto.

The “big news” here is that both Google and Apple are EMBEDDING SEs in their hardware architecture. Embedded SEs are a threat to Mobile Operators and their preferred Single Wire Protocol architecture. As you can imagine, an embedded SE has all the capabilities of the SE within that micro-SIM card.. and sets up the prospect for a Virtualized SIM (no more of those GSM cards popping into your phone). If the SIM can be virtualized you can switch your network provider anytime you want.. or have them bid for your phone call ( see Carriers as dumb pipes? , Who do you Trust?, Also see Apples patents on Virtualized SIM). To be clear, I believe MNOs can take a leadership position in Emerging markets and payments, but for POS Payments in OECD 20 markets it makes most sense for them to focus on the $5B KYC/Authentication/Fraud opportunity (NOT payments).

OK… now you can shoot me… Open to feedback.

Apple… Payment via BLE/Beacons will still happen (but when is issue)

2 May 2014

Many great blog comments. Let me go through some generic questions/answers.

Apple wants BLE/Beacons/Tokens… but will not release wallet with this capability for following reasons (my best guess):

Issuers must approve Token/Beacon model: creation/provisioning of token (TSP), use of tokens (not eCommerce), and assurance information. This was the reason behind my Assurance Blog this week.
Apple is keeping the Banks in the dark to protect information on the launch (probably a good idea).
Similarly merchants are being kept in the dark, no coordinated acceptance infrastructure. Thus iBeacons will likely be a phase 2 (or limited phase 1).
Politics/negotiations/existing agreements. My guess is that Apple does want revenue from this new product, but will be disappointed. There is no economic model for a wallet provider in a card present transaction. This has been one of the reasons why NFC/Provisioning has failed, and the credit card only model.
Payment is NOT the focus of Apple’s new services and Hardware.. (see blog Apple Greatest Asset – Ability to Change Consumer Behavior)

What makes most obvious sense for Apple in Payments?

In a perfect world Apple would convert all 600M cards to tokens and leverage this both for iBeacon/POS presentment AND for eCommerce. I believe this was their initial plan.. and still their plan. My view is that all eCommerce merchants and wallet providers would be glad to let the networks exchange COF for tokens.. a few of the big ones are my clients. Lets just say the network’s message “you have to work with EACH issuer on card present pricing, value proposition and data”. Yep it is that bad.

As you can imagine Issuers want revenue, credit card usage is incremental revenue.. Everything else in the iBeacon/token model above is a LOSS, thus Issuers are not exactly running to support. Thus token business issues abound for: debit, eCommerce, wallets, data, control, acceptance, …etc.

For example, Banks hate the idea of losing card not present (CNP) rates for eCommerce and having the networks locked into the TSP role. So Apple must keep a token in the phone, and also keep the 600M cards on file until the payment networks can get the cojones to define standards around assurance, tokens in eCommerce, and force issuer acceptance of risk and card present rates. Issuers have a strong case for caution, as Networks did this before (eCommerce/CNP liability shift) and failed miserably (see my blog vbv/msc Failure, and Bruce Schnieier’s similar post).

Data, data, data. My belief is that Apple is taking on the role of consumer champion (see blog Apple’s Platform Strategy: Consumer Champion). Apple may not realize that the this new architecture meaningfully impacts both bank and merchant data services. Merchants and processors will no longer have insight into the consumer card number, which in many cases is used for analytics and loyalty.

Issues/Unknowns

Durbin/Hybrid Card. Per rule you can NOT wrap a debit card with a credit card. The card type must also be know to the merchant. If the Apple wallet has only one card per network, and consumer can store a debit card.. then that card must be a debit card. Perhaps Apple doesn’t know this, or the implications. Someone is pulling a fast one.. the networks certainly know this rule, and undoubtedly will feign ignorance when consumers try to register their debit cards… only to find out later that they can’t be used.
Acceptance. If Apple launches with credit card only they will have failed to deliver any merchant benefit, or act as consumer champion. Similarly merchants (ex MCX consortium) will have little case for adding contactless acceptance if they don’t know the card/cost or everything is a credit.
Process for taking the 600M cards on file and auto registering them with the networks. This could be going on now, with the networks building an issuer interface for approval.
Tokens. Apple really wants to make this happen, but only Amex and Paypal are in a position to support. My recommendation to Apple would be to get moving with tokens and Amex… as a lever to make V/MA networks get moving.
Pilot Merchants. Beyond the Apple store, I would pick Macy’s, Nordstrom, American Eagle, Gap, and a few others out as the most innovative in payments.. and the most likely pilot customers for a iBeacon shopping and checkout experience. Keep your eyes peeled.
Will Apple move forward with an iBeacon breakout without network/issuer support? This would make sense in the US, where contactless adoption is terrible. Apple certainly has the expertise (and cash) to go strong on iBeacons, go around the networks and treat as CNP transaction (owning the fraud/risk) and manage the fraud internally. The could do this in select retailers (in US), and focus EMV Contactless capability outside the US.

I believe Apple didn’t put NFC in the 5s because they thought that they could launch Beacons without the Network’s support. When launched all iPhones will be able to take advantage (only BLE H/W dependency).

Token Assurance – Updated

28 April

The most interesting aspect of the new EMVCo Token Specification is section 6 – Token Assurance ID&V Methods.

Technical

Tokens must be combined with a form of identity to be useful. The specification outlines a rather ambiguous set of placeholders

Account verification
Token Service Provider risk score
Token Service Provider risk score with Token Requestor data
Card Issuer authentication of the Cardholder (ie PIN)

Real world examples would be Apple’s score on your fingerprint biometrics (ex 95% match), or Payfone’s device ID information on the phone you are using. Actually, just about any entity could provide this data to the issuer (with issuer agreement). Per the specification

ID&V steps may be performed by the Token Service Provider, the Token Requestor, or a third party. In instances where the ID&V steps are performed by an entity other than the Token Service Provider, verifiable evidence SHALL be provided to prove that the steps were performed and the resulting outcomes were provided. Verifiable evidence may consist of any value provided to the Token Service Provider by the ID&V processing entity that the Token Service Provider may validate. The details of what constitutes verifiable evidence are outside the scope of this specification, but examples include a cryptogram or an authorisation code

In the GSMA NFC world, a card is “provisioned” to the phone through the TSM. In the token world a card is provisioned as a token to a phone by the Token Service Provider (big issuers will do this internally, V/MA will also offer services). If the card (or token) is presented to the merchant via NFC protocol it is operating within the contactless/EMV pricing. If the card (or token) is presented to the merchant via an iBeacon or QR code then it falls into some unknown TBD pricing.

Business issues

Problem becomes who will pay for great ID&V “Assurance”. For example, Apple could provide biometrics.. but shouldn’t the banks pay for Apple’s score (see Blog Authentication in Value Nets)?

Let me extend the example further. Today Banks are working to extend their mobile applications to add payment capability through HCE (on Android). Who is the TSP? Answer it is the banks themselves… they generate the tokens and their own Assurance information. Who will deliver “tokens” to Apple? There are only 2 entities that can map tokens to cards: Issuers or Networks (acting as TSP).. wallets can’t do it.

Thus there are 3 ways a payment instrument can be added/stored/provisioned in a phone/cloud/device

Consumer enters card number (Google, Apple, Amazon, Paypal, …). Benefit, consumer chooses any card they want. Downside CNP rates
GSMA/TSM. Provisioned by Card. Only issuers that provision cards.
Tokens. Provision token. Only issuers/TSPs can provision tokens

There are also different mechanisms for card Use/Presentment

eCommerce (buying iTunes/App store, Amazon, …)
EMV/Card Emulation
Token Presentment (iBeacon, QR, eCommerce Token Presentment)
…

My view is that there are only 2 areas where tokens will move in next 12 months:

Banks are focused on enabling Apple to use tokens later this year (in iBeacon model), so cards will exist in token form both within the Bank mobile application (Android HCE) and
Apple’s wallet (IOS) in Beacons + NFC/Card Emulation

Looks like everyone else will be stuck with the “old” NFC/TSM model for quite some time.

Apple

For Apple to receive Card Present rates in a iBeacon model, they must provide information as a TSP to create a high assurance level. Here is the REAL ISSUE. WHO DECIDES what degree of assurance equals card present rates. Right now only the ISSUER can make this call. Worst of all… the merchant will have NO IDEA of what the cost is. That’s right, Apple must negotiate with each and every issuer not only on ID&V data exchange, but also on the rate. The token specification outlined how the data must flow, but not how the pricing will work. I sure hope Apple is pushing for pricing MUCH better than listed card present rates. Fantastic authentication should lead to risk based pricing. My recommendation to Apple (beyond call Starpoint), is to price in a way that merchant sees card present rates and you are paid for risk reduction. This aligns everyone to reduce risk.

Banks are focused on Apple because: #1 Apple can move the needle in adoption, #2 Increase use of cards in iBeacon model, #3 Apple is dumb container for card and not as concerned about capturing data. Banks may work to restrict Apple’s ability to use tokens in an NFC contactless transaction only. One of my top questions is HOW will apple present these tokens in an EMV contactless scenario? There is no work being done on card provisioning with issuers… so how are the tokens getting into their phone? Will Apple convert their 600M cards on file to tokens? Will the networks work to simplify and “on ramp” issuers without their technical involvement? This could be a brilliant move, as nothing is more broken about the NFC/TSM model than working with 10,000 bank issuers individually to provision cards.

I hear nothing on Apple Tokens + Beacons. Which means Apple Payment launch is EMV Contactless only (but in a uniquely Apple Way with fingerprint). If Apple is working in an EMV contactless model ONLY, did they certify an application? Who holds the encryption keys if cards are not provisioned by the issuer? the network? (my guess) If this is the case, what do card issuers think about the networks managing their keys?

Google

Today Google wallet (POS) wraps all other payment products in a Bankcorp (TBBK) Mastercard. Google is issuer so they provisioned the card (with a few exceptions in Citi/Barclays, …). It is the ONLY wallet where a consumer can load any payment card they want to. Today Google gets card present rates (for the TBBK Debit Mastercard) as they present cards within EMV contactless/card emulation rules. If they switch to tokens, what merchant pricing applies? If merchant accepts card via EMV contactless, contactless rates apply, but what if token rates are “better”? Can Google arbitrage? What if presentment could be based upon merchant preferences? Present token if you have a lower rate (via via QR code or “Beacon”) otherwise present card via NFC/EMV for card present.

I’m getting a headache!! Can you imagine Google would have to store cards/tokens by issuer/presentment mechanism, with different assurance data and provisioning for each. Some cards are provisioned via TSM, others via token, others entered by consumer, cards used for eCommerce on Google store could be tokens, cards used in Chrome autofill would be PANs, cards presented via NFC would be encrypted PANs, cards presented via BLE would be tokens..

In the token model, what is incentive for Google to deliver Assurance data? What is merchant incentive to accept? Today Google can allow the consumer to use any card.. in a token world they have no control over which cards can be provisioned/stored, nor the rate the merchant will pay. Someone please draw me a picture of options…

Assurance Business Model

Can you imagine playing football where the opposing team also staffs the referee positions and can change the length of the chain whenever they want? The token specification is a very, very solid document. But the business model is a little crazy. The only place where it will see short term traction:

Issuer’s own mobile application
eCommerce (where Apple/Google/Amazon/Paypal directly benefit from CP rates)
Apple (if they negotiate agreements well)

End result – No POS Merchant Adoption

Obviously, if merchants have no idea of the cost of a payment product.. they will not accept it. I couldn’t imagine anything worse than the ISIS NFC wallet… but a token at a card not present rate could fit the bill. Now you see the reason behind MCX…

eCommerce Merchants DO have a reason to jump on tokenization. As they will benefit from risk based pricing.

Thoughts appreciated.

Apple’s iPhone 6: GSMA’s NFC thrown “Under the Bus”

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.

Apple’s Platform Strategy: Consumer Champion

I’m trying to read the tea leaves on Apple and it seems they have devised a unique.. brilliant platform strategy around securing consumer data. I think of it as the anti-Google strategy. As we see so much commonality between the functionality of IOS and Android.. along with the associated legal wrestling, what could Apple do that would be something Google never could?

Per my previous blog Apple and Physical Commerce, Apple has an unmatched level of trust with the consumer, and ability to change consumer behavior. I also outlined how Apple is completely reworking the role of authentication in the platform (see this great article from Networked World), this work, combined with Apple’s efforts to limit ad tracking are frustrating advertisers (see Tech times ). But there is hidden genius in all of these mechanizations. Apple seems to be making a bet that there will be a tsunami of coming issues with privacy and anonymity. In this they are turning themselves into the ultimate consumer protector… both online and in the physical world. They are the gatekeeper… the only entity that can know what a consumer is doing.

How can they monetize this role? In hardware sales… Don’t look at them as an ad business.. (although they could build it later).. but right now protecting your consumer from data leakage and loss is a VERY big competitive differentiator, a feature that is particularly well aligned to Apple’s demographic. It is also a very hard one for Google/Android to match.

Thoughts?

Authentication – In “Value” Nets

March 3, 2014

Today’s blog brings together: the Role of Authentication in Value Orchestration, Apple’s Role in Commerce, Constructs for Compensating Authentication Agents, and Ability of Payment Networks to Adapt. The ability of other parties to assume risk in payment is the key shortcoming of all of our existing payment systems (see last week’s Blog). The recent activities around tokens can best be explained through this Risk Lens.

My use case for today: Assume Apple has the best biometrics system on the planet, and Consumers trust Apple with all their credentials. How can non-Apple Service Providers use Apple’s Authentication service (pay them)? As I outlined in Who do you Trust (Sept 2013)

The “KEY” [prerequisite] in value orchestration is owning the Consumer relationship. Therefore Identifying and Authenticating the Consumer is the first, primary, service that must be owned by a platform. What was a separate “Trusted Services Manager” in the NFC world has been co-opted by platforms which will take a proprietary route.

This goes hand in hand with my other favorite payment quote from Ross Anderson with respect to payments:

If you solve for Authentication.. Everything else is just accounting

The Role of Payments in Commerce

As I’ve stated before payment is just the last (easiest) phase of a long commerce process that involves design, manufacturing, marketing, advertising, retail, payment, …etc. (see Payment enabled CRM). Payment is the key PROCESS by which these parties measure the effectiveness of their activities (think attribution). To measure effectiveness (and value) participants tie their activity to Consumer and: items, activities, processes, and behaviors. Answering questions like “did the consumer see our ad on facebook?”, “did our campaign influence the consumer’s buying behavior”?

Before we can assess the value of Apple’s Authentication we need to identify the processes and participants that can use the service. My bias is that the greater value to be unlocked is around the attribution than payment (as a side note Apple has constructed a new platform to manage an Advertising Identifier around this “identity arbitrage”). My personal bets are around the hypothesis (outlined in Apple and Commerce): that Apple’s biggest asset is their ability to change consumer behavior, and are working to make the iPhone the centerpiece of physical commerce (not payment). However, since I have no interest in writing a novel on the subject, I’ll give my highly condensed views on authentication in today’s payment instruments.

Value of Authentication in Payments

What is value of authentication in payments? To whom does the value accrue? We should not assume payment methods will change in anything shorter than a 20 yr horizon (analysis of value in existing payment networks). The value flow in a 4 party payment network is fairly simple: Merchant pays with the Issuer receiving 80% of the revenue. Any payment for Authentication must therefore come as “cost” to the issuing bank. There are 5 models for extracting authentication fees from Banks:

Bank chooses to pay (or exchange something of value … like data)
Network forces payment
Authentication provider forces payment
Consumers force payment, or Choose to pay themselves
Regulators force payment

Optimally a service cost would be based upon value (if the value declines … the cost should decline). Of course nothing in payments work this logically. Issuers like to have all the control, so that they can retain all the margin. In fact, Top Issuers would be fine keeping mag stripe with no authentication (see Perfect Auth… a Nightmare to Banks). Perfect authentication would eliminate all risks not credit related (ex ability to pay). It would therefore be very hard for Banks to justify any payment fees (interchange) beyond the cost of operation. Banks make their money on the ability to manage risk (not eliminating it). Mobile Authentication (biometrics) provides a mechanism to reduce risk outside of the bank’s services.

Startups.. this is the challenge in selling banks improved risk management or identity solutions that are not in their control. It is also why Banks want their services manifested through applications they control (not others). However, Banks must live in a world where their payment product does live outside of their environment (not that they like it, but Amazon does have a little potential to sell :-)).

A recent example of external network driven services: Verified by Visa (VBV) and Mastercard Secure Code (MSC). VBV/MSC rolled out in 2003 (Europe) and shifted eCommerce CNP risk to Banks. It was a complete and utter failure, not just from a tech view but also from a customer experience and business model. Merchants were incented to put the technology in place (10bps and fraud shift to Banks). VBV/MSC failed to catch the fraud… who was motivated to fix the flaws? Not the merchants.. they had given the fraud loss to the Banks and received a discount. It was rather the Banks, which were left with declines as their only tool (as I outlined in Perfect Authentication – A Nightmare for Banks). In other words, Banks had no way to pay the merchant to do a great job at managing risk in VBV/MSC, but only penalize a merchant for poor performance (through declines). This is why we don’t see VBV or MSC running in Amazon, Apple, Paypal, … etc.. Merchants fear declines much more than they do managing the fraud.

But how do a Banks pay external parties (ex Experian, EWS, …) for assisting in the risk management of payments? Usually a per transaction fee of $2-$5 in account opening, and then 10bps for transaction risk scoring (think check verification, although not all transactions need to be scored). The Networks themselves offer services for authentication and account management.

Authentication Fee Structures

Issuer Controlled

Interchange Rate Reduction ~15-30 bps based upon performance
Fraud Shift (for CNP + Auth in eCommerce)
Data Sharing (quid pro quo)

Network Controlled

New Category – Mobile Card Present with Authentication (30bps below current)
Network Enhancement Fee – Charged to Issuer (for Token and for Auth)

Platform Controlled

Authentication Fee (Nothing gets passed to Issuer unless they choose to use service)
Network support of new field(s) for Authentication information

My preference (for Authentication) would be for last item in the list, where Apple and Google assess an authentication fee to Banks which choose to leverage Authentication. This allows for performance based pricing. If the service is not providing benefit to the Banks, it is stopped. Issuers which invest in using the service will receive benefits that can be passed to consumer.

Oddly enough the danger in this approach is for Visa and Mastercard. As Issuers work with Google and Apple directly, it provides them an opportunity to end-run V/MA and define their own rules for CP/CNP, as well as Tokenize their existing portfolio and gain access to data.

Mobile Auth and Payments – Today

The scenario on biometrics and tokens is happening today… Apple’s new iPhone will have both biometrics, a secure enclave, and patented Point of Sale Interaction. Host Card Emulation has evolved so quickly because Banks were told by Apple that they would have to pay for their cards operating within Apple’s scheme. As I outlined in Token Acceleration, the Banks responded by telling V/MA “we are not going to let our Cards operate under an Apple Patent… you guys killed our TCH project and said you would own this… so are you owning it or not?” Hence we have this Press Release.

The networks are committing a fair amount of brain power here. Clearly the benefits and control of a token led scheme will flow quickly to issuers unless there is a solid process to lock up the token standards and token translation. For example, assuming V/MA certify an HCE scheme that provides for “transparent” EMV compliant Paypass transaction.

This is why NO ONE has seen the token spec… and why it is not evolving as quickly as hoped. Not only must V/MA/Amex make the Spec functional, they must also work to control the token creation, authentication and routing rules. Arrggghhh…

Big Picture Thought

What we REALLY need is a payment network where risk and data can be owned by non-banks (selectively). This was my input to the Federal Reserve, and the driver behind last week’s post Risk: Carving it up in Payments. Real time payments is not holding up innovation, the ability to take risk and manage it is (just as it is in our economy). While I believe Ross Anderson’ view that Authentication is the key to value, the dumb pipes are all owned by non-aligned Banks.

What if American Express created a new payment network that allowed for merchants to selectively own risk for clearing? In this model, Amex could operate as charge card, Bank, prepaid card, or link to another banked account. Merchants could assume risk depending on consumer history, payment type, purchase type, reputation, … Some merchants would choose to allow the consumer to decide. Others (like Grocery and WalMart) would encourage the consumer to choose the lowest cost instrument (selective settlement risk), or even change their relationship (banking, data sharing, … ).

If the value of authentication and the value of “payment” is not in settlement and risk but in the attribution, then we must have much more flexibility and consumer participation.What will glue together these new Value Nets?

Token Acceleration

20 Feb 2014

Let me state up front this blog is far too short, and I’m leaving far too much out. Token strategies are moving at light speed… never in the history of man has a new card present scheme developed so quickly (4-6 MONTHS, see announcement yesterday). As I tweeted yesterday, the payment industry is seldomly driven by logic, and much more by politics. Given many of my friends (you) make investments in this industry, and EVERY BUSINESS conducts commerce and payments, movements here have very broad implications. The objective of this blog is to give insight into these moves so we can all make best use of our time (and money). I was flattered at Money 2020 when a number of you came up and told me that this blog was the best “inside baseball” view on payments. Perhaps the only thing that makes our Starpoint Team unique is that we have a view on payments from multiple perspectives: Bank, Network, Merchant, Online, Wallet, MSB, Processor, … etc.

It’s hard to believe I’ve already written 12 blogs on tokens… more than one per month in last year. As I outlined in December there are (at least) 10 different token initiatives (see blog). Why all the energy around tokens? Perhaps my first blog on Tokens answered this best… a battle for the Consumer Directory. It is the battle to place a number in the phone/cloud that ties a customer to content and services (and Cards). The DIRECTORY is the Key service of ANY network strategy (see Network Strategy and Openness). For example, with TCH Tokens Banks were hoping to circumvent V/MA… (see blog). The problem with this Bank led scheme (see blog): NO VALUE to consumer, wallet provider or merchant. It was all about bank control. The optimal TCH test dummy was almost certainly Google, and the “benefit pitched” was that Regulators were going to MANDATE tokens, so come on board now and you can be the first.

Obviously this did NOT happen (perhaps because of my token blog – LOL), but the prospect of a regulatory push was the reason for my energy in responding to the Feds call for comments on payments. In addition to the failure of a regulatory push, the networks all got together to say no Tokens on my Rails (see blog). Obviously without network rail allowance, a new token scheme would have to tackle acquiring, at least for every bank but JPM/CPT (see blog). Paul Gallant spent 3 yrs pushing this scheme uphill and had no choice but to look for greener pastures as the CEO of Verifone (Congrats Paul).

In the background of this token effort is EMV. I’m fortunate to work at the CEO level in many of the top banks and can tell you with certainty that US Banks were not in support of Visa’s EMV announcement last year. One CEO told me “Tom I found out about EMV the way you did, in a PRESS RELEASE, and I’m their [Top 5] largest issuer in the world”. Banks were, and still are, FUMING. US Banks had planned to “skip” EMV (see blog EMV impacts Mobile Payments). The networks are public companies now, and large issuers are not in control of rules (at least in ways they were before). Another point… in the US EMV IS NOT A REQUIREMENT A MANDATE OR A REGULATORY INITIATIVE. It is a change in terms between: Networks and Issuers, and Networks and Acquirers, and Acquirers and Merchants (with carrots and sticks).

In addition to all of this, there were also tracks on NFC/ISIS (which all banks have walked away from in the US), Google Wallet (See Don’t wrap me), MCX, Durbin, and the implosion of US Retail Banking.

You can see why payment strategy is so dynamic and this area is sooooo hard to keep track of. Seemingly Obvious ideas like the COIN card, are brilliant in their simplicity and ability to deliver value in a network/regulatory muck. This MUCK is precisely why retailers are working

Payment Value

to form their own payment network (MCX), retailers and MNOs are taking roles in Retail banking, and why Amex has so much more flexibility (and potential growth).

Key Message for Today.

With respect to Tokens, HCE moves are not the end. While Networks have jumped on this wagon because of HCE’s amazing potential to increase their network CONTROL, Banks now have the opportunity to work DIRECTLY with holders of CARDS on File to tokenize INDEPENDENT of the Networks.

Example, if JPM told PayPal or Apple we will give you:

an x% interchange reduction
Treat as Card Present, and own fraud (can not certify unless acquirer)
Access to DATA as permissioned by consumer
Share fraudulent account/closed account activity with you to sync

If you:

Tokenize (dynamically) every one of our JPM cards on file
Pass authentication information
Collaborate on Fraud

This is MUCH stronger business case for participation than V/MA can create (Visa can not discount interchange, or give access to data).

This means that smaller banks will go into the V/MA HCE schemes and larger banks, private label cards, … will DIY Tokens, or work with SimplyTapp in direct relationship with key COF holders.

Sorry for the short blog. Hope it was useful