Token update – TCH + 2 Big Banks and Paypal

I’ve been writing about this token stuff for over 5 yrs. Wow.. This is an update to my June 2013 blog – Tokens: any volunteers ,  SRC- W3C and Tokens and the Trojan Horse.

First my bias.. I may be naive.. but as I stated in Tokens and the Trojan Horse

Visa and Mastercard provide a level playing field for Issuers and Merchants (with few exceptions). Per my blog Payments Civil War, V/MA are a fantastic creation that have experienced profound success (and growth). As I outlined in the Changing Economics of Payments, the beauty of the V/MA model is that it creates incentives for millions of businesses to invest billions of dollars. For investors, the attraction of V/MA is that it is scale free.. with minimal effort required to add volume. While there are MANY more logical ways to deliver payments.. there are none with more profitable incentives for investment.

Tokens are an enormously powerful control point for the payment networks. 9 years ago the banks were working to “build a new Visa” within an initiative launched by The Clearing House. The idea was to create a new scheme that “wrapped” account numbers with another number (token) and avoid network routing (see wrapping). The networks smartly came down and issued clear guidance, if you wrap my card number with another number …. It is still a Mastercard/Visa.

TCH has been seeking a partner for tokenization since Paul Gallant led the 27 bank consortium 8 yrs ago.  Can you imagine the sales pitch (as I reviewed in the Trojan horse) “give me all of your customer information, I will lock it up.. and give you one of my keys for you to access it”. Google, Apple and Amazon have all smartly said no. What is the remaining “big” eCommerce Cards on File (COF) home? You guessed it PayPal.

While I’m not 100% sure about this.. it is the only group left AND two of these banks told me this week “Paypal is the only one that can move merchants effectively”. I was shocked … paypal can move merchants more than Google? They responded “Google has the best technology, but they just can’t sell merchant more than adwords”.. wow.

Thus my best guess is that 2 of the top banks are working with Paypal as the processor/gateway  to move “W3C” in the direction of the TCH tokenization service. The head of the W3C WG wrote me on twitter

Quite frankly my head is spinning. W3C is a browser standard.. how can Paypal get their TCH tokens in? I haven’t figured this out yet, but what I do know is that the complexity is enormous. We have 3 different token services

  • Visa VTS/MA MDES (Apple is primary customer)
  • Google (see Blog) – had no choice but to develop a new custom “standard” by which the encrypted FPAN flows to the merchant acquirer
  • TCH – Paypal + ??

And also multiple new eCom standards

To read what is happening you must therefore take a matrix view.  Obviously Google is moving with their own token service and W3C. Paypal seems to be moving with TCH and W3C.  Apple with network tokenization and ApplePay.

My head is spinning. I must say I did buy Paypal stock this week. I’m just floored that top tier issuers are innovating with Paypal.. focus, partnerships and execution are moving them into the bank friendly category.

Chase Net 2017

Its tough to find time to Blog as a CEO…. Most of you my blogs are sometimes snarky and tactless (making NOT offending someone a new consideration).

I was taking a look at JPMC’s latest investor presentation and noticed that ChaseNet is gone.. Why? I’ve written on JPMC and ChaseNet a number of times over last 6 yrs. Today I’ll cover my views on the latest developments and my views on JPMC’s ChaseNet strategy. Lets recap first: Continue reading “Chase Net 2017”

Can I see your ID?

credit_card_transaction_paul_burns18 March 2015

 

A major retailer just called me this AM. Theme of conversation is that the industry is creating a “perfect storm” for issuers in acceptance.  While LoopPay is very secure (because of Visa/MA tokens, phone ID, and transaction counters), the existence of a commercial grade mag stripe emulator in the hands of “bad guys” will create a little chaos… particularly when the cashiers think nothing of consumers (or fraudsters) waving their phones at the POS.

While both Visa and Mastercard have set rules that prohibit merchants for asking for IDs in a contactless EMV transaction (EMV), LoopPay (Samsung calls it MST) muddies the waters as it uses the phone to talk to the magnetic reader of the payment terminal. MST transactions are magstripe transactions which merchants are (and have always been) allowed to ask for IDs. Merchants can make the case that they have no idea which is which, and they have no way of “prohibiting” either, thus they must assume that it requires them to treat as something that requires them to validate (signature).

Let me see if I can list the different acceptance methods (looking for input into what I miss)

Acceptance Options

 

Add to this list Token authority (Tier 1, Tier 2, Visa, Mastercard, TCH, Bank, …) and TSM for GSM style NFC and we have quite a complex mess. The good news is that issuers have control over where their cards are presented.. Problem is that there are many new “exploits” which can be attacked by very well funded fraudsters.

