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.

Perfect Authentication… A Nightmare?

This question is very similar to the story above on EMV. The engineer in me recoils at the thought that a sophisticated technology (which decreases risk), would not be welcomed within a market. To understand WHY, you must answer the question: WHO benefits from the risk reduction? If your business is risk management, and someone takes risk away, what is your business?

4 Nov 2013

Long blog.. load of typos

As I’ve stated before, this blog has been a great way to make new friends and stay in touch with my 100s of friends and former employees around the world. When you are in a small company you tend to lose touch with what else is going on as you no longer have 1000s of folks feeding you market intelligence. Small companies live and die by the risks they take, and I’m primarily focused on reducing risk by sharing G2 and perspective.worry-about-identity-theft-confession-ecard-someecards

Industry History (experts can skip this section)

I’m fortunate to have worked with some of the best teams in both Security and Fraud areas. Back in 1998 I ran Oracle’s Payment and Security National Practice where we did things like PKI, Single Sign On, as well as Oracle’s first Java application: iBill and Pay (built on Oracle’s first Application Server OAS which scaled to 40 users regardless of hardware). I switched from the tech side to the business side in 02, and can assure you that running online Banks keeps you in the security AND Fraud space. In 2008 I left Citibank to go to 41st Parameter (just acquired last month by Experian). 41st Parameter was founded by a visionary fraud prevention guy.. Ori Eisen, with a focus device ID.

From a Commercial/operational perspective there is always friction between the security teams and the Fraud/Operations teams. The security teams are always working to enhance security, the fraud and operations teams are always working to mop up the mess from any holes in security and create proactive processes by which they can stop it. As I said in my blog last week, if I let security guys have their way with authentication …. customer experience would be awful.. and no one would use online banking. Hence we have services like Risk Based Authentication, Honey Pots, Fraud Controls, …

This same Security vs. Fraud dynamic plays out in payments. From the 1970s to the 1990s banks had built their authorization infrastructure around tools like HNC’s Falcon to create rules based authorization, with daily tuning of rules based upon fraud. Today Banks continue to invest billions of dollars in fraud and risk infrastructure (see blog). The metaphor for competition here

If you are camping with your friends and a hungry bear comes to your campsite.. you don’t have to be faster than the bear.. you just have to be faster than at least one other camper.

Thus the rule of thumb: fraudsters always attack the easiest target. Big bank billion dollar fraud platforms thus drive fraud to smaller competitors. This enables the large banks with sophisticated controls to derive higher margins in payment products, which drives incremental investment.  This is one reason why large US banks are so resistant to EMV (it levels the playing field). Fraud numbers in the US are not well reported, the best data is from my friend in the UK (see UK Card Association).  Large US banks were not involved (or informed) of Visa/MA’s plans to mandate EMV. As one CEO told me personally “Tom .. to this DAY Visa has never come by my office to discuss EMV, I found out about it the same way you did.. in a PRESS RELEASE.. “ [Top 3 Issuer].

In the late 90s Banks were not prepared for Card Not Present (CNP) Transactions that came from eCommerce. Their fraud systems (ex HNC Falcon rules) were not tuned for this type of transaction. Actually, banks really didn’t care much here because 100% of fraud loss was borne by the merchant. The only Bank impact was helping the customer deal with fraud (and reissuing cards). Thus RETAILERs began investing in Fraud systems and 3rd Party specialists (GSI, CYBS, 41st P, Digital River, 2CO, PayPal, …) emerged to help manage fraud on behalf of retailers. LARGE retailers followed the same path as large banks, investing in custom fraud infrastructure (ie Amazon, Apple, Google, Airlines, …).

Banks thus ceded eCommerce risk management to 3rd parties until around 2003 where 3DSecure was developed (See Wiki. Implemented as VBV by Visa and MSC by Mastercard). Merchants were incented to adopt the scheme by a liability shift (to banks) and an interchange reduction of 5-10bps. Rollout of the scheme in Europe was a disaster (see UK Guardian). Banks now owned a mountain of new fraud losses (as 3DS technology was broken), with only ONE tool to address: Decline Transactions. See my 2010 blog and Schneier’s: Online Credit/Debit Card Security Failure

