V, MA – From NSPs to TSPs: The Impact of Tokenization on the Payments Value Chain

nicklipinski
Print Friendly
Share on LinkedIn0Tweet about this on Twitter0Share on Facebook0

SEE LAST PAGE OF THIS REPORT FOR IMPORTANT DISCLOSURES

Howard Mason

203.901.1635

hmason@ssrllc.com

May 30, 2016

V, MA – From NSPs to TSPs: The Impact of Tokenization on the Payments Value Chain

“It’s everywhere you want to be” Visa Acceptance-Brand Campaign, 1985-2006

“We want Android Pay to be everywhere where you and I expect it[1]” Google, 2016

  • A natural context for mobile payments is shopping apps, as with Walmart Pay, and banking apps as with Wells Fargo Wallet announced last week. By integrating payments into other services, checkout/couponing tools in the case of retailers and personal-budgeting tools in the case of banks, these app-providers can add value to the consumer experience in ways that Apple and Android Pay independently cannot. Furthermore, retailers and banks will promote proprietary mobile payments solutions to increase consumer engagement with own-brand apps.
  • As shop-and-pay and bank-and-pay apps gain consumer adoption, the acceptance brands of Visa and MasterCard will be increasingly “wrapped” by the own-brand apps of retailers and banks. This undermines network pricing power which rests on acceptance-brand rules limiting the transaction processing or “routing” choices of retailers: a retailer accepting, say, the swipe of a MasterCard-branded credit card has no choice but to route the transaction over MA “rails” since the card supports no alternative processing. As legal cases against FDC in 2006 and WMT this May illustrate, the networks aggressively defend an ability to monopolize the card face by binding their rails to acceptance brands. They have been successful with two important exceptions:
  • Durbin insists that debit cards are enabled for two or more unaffiliated brands and that retailers be permitted to process debit transactions over any available infrastructure; and
  • JPM is permitted to route Visa-branded transactions over ChaseNet when JPM is both the issuing bank representing the cardholder and acquiring bank representing the merchant.
  • The networks are responding to acceptance-brand deprecation in mobile payments by looking to establish market power as token service providers; the role of these TSPs is to generate the device tokens which link a mobile device to a payment account. Stored on a secure element that is device-based for iOS and cloud-based for Android, device tokens are used by Card Service Providers (CSPs) – AAPL in the case of Apple Pay and GOOG in the case of Android Pay – to generate transaction tokens on request by a payment app after customer authentication through, typically, a fingerprint scan. Transaction tokens are dynamic in the sense of being limited- or single-use tokens or “keys” (LUK/SUKs) while device tokens or “tokenized PANs” (tPANs) are static in the sense of persisting over the life of the linked device and PAN (see Chart).

Chart: Token Service Providers and Card Service Providers in Two-Stage Tokenization

Source: SimplyTapp.

  • Through providing device tokens for Apple and Android Pay, V and MA have established a de facto duopoly as TSPs for app-based transactions similar to that as network service providers (NSPs) for card-based transactions. However, the duopoly in mobile payments is strategically more vulnerable because CSPs, including Apple and Google, can switch TSPs without downstream consequences for app-clients while card-issuers cannot switch NSPs without re-issuing cards to consumer-clients.
  • For example, the decision by USAA to switch NSP from MasterCard to Visa involved issuing new debit and credit cards to its customers with the Visa, rather than MasterCard, brands and primary account numbers or PANs (the 16-digit number linked to the ultimate funding account and embossed on the front of traditional, magnetic-stripe cards).
  • To temper the relative weakness of the TSP position, V and MA are looking to integrate forward to become CSPs through distributing this service in software development kits (SDKs) to app-providers; a recent example is Visa’s support of pump-and-pay dashboard apps for IP-connected cars. Visa SDKs use Visa as both CSP and TSP and cannot be configured differently; to switch TSPs, an app-provider must update apps to work with tokens from a different CSP just as, to switch NSPs, a card-issuer must update cards to work with PANs from a different network.
  • However, having lost out to the networks in a collaboration to establish token standards through The Clearing House, the banks also covet a CSP role from which they can integrate back to become TSPs. Indeed, a key distinction between Wells Fargo Wallet and Android Pay is that WFC and not GOOG is the CSP (with device tokens stored on bank, not Google, servers). The result is that WFC can switch TSP, or itself act as TSP, without downstream consequences for the wallet. The opportunity for banks to fill a TSP role will become more relevant as they seek to extend clearXchange from P2P to POS payments as an alternative to V/MA debit rails; this will require replacing network-issued device tokens with bank-issued tokens unless – as MA has done with private-label card providers such as SYF, ADS, and C – an issuer and network can come to terms on using network-issued tokens for transactions that are settled off-network.

