2 May 2014
Many great blog comments. Let me go through some generic questions/answers.
Apple wants BLE/Beacons/Tokens… but will not release wallet with this capability for following reasons (my best guess):
- Issuers must approve Token/Beacon model: creation/provisioning of token (TSP), use of tokens (not eCommerce), and assurance information. This was the reason behind my Assurance Blog this week.
- Apple is keeping the Banks in the dark to protect information on the launch (probably a good idea).
- Similarly merchants are being kept in the dark, no coordinated acceptance infrastructure. Thus iBeacons will likely be a phase 2 (or limited phase 1).
- Politics/negotiations/existing agreements. My guess is that Apple does want revenue from this new product, but will be disappointed. There is no economic model for a wallet provider in a card present transaction. This has been one of the reasons why NFC/Provisioning has failed, and the credit card only model.
- Payment is NOT the focus of Apple’s new services and Hardware.. (see blog Apple Greatest Asset – Ability to Change Consumer Behavior)
What makes most obvious sense for Apple in Payments?
In a perfect world Apple would convert all 600M cards to tokens and leverage this both for iBeacon/POS presentment AND for eCommerce. I believe this was their initial plan.. and still their plan. My view is that all eCommerce merchants and wallet providers would be glad to let the networks exchange COF for tokens.. a few of the big ones are my clients. Lets just say the network’s message “you have to work with EACH issuer on card present pricing, value proposition and data”. Yep it is that bad.
As you can imagine Issuers want revenue, credit card usage is incremental revenue.. Everything else in the iBeacon/token model above is a LOSS, thus Issuers are not exactly running to support. Thus token business issues abound for: debit, eCommerce, wallets, data, control, acceptance, …etc.
For example, Banks hate the idea of losing card not present (CNP) rates for eCommerce and having the networks locked into the TSP role. So Apple must keep a token in the phone, and also keep the 600M cards on file until the payment networks can get the cojones to define standards around assurance, tokens in eCommerce, and force issuer acceptance of risk and card present rates. Issuers have a strong case for caution, as Networks did this before (eCommerce/CNP liability shift) and failed miserably (see my blog vbv/msc Failure, and Bruce Schnieier’s similar post).
Data, data, data. My belief is that Apple is taking on the role of consumer champion (see blog Apple’s Platform Strategy: Consumer Champion). Apple may not realize that the this new architecture meaningfully impacts both bank and merchant data services. Merchants and processors will no longer have insight into the consumer card number, which in many cases is used for analytics and loyalty.
Issues/Unknowns
- Durbin/Hybrid Card. Per rule you can NOT wrap a debit card with a credit card. The card type must also be know to the merchant. If the Apple wallet has only one card per network, and consumer can store a debit card.. then that card must be a debit card. Perhaps Apple doesn’t know this, or the implications. Someone is pulling a fast one.. the networks certainly know this rule, and undoubtedly will feign ignorance when consumers try to register their debit cards… only to find out later that they can’t be used.
- Acceptance. If Apple launches with credit card only they will have failed to deliver any merchant benefit, or act as consumer champion. Similarly merchants (ex MCX consortium) will have little case for adding contactless acceptance if they don’t know the card/cost or everything is a credit.
- Process for taking the 600M cards on file and auto registering them with the networks. This could be going on now, with the networks building an issuer interface for approval.
- Tokens. Apple really wants to make this happen, but only Amex and Paypal are in a position to support. My recommendation to Apple would be to get moving with tokens and Amex… as a lever to make V/MA networks get moving.
- Pilot Merchants. Beyond the Apple store, I would pick Macy’s, Nordstrom, American Eagle, Gap, and a few others out as the most innovative in payments.. and the most likely pilot customers for a iBeacon shopping and checkout experience. Keep your eyes peeled.
- Will Apple move forward with an iBeacon breakout without network/issuer support? This would make sense in the US, where contactless adoption is terrible. Apple certainly has the expertise (and cash) to go strong on iBeacons, go around the networks and treat as CNP transaction (owning the fraud/risk) and manage the fraud internally. The could do this in select retailers (in US), and focus EMV Contactless capability outside the US.
I believe Apple didn’t put NFC in the 5s because they thought that they could launch Beacons without the Network’s support. When launched all iPhones will be able to take advantage (only BLE H/W dependency).
Completely agree, there is no money here for Apple to make from enabling and supporting payments in the iPhone specifically. It will come from the services Apple and/or from others paying Apple to engage the consumer as part of the commerce experience that Apple will deliver.
I don’t think having the Cards on File (COF) is worth anything for physical mobile payments because those credentials are essentially worthless for use with Contactless EMV.
I think Apple will be able to store multiple tokens for each individual card the consumer would like to put into their Apple Wallet.
Each Contactless EMV Card requires Apple to store the User Derivation Key (UDK) for the EMV credentials and because they will leverage NFC or Contactless specifically there is an additional key needing to be stored to generate the dCVV. These keys required to generate the EMV cryptogram and to validate the cryptogram and the dCVV are held by Issuers and are typically not shared with V/MA.
Now V/MC both have On-Behalf Of (OBO) services for EMV processing that they offer to Issuers, where Visa and MasterCard will generate the EMV keys and during an EMV transaction resolve them and pass only the results to the Issuers. The idea is to offer a quicker to market solution, or as an alternative for issuers who don’t want to upgrade their payment or core systems to handle the additional requirements of EMV. In one option, both V/MC support translating the EMV transaction all the way to a mag. stripe transaction. With that option, if the Issuer wasn’t engaged, they may not even realize that a transaction coming to them was sourced by credentials from V/MC pushed into Apple’s wallet and the Issuer would process it just same as any today.
Pair the V/MC Provisioning services with the OBO and V/MC doesn’t need any additional involvement to make it work from a technology perspective. It would be a very bold move to pull this off solo, but the banks will be jumping on board anyway.
With all of the above said, I still don’t understand how this works for Debit Cards because of Durbin’s requirement for multiple network choices OBO is worthless for Debit Issuers because the other “PIN” network would have to support this same process in some form so the merchant could have a routing choice.
I have more thoughts and questions on this I will share here later.
Think we are mainly in agreement, except for the token generation. Apple could certainly generate tokens, but they would not fit the bank definition. I think of this as the Venmo model. Issuer generation of token either directly or through their approved TSP is required to run within the V/MA/AMEX rules.
For the 600M cards on file, they could have a role in provisioning. You are correct, this is the classic NFC provisioning issue however Apple is not operating in the classic model. My educated guess is that there are 3 tokens in the phone at launch. A Visa, a Mastercard, and an Amex token. The networks modeled the solution on what Google did, but in stead of one mastercard … there are 3 cards, and opposed to google operating as the TSP, the networks have assumed the role.
Apple wants to pre-populate the wallet with registered cards. Every wallet wants to do that. Banks need to know what cards are already registered with Apple approve them. I’m almost certain this process is NOT worked out, as there doesn’t seem to be a bank that knows what is going on. Interesting that a few credit bureaus have gotten into the game, I hope Apple knows this approach. Go to the bureau and approve all of your cards going into the wallet. That would be totally cool.
My guess is that several issuers are going to have a fit at the Visa/MA TSP role. If the networks are smart they are trying to get 2-4 of the big issuers to bite so that everyone else follows. That is always how it is done.. but also how things die very quickly (think Visa Money Transfer)
Tom, agree with most of what is written in the blog as well as what Derrick mentioned.
Few points:
1. Completely agree on “Apple would be to get moving with tokens and Amex… as a lever to make V/MA networks get moving”, but i think V/MA would be more than willing to perform the TSP role.. depends on how big banks respond to it???… big banks already have their token infra (why would they want to go with V/MA unless Apple mandates to talk to only V/MA for tokens instead of individual banks… smaller banks would be more willing to go with V/MA as TSP)
2. Continuing with above point, how would commercials work?? In card present txn, even if V/MA do the TSP role, its a cost to them (Would they charge banks for this, who would be unwilling to pay.. or would V/MA fund it on their own in lieu of access to consumer data??)
For CNP txn, can V/MA try to charge merchant for TSP cost in lieu of shifting the liability to the banks?? (don’t think banks would agree to it)
3. As you mentioned in your earlier blog, i feel Apple will not expose the APIs for authentication to anybody except the iWallet/Passbook. A lot of retailers are already consuming Passbook APIs to put their loyalty cards, coupons, tickets etc. in Passbook. Going forward payments & loyalty redemption etc. through iWallet/Passbook will also happen after Touch ID authentication
4. I agree that this new architecture is a big impact to merchant/processors as they lose the consumer data, but it might not be a big impact to the banks (assuming V/MA handles the TSP part) apart from the fact that banks lose consumer data to V/MA as well (see my next point)… in fact the merchants will now be more consumer-centric in analytics rather than being card-centric.. Can retailers issue loyalty cards through its apps which can be added to iWallet/Passbook and redeemed every time a transaction is completed ???(that way retailers can have most of the consumer related data apart from the card number – For retailers, Loyalty is the new identity)
Otherwise, retailers would not agree to part with their data and pay Apple for consumer insights at some later point.
4. To what Derrick mentioned about V/MA OBO services ” In one option, both V/MC support translating the EMV transaction all the way to a mag. stripe transaction”… I don’t think the issuer will agree to this.. V/MA is aware of this… if you go through the EMVCo token specs, they have clearly mentioned that new POS entry modes field will be passed to the issuer as well
5. It looks logical that there will be 3 cards in secure element (Debit Card issue still not clear though)
6. Payments with BLE/Beacon might not come as of now, but does it makes sense to enable CNP (higher pricing) rates to retailers even if Apple can manage the risk well (would retailers go for it??).. In this case, can Apple can let the retailers own the risk but charge them for reducing the risk (because of Touch ID)
Vipul, these are great questions.. and unfortunately on this one I will have to be silent. It surrounds too much of our active work.
Amex, Discover, and to some extent paypal run under a unique regulatory regime that allows their product to wrap another card. Amex has a tremendous asset in Serve. Paypal does this online today, but has very little traction at POS. In essence, Paypal, Amex, DFS can allow for an iBeacon model to run by having ONE network aggregate many payment accounts. Instead of 3 cards in the APple wallet it is One (PP/Amex/DFS) with Card Present rates. The other unique aspect to Amex/DFS is that they own the merchant AND consumer agreements. They are uniquely position to define the rules of operation. In the Apple case they would define “an Apple Token transferred via iBeacon is a Card Present Transaction”. V/MA can’t do that (see blog)
In the back end Amex could translate this token to any other payment card… AND Amex could set the price of this product at anything they want to.. (no Durbin compliance issues).