Post image for Transactions Get Smart

Glenbrook held a great “Innovations in Payments” workshop this week – a group which energetically debated many topics, including Bitcoin (of course), tokenization, beacons, authentication, wearables, interoperability and mobile ad spend.

As I reflect on the day, it seems that an interesting theme emerged.  Many of the topics were about payment transactions that are – or will be – a whole lot smarter than the transactions of today.

The EMVCo Payment Tokenization spec – a document well worth reading – lays out a framework by which payment tokens, (dummy numbers, essentially) are  provided to wallets, merchants, billers or other service providers by card networks or third parties acting as a “Token Services Provider”.  These tokens have useful limitations – they’re only good if used by a particular merchant or wallet, for example.  But they may have additional “smarts” attached to them: they may identify the required level of identity assurance (from nothing to full-blown 3DSecure) required for use, or they may be good for only one use (in which case the one-time dummy card number becomes something like an account-number-length dynamic CVN).

Most of this is about transaction security, but with a framework like this, it is not difficult to imagine other types of conditions that could be layered in: conditions that might have more generalized business impact.  Imagine a token that is only good if it is presented along with accompanying Level 3 data.  The same thing could be done with static card numbers (and is today, to some extent, in some specialized corporate and prepaid card scenarios) – but the tokenization framework is much more flexible: as a result,  the tokens will be “smarter” than plain ‘ol card numbers. And then there’s the positive impact on security.

As it stands, this specification, when implemented, will demand some sophisticated card network rule changes to do justice to the framework.  The simple “card present” vs. “card not present” split is not going to work for very much longer.  I hope the card networks accept the challenge!

In the world of Bitcoin, multi-signature transactions (a Bitcoin address that can only “spend” with two or more signatures) have the potential to open up a world of interesting, smart, transactions.  Imagine embedded conditions that trigger an automatic payment: when the loading dock scans the RFID tag indicating successful delivery, a message is sent which triggers a machine-initiated second signature – resulting in an automatic payment.  Or the same scenario, triggered by a stock hitting a given price. I find it particularly interesting to think about this in the context of machine-to-machine interactions.  Maybe we can just sit back and watch them work!

The topic of smart transactions just kept recurring throughout the day.  A discussion of the FIDO authentication framework had control options for identity that were very similar to those in the tokenization spec.  And we all had fun thinking about beacons and wearables and how real-world actions might trigger “smarts” in apps and transactions.

Join us for some of our upcoming Glenbrook Insight workshops and be part of the conversation!  Our full schedule is shown here.

This post was written by Glenbrook’s Carol Coye Benson.

 

3 Responses to “Transactions Get Smart”

  1. Welly says:

    I think it’s important to note that Bitcoin always requires that the user (business, consumer, etc.) must always convert their preferred currency into BTC before being able to use Bitcoin for payments. Once the payment is made, the receiver must always convert BTC into their preferred currency.

    The two exchanges in/out of BTC seem to contain foreign currency risk as a necessary element to using the protocol.

  2. Ashok Misra says:

    Welly, I think this article is not necessarily talking about cross border transactions. Exchanges will not be required in a mature BTC economy where end participants see no reason to transfer in/out of fiat.

  3. Ashok Misra says:

    @Carol, I have read the ENV tokenization spec in depth. A couple of things I would like to understand further are :-

    1. The spec calls for a bin control manager to assign dummy bins for the token. How will they be assigned? I do not believe there is any bin in ISO 7812 which is precluded from being allocated to an issuer.
    2. What if a cardholder is not comfortable with giving the merchant holding the token the ability to charge the instrument at any time.

    I have asked some folks about this, but have not received an answer. Please let me know if you know or can find out.

    Regards
    Ashok

Leave a Reply

Previous post:

Next post:

Clicky Web Analytics