Overview

Payments are the foundation of bank account services, whether checking accounts or pre-approved lines of credit and, as PYPL has demonstrated, risk losing share of these account services to fintech players offering alternative front-ends (such as Simple and Moven), as well as to each other, if they cannot offer compelling mobile payments solutions. Apple and Android Pay do not cut it for consumers because they offer payments outside the context of a bank or shopping app and, as COST has demonstrated in switching its co-brand card from AXP to C/V, retailer-branding of the payments experience risks relegating card-issuers to the status of commodity partners rather than valued marketing partners; the issuer-negotiated credit discounts obtained by MCX for granting Chase Pay preferential access reinforces this point and, if CurrentC successors such as Walmart Pay and Target Pay succeed as we expect, banks will follow CPGs in making pilgrimages to Bentonville and Minneapolis to bid against each other for advantaged shelf- and app-space.

The strategic response is for banks to offer proprietary mobile payments solutions from within their own-brand apps not only to defend their payments franchises but also to build consumer brands and loyalty by increasing app-engagement beyond the early use-cases of balance-check and remote deposit capture. These proprietary mobile payments solutions require proprietary rails and it is not a coincidence that BAC in March launched a P2P service from within its mobile app using the bank-owned clearXchange or CX network and, last week, WFC announced the summer launch of Wells Fargo Wallet for Android devices which will use a proprietary cloud-based solution to support mobile payments at NFC-enabled points-of-sale and ATMs. Given the cluttered market for mobile payments solutions, it is easy to lose track of subtle differences in implementation that can have important effects on the consumer experience; in particular, the critical design issue for a mobile wallet is how to represent and securely store the “card credential” providing payments access to an underlying funding account:

  • Representing the Card Credential: Mobile payments solutions using the near-field-communications (NFC) radio protocol for contactless communication between the NFC controller on a device and the NFC reader on a point-of-sale terminal have adopted the token standards established by the network brands so that the network-issued primary account number (PAN) for a bank card is represented by a “device token” associating the device with the PAN. These device tokens are static in the sense of having a lifetime that can match that of the PAN but, under the token standard, are cryptographically linked to transaction tokens (referred to by Apple as cryptograms) that are dynamic in the sense of being valid only for a limited or single use; transaction tokens take the same form as a PAN (and so can be processed by the same infrastructure that supports card swipes) and with the device token communicate information – such as the device ID, the point-of-sale terminal ID, and transaction amount – necessary for the card-issuing bank to authorize a transaction.
  • Storing the Card Credential: Apple Pay uses device tokens stored on a “secure element” which is a proprietary chip isolated from the CPU with which it communicates only via the NFC controller; Apple does not allow third-party access to the NFC controller which is why, to participate in Apple Pay, consumers must register bank cards to the native Passbook app which does. Android Pay stores device tokens on Google servers for a cloud-based, rather than device-based, secure element. The technique is referred to as “host card emulation” (HCE) since the operating system which hosts the apps enabled for Android Pay communicates with the remote device token in such a way as to emulate a bank card as if the device token were stored on-device in “secure-element card emulation”. Wells Fargo Wallet uses HCE but with a proprietary implementation rather than that of Android Pay; in particular, the wallet stores device tokens on bank servers rather than Google servers.

