Tokens: Any Volunteers?

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,, 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 –  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)

  1. Consumer presents Token (virtually or physically) held by consumer (or 3rd party)
  2. 16 digit “token” treated same as card (although not a V or MA PAN)
  3. Processor routes token to Bank Token Authority (TCH) in an ISO 8583 transaction
  4. TCH can resolve token directly (switch to network), or forward to participating bank for resolution (switch to network)
  5. JPM resolves token to Visa Credit, if on Merchant is CMS customer.. then on-us (No Visa Interchange). If non CMS, route through Visa.
  6. Authorization sent to Acquiring bank/Processor
  7. Authorization sent to both merchant payment terminal and to 3rd party wallet provider (?). Pilot prospects.. negotiate this one HARD
  8. POS settlement

16 thoughts on “Tokens: Any Volunteers?”

  1. Tom, what is the consumer benefit of that yet another layer?

    I guess an interesting use case to explore is “use ANY token (identifier) to link to any payment method). But even them, if my iTunes account is linked to my card, why would I use iTunes instead of the card itself?

  2. This discussion of tokens reminds me a lot of the mobile wallet fight, in that it involves a sort of prisoner’s dilemma (; if all parties cooperate, all will benefit in the form of cost savings, lower fraud, and expanded commerce; however, there is a strong temptation to engage in selfish behavior that increases short-term returns at the expense of the marketplace as a whole. This temptation does not actually have to be acted upon; the mere threat is enough to stall progress.

    As a result, what I see is a proliferation of tokens of various forms: e-mail addresses, phone numbers, user IDs, virtual card numbers, biometrics, etc. Card numbers and bank account numbers are tokens themselves, although lacking in security. One approach would be for various parties to start accepting each other’s tokens; this is what PayPal does, essentially translating an e-mail address or phone number into a card number or bank account number. Some banks have started to support PayPal and other networks on their own online banking sites, essentially ceding some control in exchange for what they hope will be higher customer satisfaction and loyalty.

    A possible solution to the prisoner’s dilemma comes in repetition; if the game is played over many rounds, eventually the players do begin to cooperate more. Thus, like so much else in payments, I see tokens as a gradual, iterative process. “Cheaters” have to fail, and recognize the impossibility of “winning” the game, before they will consent to cooperate.

    One reason I like the idea of using a 16 digit token is that it appears to balance security with interoperability; I personally hate having to use my e-mail address or phone number as a token, because it gives away too much information about me. Unfortunately, I think we’ve got a few more years of failed attempts at market dominance before enough trust emerges to allow it.

    1. If one has to disclose the token during a transaction, there is no security benefit. If you need “token + authentication”, then the token could be anything.

      In case of bank-issued tokens, that’s just the means of disintermediating the “wrappers”, as far as I can see…

      1. Alexander, your comment perfectly illustrates the “dilemma” part of the prisoner’s dilemma. Your statement that bank-issued tokens would “just” be the means of disintermediating the “wrappers” (and thank you thank you thank you for using the word “disintermediating” properly!) suggests to me that you believe banks would never issue tokens out of enlightened self-interest, just to grow the whole pie and maintain their relevance to the payments industry. This mutual distrust is what is holding up progress. Yet I see more and more bankers who recognize that end-to-end control is no longer possible, and are willing to consider collaborative solutions, particularly to counterbalance the JPMorgan Chases of the world.

        Fortunately, ISO/IEC 7812 is an open standard, and there are several banks already who will issue 16-digit numbers to non-banks (see Bancorp Bank, for instance). Technically, you could use the standard without any bank involvement at all, as long as you stay out of the bank card networks. A 16-digit token without in-line authentication can work as a security measure if it is unique to a single transaction – what Orbiscom called a single-use card number. In this case, the authentication is done when the token is generated, not when it is used. I do not assume that such tokens would necessarily be controlled by banks, and in any case consider them preferable to e-mail addresses and phone numbers, which have unrelated uses that I don’t care to expose, and which can change for unrelated reasons, such as a move or job change. On the flip side, I can’t easily change my e-mail address or phone number, so unless I want to generate a whole bunch of fake Gmail accounts, I’m stuck. I recognize the weaknesses of the 16-digit token, but it seems to have the least downsides of any alternative.

      2. Thank you for the explanation, Aaron. To get one-time token (OTT), one has to ID himself/herself (using some fixed identifier) and then authenticate. If that step is assumed to be secure, why not just stop there?.. I.e. if we can do secure authentication using fixed ID, how does (subsequent) OTT makes it any better?

        Getting OTT via out-of-band channel could be the answer, but then ubiquity and ease of transaction flow suffers, IMO.

  3. Hi Tom,
    We have 20+ commercial installations around the world using our patented processes and methods in their mobile payment/mobile banking/mobile security services.

    After the secure online authentication direct to the issuer of the mobile service, the only thing used in the payment transaction is a one time ticket. No sensitive data like account/card number, CCV, etc. is communicated/transferred during the transaction nor stored on the mobile (= no need for a SE).

    Customer includes PKO Bank Polski, 4T (the four largest MNO’s in Nordics), PayPal, Borica, the largest bank in MEA, a number of banks in LA, etc.

    We will be at Money2020 and will be happy to join your panel with insite on a real and disruptive alternative to schemes from card companies, GSMA and Google/ISIS.

    1. Hi Lars, if you can securely authenticate user using fixed ID, why not use the same secure approach for the transaction itself? I.e. why is OTT is needed at all in that case?..

      1. Hi Alexander,
        Here is the short version.
        The OTT is used for matching and verification of the payment between the user and the merchant. It is not used for identifying the user towards the issuer itself. That is already done in the secure channel between mobile application (thin client) and the issuer (server side).
        After the initial identification of user and then the matching of user merchant is done, solution at issuer (server side) initiates the financial transactions down towards the clearing and settlement.

      2. That’s still CNP, as far as the merchant is concerned, so what’s the benefit? Compared to a “chip-n-PIN” (with P2PE), what problem does it solve and who for?

        1. No sensitive info is transmitted nor stored on the mobile, so for example no need for a secure element on the mobile, merchants could use cheaper terminals as for example merchant app’s on a mobile/tablet. Reach for electronify cash for the longtail small merchants and temporary merchants at fairs/exhibitions/flee markets, etc. etc.

Please Login to Comment.