Apple vs. Banks in Mobile Payments

Print Friendly, PDF & Email



May 23, 2014

Apple vs. Banks in Mobile Payments

  • Based on its patent filings, we expect Apple to extend its Passbook app (currently reserved for gift cards) so that it is compliant with EMV contactless and tokenization standards. This means customers, via their banks, can enable iPhones for mobile bankcard payments at merchants who have installed iBeacon technology (with which Passbook is already integrated).
  • We expect Apple to position the iPhone as a digital shopping assistant (acting as an in-store navigator, “genius” recommender, virtual shopping cart, digital coupon-book, and mobile wallet all-in-one) rather than a stand-alone wallet. To make this work, merchants will need to install iBeacon technology rather than merely be compliant with EMV contactless standards.
  • To improve the business case, Apple will be looking for card-present or “CP” rates (more favorable to merchants than the card-not-present or “CNP” rates on a PayPal wallet) and hence an EMV-compliant solution. In particular, this means payments information will be transferred from device to point-of-sale (POS) system over NFC even if Bluetooth (BLE) is used for data transfer (e.g. real time messages and marketing) between iPhones and iBeacons. Apple’s patent is explicit about this “dual air interface”.
  • The bankcard-enabled version of Passbook will compete with mobile bank apps on Android devices into which mobile payments is incorporated using host card emulation or “HCE” (now supported by Visa and MasterCard). HCE is software built into the device operating system that allows a phone to emulate a card while card credentials are stored in the cloud. It differs from the Apple solution (where card credentials are stored in a secure element built into device hardware) and the Isis wallet (where card credentials are stored in a carrier-provided SIM card).
  • These three wallet solutions are the only ones that will qualify for CP rates and, in effect, substitute a phone for a card; other wallet solutions, such as PayPal, are assessed CNP rates because, in effect, they substitute a phone for a desktop.
  • Both Apple Passbook and Android-based mobile bank apps will use tokenization so that sensitive card account information is not passed to merchant point-of-sale (POS) systems.
  • Apple’s control of device hardware allows it to make a unique and important contribution to reducing fraud risk through using TouchID to generate identification-and-verification or “ID&V” information in the form of fidelity risk-scores on fingerprint scans. Given large banks view lower fraud costs as a source of competitive advantage, they will likely negotiate reduced CP rates to the extent Apple provides this ID&V information; merchants will benefit from these lower rates improving the business case for investing in iBeacons, and Apple will establish an important use-case for its secure biometric solution to digitally identifying and authenticating customers.
  • Longer term, Apple’s solution is likely to pitch it against banks in shaping mobile payments. In all three of the immediate Apple, Android, and Isis solutions, banks can control which cards are provisioned into phones and will seek to reserve the mobile channel for premium products – in other words, banks will provision in credit cards but not interchange-regulated debit cards. A mix-shift to high-cost products as customers migrate to mobile payments is precisely what MCX is seeking to avoid, and is a key reason the consortium has asked members not to accept mobile wallets other than the MCX solution. However, Apple may turn out to be a key enabler of the MCX solution.
  • While MCX will initially use QR-codes to transfer payments information between phones and POS terminals, we see the Apple solution as dovetailing well with MCX members who want to deploy iBeacon technology. Tokens for merchant-based card products can be provisioned into iPhones just as well as tokens for bankcard products, and merchants will find attractive the tight integration of payments and proprietary loyalty programs in Apple solution.
  • Merchants will be concerned about the risks of data leakage in all third-party wallet applications but Apple is likely to position, credibly with both consumers and merchants, around better control of data than Android-based solutions.

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


Apple is important to mobile payments because of its ability to catalyze consumer adoption. In practice, we believe the firm’s objective is not to enable mobile payments in isolation but position the iPhone as a digital and personalized shopping assistant. Enabled by iBeacon (Apple’s brand for data transfer between devices using Bluetooth Low Energy or BLE), the iPhone can be in-store store navigator, “genius” recommender, virtual shopping cart, digital coupon book, and personal cash register all-in-one. Communication with in-store BLE transmitters (or “beacons”) will provide a “micro-location” context more precise than available from GPS.