Our core thesis is that payments will be integrated into the natural context of shopping and banking apps because retailers and banks can leverage the payments service and information to improve related in-app services such as checkout tools in the case of retailers (including digital receipts, tender-splits with loyalty points, and the integration of the earn-and-burn of shopping incentives, including manufacturer coupons, into the main payments stream) and budget tools in the case of banks (including real-time transaction and balance alerts, the linking of digital receipts if scanned to charge amounts, and the earn-and-burn of shopping incentives provided under joint marketing programs between banks and retailers, particularly retailer-clients of bank merchant-acquiring businesses, into the main payments stream).

This branding of the consumer payments experience by shopping and banking apps shifts power in the payment ecosystem to the edge of the network – from the merchant-acceptance brands of the networks to the consumer brands of the retailers and banks. This is because acceptance brands are the cornerstone of network pricing power since they are used to limit merchant routing choices; for example, if a retailer accepts a swipe from a MasterCard-branded credit card, that transaction must be routed over the MasterCard processing infrastructure or “rails” generating monopoly pricing power. Until recently, Visa has aggressively defended the binding of its rails to its acceptance brand including using the Courts to insist that FDC abandon its own proprietary network and, in response to Durbin which requires that two of more unaffiliated network brands be represented on a debit card and that retailers be permitted to use any available infrastructure for processing debit transactions regardless of network brand, that retailers support “chip-and-choose”, rather than the more secure “chip-and-PIN” standard, thereby tending to limit the availability to retailers of competing PIN debit networks such as STAR owned by FDC and NYCE owned by FIS. A recent exception to Visa binding its rails to its acceptance brand was with JPM’s launch of ChaseNet in February 2015; JPM can route Visa-branded transactions, whether debit or credit, over ChaseNet in cases where Chase is both the issuing bank for the cardholder and the acquiring bank for the accepting merchant.

As its acceptance brand is increasingly at risk of being “wrapped” by the mobile apps of retailers and banks, Visa is seeking to sustain pricing power through locking app-transactions into use of its device tokens (just as, before ChaseNet in credit and Durbin in debit, swipe transactions were locked into use of its PANs). For example, developers who payments-enable apps using Visa’s software development kit (SDK) – such as Honda in launching a dashboard app that detects when fuel is low, navigates to the nearest gas station, and makes payment at a gas station – request transaction tokens from Visa, as “card service provider” or CSP, and are then locked into using device-tokens from Visa as “token service provider” or TSP (see Chart); the locking occurs because Visa’s CSP service cannot be configured for a third-party TSP, and the same is true of apps requesting transaction tokens from MasterCard as a CSP. However, the CSP role can be fulfilled by a non-network provider, such as SimplyTapp, which allows the app-provider to change TSP in mid-service in a one-time switch for the entire card-set without rather than undertaking a device-by-device migration to a new CSP. In other words, network SDKs create similar network-switching costs for app-provider as faced by card-issuers using network PANs; in the former case, switching the network providing device-tokens requires re-issuing apps for different transaction tokens and, in the latter case, switching the network providing PANs requires re-issuing cards for a different acceptance brand.

Chart: Token Service Providers and Card Service Providers in Two-Stage Tokenization

tPAN for tokenized PAN is a device token and LUK/SUK for limited- or single-use keys are transaction tokens

Source: SimplyTapp.

This brings us back to Wells Fargo Wallet and the relevant distinction from Android Pay from the perspective not of the consumer payments experience but of the payments value chain. In Android Pay and Apple Pay, Google and Apple respectively are the CSPs so that the card-service consumer apps, including those from banks, are locked into their choice of TSP and, over time, V and MA are likely to provide financial incentives to them not to switch just as they do today to large banks and merchants that support network effects. In Wells Fargo Wallet, however, WFC is the CSP since the device-tokens are stored on its secure servers so that WFC can switch between networks for TSP services, or even backward-integrate into TSP services itself, without downstream consequences for the mobile banking and payments app. One specific instance where this will likely be relevant is when the banks look to extend clearXchange from P2P to POS (point-of-sale) payments as an alternative to the debit rails of the network brands; this will require replacing network-issued device tokens with bank-issued tokens unless, as MasterCard has done with for private-label card providers such as SYF, ADS, and C, an issuer and network can come to terms on using a network-issued token for a transaction that is settled on non-network rails.

