Token Activity – 10 Approaches?

11 December 2013

I’m preparing for a few institutional investor chats next week in NYC and thought it was time to update my view on the payment landscape. Summary: much chaos and noise, with existing players throwing sand in everyone else’s gears… lots of energy.. but NO HEAT. This blog contains a brief inventory of initiatives I’m aware of. One of the reasons I do this is to solicit further dialog from blog readers.. so your thoughts are always appreciated. It is very difficult for small companies to identify activities which will impact them.. turns out that most non banks and even Visa and MA are ill informed on some of these as well.

In my June Blog Tokens: Merchant Options, and September blog Money 2020: Tokens and Networks I laid out 5 token initiatives.. we have now almost doubled..

The key differentiation between these Token initiatives is WHERE the translation occurs (Wallet, POS, Processor, Network, Issuer).  Translation is also referred to as DIRECTORY, which I define as the mapping of consumer information to payment information (see blog Battle of Cloud Part 1). The owner of the consumer directory is the winner in all of this, as the value of payment pales in comparison to the value of data and the consumer relationship. This is the core of the token battle

Inventory is for POS payments only. 

Token schemes

  • Form A (TCH Pilot – Processor Translation)
    • Consumer Directory: Bank
    • Token is presented to Merchant at POS (QR code, NFC, Barcode, …)
    • POS forwards token to Merchant processor (ie Elavon)
    • Elavon translates token into card through TCH service
    • TCH can resolve token directly (switch to network), or forward to participating bank for resolution (switch to network)
    • Issuer sends Authorization to Elavon
    • POS settlement
    • Patent issues surrounding merchant processor translation of tokensTCH Scheme
  • Form B – Wallet Translation (Push Payments)
    • Consumer Directory: Wallet
    • Token is presented by Merchant and read by Wallet. Token represents MID, TID, Processor and Amount
    • Merchant POS is awaiting authorization as if a card was swiped
    • Wallet sends token to Issuer (circumventing Visa/MA). Note this is WEAK LINK as data connectivity required for Consumer’s phone at POS
    • Issuer translates token into authorization, sends to processor
    • Processor passes authorization through to TID as if card was swiped
    • SMS based payments done in this model for years. Form of tokens could be beacons, QR, biometrics. Difficult to patent as core for operation is consumer directing bank to make payment.
    • Key differences (globally) are how consumer IDs the merchant and amount, and how does issuer pass the auth
  • Form C (C for Chase with their unique VisaNet deal)
    • Consumer Directory: Bank
    • Token is card number, Presentment is TBD.
    • If Merchant is a CMS merchant, Card routes through JPM’s version of Visa net for offers/incentives (given merchant participation.. of which there is none).
    • If Consumer card is JPM then deliver Card Linked Offers. Again.. not much here.
    • Unique capabilities, but all based upon Visa’s network. Barrier to replication is the unique deal that JPM constructed to “branch” VisaNet
    • JPM Visa flow
  • Form E – EMV/NFC
  • Form G (G for Google’s old Mastercard proxy model)
    • Consumer Directory: Google
    • Token is a card number – Issuer is google (See blog)
    • A plastic version of this was planned in 2012 as reported by Android Police, but was pulled because of high stakes war involving top issuers and Mastercard.
    • Merchant runs transaction as normal
    • Google acts as issuer receives authorization request and routes to selected card (using facilities of TXVIA).
    • After receiving authorization from funding card, google authorizes transaction
    • Issuers make all of the interchange they did before, but don’t like being wrapped. They also don’t like the data leakage and the fact that this impairs their ability to offer unique services (10% off at Kinkos).
    • Note: this scheme has a value proposition for everyone.. and banks still don’t like it… Google loses money on every transaction.
    • Another little known fact is that early versions of GW ran in this model due to limitations within NXP’s chip (only supporting one card emulation app)
    • No Patent issues, few other companies could afford to take a loss on every transaction (buying data). Network rules are the primary issue.
  • Form H – Host Card Emulation  (Google, MA, SimplyTapp) I like – this one
    • Consumer Directory: Issuer
    • HCE Blog
    • Blend of NFC and Form V below. Simplifies the NFC supply chain
    • No dedicated hardware, NFC just another radioExposure: 000 : 00 : 00 . 156 %Accumulated%=0
    • Issuer Creates One time use tokens for EMV key generation
    • Merchant acceptance hurdle CURRENTLY same as NFC
    • Can be leveraged for non EMV purposes (Beacons, QR, wi-fi, …)
    • HCE is GPL, but ability to generate one time use tokens for EMV generation is unique.
  • Form M – MCX/Target Redcard
    • Consumer Directory: Wallet/Retailer
    • See Gemalto/MCX Blog
    • Very similar to Model S (Square) below except wallet is owned by the retailer and form factor is QR code
  • Form P – Paypal/Discover
    • Consumer Directory: PayPal
    • OK… this is not mobile yet.. but since I have Square down below, I thought I would be fair
    • Consumer registered for Paypal Card running on Discover network.
    • Consumer enters phone number at POS + PIN
    • Processor translates phone + PIN into Discover transaction
    • Discover routes to Paypal for authorization
    • Very similar to Model G above
    • Transaction authorized
  • Form S – Square/Starbucks/LevelUp – POS translation
    • Consumer Directory: Wallet/Square/Starbucks
    • Consumer account mapped to phone, ID, voiceprint, card, picture, location
    • POS translates ID to Card
    • POS request authorization as a card not present transaction
    • Consumer Authorization was taken during service registration
    • Consumer receives digital receipt for transaction
    • See Square Stand, LevelUp
  • Form V – Visa/Amex/MA – Network Tokens (TBD)
    • Consumer Directory: Network (Issuers don’t like this)
    • Press Release
    • See blog on Battle of the Cloud Part 4 – Clusters Form
    • Tokens will evolve to a very long number which will be translated to an issuer/account number. This is what Visa/MA do today.
    • Patents will be around generation, use and validation of token. In the future, merchants will not store your card numbers on file (COF), each merchant will have a unique token based upon your actual account number and their own ID.

From Business Implications of Tokens

Business Drivers

As I outlined in New ACH System in US, my view of Bank business drivers for Tokenization are:

  1. Stop the dissemination and storage of Card numbers, DDA RTN and Account Numbers
  2. Control the bank clearing network. Particularly third party senders and stopping the next paypal where consumer funds are directed to unknown destinations through aggregators.
  3. Own New Mobile POS Schemes to protect their risk investment
  4. Improve ACH clearing speed (new rules, new capabilities to manage risk). In a token model the differences between an ACH debit and a debit card will blend as banks leverage common infrastructure.
  5. Create new ACH based pricing scheme somewhere between debit ($0.21) and credit cards
  6. Regulatory, Financial Pandemic, AML controls (per  blog on HSBC)
  7. Take Visa and MA out of the debit game (yes this is a major story)
  8. Maintain risk models (see both sides of transaction)
  9. Control Retailer’s efforts to form a new payment network

What banks seem to be missing is that mobile payment is not just about payment (seeDirectory Battle Part 1). Payments SUPPORT commerce, Banks therefore do not operate from a position of control but rather of enablement. Most retailers recognize that Consumer access to credit has resulted in improved retail spending, however most would also say consumer addition to bank rewards has been detrimental to their margin.

Leave a Reply

Your email address will not be published. Required fields are marked *