Apple Patent

The real-time digitization of shopping activity, folded into micro-location data, opens the door for a retailer to engage with consumers with one-to-one relevance – for example, pushing real-time messages and e-offers on goods related to those already selected or included in a shopping list. Having scanned selected items into a virtual shopping cart, customers will ultimately check out by authorizing payment through an integrated iWallet that communicates with the retailer point-of-sale (POS) systems. Apple has filed a sequence of patents pointing to this shopping sequence with the most recent, published by the USPTO in January[1].

In its patent, Apple notes that current mobile wallets send payment information such as credit card data directly from the secure element of phone to POS terminals through proximity “air interfaces” such as near-field communications (NFC) radio technology. The payments information is not available to apps because it contains sensitive account numbers and other information that, if intercepted, could be used to make unauthorized purchases. Apple also notes the limitation of dependence on NFC: the customer must bump, tap, or wave the phone on, or within a few inches of, the POS terminal which limits mobility and the potential for exchanging information to a short time window.

Apple looks to solve the security limitation through tokenization and the proximity-limitation through a dual air interface (with NFC to securely pair phone and POS, and BLE for less sensitive data transfer). The patent describes tokenization as “using an alias to identify a purchasing account such as a credit card”. These aliases or “tokens” will be provisioned into the secure element of the phone from the cloud; they are not valid without the corresponding device-ID and can be disabled after each use, and so are worthless if stolen. Apple argues that its solution provides a “commercial transaction that is both secure and user friendly” because the customer has increased mobility and because tokenized payments information is safe enough for app use.

Below, after a review of the authorization, EMV, and tokenization standards that have shaped Apple’s patent, we describe how Apple’s mobile shopping app (likely an extension of the Passbook app which is already BLE integrated and can be used to pay with digital gift cards) will compete in the mobile space for bankcard payments with mobile banking apps on Android phones leveraging Google’s host-card-emulation technology.

Authorization and EMV

When a customer swipes a payment card at a POS terminal, the retailer sends a message to the issuing bank requesting an authorization for the transaction. To manage fraud risk on lost and stolen cards, large banks have invested heavily in authorization infrastructures which, by lowering relative fraud costs, are a source of competitive advantage. That advantage degrades as system-wide fraud is reduced which is one reason the large banks have equivocated, at least until recently, around initiatives such as EMV and tokenization which reduce fraud. Today, and particularly with the Target data breach, the game is up and both banks and networks are committed to migrating to EMV and tokenization.

The EMV standards encompass both contact payments (where a chip-enabled card is slotted into a chip-reader) and contactless payments (where a phone is positioned in close proximity to an NFC-enabled terminal in a “bump”, “tap”, or “wave”). Merchants must implement both acceptance technologies to obtain relief from the liability-shift which occurs in October 2015 under which, merchants (and not issuers as at present) bear liability for fraud losses if an EMV-compliant card is presented to a merchant that does not have an EMV-compliant POS. MCX members are resisting the linkage of EMV-compliant contact payments to contactless since they want to reserve the mobile channel for their own products and prevent banks from carrying-over current card-industry pricing and practices to the mobile environment. As discussed below, this could have important implications for Apple as the most credible competitor to mobile bank wallets.

Two Different Classes of Wallet: Card-Present and Card-Not-Present

Regardless, the EMV standards are explicitly linked to communication between payment device and POS terminal over NFC with card-present or CP rates, which typically apply for card swipes, available if the card credentials (whether or not tokenized) are passed to the POS terminal and less merchant-friendly, card-not-present or CNP rates if not. Aside from rates, an important difference between CP and CNP transactions is that the issuer bank underwrites fraud risk on the former while the acquiring bank (and, hence, merchant-of-record) underwrites fraud risk on the latter; this is why PayPal’s business model has depended on building over time leading fraud risk management capabilities.