Our final observation concerns Apple. Apple has restricted access to the NFC controller on iOS devices to the native Passbook app and extracted fees (reported at 15bps of credit transaction amount in the US) for allowing banks to register cards to the app and hence participate in Apple Pay. Google does not levy similar access fees (and, indeed, these fees are now prohibited for a CSP using the V/MA token systems) and, in any event, permits third-party access to the NFC controller on Android KitKat+ devices through host card emulation. Banks have initially dealt with the challenge of restricted access to the NFC controller on iOS devices through using another approach to credentials-transport (QR codes in the case of Chase Pay announced last October, for example) or through supporting NFC-enabled payments separately from their mobile app (as in the case of the Capital One Wallet which is separate from the Capital One mobile app). WFC, however, has simply decided to develop payments features for its Android mobile app that will be unavailable on iOS devices creating a positively-differentiated consumer experience and potentially contributing to a preference among its customers for Android over iOS devices.

Appendix: A Review of Tokenization Schemes

The integration of payments into apps – whether into a shopping app as in the case of Walmart Pay, the dashboard of a connected car as in the case of the fuel-and-navigation app on a new Honda, or a bank app as in the case of the Wells Fargo wallet announced a few days ago – is changing the branding of consumer payments. While Visa and MasterCard may well be providing the underlying settlement infrastructure or “rails”, their acceptance brands are being wrapped by app-providers. This is commercially important because network acceptance brands underpin pricing through a set of rules, including honor-all-cards, no-steering[2], and mandatory routing rules, that we have exhaustively detailed[3] and that have caused decades of litigation with merchants including this month WMT’s complaint that Visa is not allowing it to insist on PIN verification for debit transactions.

Both card-issuing banks and card-accepting merchants see the consumer shift to mobile payments as an opportunity to weaken the grip of Visa’s rule-set with WMT commenting[4] as early as Jan 2013 that “we’re open to partnering and playing with the existing network … but the existing rules that are in place for card-based payments are not going to be acceptable for mobile-based payments” and JPM commenting the following month with the launch of Chase as an acceptance brand on the merchant complaint that “Visa’s got all these operating rules … why can’t we just deal with you and now we can”. Visa, of course, prefers the status quo so that when Apple began negotiating bilateral deals with issuing banks around the terms of inclusion in Apple Pay, Visa acted swiftly to re-establish standards through introducing a security solution, referred to as tokenization, where the network-issued primary account number or PAN of a card is ultimately represented in a mobile payments transaction as a limited-use token.

One of the cornerstone requirements for participating in the Visa Token Service is that merchants must honor-all-tokens, that is not discriminate between banks, just as they must honor-all-cards. And that, in turn, preserves more of Visa’s traditional ability to act as agent in what amounts, in economic if not anti-trust terms, to collective bargaining by banks in establishing merchant acceptance fees. Remarking on this success, Visa commented in September 2014 that “the transaction with the token using Apple Pay or [Android Pay’s] HCE is exactly the same network transaction as we have today so we are not looking at rethinking interchange or the network model”. The natural conclusion is that tokens are critically important to network pricing power as payment volumes shift from network-branded plastic to network-tokenized apps whether these apps are provisioned into IP-connected phones or IOT items such as cars and washing machines.

And whether networks succeed on porting their pricing power from plastic to mobile payments depends on whether they can sustain the same competitive position as token service providers (TSPs) that they have in network service providers (NSPs). Evaluating this requires a deep-dive into tokenization.

Tokens in a Plastic World

