Apple vs. Banks in Mobile Payments: Update

Print Friendly, PDF & Email



May 30, 2014

Apple vs. Banks in Mobile Payments: Update

  • The first media reports[1] appeared today of Apple’s discussions with retailers around a mobile payments system where payments are integrated into a premium shopping experience relying on wireless communication between iPhones and iBeacons (as piloted already in a few Apple stores).
  • While the initial launch will likely be a “pay-with-iTunes” model leveraging Apple’s 800mm cards-on-file, we expect this to evolve to a model that is compliant with network “EMV” standards using NFC to pass card credentials from the secure element of the iPhone to the merchant point-of-sale (POS) system as outlined in our note of May 23rd “Apple vs. Banks in Mobile Payments”.
  • There are three implementations for EMV-compliant mobile payments that vary in where the card credentials are securely stored: on the SIM card (which is the solution for the Isis wallet); in the operating system (which is Google’s “host card emulation” solution launched last September for Android “KitKat” 4.4); and on a secure element embedded in the ‘phone hardware which is a solution that will be adopted by device manufacturers such as Apple.
  • The advantage of EMV is that merchants receive the lower “card-present” rates that apply for physical card transactions than the higher “card-not-present” rates that apply for e-commerce; in addition, merchants are indemnified by banks against fraud losses. The disadvantage of an EMV implementation, from Apple’s standpoint, is that it cannot use cards-on-file but will rely on NFC communication to pass bank-provided tokens (aliases for card credentials) from the secure element built into iPhones to merchant point-of-sale (POS) systems.
  • There will likely be an important negotiation between Apple and large banks over the terms under which these tokens will be made available, and this will broaden to encompass bank-funding of rewards programs and the provision by Apple to banks of the risk-scores from fingerprint scans on TouchID devices; the scans themselves, of course, are unavailable even to Apple.
  • These risk scores are valuable because they have the potential to allow banks to reduce fraud losses, and raise the possibility that the Apple mobile product may involve lower costs to merchants not only than the card-not-present rates that apply on, say, PayPal transactions but also the card-present rates that apply on physical cards.
  • In an architecture where tokens are provided by bank issuers and reliable cardholder authentication is provided by a mobile phone, the value of network-level fraud risk-management services declines. More broadly, mobile may catalyze a shift of intelligence to the periphery of the networks.
  • While public figures are not available, we believe fraud services account for a meaningful portion of the difference between the network fees charged by V and MA (6-7 cents/transaction for debit and 11-13 cents for credit) and the sub-1 cent fees charged by national payments systems such as Interac in Canada and EFTPOS in Australia; we do not expect even the for-profit FIS to charge more than 2 cents/transaction to for processing MCX transactions.


There are media reports today that Apple is in discussion with retailers selling luxury goods and premium brands around a mobile payments service that would be integrated with broader digital services enabled by iBeacon technology. As discussed in our note of May 23rd “Apple vs. Banks in Mobile Payments” and illustrated in Exhibit 1, Apple has filed a number of patents involving the integration of NFC technology for communicating with merchant POS systems (presumably for payments) and Bluetooth technology for a wider-ranging and more durable wireless connection (presumably for in-store micro-location based services and messaging).

Exhibit 1: Illustration from Apple’s Patent for Dual Air Interface Incorporating NFC and BLE

The Card-on-File Model (i.e. Pay-with-iTunes)

Initially, we expect the Apple mobile payments service will work just as when you “pay with iTunes” for an in-app purchase or some accessories at selected Apple stores. This means it will be a “card-on-file” model, as at PayPal for most transactions, where the merchant-of-record is Apple, and Apple then forwards proceeds to the end-merchant. The advantage of this implementation is that it can be enabled for all of the 800m card accounts on file at Apple.

The disadvantage of the “card-on-file” implementation is that merchants will receive the “card-not-present” rates and liability for fraud loss that applies for e-commerce, not the lower “card-present” rates and indemnity from banks against fraud losses that apply for point-of-sale (POS) transactions compliant with EMV standards. In these transactions, card credentials pass through POS systems and ultimately (via the acquiring processor and network) to the issuing bank for transaction authorization rather than being submitted by Apple, and the merchant-of-record is the actual end-merchant and not Apple. Aside from the better rates and lower fraud risk to merchants, this will also take Apple out of the role – and potential reputation risk – of intermediating between iPhone customers and end-merchants on disputed transactions.

The EMV Model (i.e. using NFC and a Secure Element)

Use of near-field communications (NFC) radio technology is part of the EMV standard which, we believe, is why Apple has filed the patent in Exhibit 1 above for “dual air interface” technology, where an iPhone is enabled for both NFC and Bluetooth wireless communication. Apple needs to range and durability of a Bluetooth connection to provide the premium shopping experience (in-store navigation, location-based “genius” recommendations, virtual shopping list and cart, digital assistant) that it is promoting as brand-enhancing to merchant prospects. There is no technological reason the Bluetooth connection could not also be used to communicate payment credentials, and this would have advantage over NFC’s short-range (3-4 inches) capability of untethering consumers from the cash register. However, Bluetooth is not EMV compliant hence Apple’s patent for a dual air interface.