Normally, all of this seems to put pressure to update and lock down your payment terminals. But merchants don’t bear any costs for POS fraud where they have validated signature/ID… it moves to the banks. How can Banks force merchants to lock down terminals? The incentives are very complex.. so complex that it may mean “can I see your ID” happens in every case.  So much for mobile making things easier.

In EMV transactions, issuers are normally in control of when PIN is required.. In mobile  there is no physical payment instrument (card)  for the cashier to validate signature … so when they ask for ID what do they validate against? (ie no embossed card with your name on it). This means issuers will naturally like PIN for mobile. In the US consumers don’t know their PIN (for credit cards)..

This is just too confusing.. lets just say small issuers will have a very challenging time adapting here, while the big issuers will maintain a substantial advantage. This is the normal course of [big] bank fraud strategy:  if a bear comes to your campsite you don’t have to be faster than the bear.. just faster than the slowest fellow camper (small banks)

Samsung Pay Launches Today: LoopPay + NFC + Tokens

1 Mar 2015

———–Update 8pm

It seems that in the US, Samsung plans to create and certify a new software secure element within the ARM Trustzone architecture that precludes the need for SE Keys, avoids US MNO SE Key Ownership issues (that can’t make MNOs happy).

In other countries (China, EU, …) Samsung’s architecture would leverage the traditional NFC approach within the NXP SE (and traditional TSM).

This is a great technical approach, but is doesn’t appear that Samsung has bothered to sell US MNOs on the concept (of going around them). Anything US MNOs subsidize they must approve..  Which means no pre-installation, particularly given the new Google relationship outlined below.

—————-

Brilliant tech and security.. killed in the US by recent Softcard deal

Samsung has just launched its LoopPay plus NFC (plus tokens) with support of top 5 US banks, MA, Visa, Amex, FD. What is it? a mobile payment wallet that works at the POS within Samsung’s new S6. The “new” part is hardware based upon their recent LoopPay acquisition (Samsung calls MST ?Magnetic Secure Transmission?). What does this Loop stuff do? It enables your phone to talk to any payment terminal that accepts a swipe by “emulating” the magnetic field generated as your plastic card’s magnetic stripe goes across the payment terminals’ reader (ie head). This is SUPER cool stuff.. and addresses the key problem impacting ApplePay today: merchant acceptance. In other words a LoopPay enabled phone payment can be accepted anywhere a card swipe is accepted (mag stripe).

Operationally the new payment wallet will combine Loop’s mag stripe emulation plus traditional NFC to work with terminals in either a “swipe” or “tap” mode. If a terminal accepts NFC SamsungPay will detect it and use the more secure NFC, if not it will emulate the magstripe. Technically Samsung has done a super job creating a “secure enclave” equivalent within the ARM TrustZone (and NXP’s PN66T.. having dumped Samsung’s Snapdragon). Samsung may have achieved a coup over  Apple in this new architecture (approval for storing card encryption keys within a new software secure element which will be certified as EMV compliant). This means Samsung doesn’t require the SE keys (in the US) and can also ride on the existing token rails that were created by ApplePay, thereby leveraging the same provisioning process for enabling cards that the networks created in ApplePay. Interestingly neither Samsung nor Google have been able to get the 15bps that Apple got.. showing that banks have learned lessons and that the ApplePay late followers (Samsung)  are now in a weaker position.

The “bad news” is that SamsungPay software is VERY VERY far behind (think Aug/Sept best case), and even if it were ready today it will never be be pre-loaded on ANY phone in the US (given the recent Google/Softcard deal with all 3 major US MNOs). The Google/Softcard deal hit Samsung HARD.. a complete surprise. What does this mean? Complete chaos. SamsungPay Loop requires specialized hardware (MST in S6 Only),  This means that SamsungPay will not work with any existing US handsets (all the SE keys went to Google and old phones don’t have the new ARM TEE with Software SE), applekorea-nov2014-counterpoint

Why would Samsung make this kind of “marketing announcement” without an operational wallet, carrier support and big US holes? Guess is they are feeling the pressure from Apple. The new iPhone is even grabbing over 33% marketshare even in Samsung’s home market (see Reuters article). There are MANY pieces necessary to make a wallet launch work: hardware, new loop acquisition, tokens, certification, bank support, it looks like they have those taken care of.. what is missing? MNO support, SW SE certification and a production ready software wallet.

While I’m rather negative on the prospects for Samsung in the US, I’m very enthused about Samsung’s prospects outside the US by leveraging a traditional NFC architecture plus tokens. As I discussed in Secure Element, NFC, HCE, EMV, Tokens and Cards, tokens plus mobile enabled identity (token assurance information) have enabled software to displace specialize hardware. In this case, a tokenized LoopPay is pure genius.. taking a basic device the tricks the card head into accepting information.. into a card transaction much more secure. I’m not going into the fraud prevention measures, but rest assured “replay attacks” will not be possible.