The 16-digit number on the front of your Visa or MasterCard debit or credit card, referred to as the primary account number or PAN, is a network-issued token: it is a proxy for the bank-issued number associated with an associated funding account whether a checking account (for a debit card) or pre-approved line of credit (for a credit card). The PAN is a static token, in the sense that it is unchanged for the life of the card, and is an example of a master token that is mapped to the number of the associated funding account by the networks acting in the role of “master token service provider”. When a consumer wishes to use a traditional Visa- or MasterCard-branded plastic card for payment at point-of-sale, the accepting merchant requests the token which is read by a point-of-sale terminal from the magnetic stripe on the card. Having acted in the role of “token requestor”, the terminal submits an authorization request, including the token and transaction details, to the card-issuing bank via the merchant acquiring bank and relevant network and proceeds if the authorization response is in the affirmative.

The security advantage of using a PAN to tokenize the number of the funding account is that if the PAN is intercepted, the issuing bank can issue a new card (and the network a PAN to go with it) but there is no need to terminate the underlying account and require the consumer to open a new one.

Tokens in Apple Pay

Unlike the magnetic stripe used to store the PAN on a traditional plastic card, the chip used to store card credentials on a mobile phone is capable of performing some processing and, in particular, of cryptographically generating what Apple refers to as a “cryptogram” for each transaction[5]. These cryptograms, also known as “transaction tokens”, are uniquely identified with the on-chip card-credential and, sharing the same digital form as PANs, can be processed by the merchant in a transaction authorization request using existing infrastructure. However, unlike a PAN which is static, transaction tokens are dynamic in the sense that a new one is generated for each transaction; the security advantage is that if a transaction token is intercepted, it is worthless because its use is limited to a single transaction and there is therefore no need for the network to issue a new PAN.

Apple Pay’s security solution goes further because, rather than storing the PAN as do magnetic stripes on traditional cards, a static token referred to as a “device token” represents the PAN and is stored on iOS devices in a “secure element”; the secure element is a cryptographically protected chip that is isolated from the CPU except for communications via the device’s NFC controller which, in turn, intermediates the exchange of radio information, under the near-field-communications or NFC protocol, between secure element and an NFC reader on an NFC-enabled point-of-sale terminal. Apple does not allow third-party access to the NFC controller which is why Apple Pay is implemented via the native Passbook app, which does have access to the controller, and why bank cards and other payment credentials participating in Apple Pay are aggregated in the Passbook app.

Returning to the security solution, the use of both device and transaction tokens means that funding account details are protected by nesting first in the PAN, then in the device token, and finally in transaction tokens. The advantage of a device token is that if the device is compromised, a new device token can be provided without triggering the need to re-issue a PAN. A consequence of the additional layer of security is that there are two different classes of token requesters in the Apple Pay design: Apple which, when a consumer wishes to register a card to an iOS device, requests a static, life-of-card device token from the networks; and the Passbook app, through which Apple Pay is implemented, requesting dynamic transaction-by-transaction tokens from this device token.

Tokens in Android Pay

In implementing Android Pay, Google follows the two-stage tokenization approach described above for Apple: it requests device tokens from the networks as token service providers and then, in the role of card service provider, support the cryptographic generation of transaction tokens from these device tokens. A key distinction, however, is that while Apple provides its card service only through the native Passbook app, Android Pay makes the card service available to any mobile app through host card emulation or HCE.

The specifics are that, rather than routing radio information messages from the NFC reader on a point-of-sale terminal to a device-based secure element[6], HCE directs them to the host CPU on which the token-requesting Android app is running (Chart 2). This triggers the CPU to open a communication channel with Google servers, request a transaction token from the device token stored remotely on a cloud-based secure element, and forward the response to the token-requesting app.

Chart 2: NFC Card Emulation with Secure Element (top) and without Secure Element (bottom)

Source: Google

Tokens in Wells Fargo Wallet

