Google+Softcard Levels Field Against Apple

24 Feb 2014

Well done Google. As predicted last month, Google announced last night that it had acquired “some exciting technology and IP from Softcard”. The price? My guess is around $50-60M, plus multi year revenue share (below). This is a FAR cry from the $3-$4 BILLION that these same Mobile Operators wanted for “NFC RIGHTS” in 2011. Google proposed a rev share back then too.. but MNOs were convinced they could go it alone. After dropping almost a billion in ISIS/Softcard with no future revenue of any kind in sight the drivers of the deal were obvious. Not only did carriers need an exit for their investment, they needed a partnership that gives them a role in the future of mCommerce.

What technology will stay? The SE Keys and the vending machine acceptance terminals.. seriously.. 98% of what ISIS/Softcard was is completely dead. My biggest unknown? I would love to see if Amex Serve could pick up the pre-paid card from Mastercard.. as the banks wanted to beat up my good friend Ed McLaughlin for doing what I still think was one of the best most innovative deals ever (Google pre-paid).SONY DSC

What did Google get? MANDATORY GOOGLE WALLET. That’s right, now EVERY ANDROID phone sold by the carriers will have wallet installed. This addresses a key advantage that Apple has in mandating an iTunes account (with credit card) for activating the iPhone. Apple’s brilliant registration process allowed it to know its customers (ID, card on file) where Android/Google did not. Many analysts believe that this ID/Payment deficiency is THE KEY reason why Apple’s environment is 8x-10x more profitable with less than 20% of the handsets. Now Google can compete in all things which require identity+payment. Not JUST in buying apps/music in Google Play, but in orchestrating commerce and brokering identity. I cannot understate the win here for Google. A brilliant move, and I firmly believe that this was the primary driver of the deal. Don’t look at this as a ApplePay competitive thing, it is about enabling Google to identify every Android holder as a default “opt in” during phone activation (iTunes Account Mandatory = Wallet Account Mandatory).

The Carriers? A partner that will share revenue. Where Apple takes 15bps for itself, my guess is that Google will give that to the MNOs, plus some revenue share for play services. My TOP 2015 prediction was that this would be the year of partnerships.. This is certainly my top new one for the year. MNOs are losing sleep about Apple’s unmatched “walled garden”, no one plays but Apple here. Google is developing an open model and this deal may be the first template for MNO/Platform revenue sharing.

Banks? Google will likely slowly “roll out” of its Google Wallet Card (also see TXVIA blog) which wrapped all other cards in a Mastercard Debit. Banks will be able to sign up for Google Wallet through network agreements just as they do for ApplePay today (at same rates/rules). This will mean that the networks will provision bank cards as tokens, and that Google will also benefit from forthcoming CNP token rules this summer. The primary difference in GW operation is HCE+Tokens (see blog). The Google Wallet model is not dependent on the SE Keys, or SD storage.. but it CAN operate in a non HCE model (from its GW 1.0 lineage).

Payment Networks. BIG WIN. Cards are the defacto standard for everything in mobile. I’m interested to see if the networks recognize (certify) the HCE card emulation application, as of 3 months ago it was still not certified. My belief is that they certify as part of tokenization scheme acceptance. This is a funny side story in itself. Most would ask how Google Wallet could run a non-certified card emulation app. Remember that the ONLY card being emulated was a Google owned mastercard debit.. just a brilliant work around. Note that in ApplePlay, Apple operates as a tier 1 token requestor in the current ApplePay model, and V/MA/Amex are tier 2 token requestors (see this excellent blog by SimplyTapp). In the Google model Visa and Mastercard will act as both Tier 1 and Tier 2 token requestors.

Big Losers? Samsung. OUCH!! No wonder they had to buy loop. Their new wallet strategy was to have a DUAL NFC/LOOP wallet. Google just got all the SE keys for the Samsung Phones. This means that Samsung’s wallet will only work on new phones.. a rather rough place to start.  Paypal.. with the birth of a new CNP scheme this summer driving ApplePay and Google Wallet beyond Apps to mCom checkout.. Paypal has no future in Mobile…  Except in emerging markets.

More to come.. but wanted to get this out today.

Token Assurance – Updated

28 April

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


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.


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?



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.

Authentication – In “Value” Nets

March 3, 2014

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

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

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

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

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

The Role of Payments in Commerce

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

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

Value of Authentication in Payments

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

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

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

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

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

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

Authentication Fee Structures

Issuer Controlled

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

Network Controlled

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

Platform Controlled

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

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

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

Mobile Auth and Payments – Today

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

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

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

Big Picture Thought

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

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

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


Apple Services


What is NFC? What part is Dead? A: The GSMA part

23 Feb 2014

I decided to turn this into a Wiki update.. as the prior entry is somewhat lacking. For example: Who created the TSM? Single Wire Protocol in the UICC? Who certifies a device for payment?