Mobile

Banks are determined to avoid their prior mistakes, in eCommerce risk/roles,  and take a leadership position in mobile (ie payments, risk, authentication, data, … ). I’ve detailed their efforts in:

Why is mobile so important to Banks?

#1 PRIMARY INTERACTIVE customer touchpoint. 10 years ago, how did you interact with your bank when you were away from home, work and a branch? The only interaction you had was a piece of plastic.  Mobile enables a new class of Services.. but ALL mobile services must add value. The rest of these priorities pale in comparison to consumer touch… Banks are thus experimenting on what they COULD DO with mobile to remake banking.

#2 Authentication. Confirming identity of consumer.

#3 Risk Management. Both gaining additional consumer insight, and enabling new levels of risk control based on this data.

#4 Remaking of Retail Banking (reducing cost to serve)

#5 Mobile Payment.

#6 Partnerships. Sales, Distribution

I’ve touched on #1 many times, but before I go to Authentication/Authorization/Risk, let me provide a brief recap of my many blogs covering the “other services”. As I outlined in Card Linked Offers, Banks don’t realize is that just because you CAN interact with the consumer doesn’t mean that the consumer WILL. You must actually deliver VALUE if you want to capture consumer TIME. Having run 2 of the largest online banks I know what customers do. Retail Customers log in 3 times a week, check their balance, pay a bill or two and log off (180 seconds later).  Bank CEOs.. I gave my recommendation on what you SHOULD be doing in my Bank NewCo blog.

Authentication – THE Lynch Pin

As I stated in Who do you Trust,

Google and Apple are working to secure their platforms, and assume the central trust role in authenticating the consumer. I’m much more interested in the Apple’s new developer APIs than I am in the fingerprint app. How will they begin to “lock down” applications, what new authentication features will they expose to developers? How will they allow consumers to provision sensitive data to other apps?NFC Change

Hardware is evolving to software (from NFC to the SIM). …[ If Google locks down Android with a new secure OS, they will be in a position to provision Google applications (Maps, mail, search, …), identities, and cloud based services (drive, Google Now, Commerce, …).  The “freeware” model could still exist, but without the cutting edge Google services it becomes a COMMODITY HARDWARE game.

What we will see at Money 2020, is that there is an all-out war going on for the Trust role: Banks (see Tokenization), MA/V, MNOs, Samsung, retailers… everyone realizes this is the “key” to unlocking future value in the convergence of the virtual and physical world.

and in Authentication – A Core Battle for Monetizing Mobile

As Ross Anderson said “if you solve for authentication.. everything else is just accounting”. Think of how much bank infrastructure is dedicated to authentication of the consumer and risk/fraud management. This infrastructure was built over last 30 years because there was VERY poor ability to authenticate a consumer (ex. signature and possession of card) AND inconsistent CONNECTIVITY at each commercial “node” touching the transaction. Today we have complete connectivity, but the MODEL has not evolved from its archaic past.

Beyond Authentication, mobile also plays SUBSTANTIALLY on the risk side, as it enables Banks to interact OVERTLY and COVERTLY with the customer. For example a risk system could ask: is the customer’s cell phone within 20 yards of their transaction (at X merchant).  Or even issue the customer a one-time PIN (or PIN request) to complete transaction.

Perfect Authentication – A threat to Banks?

This question is very similar to the story above on EMV. The engineer in me recoils at the thought that a sophisticated technology (which decreases risk), would not be welcomed within a market. To understand WHY, you must answer the question: WHO benefits from the risk reduction? If your business is risk management, and someone takes risk away, what is your business?

If we made an inventory of payment systems (technical investment) between merchant to consumer bank we would see today’s systems, processes and rules would be DESTROYED by a future state of connectivity and authentication. I’m sure this one line statement will be questioned “prove it”, but I don’t have time.. I’ll leave it to someone else. Take this statement for what it is: my opinion.

Authentication is 0-1, Risk and Fraud deal in shades of grey. For example, if there is a CHANCE that Joe Smith is a really a the end of the transaction, and he is my wealth customer, I’ll let him in the door, see what he wants to do and then risk it based on it. I certainly won’t LOCK HIM OUT.  Another example, if I could authenticate a customer why do I need to make the transaction secure? This is the BEAUTY of the Square “pay with your name” scenario.  Why do I need tokens? Someone just needs to map consumer ID to payment types.

The very concepts of payment “products” begins to dilute. No more credit, debit, pre-paid, Amex, ACH, check, … In a world of perfect Authentication “old line” products evolve toward dumb pipes as competition shifts to speed and cost (not risk).

From Cash Replacement

Networks are designed around a value proposition.  For payments to flourish, a coordinated system of instructions which can be read by trusted participants is necessary. Providers of payment services must consider what network participants are providing in order to collaborate in risk management and settlement; the greater the number of consumers and businesses that participate, the greater the collaboration and interdependency. As more people adopt the payment system, its value increases, since it provides access to more people; this encourages larger networks. Not only do the benefits increase as the network expands, but the per unit cost of service falls. This behavior is the basis for what economists refer to as a “network effect”.

Once a payment system reaches a “critical mass”, economic value will be created at the ends of networks. At the core- the point most distant from users-generic, scale-intensive functions will consolidate. At the periphery-the end closest to users-highly customized connections with customers will be made. This trend pertains not only to technological networks but to networks of banks as well as small merchants and even to consumers who engage in shared tasks9. From a payment network perspective, this means that the “routing” of payments will provide much less revenue opportunity than managing the end points (e.g. the customer interaction or the products which are sold on the network).

…] Payment networks are inherently “sticky” with investments required by consumers, merchants, and banks for effective functioning. Payment networks also have substantial government involvement to support Commerce and Treasury functions that ensure stability, resilience and protection of parties. Innovation in payments is challenged by this network dynamic. As most small companies know, getting a bank to make a decision is tough… but nothing compared to getting 4-6 groups (issuers, acquirers, merchants, MNOs, Regulators, networks, ..) to collaborate in making coordinated change. A level of difficulty that is only superseded by the challenge new entrants face in competing directly against these existing networks.