The advantage of host card emulation is that it removes card-issuer dependence on owners of device-based secure elements whether equipment manufacturers as in the case of Apple Pay or mobile network operators as in the case of the now-defunct Softcard. However, as with Apple Pay, Android Pay takes payments out of the context of a banking or shopping app, and locks token-requesting apps into use of the master token service provided by the network brands (or any alternative TSP that Apple and Google respectively may choose to work with in the future). We believe these shortfalls lie behind WFC’s announcement last week that, with deployment over the summer, it would be upgrading its mobile banking Android app with a proprietary HCE solution to provide an “integrated mobile banking and payments experience”; the resulting Wells Fargo Wallet will be offered in addition to continuing support by WFC for Android Pay. Of course, like other banks, WFC cannot integrate NFC-enabled payments into its iOS mobile banking app because Apple does not allow third-party access to the NFC controller on iOS devices.

Given that WFC has a proprietary implementation of HCE, we assume that it, rather than Google, acts as a card service provider in requesting device tokens from the networks, stores these securely on its own servers, and responds to requests from its mobile banking app for transaction tokens. This addition of tap-and-pay to its own-brand mobile banking app has several benefits for WFC:

  1. WFC controls the registration of WFC-issued card credentials into the app and can reduce enrolment frictions for consumers relative to Android Pay; furthermore, when a consumer enrolls a WFC-issued card into Android Pay any Android app can access the tap-and-pay feature so that WFC support for Android Pay means that it is creating payment-competitors to its own mobile banking app; the proprietary HCE solution, on the other hand, is available only from within WFC’s mobile banking app.
  2. Beyond improving enrolment rates in mobile payments, WFC’s proprietary solution moves payments into the familiar consumer context of a banking app, and it is not a coincidence that Wells Fargo Wallet will at the same time as supporting NFC-enabled payments at point-of-sale will enable card-less cash transactions, including cash withdrawals, at NFC-enabled ATMs (which WFC expects to represent 40% of all its ATMs by end-2016). In effect, WFC is looking to establish its mobile banking app as the de facto context for payments first because payment services are a cornerstone of the checking and credit account relationships and second because payments increase consumer engagement in the mobile banking app – extending capabilities beyond the existing balance-check and remote deposit capture – which reinforces the bank brand and consumer relationship.
  3. Consumer payment from within a mobile banking app may facilitate proprietary real-time services such as the presentment of transaction details, the integration of the earn-and-burn of coupons into the main payments stream (for retailers with whom WFC strikes bilateral co-marketing deals) and, for consumers who scan paper receipts at time of purchase, the linking of the account charges to receipt-scans. These services can be cloud-provided with Android Pay, and even Apple Pay (as Capital One does), but a proprietary implementation of HCE potentially facilitates in-app processing and reduces fraud risk since the bank has server-control over device tokens.

©2016, SSR LLC, 1055 Washington Blvd, Stamford, CT 06901. All rights reserved. The information contained in this report has been obtained from sources believed to be reliable, and its accuracy and completeness is not guaranteed. No representation or warranty, express or implied, is made as to the fairness, accuracy, completeness or correctness of the information and opinions contained herein.  The views and other information provided are subject to change without notice.  This report is issued without regard to the specific investment objectives, financial situation or particular needs of any specific recipient and is not construed as a solicitation or an offer to buy or sell any securities or related financial instruments. Past performance is not necessarily a guide to future results. The analyst principally responsible for the preparation of this research or a member of the analyst’s household holds a long equity position in the following stocks: JPM, BAC, C, WFC, and GS.

  1. https://www.youtube.com/watch?v=JQ8w_TbQqVA – at 4 minute mark
  2. These are imposed by AXP on all Amex-accepting merchants across all network-branded cards.
  3. See, for example, note of 7/3/2015 titled “Impact of Pricing Power of the Shift from PANs to Tokens”
  4. http://www.paymentssource.com/news/technology/walmart-other-retailers-on-why-mcx-can-beat-rival-mobile-wallets-3012969-1.html
  5. For a chip-enabled card, this cryptogram, also referred to as a transaction token, is generated by hashing the PAN with transaction information including the amount and point-of-sale terminal identifier.
  6. Earlier mobile payment solutions, such as Isis which was renamed Softcard, used secure elements store on the SIM but these require commercial collaboration with the wireless carriers providing the SIM.
Print Friendly