The purported “mobile acceptance gap” that Samsung’s wallet WOULD address is primarily in the US and due to a lack of merchant terminals that accept NFC. LoopPay addresses this gap through emulating the mag stripe swipe.. The US is where mag stripe swipe remains predominant, and only in a very short term “interim” period before EMV becomes mandatory in October of this year. Thus the market where mag stripe emulation would deliver the most value is the US, yet it is only so for the near term (EMV rollout), with a much delayed software release (September) in an inaccessible MNO environment (per Google/MNO reasons above).

Summary

  • SamsungPay is LoopPay plus NFC plus tokens. There won’t be anything to even trial until late summer, it is a marketing launch only (S6 contains the necessary HW)
  • Google/Softcard/US MNO deal has completely killed hopes for SamsungPay in the US, as MNOs CAN NOT pre-install on any Android phone (including S6).
  • Samsung’s hardware is very innovative, leveraging Arm’s TrustZone to store the EMV keys in a new software secure element within ARM’s TEE. I’d be surprised that the networks have already certified this.
  • Visa/MA and Amex will leverage their existing token infrastructure (from ApplePay).
  • LoopPay is super cool and tokens make is super secure.
  • Banks will be able to provision cards to SamsungPay just the same as the do with ApplePay today. Some banks may want to consider the incremental risks associated with the LoopPay card emulation. It looks like the controls are there, but it is not a card presentment mechanism that many have experience with.
  • Perhaps my biggest news here is something that wasn’t announced. My understanding was that Paypal was part of the launch. Perhaps they want to get a little momentum before pissing off all the banks.
  • My biggest unknowns: software live date, bank rev share, TEE certification for holding card keys (Tier 1 TSP), Paypal, HCE in the US (to by pass the Google’s SE key ownership), how will consumer install on top of (next to) GW and why would they want to?

 

 

 

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:

  1. Physical goods/services in a browser,
  2. Physical goods/services in an app, and
  3. 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.

Custora_MobileShare_Brand_Aug2014_570px2

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 3rd 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.

 

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.assurance

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

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

There are also different mechanisms for card Use/Presentment

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

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

  1. 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
  2. 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.

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.Token schemes

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

Token Activity – 10 Approaches?

11 December 2013

I’m preparing for a few institutional investor chats next week in NYC and thought it was time to update my view on the payment landscape. Summary: much chaos and noise, with existing players throwing sand in everyone else’s gears… lots of energy.. but NO HEAT. This blog contains a brief inventory of initiatives I’m aware of. One of the reasons I do this is to solicit further dialog from blog readers.. so your thoughts are always appreciated. It is very difficult for small companies to identify activities which will impact them.. turns out that most non banks and even Visa and MA are ill informed on some of these as well.

In my June Blog Tokens: Merchant Options, and September blog Money 2020: Tokens and Networks I laid out 5 token initiatives.. we have now almost doubled..

The key differentiation between these Token initiatives is WHERE the translation occurs (Wallet, POS, Processor, Network, Issuer).  Translation is also referred to as DIRECTORY, which I define as the mapping of consumer information to payment information (see blog Battle of Cloud Part 1). The owner of the consumer directory is the winner in all of this, as the value of payment pales in comparison to the value of data and the consumer relationship. This is the core of the token battle

Inventory is for POS payments only. 

