19 June 2013
I’ll be leading a panel on Tokens at Money 2020 so thought I would spend a little prep time this week.
V, MA, TCH token initiatives all share one very big problem: no volunteers. Visa is the furthest along organizationally.. they tried tokens before (2010 Token best practices), technically there was nothing wrong with Visa’s previous efforts. The primary problem was that network participants (POS, Card Reader, Gateway, Processor, Acquirer, .. ) were ill suited to transmit anything but a 16 digit PAN. Now that we have 16 digit tokens (likely based upon ISO/IEC 7812 BIN ranges owned by individual banks), the network CAN forward them for resolution.. these tokens are not Visa, MA, or ACH numbers.. they are an identifying “key” to information (other cards).. which only the holder can determine. This is the heart of what I referred to in Directory Battle Part 1.
If you were a merchant and a vendor came to you with this proposition “give me all of your customer information, I will lock it up.. and give you one of my keys for you to access it”… would you do it? There are some possible business cases around fraud/data leakage liability…. but customer information is somewhat important to most businesses. Token value propositions are not much different.. give me all your stored cards and I’ll give you a token. At least Visa and Mastercard have rules around PAN.. but what are the business rules around tokens? Think of the Amazon world where I select from a list of stored cards… does the customer have to consent to exchange of PAN for token? In instances where I have multiple bank accounts/cards. Will there be a token for each bank? for each card? (Networks are prohibiting “non compliant” schemes today). How does customer select instrument (debit/credit) if multiple products are behind token.
I believe that if the consumer has given a merchant payment information, it is an asset that they should only part with if there is a significant value exchange (data, rates, …). The idea that a merchant would willingly part with card data is just plain silly.. and hence the lack of pilot participants.
The only way I see this working is if banks “push” tokens into every wallet/retailer. Automatically enrolling them into Google, Amazon, V.me, Apple, PAYPAL, … In this model consumers are permission banks to assist with “fast checkout”. In the NFC world this is akin to “provisioning” a card.
We are very far away from seeing tokens at the POS “work” in any business sense, as there are no clear business drivers (beyond giving banks greater control of payments). Banks are not solving a consumer problem, nor are they solving a merchant problem. It is a strategy to maintain control (rules, rates, liability, speed, clearing, network, …). There is also friction within competing networks as MasterCard and Visa do not want to be wrapped by a TCH token, nor vise-versa… As stated previously, in the eCommerce world V/MA could see substantial success if they replace VBV/MSC with this token approach, shift liability to banks and give discount CNP rates. Banks would have great trouble replicating this eCommerce approach because they are in a very poor position to influence eCommerce gateway/processors.
From my view the future of any Token must be driven by customer first. This is where the best opportunities exist for MNOs, and the Banks (physical distribution). I call this federated identity management. Enabling a way for your real world ID to be associated with your virtual accounts and IDs (see my blog on Apple – https://tomnoyes.wordpress.com/2013/04/03/apple-and-nfc-part-2/). Currently Apple, Google, Amazon and Square are leaders here… although there is a$5B opportunity for MNOs if they could put a team together with some focus.
My updated view on TCH token framework – Usage (“Wallet” transaction for JPM Visa Credit Example)
- Consumer presents Token (virtually or physically) held by consumer (or 3rd party)
- 16 digit “token” treated same as card (although not a V or MA PAN)
- Processor routes token to Bank Token Authority (TCH) in an ISO 8583 transaction
- TCH can resolve token directly (switch to network), or forward to participating bank for resolution (switch to network)
- JPM resolves token to Visa Credit, if on Merchant is CMS customer.. then on-us (No Visa Interchange). If non CMS, route through Visa.
- Authorization sent to Acquiring bank/Processor
- Authorization sent to both merchant payment terminal and to 3rd party wallet provider (?). Pilot prospects.. negotiate this one HARD
- POS settlement