Dumb pipes and Wide moats: Networks and Tokens

For Apple Pay, tokenization is the process by which card information is protected and subsequently shielded from the merchant and other parties in the transaction flow – till it reaches an entity equipped to reverse the translation and submit the authorization for bank approval. With AP – this role is entirely owned by the card schemes, even though the specification put forth by EMVCo places no such stipulations and allows third party “Token Service Providers” to exist. Apple is said to have welcomed “non-card scheme TSP’s” to operate within Apple Pay for a couple of reasons – the ability to support non-payment tokens as well as a hedge against putting all its eggs in one basket. For network TSPs like V and MA – tokenization represents a real advantage that dis-incentivizes disruption, while opening their rails to far more potential than just payments.

Consider the prospect of a non-network TSP in a commercial implementation such as Apple Pay. Though such notion is fundamental to its definition in the EMVCo spec, the practicality of 3rd party TSPs at least for the near term is a lost cause – and the lack of progress TCH has made on this front is a testament of that. Even if others go at it and create competing implementations of the EMVCo spec, banks are limited in their focus and efforts to integrate with a new TSP, and this has summarily discouraged new partnerships. I don’t expect this to change in the near future – and entities like TCH can expect a lonely and thankless slog.

As prospects for non-scheme TSP successors dwindle in NA – better success may be found internationally. In NA, among issuers – Chase has a higher likelihood of becoming a TSP – and can be the first step to standing up a vertical stack inside AP. Apart from Chase – other issuers have little reason to standup a TSP – and with Visa eliminating tokenization fees for issuers they process for – offers little incentive as well. The effort to vet, integrate and support new TSPs – forget becoming one – are not insignificant for an issuer – and thus not attempted lightly. This thinking can be subject to evolution as interchange rate reduction via a legislative or regulatory event in US become real at some point – and compressing the payment stack represents real savings for banks.

The above thinking is reflected in a question I was asked recently at a Top 5 issuer – “Should we pitch in 100m to build a TSP now or regret we had, later?”

For networks however, tokenization has meant much more than mere participation in Apple Pay as a TSP. Though tokenization has itself been presented as a security construct to all – such as its capacity to prevent online card fraud – there are two reasons why it is proving to be divine providence to V/MA.

Dumb pipes today. Smart rails tomorrow.


Even with approx 30,000 member banks between them – it has been both fascinating and terrifying for V and MA that in the last decade, growth of new account holders has paled against smartphone adoption worldwide. Networks feared that new end-points for commerce made possible entirely new sets of rails – and worked to modernize existing assets in a way to wring incremental value out of them.


Though schemes have largely aspired to route and process non-payment transactions to squeeze more utility from a fixed cost asset, largely the economics as well as incompatibility with other transaction types have posed an issue. The economics gets sorted out quickly – mainly because it’s in the schemes interest to shove more transactions through a fixed cost asset and therefore – enable a cost structure that incentivize it. This is happening today with MA and Private Label – as demonstrated in their success of signing up and tokenizing the Private label portfolio for Synchrony, ADS, CapOne (BJs, JC Penney and Kohls). What remains is conformity – and the token translation enforces it on the message type at the point of tokenization. Thus, despite the rails being payment centric – what the transaction and the token may represent can become something entirely different – and in many cases bear a non-payment intent.

As payments, rewards and loyalty start to decouple from the point of sale inside a store to a number of connected devices – networks are freeing themselves of loyalty towards who owns those pieces – as long as those pieces converge on the rails that carry them.

It is interesting to contrast what Visa and MA may have achieved to what Discover has been talking for a while – which is to white label its rails to any who so wish to use it to ferry transactions (e.g. Paypal, Isis/Softcard or MCX). But it seems to me that Visa and MA may go further – by using translation on the edge of the network to ferry more than payments.

Finally, for Apple – whose support of tokenization has proven to be a powerful propellant – non-payment transactions through NFC pose an ask – to decouple from the hardware centric (SE) payment framework, as well as potentially stand up its own TSP. The former is where Apple could look to implement its own version of HCE (Host Card Emulation) and decouple the radio from credential – possibly shifting the latter entirely to the cloud. Storing non-payment credentials that tend to have a much shorter shelf-life (transit for example) on the Secure Element (or even on the Secure Enclave) is expensive and wasteful. Cloud makes sense and I would be surprised if they haven’t been working on this already.

Board of Advisors at SimplyTapp - creators of Host Card Emulation driving democratization and open access to NFC in Android. Mobile Commerce & Payments Lead at Experian Global Consulting, serving Experian's clients in Banking, Retail, Consumer Credit & Payments. A strategic adviser w/ over 17 years of international Tech & Business Strategy consulting, advising firms in banking, retail & asset mgmt that seek clarity & insight in to the myriad business models around payments, fraud & commerce. Founded DROP Labs, a mobile payments/commerce strategy & advisory practice. Tweets here. I'm on LinkedIn here.
Cherian Abraham
View all posts by Cherian Abraham
Tagged , , , , , , , , , , , , , , , , , ,
  • FrankT

    Two additional thoughts: (1) The EMVCo spec requirement that really gums up the prospect of alternative TSPs is the requirement for the tokens to match the registration characteristics of the underlying payment credential – Durbin / Non-Durbin, Standard/Gold/Platinum interchange, routing etc. The networks clearly have this info. And the issuers have it as well – but you’re correct in noting that they have little incentive to invest the $$’s to stand up a competitive service to the networks. So agree – the moat has gotten wider and deeper. (2) In the minds of consumers and merchants they will increasingly come to believe that they are accepting ApplePay and AndroidPay (in the case of merchants) and they are using ApplePay and AndroidPay (in the case of consumers) – the “end point” brands will shift from payment networks to the mobile OS providers – the impact this will have on the future of the networks is one of the more intriguing strategic issues in play today.

  • Tito Hortiguela

    What surprises me on V/MA TSP is that enrolling is performed by using ISO8583 Messages and not APIs. What will happen in countries with local networks?