Coin vs Google Wallet: comparing card-aggregation designs (part I)


Judging by the excitement around crowd-funded Coin, “card-aggregation”– having a single credit-card that can stand-in for multiple payment instruments– speaks to an unmet market demand. In the abstract the concept hardly seems innovative and already implemented in various online approximations. Many online  services such as PayPal perform exactly this service in the context of web payments. Users can load their PayPal account from traditional debit/credit cards or ACH transfers from a checking account, and later get to spend the funds at any merchant accepting PayPal. But that model requires a change on the merchant side to integrate the new payment method; PayPal transactions look very different from standard credit or debit payments to the merchant. Also customers typically fund a stored-balance account ahead of time, floating money to the payment provider and committing to the payment source long before the actual transaction time. It is a lot more tricky to support real-time card aggregation in the context of existing card networks and even more difficult to implement that for in-person payments at a bricks-and-mortar location as opposed to online transactions. (Prepaid cards suffer from the same problems as PayPal: requirement for advance funding.)

Coin is not the first company to tackle this problem but it has gotten a lot more traction than previous attempts which for the most part, never went beyond a technology demonstration. One possible exception is Google Wallet. In 2012 Google introduced a different approach for combining multiple payment credit-cards in a single mobile wallet. [Full-disclosure: this blogger worked on Google Wallet.] These two products make for an interesting comparison, attempting to create the same user-experience with diametrically opposed designs under-the-hood.

Coin: commercializing the dynamic mag-stripe

Coin is an example of the programmable magnetic-stripe (also called “dynamic magnetic stripe”) technology, covered earlier on this blog. When credit cards are swiped, the point-of-sale terminal reads information encoded on a thin-film made of magnetized material on the back of the card. That information is used to request payment authorization from the card network. The physical layout as well as logical format for this is standardized by ISO/IEC 7813. Informally the format is often referred to as track-data, because it is organized into three tracks with only the first two used on payment cards.

For vanilla plastic cards the contents of the magnetic stripe never change. They are written once at the time of issuance and remain fixed for the lifetime of the payment instrument. About the only change that can occur is unintended and detrimental: when the card comes into contact with a very strong magnetic field, that can lead to erasure of encoded data, resulting in an unreadable card much to the chagrin of the cardholder. This basic technology remained unchanged for decades, until around 2010 when programmable magnetic stripes made their commercial debut. These use a small embedded processor on the card to change the encoded data on demand. It’s clear this technology allows the realization of many advanced concepts, such as single-use card numbers or even single-use track data for a fixed card number that would be immune against skimming. (One could even implement a variation on the mag-stripe profile of EMV, by simulating an internal counter and reader-challenge to output track data containing  dynamic CVC3.)

Coin implements a more elementary scenario: switching between track-data copied from multiple cards, in order to “simulate” any one of these cards. Coin relies on what is arguably a security flaw in the design of magnetic-stripe cards: it is trivial to clone them. Information encoded on the stripe is fixed and readable by anyone in possession of inexpensive off-the-shelf equipment. Anyone can create a new card with exactly the same data– and consequently the same spending authority as the original card, when it is swiped for a purchase.

Abstract architecture of Coin

Coin card model for aggregating multiple cards

Card-cloning, grassroots approach

When journalists speak of card-skimming attacks against ATMs and point-of-sale terminals, usually they are referring to gangs installing malicious software or physically tampering with reader hardware to steal magnetic-stripe data for any card swiped at that location. Armed with that information, the criminals can create duplicate cards bearing same track-data and attempt fraudulent purchases with these clones. (There are additional complications of course: the cards need additional features to look legitimate, such as appropriate logos, holograms, embossed card-holder name etc. Also CVC2 is not present on the magnetic stripe, as such the “clone” is only usable for card-present transactions.)

Coin institutionalizes that practice, except this time cloning is done by the cardholder for his/her own convenience/benefit.

The product has not been released to the general public at the time of writing, but extensive FAQs and a lengthy demonstration given to TechCrunch conveys the general approach taken for provisioning. Users are given card readers– similar to the ubiquitous white Square readers– that interface with their iPhone/Adroid device. Existing plastic cards are swiped to extract their track-data. A mobile app then syncs the information over Bluetooth to the Coin card where it is stored. Shortly before a transaction, that same mobile app allows choosing among cloned cards. Dynamic magnetic-stripe is then reconfigured to present a perfect copy of the same track-data as found on the original card.

[continued at part II]

CP

 

4 thoughts on “Coin vs Google Wallet: comparing card-aggregation designs (part I)

  1. the core difference between Google Wallet and Coin is the form factor. Google Wallet has a chicken and egg problem, whereby merchants need to change their POS systems; Coin works with existing systems. Google Wallet needs customers to change their paying habits; Coin is in the form of a credit card, like customers are already used to.

    • Actually Google Wallet has a plastic card option, which is used for ordinary swipe transactions (not NFC):
      http://www.google.com/wallet/faq.html#tab=faq-card

      But that has a slightly different model than the transparent proxy functionality as NFC payments from the mobile app. The Wallet card is a traditional prepaid card with a stored-value that must be funded in advance before spending.

  2. Alexej Muehlberg says:

    I like how you state
    “Coin relies on what is arguably a security flaw in the design of magnetic-stripe cards: it is trivial to clone them.”
    It is also questionable what happens with Magstripe in the future having the credit card companies a mandate to switch to chip based products (EMV).
    Now if Coin would use a dynamic PAN, changing each time, it would have similar protection compared to Google Wallet. But then Coin would need a service in the back to map dynamic PAN to real PAN.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s