Payment Token Implementation Do’s and Don’ts

Payment Token Implementation Do’s and Don’ts

Jul 1, 2014 | Payments, Tokenization

With an estimated 70% of US credit cards likely to be EMV chip ready by the end of next year ((70 Percent of U.S. Credit Cards to Include EMV Chips 2015, Computer World, June 16, 2014, http://www.eweek.com/security/70-percent-of-us-credit-cards-to-include-evm-chips-by-2015.html)) , the race to protect against sharply increased levels of card-not-present fraud has begun in earnest. As we’ve discussed in the past, one of the most important tools to help mitigate card-not-present fraud will be tokenization of the front end of the payment. EMVCo, which is one of several organizations developing a payment token specification, has committed to a speedy drafting process, promising a completed standard this year ((Chip Standards Body Fast-Tracks New Token Standard in Wake of Target, Other Recent Breaches, DigitalTransactions, February 5, 2014.http://digitaltransactions.net/news/story/4502)) . At the moment, although both The Clearing House and X9 are working on (and in the case of The Clearing House largely completed) tokenization standards, it appears that EMVCo has the best shot at prevailing in the marketplace, at least in the short term.

The work product ((EMV Payment Tokenisation Specification – Technical Framework, Version 1.0, March 2014, http://www.emvco.com/specifications.aspx?id=263)) released by EMVCo in March of this year was a promising start, and contains some critically important elements. For example the standard’s Technical Framework contains a process for establishing and vetting the assurance level of each token, based on the identity and verification performed, the entity that performed the evaluation, as well as other factors. Token assurance levels are designed to be conveyed with each transaction, and optionally the Token Service Provider’s additional information supporting a particular token assurance level can be passed to the issuer as part of an authorization request.

Another significant positive is that the standard anticipates useful payment token domain controls. Token domains define the types of transactions for which a given token may be used. The standard will provide for payment tokens that are channel specific (for example, NFC only), merchant specific, digital wallet specific, or any combination of these items. Venue specific token hierarchies such as those proposed in the standard are a very important feature that have the potential to increase security levels while making life less complicated for key stakeholders.
The Technical Framework also contains a number of use cases, including Mobile NFC at the Point-of-Sale, Mobile/Digital Wallet E-Commerce, Card-On-File E-Commerce, and Scan at Point-of-Sale. It also documents the capture and clearing and exception flows.

So far, so good, and it’s important to note that EMVCo has not yet released a full draft of the complete standard. That said, from what we can see in the Technical Framework document, the standard will be written so as to allow participants considerable freedom in terms of how they execute product against the standard. That’s not inappropriate, but there may be unintended consequences, especially if the industry flocks to a lowest common denominator approach to execution.

What are the key choices the industry will make?

  • What’s the life span of a token? Tokens can be completely dynamic (that is, they change with every transaction), they can be static (they don’t change until the token expiry date, and then can be renewed “as is” at each expiry date in perpetuity), or, effectively, anything in between.
  • What’s the token’s bandwidth? The standard seems certain to provide considerable flexibility concerning the constraints around token use. As we’ve noted earlier, the standard provides for merchant specific tokens, channel specific tokens, digital wallet specific tokens, or tokens with any combination of those three items. But there will likely be nothing in the standard that prohibits parties from using a single token without bandwidth restrictions. And if those tokens happen to be static tokens, then the question of safety compromise cannot be avoided.
  • How effectively will the token assurance framework be implemented? High assurance tokens issued to individuals based on weak credentials will compromise the system, as will significant actor to actor variations in the interpretation and implementation of each assurance level definition.
    • We’re still relatively early on in the EMVCo process, but once stakeholders coalesce around a single tokenization standard, work has just begun. There has yet to be a broad industry discussion about the consequences of different payment token implementation paths, but there is still time. The industry will be best served by a more robust discussion among all stakeholders about the ramifications of key implementation choices that – after all – will determine the standard’s ultimate effectiveness. The industry’s credibility is very much on the line.

      For more than 35 years, Santa Fe Group Senior Advisor, Gary Roboff, contributed his outstanding talents to the financial services industry, and in particular to financial services payments systems. Gary has focused on such issues as privacy and information utilization, business frameworks, changes in the payments and settlement systems, and standards for emerging e-commerce applications. He has chaired the Electronic Funds Transfer Association (EFTA) Board of Directors and was a founder of the International Security Trust and Privacy Alliance (ISTPA), serving as Vice Chair of its Board.

Sign up for our Newsletter

Learn about upcoming events, special offers from our partners and more.

Sub Topics