Token schemes

  • Form A (TCH Pilot – Processor Translation)
    • Consumer Directory: Bank
    • Token is presented to Merchant at POS (QR code, NFC, Barcode, …)
    • POS forwards token to Merchant processor (ie Elavon)
    • Elavon translates token into card through TCH service
    • TCH can resolve token directly (switch to network), or forward to participating bank for resolution (switch to network)
    • Issuer sends Authorization to Elavon
    • POS settlement
    • Patent issues surrounding merchant processor translation of tokensTCH Scheme
  • Form B – Wallet Translation (Push Payments)
    • Consumer Directory: Wallet
    • Token is presented by Merchant and read by Wallet. Token represents MID, TID, Processor and Amount
    • Merchant POS is awaiting authorization as if a card was swiped
    • Wallet sends token to Issuer (circumventing Visa/MA). Note this is WEAK LINK as data connectivity required for Consumer’s phone at POS
    • Issuer translates token into authorization, sends to processor
    • Processor passes authorization through to TID as if card was swiped
    • SMS based payments done in this model for years. Form of tokens could be beacons, QR, biometrics. Difficult to patent as core for operation is consumer directing bank to make payment.
    • Key differences (globally) are how consumer IDs the merchant and amount, and how does issuer pass the auth
  • Form C (C for Chase with their unique VisaNet deal)
    • Consumer Directory: Bank
    • Token is card number, Presentment is TBD.
    • If Merchant is a CMS merchant, Card routes through JPM’s version of Visa net for offers/incentives (given merchant participation.. of which there is none).
    • If Consumer card is JPM then deliver Card Linked Offers. Again.. not much here.
    • Unique capabilities, but all based upon Visa’s network. Barrier to replication is the unique deal that JPM constructed to “branch” VisaNet
    • JPM Visa flow
  • Form E – EMV/NFC
  • Form G (G for Google’s old Mastercard proxy model)
    • Consumer Directory: Google
    • Token is a card number – Issuer is google (See blog)
    • A plastic version of this was planned in 2012 as reported by Android Police, but was pulled because of high stakes war involving top issuers and Mastercard.
    • Merchant runs transaction as normal
    • Google acts as issuer receives authorization request and routes to selected card (using facilities of TXVIA).
    • After receiving authorization from funding card, google authorizes transaction
    • Issuers make all of the interchange they did before, but don’t like being wrapped. They also don’t like the data leakage and the fact that this impairs their ability to offer unique services (10% off at Kinkos).
    • Note: this scheme has a value proposition for everyone.. and banks still don’t like it… Google loses money on every transaction.
    • Another little known fact is that early versions of GW ran in this model due to limitations within NXP’s chip (only supporting one card emulation app)
    • No Patent issues, few other companies could afford to take a loss on every transaction (buying data). Network rules are the primary issue.
  • Form H – Host Card Emulation  (Google, MA, SimplyTapp) I like – this one
    • Consumer Directory: Issuer
    • HCE Blog
    • Blend of NFC and Form V below. Simplifies the NFC supply chain
    • No dedicated hardware, NFC just another radioExposure: 000 : 00 : 00 . 156 %Accumulated%=0
    • Issuer Creates One time use tokens for EMV key generation
    • Merchant acceptance hurdle CURRENTLY same as NFC
    • Can be leveraged for non EMV purposes (Beacons, QR, wi-fi, …)
    • HCE is GPL, but ability to generate one time use tokens for EMV generation is unique.
  • Form M – MCX/Target Redcard
    • Consumer Directory: Wallet/Retailer
    • See Gemalto/MCX Blog
    • Very similar to Model S (Square) below except wallet is owned by the retailer and form factor is QR code
  • Form P – Paypal/Discover
    • Consumer Directory: PayPal
    • OK… this is not mobile yet.. but since I have Square down below, I thought I would be fair
    • Consumer registered for Paypal Card running on Discover network.
    • Consumer enters phone number at POS + PIN
    • Processor translates phone + PIN into Discover transaction
    • Discover routes to Paypal for authorization
    • Very similar to Model G above
    • Transaction authorized
  • Form S – Square/Starbucks/LevelUp – POS translation
    • Consumer Directory: Wallet/Square/Starbucks
    • Consumer account mapped to phone, ID, voiceprint, card, picture, location
    • POS translates ID to Card
    • POS request authorization as a card not present transaction
    • Consumer Authorization was taken during service registration
    • Consumer receives digital receipt for transaction
    • See Square Stand, LevelUp
  • Form V – Visa/Amex/MA – Network Tokens (TBD)
    • Consumer Directory: Network (Issuers don’t like this)
    • Press Release
    • See blog on Battle of the Cloud Part 4 – Clusters Form
    • Tokens will evolve to a very long number which will be translated to an issuer/account number. This is what Visa/MA do today.
    • Patents will be around generation, use and validation of token. In the future, merchants will not store your card numbers on file (COF), each merchant will have a unique token based upon your actual account number and their own ID.

From Business Implications of Tokens

Business Drivers

As I outlined in New ACH System in US, my view of Bank business drivers for Tokenization are:

  1. Stop the dissemination and storage of Card numbers, DDA RTN and Account Numbers
  2. Control the bank clearing network. Particularly third party senders and stopping the next paypal where consumer funds are directed to unknown destinations through aggregators.
  3. Own New Mobile POS Schemes to protect their risk investment
  4. Improve ACH clearing speed (new rules, new capabilities to manage risk). In a token model the differences between an ACH debit and a debit card will blend as banks leverage common infrastructure.
  5. Create new ACH based pricing scheme somewhere between debit ($0.21) and credit cards
  6. Regulatory, Financial Pandemic, AML controls (per  blog on HSBC)
  7. Take Visa and MA out of the debit game (yes this is a major story)
  8. Maintain risk models (see both sides of transaction)
  9. Control Retailer’s efforts to form a new payment network

What banks seem to be missing is that mobile payment is not just about payment (seeDirectory Battle Part 1). Payments SUPPORT commerce, Banks therefore do not operate from a position of control but rather of enablement. Most retailers recognize that Consumer access to credit has resulted in improved retail spending, however most would also say consumer addition to bank rewards has been detrimental to their margin.