The other EMV requirement is that card credentials be stored on a secure element of the ‘phone, and there are only three locations for this:

  1. On the carrier-provide subscriber identity module or SIM card. This is the basis of the Isis mobile wallet, now supported by AXP, JPM, and WFC, and rolled out last July (see our note “Mobile Payments at the Tipping Point of August 5th). The drawback of the approach is that some of the economics are appropriated by the carriers in return for providing access to the SIM card.
  2. On the operating system. This is the Google solution where, through host card emulation or “HCE” launched with Android 4.4 “KitKat” last September, the phone emulates a physical card using software while the actual card credentials are securely stored in the cloud (on a “virtual” secure element, if you like). Visa and MasterCard announced standards support for HCE in February.
  3. Embedded in the hardware. We believe Apple will adopt this solution given its control of hardware and given it has already built a secure element into iPhones to store fingerprint scans, for example.


The EMV standard is surprising in that it does not address the vulnerability of merchant systems to attack, but seeks to address counterfeit fraud (accounting for 70% of dollar fraud losses vs. lost and stolen cards) by replacing mag-stripe cards (easy to clone) with chip-cards (harder to clone); in other words, under the EMV standard, card credentials can be passed in the raw from the secure element of a ‘phone to the merchant POS system.

In practice, we do not expect Apple to implement EMV in this way and risk exposing itself to the reputational damage of association with a data breach. Rather, it will implement a tokenized approach compliant with the standards emerging from Visa, MasterCard, and American Express. In a tokenized approach, the card credentials are substituted by an alias, or “token”, that is passed from the mobile device to the merchant POS system and submitted for transaction authorization by the merchant (not by Apple as in the pay-with-iTunes model) to the network and issuer who “resolve” the token to the card credential based on a “token directory” that maintains the mapping between tokens and card credentials.

The advantage of tokens is that they can be limited life, and even one-time, and context-restricted (so that if a token intended for use on a mobile device appears in an authorization transaction on an e-commerce transaction it is invalid).

Apple vs. Banks

The challenge for Apple of implementing tokenization is that it needs tokens from the banks or networks; in practice, the large banks will want to control their own token directories but smaller banks may allow Visa or MasterCard to manage tokenization of their transactions. In other words, the 800mm cards-on-file cannot be used. (In theory, Apple could implement its own tokenization scheme but it is hard to see banks then accepting fraud liability and this is, after all, a key motivation for adopting EMV standards).

While Apple may launch its mobile payments service in a cards-on-file model (where tokenization is moot since it is Apple, not the end-merchant, who is submitting the authorization request so that card credentials never enter the merchant POS system), we imagine the objective is to transition to an EMV-compliant tokenized scheme to improve the value proposition to merchant customers: lower rates and bank indemnity against fraud risk.

This transition is going to involve Apple in an important negotiation with large banks over the terms under which they provision tokens into the secure element, and the negotiation will likely broaden to include bank-funding and cobranding of loyalty programs and the terms under which banks can access the identity and verification or ID&V information generated by the fingerprint scans from TouchID-enabled ‘phones.

TouchID and the Management of Fraud Risk

Fraudulent transactions occur when a thieves attempt to pass themselves off as valid cardholders. In developed Europe, this is managed through a standard “something you have and something you know” security model; the something-you-have is the physical payment card (which is chip-enabled to make it more difficult than a mag-stripe card to clone), and the something-you-know is the personal identification number or PIN. A different security model from this chip-and-PIN approach has evolved in the US because a ubiquitous and reliable telecoms infrastructure allowed for real-time validation of transactions against network-level algorithms that seeks to deny fraudulent transactions by looking for patterns indicative of identity theft.

While public figures are not available, we believe these authentication algorithms are an important contributor to the profits of Visa and MasterCard and help explain the difference between their network fees (6-7 cents/transaction for debit and 11-13 cents for credit) versus the sub-1 cent fees charged on national payments systems such as Interac in Canada and EFTPOS in Australia. We do not expect the for-profit FIS to charge more than 2 cents/transaction for network processing to MCX.

In mobile payments, and the Apple system in particular, fraud intelligence is likely to move from the network to the periphery at least for large banks. For example, these banks will provide the tokens that protect against fraudulent interception of card credentials so reducing reduce system-wide fraud losses and hence the value of network-level fraud risk-management. Apple’s fingerprint-scanning has the potential to further reduce fraud risk by providing more a more reliable means of authenticating the cardholder than a signature.

Apple, of course, owns the identification-and-verification (ID&V) information arising from the finger print scans in the form of risk scores that quantify the closeness of the fingerprint match on each transaction; the actual scan, of course, is on the secure element of the ‘phone and unavailable even to Apple. Given these fingerprint risk scores have the potential to reduce fraud losses to banks, it is possible that by making them available to banks Apple will be able to negotiate merchant rates for the EMV-form of its mobile payments service that are not only lower than the card-not-present rates on, say, a PayPal transaction but also lower than the card-present rates on physical cards (because of the more reliable authentication provided by a finger-print scan). Indeed, in due course, we may see risk-based pricing where the card-present rate is linked to the biometric or other ID&V information from a wallet platform such as Apple.

Print Friendly, PDF & Email