The New Wiki is now (with the last 2 para’s just added)

Near field communication (NFC) is a set of standards for smartphones and similar devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than a few inches.

Present and anticipated applications include contactless transactions, data exchange, and simplified setup of more complex communications such as Wi-Fi.[1] Communication is also possible between an NFC device and an unpowered NFC chip, called a “tag”.[2]

NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443and FeliCa.[3] The standards include ISO/IEC 18092[4] and those defined by the NFC Forum, which was founded in 2004 by NokiaPhilips Semiconductors (became NXP Semiconductors since 2006) and Sony, and now has more than 160 members.The Forum also promotes NFC and certifies device compliance[5] and if it fits the criteria for being considered a personal area network.[citation needed]

In addition to the NFC Forum, the GSMA has also worked to define a platform for the deployment of “GSMA NFC Standards”. within mobile handsets. GSMA’s efforts include“Trusted Services Manager”., Single Wire Protocol, testing and certification, “secure element”..

The GSMA’s standards surrounding the deployment of NFC protocols (governed by the NFC Forum above) on mobile handsets are not exclusive nor universally accepted. For example, Google’s deployment of Host Card Emulation on “Android KitKat 4.4”. in January 2014 provides for software control of a universal radio. In this “HCE Deployment”., the NFC protocol is leveraged without the GSMAs standards.


From a mobile payment perspective, NFC is

  1. Protocol. NFC Forum owns the Protocols making up the ISO specifications.  These protocols are the “universal” aspect of NFC that is NOT changing.
  2. Platform for How NFC works in a Phone
    • GSMA NFC Specifications, reference architectures, platform constructs (TSM, ..) outlining a SCHEME for how NFC manifests itself within a Handset Architecture
    • HCE
    • Apple Secure Enclave
    • ??
  3. Payment Network Standards and Certification. Exxon Mobile and Mastercard were the first contactless payment mechanisms, and Mastercard PayPass was the first Network Standard with reference implementation and certification for presentment and acceptance.

With HCE, the entire GSMA “NFC platform” is dead, but NOT the protocol (No UICC/SWP role, No TSM, Access to “controller” and Secure Element, no Handset Certification).

Comments on Wiki and blog welcom



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

HCE – Now the PREFERRED contactless approach

Feb 19

HCE Gains Official Support from V/MA today

So much for 2 NFC/TSM CEOs telling me that HCE was “not viable”.  I told you Feb was going to be a great month.. and this is not even the tip of the iceberg. As I look at the number of reference links below.. I realize that I’ve been talking about this stuff for far too long. For detail on what HCE is see my November Post HCE Breaks the MNO Lock.

Today’s announcement primarily impacts BANKs. Message to Banks, if you want to test HCE TODAY there are 3 options: Mastercard, SimplyTapp, or Android 4.4 DIY.  Before everyone gets too excited.. the same mobile payment hurdle remains: merchant adoption. Technically HCE looks exactly the same to a payment terminal as NFC and unfortunately it also has same (terrible) business model (everything is a Credit Card .. by Bank design). Credit cards cost 200-500bps (% of sales) vs a flat fee of $0.07-$0.21 for most debit cards.