A truely jaw dropping piece of research was completed last month by philippon_newfig1NYU’s Thomas Philippon (  http://www.voxeu.org/article/where-wal-mart-when-we-need-it).

The cost of intermediation grows from 2% to 6% from 1870 to 1930. It shrinks to less than 4% in 1950, grows slowly to 5% in 1980, and then increases rapidly to almost 9% in 2010

In other words Payments and Banking are one of the few network businesses in the HISTORY OF MAN to grow less efficient (rail, telecom, energy, …). This is BY DESIGN as the orchestrators of banking have successfully created constructs to squeeze COMMERCE. Further demonstrating that existing payment networks are incapable of leading ANY FORM creative destruction. As I stated in Commerce Battlefield

Mobile is a platform which enables a radically improved customer experience. With respect to payments it also offers a unique ability to authenticate a consumer (fingerprint, GPS, cell tower location, voice, camera, …). Yet, no banks are looking to leverage these “new” capabilities in a “new” payment system. After all, given a clean sheet of paper, no one in their right mind would design a payment system like we have in Visa/MA: present a credential to a merchant, who passes to a processor, who passes to network and routes to issuer to approve a customer transaction… giving the auth to everyone in the chain again.. and getting back another message. If everything is connected why not just ask the consumer to send the money from their bank (ex Sofort,  Push Payments also read Banks will Win in Payment ).

Why? Well because Banks can’t make money in a Sofort model.. (would need to create all new merchant agreements). This is why Banks are going through contortions to stay within Visa/MA, yet attempting to alter it fundamentally (ie Tokens). … (Also see Push Payments)

Regulation… the KEY

Payments, telecom, commerce, customer data, … all are regulated (merchants … not so much). Banks are completely justified in seeking solutions to their current regulatory burden. After all they bear most of the AML, BSA, CPFB, FED, OCC, .. burdens here. What needs to happen is that regulators must allow non-bank entities to bear risk. This is where innovation occurs. See blog US Payment Innovation and Regulation