The Fed Wants To Clean Up Token Confusion

The Federal Reserve Banks of Boston and Atlanta applaud the many efforts to standardize payment tokenization, except the part that there are in fact so many such efforts. The potential for confusion and, much worse, standards conflicts undermining token efforts—especially in mobile—is a great concern of the Fed.

“There are several obstacles to developing a common set of standards for tokenization for the payments industry. First, different tokenization models are being developed (e.g., EMVCo, TCH, card networks, PCI SSC, and ASC X9),” said a joint report issued by the two Fed groups. “At this time, it is not clear how the different payment models (EMVCo, TCH, and the card networks) may complement each other as they remain in different stages of development and coordination. Second, the models do not use consistent terminology, which is necessary to develop common standards.”

The groups also had more specific concerns. For example: “Global tokenization standards should address front-end fraud, but none of the current models do,” it said, before adding that EMVCo at least develops assurance scores and supports the brands’ vetting of token requestors.

Another serious concern is how retailers will work with tokens, given how extensive—and different—the various infrastructure change needs are. “If the EMVCo spec becomes the dominant industry standard, it may be difficult for businesses with legacy systems to adopt it, as they may not be able to accept all features,” the report said. “Whether the tokenization standard adopted is EMVCo or non-EMVCo, businesses will need efficient and compatible solutions that have minimal impact to their operations.Tokenization platforms that include format-preserving protocols, tokenization and encryption of data and files, centralized policy control, and simplified key management may help to address this issue.”

The report also referenced another infrastructure concern: “The framework proposed by the card networks basically overlays the EMVCo spec, but allows for customization typically required by the networks. For example, EMVCo may require a minimum of five fields, but a network could specify seven fields to accommodate more proprietary information. The EMVCo spec will need to maintain compatibility with the existing payments infrastructure and complement existing specs to ensure consistency across all payments environments.”

That consistency is the problem. The Clearing House (TCH), for instance, in 2012 developed the Secure Token Exchange (STE) tokenization specification, which originally was called Secure Cloud.

“TCH evaluated differences between the STE and EMVCo specs and identified key disparities in token formatting, lifecycle management, PAN ownership and the use of static versus dynamic tokens. TCH defined and developed a set of messages to support token formatting, which EMVCo does not include. TCH also has a lifecycle management process to handle a stolen payment card or mobile phone, includingidentification of messages that need to be exchanged to cancel the tokens and ensure the customer experience is not negatively impacted,” the report said. “TCH and EMVCo view ownership of the real PAN differently. Acquiring bank participants in the TCH pilot expressed a strong need to access the real PAN, which the STE spec addressed by assigning PAN ownership to the acquirer. PAN access provides the ability to track purchases across mobile and non-mobile use cases, facilitate loyalty and returns, and provide fraud services. Although TCH discussed the PAN issue with the card networks, the current EMVCo spec does not address ownership of the PAN.”

The report then said that both TCH and EMVDo “are considering adjustments to their specs. TCH plans to modify its spec to incorporate several EMVCo requirements. For instance, TCH may publish information on how to prevent re-use of tokens. TCH also plans to maintain its distinct capabilities in the STE model and is hopeful that these capabilities will be incorporated into the EMVCo spec in the future.”

There was also concerns about the differences between dynamic and static tokens. “Dynamic tokens change with every transaction. Static tokens do not change until the token expiry date and then can be renewed ‘as is’ at each expiry date in perpetuity. Despite the fact that dynamic tokens are considered more secure in the payments industry, they present challenges that need to be addressed. For instance, some large issuers may consider static tokens because dynamic tokens impact how they perform fraud prevention, which occurs before the token enters the back-end system. The EMVCo spec supports static, domain-specificpayment tokens with a token cryptogram.The TCH model also plans to support static tokens with cryptograms. A key consideration for merchants with the use of static tokens is the potential for increased risk of re-use in fraudulent transactions. It is also unclear as to whether static tokens will allow merchants to usefully track transaction history for customers.”

Then there are the many related authentication mechanisms, which are throwing yet more confusion into the space.

“Token tiers categorize different token options, venues, uses, and values to help assign the appropriate risk assurance level to the token. Risk assurance levels are negotiated between the TSP and the Token Requestor. EMVCo defined four use cases (NFC at POS, ecommerce purchases, ecommerce with stored accounts, and use of QR codes at POS) as initial applications of tokens, but left open the possibility of more use cases,” the joint report said. “Non-EMVCo examples include: pseudo-PAN tokens used for online purchases (e.g., Braintree/Venmo, Stripe, and WePay); processor-provided tokens used by merchants internally; second log-in tokens (PayPal, 3-D Secure, and Visa Checkout); and proprietary tokens that support new business models for POS payments. Other potential use cases that need to be investigated include digital content, host card emulation (HCE) applications working with NFC, fingerprint-reading/verifying authentication to obtain purchasing tokens, and use of Beacontechnology to pass tokens for payments.”

With all of the attention focused on the card brands and payment firms and the associations and the mobile companies and retailers, there has been surprisingly little focus on shoppers and what will get them to use—or avoid—these tokenization and related efforts, especially for mobile payments.

“Many industry stakeholders are using multi-factor authentication, registration of the mobile phone, and/or biometrics/fingerprinting to engage the consumer and improve cardholder identification and verification and overall transaction security. A key consideration is what is required to change consumer behavior,” the joint report said. “If the consumer links multiple wallets or solutions, and the tokenization schemes are not connected or interoperable, what will happen? How should differences between non-interoperable and fully updated systems be explained to the customer to avoid confusion or frustration? For example, newer systems display the last 4 digits of a card number on a receipt (printed or electronic) and may provide online payment confirmation. Do customers need to be trained to expect some variances on their receipts and changes to purchase confirmations? How much consumer education is required to explain the use of tokens for enhanced payment security and to build confidence? Do customers need to be aware that the industry is driving tokenization or is it simply enough that they have been advised in recent announcements, such as with the launch of Apple Pay? As with other features, any changes need to factor in consumer privacy.”

The report also addressed the many other ways businesses have used payment card numbers—whether or not they should have—and how these efforts could be impacted by tokens.

“In addition to serving as an account identifier, some retailers, acquirers, and cardholders use the PAN for other purposes. The first 6 digits (BIN) are extensively used for routing in today’s POS infrastructure—not only for open-loop (multi-issuer) systems, but increasingly for closed-loop alternatives as well (e.g., AmEx, Discover, private label, etc.). The PAN can also help recognize frequent shoppers, and a partial PAN (usually the last 4 digits) is printed on a receipt to aid consumers in reconciling their accounts,” the report said. “In the trucking industry, the PAN prompts drivers to enter mileage and/or a driver ID when getting fuel. Drivers cannot purchase fuel without keying the middle nine digits of the PAN on the reader. While it might be helpful to separate these types of data elements from the PAN, PCI requires that certain components of the PAN be present to determine if it is a token. This creates questions about how much of the PAN can be used for everyday transaction management purposes and still protect the overall account.”