With the exception of Isis, early mobile wallets have attracted CNP rates because, in effect, they extend an e-commerce protocol to the physical point-of-sale. For example, users of the PayPal wallet initiate transactions, whether on-line or in-store, by entering their PayPal credentials and triggering PayPal, not the end-merchant, to request payment from the issuer bank based on the card information it has on file. As a result, PayPal bears settlement risk if the issuer declines the transaction and, to accept the wallet, merchants must explicitly enroll with PayPal.

Card-present wallets are different in that the authorization request is made by the end-merchant, just as if a physical card had been swiped, and not the wallet provider. Merchants can accept these wallets, if they accept the relevant network brand in an EMV-compliant way, and do not need to enroll with the wallet-provider and the wallet-provider takes no settlement risk. To work in this card-present way, mobile wallets must pass card credentials, possibly in tokenized form, to the POS terminal and that means these credentials must be securely available to the phone. There are three possible architectures for this:

  • Card credentials are provisioned into a secure element built into the carrier-provided SIM card. This is the approach adopted by the Isis wallet, and it provided the carriers with the opportunity to charge issuer banks for access to the SIM card.
  • Card credentials are provisioned into a secure element that is built into the phone hardware (as opposed to the SIM card). This is the approach that Apple, with its control over iPhone hardware, will adopt.
  • Card credentials are provisioned into a secure element that is built into the phone operating system. This is the host card emulation or HCE approach that Google adopted in its release of Android “KitKat” 4.4 last September and for which Visa and MasterCard announced support and specifications in February. We expect banks to integrated payments capability into their mobile banking apps on Android phones using HCE.


Card-present wallets pass card credentials to the merchant POS and, in doing so, have the potential to create the same potential for theft of card data from these systems. The EMV standard in itself does nothing to address this since it allows for card credentials to be passed raw as they are in the case of the Isis wallet. The Apple and Google solutions, however, will address this using tokenization compliant with tokenization standards for IP-connected devices promulgated by the Visa, MasterCard, and American Express networks beginning last October.

The essence of tokenization is that the card account number is replaced by an alias or “token” that is valid only when presented with the proper device-identification and typically for only one transaction. In practice, this means merchant systems are less likely to be attacked because stolen tokens are worthless; they cannot be used without the device to which they were provisioned and, even then, may have expired. An example of specific mechanics is that an issuer bank provisions tokens into a secure element (whether built into the phone SIM, hardware, or operating system) with a few being stacked in reserve in case connectivity is lost. At time of payment, the token is passed through the merchant, acquirer, and network systems to the issuer where it is matched back by a “token directory” to the original account number against which the transaction is authorized or declined.

In this example, the bank is acting as the token service provider or TSP in providing tokens and maintaining the token directory. This is not the only possible configuration and, indeed, the networks will likely act as TSPs for smaller banks that do not want to support their own token systems.

Apple’s Card Present Solution

To position the iPhone as a BLE-enabled shopping assistant, Apple needs to persuade merchants to install beacons, and the merchant business-case is helped if the associated payments are at card-present rates; these are only available on contactless payments that are EMV-compliant and compliance is, in turn, predicated on wireless communication of card credentials, whether or not tokenized, over NFC.

The impact of the insistence by networks (who set EMV standards) on NFC can be seen in Apple’s patent. From a technology standpoint, there is no reason for a dual air interface. BLE alone would be sufficient for the transfer of payments information and would relieve the customer from having to present the phone at a POS terminal (since it could interact at a distance with a BLE-enabled POS system). However, card-present rates are available only on EMV-compliant mobile transactions and EMV is, in turn, tied to NFC. Hence, Apple’s patent calls for a dual air interface where most data transfer will be over BLE but, for purposes of EMV compliance and despite the loss of customer mobility, certain payments information will be over NFC or something that emulates NFC.

There is also an important impact on the implementation of tokenization. With 800mm cards-on-file, Apple could implement its own tokenization scheme and maintain a token directory; this would achieve the security objective of ensuring tokens, not card account numbers, passed through merchant systems. However, such a scheme would likely not be qualified for card-present treatment leaving Apple with fraud risk and merchant-adopters of iBeacon technology with high card-not-present rates. Large banks do not want to give up control of the token directory particularly if they are liable for fraud risk.