What does this announcement mean?

  • HCE Token Presentment = Card Present Paypass/Paywave
  • No more TSM, Payment is in the OS, No more dedicated NFC chipsets, and the MNO lock is gone. (Sell Gemalto … loosing MCX and NFC in the same week?)
  • Visa/MA prefer HCE to NFC hands down. It allows them to own the tokenization of cards in mobile. HCE actually ALIGNS to bank and network (V/MA) objectives: keep intelligence in network and control with issuers. The Networks ARE the TSMs. Mastercard is 3-5 years ahead of Visa here (with actual pilots). Visa’s is attempting to make up lost time by creating a more flexible program to support HCE within Visa Ready (Issuer Support). Note “Visa is Developing”.. vs.. call up MA and start the pilot. Visa’s token focus had been on the eCommerce side (, and will have to run hard to play catch up.

Visa Ready

  • Android Rules! Cards, Tokens and Door Keys in Apps. Your Citibank mobile app can pay at a contactless terminal, your Starwood App can open hotel room doors. Apps have access to ISO 14443/18092 compliant exchange.. with the support of Android. This is where it will get VERY interesting. Google created HCE based upon the contribution of SimplyTapp’s Software (via GPL). I believe it is a tremendous competitive edge for Android, and I would bet they work to “manage” the deployment of KitKat and approve applications that can leverage it, as they MUST be part of Google’s Authentication/Biometric plans. Why is this better than Apple’s Beacon/BLE approach? Google is a Platform that will allow hundreds of apps to access the radio where they will own security and authentication (open innovation). Apple is a hyper controlled structure where beacons will talk to your phone in defined ways through approved apps (managed innovation). OK this is a bit of simplification, but until Apple actually releases a product don’t complain about it.
  • Tokens, Tokens, Tokens.  I could write a book on the interplay here. Much of the V/MA stance evolved from the previous TCH Token Project (see Money 2020 Blog and Business Implications of Tokens). The banks were working to end run Visa and MA on mobile tokenization. Theme is “if there is a number in the phone, why would we [Bank] want it to be a Visa or MA number.. lets make it OUR OWN number (ie a Token). After 3+ years the effort floundered and now TCH is left to be the standards body. Visa and MA reacted, most likely because of all my excellent token blogging (not), and together with Amex announced a new shared token approach.

Important. In the mobile context think of tokens are constantly changing card numbers. In the early stage HCE tokens will be 16 digits to support current payment infrastructure, but will evolve in next 2 years to be complex token identifiers much longer than 16 digits. Visa and MA have both developed controls for how this will work, for example having a “token” that refreshes at a given rate based upon where the phone moves and how the phone transacts. A Token could refresh at different rates (10 seconds to 10 weeks) based upon how the user transacts or what part of the world they are in. In this model Token generation is a NETWORK responsibility, which is why V/MA love this model.  In the new token schemes, there is opportunity for the “mobile handset” to provide biometric and security information. As I stated before, NFC zealots will HOWL that there is no TSM, or security that a number will be stored in software. But SECURITY has DEGREES.. there is no such thing as 100% non-repudiation.  I will leave it a subject to a future blog how ID providers are paid for this service.


There maybe a few new readers on this blog, so let me recap a brief history of how this came to pass.

NFC is a great technology, with a terrible business model. Developed by carriers in a walled garden strategy, they planned to charge $0.05 every time someone wanted to access a credential (like a credit card) in the “secure vault” within the mobile phone. The secure vault was the Secure Element (SE), with companies like NXP making dedicated chipsets for the function. See Carriers as Dumb Pipes.

Also seeNFC Handset

ISIS Platform: Ecosystem or Desert

Apple and Physical Commerce

Network War – Battle of the Cloud Part 4

Controlling Wallets – Battle of the Cloud Part 3

Apple and NFC







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.

Issuers … give HCE a shot now

Imagine expanding your existing bank mobile app to do card emulation.. with NO TOLL to the TSM or carrier.. you are in complete control. A project which should be sub $1M AND NO CONTRACTS!!

Imagine expanding your existing bank mobile app to do card emulation.. with NO TOLL to the TSM or carrier.. you are in complete control. A project which should be sub $1M AND NO CONTRACTS!!

The only current dependency is Android 4.4 with an NFC or HCE capable handsets.. with over 40 new OEMs  handsets shipping in next few months.

I’ll fill this blog out in more detail, but here are the key actions

  1. mobile app development
  2. workout how your static signing keys can be deployed. SimplyTapp has solution in place (
  3. Test with legacy embedded handsets and new OEMs to establish your test pool
  4. Create a new consumer registration service where virtual keys are provisioned to application (again SimplyTapp has this)

Google’s phones are ringing off the hook. Retailers, loyalty providers, Banks are all working to leverage this new approach. The Android team can help you with the APIs.. but recommend you get in touch w/ SimplyTapp today

(I have no current relationship with SimplyTapp… but think it is something that makes sense as hardware evolves to software)

– Tom


Software Secure Element – HCE Breaks the MNO NFC Lock

Visa and MA have both created HCE Apps which will REPLACE the SE based CARD EMULATION apps. This is a FANTASTIC development for BUSINESS and for Android. Now you can create apps that leverage payment, loyalty, … It is also a fantastic development for CUSTOMERS as you will be in control of the TSM and card provisioning. You will be able to load ANY CARD you want.. not just the Chase and Amex cards that are in ISIS.

News Today – WELL DONE GOOGLE!  (Note good comments below)

In my July post Big Changes to NFC: Payments part of OS I outlined the high level view of what is going on. In order for this blog to make any sense let me be a little less obtuse on the next shoe which will drop: Visa and MA have both created HCE Apps which will REPLACE the SE based CARD EMULATION apps. “Replace” is more from a business context than from a technical one. SE based applications (like a door key, or healthcare card) could still survive.. but why would anyone want to pay the MNOs RENT if you don’t need to.

I don’t have much time to delve into the technical details, but there are 3 core elements to NFC: Radio, Controller, Secure Element. They had been all residing on dedicated silicone from companies like NXP. I discussed in Apple and NFC Part 2 how companies like Broadcom have integrated these separate components into a single piece of silicone. In other words the NFC Radio is just another radio alongside GSM, CDMS, Wi-Fi, Bluetooth, … With Android 4.4 Google has now made Payments Part of the OS by enabling an application to bypass the SE and use the radio as directed by a OS. Another way of looking at this: in a world of integrated silicone, there is NO dedicated  controller… (the controller is in the firmware/OS).Exposure: 000 : 00 : 00 . 156 %Accumulated%=0

NFC zealots will HOWL that there is no TSM, or security. But SECURITY has DEGREES.. there is no such thing as 100% non-repudiation.  Visa and MA have both developed controls for how this will work, for example having a “token” that refreshes at a given rate based upon where the phone moves and how the phone transacts.

This model also addresses a key FLAW with NFC. HCE will allow for APPLICATIONS to access payment.. yes I am speaking of mCommerce (buying from an app or a web site). No longer will you have to key in your card information. NFC did NOTHING for this.

This is a FANTASTIC development for BUSINESS and for Android. Now you can create apps that leverage payment, loyalty, …  It is also a fantastic development for CUSTOMERS as you will be in control of the TSM and card provisioning. You will be able to load ANY CARD you want.. not just the Chase and Amex cards that are in ISIS.

I believe that banks had very limited view of this development, and that several of them will be calling V/MA to confirm that they are creating an new CERTIFIED Card Present scheme based on HCE. Bank control (push for credit use) has been as much of a drag on mobile payments (at POS) as telecom control. This approach BREAKS BOTH.

Bank Benefits

No one can fix EMV…. there are too many parties. New token rules together with HCE AND Network Enhancements (ex Wallet ID, Phone forensics, ..)  a much finer grain of control than exists today. For example, new structure will allow for any given issuer to turn off all tokens for any given wallet provider. When comparing EMV to HCE++ we can’t forget WHAT EXISTS TODAY (is mag stripe). No one can suggest that HCE++ is less secure than mag. Most banks realize that payments are NOT about security and authentication.. but about Fraud and Risk management. Not just “are you the person that controls the account”.. but “did you just loose your job and about to enter bankruptcy).

The mobile device has SO much more data on which to manage fraud and risk. For example at Citi, SMS PIN code completely eliminated risk in new transactions. When we saw a new payee, we sent the consumer a PIN code to their mobile that expired in 1 min.. In future HCE environment if bank sees risk they can PIN, or ask for finger print scan (from apple).

HCE actually ALIGNS to bank and network (V/MA) objectives: keep intelligence in network and control with issuers. Today big banks differentiate themselves on ability to manage risk. They have made multi-billion dollar investments here. Complete security and authentication in a platform decreases their competitive edge. Perfect authentication is a NIGHTMARE to banks because then anyone could do their job and ID risk would be eliminated (not credit risk)NFC Change

Big Technical UNKNOWNS

  • Tokenization, Network Enhancements, New Card Present Scheme, New V/MA Emulation App, POS Terminals, Fraud Services, Device Forensics, Authentication, all are needed in this future model. Much is built.. but this is not without challenges
  • Today’s NFC requires issuer keys to generate the dynamic codes required in a contactless transaction. IF this is reused, than issuers will be able to prevent HCE from working.
  • Will V/MA attempt to impose Authentication/Fraud Services standards impact consumer experience or conflict with issuer requirements
  • Who will create the HCE standards by which everyone can use? How long will this take? are we back to ground 0?

Other quick thoughts

  • This is not just PRESS.. HCE is actually all LIVE right now with a Canadian Bank.. RBC and SimplyTap (the Rocket Scientists of HCE). In this model an ISSUER has given its “NFC Keys” to the SimplyTap for use in an HCE model that circumvents NFC controller.
  • I expect that Apple’s iOS will also follow model within next 8-12 months.
  • Very positive for V and MA, Google, Businesses that transact with consumers
  • Very positive for mobile POS payment
  • Could create new differentiators for Android if Apple doesn’t follow quickly (I expect they will)
  • Positive for merchants as consumers can now load debit cards on their phones and you can create apps that incent debit card usage
  • Negative for companies that specialize in providing payment services to mCommerce or NFC
  • Negative for PayPal.. why use them at all? your cards are stored in the phone. If you are a merchant with a mobile store front or app you will integrate with 2 payment service providers: Apple and Google.
  • SEs will be going away. Connectivity and Authentication put data in the CLOUD.. not locked in a device with the carriers holding a key.
  • Google has alignment on HCE. Devices from the top handset OEMs announced in the next week+ with no SE on board, like the Nexus 5
  • Next BIG challenge? Certifying/standardizing authentication methods which provide for finer grained control of payments, cloud data, re-issuance of tokens…. 100s of new companies.
  • HCE actually ALIGNS to bank and network (V/MA) objectives: keep intelligence in network and control with issuers. Today big banks differentiate themselves on ability to manage risk. They have made multi-billion dollar investments here. Complete security and authentication in a platform decreases their competitive edge. Perfect authentication is a NIGHTMARE to banks because then anyone could do their job and ID risk would be eliminated (not credit risk).

Appreciate feedback.