This means that Apple will be working with large banks, and with the networks on behalf of smaller banks, to provision card credentials into the iPhone secure element. While similar from a technology standpoint to the discussion between banks and carriers over the provisioning of card credentials into the secure element of a SIM card, the commercial discussions between Apple and banks will likely be different. In particular, given Apple’s objective is to position the iPhone as an iBeacon-enabled digital shopping assistant, it is unlikely to be looking to monetize access to the secure element through carrier-like tolls.

Customer Identification and Verification (ID&V)

However, Apple is likely to be able to generate better economics from banks by providing fidelity risk-scores for fingerprint scans. Tokenization standards call for the authorization request to include the token and the device-ID, but banks will still want some assurance on the identity of the cardholder. In the case of HCE-enabled mobile bank wallets on Android phones, this ID&V information is directly available to the issuer in the form of a customer log-on to the mobile bank app; in the case of the iPhone, the ID&V information is in the form of a fingerprint scan captured through TouchID that is available to Apple rather than directly to the bank.

Given large banks compete by lowering relative fraud costs, and have invested in extensive authorization infrastructures for this purpose, there is likely to be a willingness-to-pay for Apple’s biometric ID&V information that will probably be reflected in reduced card-present rates on transactions where this information is made available to the issuer; we may even see risk-based CP rates which are adjusted depending on the biometric risk score. While reduced CP rates benefit the merchant rather than Apple directly, they improve the merchant business case for accepting the Apple wallet and hence adopting iBeacon technology.

Apple and MCX

Banks are likely to work with Apple for biometric ID&V data to gain an edge (or at least avoid being disadvantaged) in fraud risk management but, in the process, will lose some control over authentication; this may have unintended consequences just as did the loss of control of authentication on e-commerce transactions to firms like PayPal. This relevant history is that, in the 1990s, consumers were reluctant to enter card credentials on multiple e-commerce web-sites creating an opportunity for PayPal to allow consumers to access credentials it already held in file by entering a PayPal ID and password on the web-sites of participating merchants. Having gained control of customer authentication, PayPal opened up new routes for settling transactions, including ACH-enabled transactions, which benefited its economics at the expense of the banks (who lose out on the interchange generated by Visa/MasterCard payments but not ACH payments).

Similarly Apple, having achieved consumer adoption of its biometric technology for secure payment authentication, is in a position to open up new routes for settling payments transactions (and, more broadly, explore new use-cases for digital identity authentication and management). In payments, Apple’s patent and

approach is not restricted to tokens provisioned into the secure element of iPhones by banks or even to payment accounts administered by banks, and there is no technological reason why MCX could not provision in tokens for DDA accounts provided by customers choosing to enroll in the MCX payments and loyalty platform. Indeed, from Apple’s standpoint, this would be a natural extension of the Passbook app into which consumers already provision gift cards and which is already integrated into iBeacon technology for micro-location based marketing and messaging.

We have no information that this is contemplated by MCX which has been steadfast that it plans to launch with a system where phones communicate with POS terminals via QR codes rather than radio; and some merchants, notably WMT, have been vocal about their opposition to contactless NFC-enabled payments. However, this opposition is routed in an understanding that the bank agenda is to reserve the mobile channel for credit cards so that, from the retailer perspective, consumer migration to mobile risks being accompanied by a shift in the transaction mix to higher-cost payment products. Apple is not beholden to this bank agenda and indeed, in positioning the iPhone as a digital shopping assistant, will want it to be enabled for the preferred payment choice of its customer. If that is an MCX product, rather than a bankcard product, so be it provided the credentials can be tokenized and provided the retailer can accept transactions wirelessly.

MCX merchants are deeply concerned about the control and protection of payments data, and do not want to risk it being used to drive their customers to competitors, and any third-party wallet-provider will need to provide assurances around data protection and system integrity. Given that its business model does not depend on advertising revenues, Apple is in a stronger position than other wallet-providers to credibly provide these assurances.

Print Friendly, PDF & Email