Managing tokenization directories
With the endless storm of data breaches, the concept of tokenization has taken the financial industry by storm. Rather than expect that each new digital device will be secure, why not replace the sensitive card and account information with something less valuable, even perishable, that will encourage the fraudsters to look elsewhere?
This sounds reasonable, especially in an age where digitally “disconnecting” is actually a chore. But with the introduction of any new approach, and especially one designed to change the near century old use of static cards, comes different stakeholders with conflicting ideas on how to implement the change. With tokenization, the “conversations” generally center around two topics: management of the token directories and the different approaches for delivering tokens to the point-of-sale (POS). In this article, we’ll address the first issue.
First, it’s helpful to review a little of the recent history behind tokenization. In February 2014, EMVCo, led by its six members (American Express, Discover, JCB, MasterCard, UnionPay, and Visa) and supported by dozens of banks, merchants, processors, vendors and other industry stakeholders, published its Payment Tokenization Framework technical specification that detailed an industry-aligned, interoperable tokenization scheme.
EMVCo exists to facilitate worldwide interoperability and acceptance of secure payment transactions. The framework that they’ve introduced is designed to achieve this goal using tokenization and contemplates a scheme whereby Token Service Providers (TSPs) author payment tokens for delivery to Token Requestors (TRs). In this new world of payments, TSPs provide a number of services including payment token generation and provisioning, TR registration and de-tokenization to facilitate issuer processing services such as authorizations.
Although the framework allows for issuers and third parties to operate as TSPs, the major card brands that make up EMVCo (often referred to as the “networks”) are clearly seen as the preferred entities for this role. Over time, the specification leaves room for up to 1,000 TSPs worldwide. This is still a relatively exclusive club, but it’s large enough to drive innovation and control costs.
The number of TRs, on the other hand, is envisioned to be in the billions (think “Internet of Things”). These are the entities that procure payment tokens from the TSPs for completing an actual purchase or payment, and include the mobile wallet providers, shopping applications, web browsers, card issuers, merchants, acquirers, acquirer processors, payment gateways and other payment enablers. As you can see, this is pretty much everyone who touches a payment today.
Consistent with the EMVCo token framework, the TSPs create a static payment token that is provisioned to the TR. The TR stores the static payment token that, along with a dynamically generated transaction cryptogram, is relayed to the applicable issuer for authorization. “Static payment token” is somewhat of a misnomer, and appears to fall short of tokenization’s goal of obfuscating the PAN (Primary Account Number) but it is an improvement. It has limited life, is restricted to a TR, and must be accompanied by a cryptogram. Together, the payment token and cryptogram provide a unique set of payment credentials for each transaction, eliminating, or at least dramatically reducing, the risk of counterfeit fraud at the point-of-sale.
So, how do we implement this new approach? In reality, there are several options each led by the different stakeholders; i.e., the networks, issuers and merchants. First, as mentioned above, the networks are crucial in these early days of interoperability. By quickly establishing their On-Behalf-Of (OBO) services, and facilitating the issuance of payment tokens for Apple Pay, the first TR, they’ve managed to accomplish more in months than the industry had seen in years. Their OBO services have also simplified the initial registration process for future TRs, streamlined de-tokenization and, with cloud-based solutions like host card emulation (HCE), have kept the banks and credit unions in the game – at least for now.
There are drawbacks with network-managed directories that some issuers and even acquirers may find troublesome. While streamlining the tokenization process, network-managed directories naturally necessitate the routing of all authorizations through the networks limiting alternative processing arrangements and potentially impacting future costs.
So what about the alternative approaches? Issuer-managed directory services, such as Orbiscom’s controlled payment number scheme, have been around for nearly a decade and were originally created to address increasing eCommerce fraud. Similar to EMVCo’s framework, this approach allows the account owner (the issuer) to generate a virtual unique credit card number to settle a specific transaction on an exact date by an authorized individual. This “alias” number is indistinguishable from an ordinary credit card number and the user’s actual credit card number is never revealed to the on-line merchant.
In 2014, innovative European and Canadian banks such as Santander and Royal Bank of Canada launched mobile wallets backed by issuer-managed directories to also facilitate secure, in-store purchases. In these launches, the issuer bank creates a payment token that is shared with the mobile device and then is de-tokenized by the same bank before completing the authorization.
Are issuer-managed directories a workable solution? Absolutely. Assuming the token delivery method, secure element or host card emulation (HCE), is consistent with industry standards, there is no restriction impacting merchant acceptance aside from POS device capabilities. More importantly, when the issuer functions as the TSP for its own accounts, it controls its own destiny with regard to integration, costs and even timing. To that point, the innovative Canadian and European banks mentioned above were able to go to market with their offering months ahead of the Apple Pay launch, and even ahead of the release of the EMVCo token framework specification.
An added benefit of an issuer-managed directory is that it enables the issuer to offer the consumer more controls for using tokens. Imagine a consumer signing up for a one-year subscription to a gym, and being able to restrict the use of the contract’s payment token to 12 uses. No more paying for services that you forgot to cancel!
Are there drawbacks or other considerations to an issuer-led approach? No doubt. If an issuer’s card portfolio is not sufficiently large enough, or there is inadequate demand for tokens, it may be more economical to use the networks’ OBO service. And while an issuer directory serves a bank-sponsored mobile wallet very well, the need to integrate with other TRs such as third-party mobile wallet providers, card-on-file merchants, acquirers and other payment enablers can quickly become burdensome.
The good news is that given the flexibility of the EMVCo token framework, a bank may launch a mobile wallet using a network’s OBO service, then shift to their own directory as circumstances warrant, or even combine the best of both worlds. As the EMVCo framework contemplates, the tokenization ecosystem will evolve over time into networks of interconnected TSPs and interconnected TRs – most likely aggregated TRs. The emergence of TR aggregators will greatly minimize the complexity of new TSPs integrating with the world of TRs.
Finally, no discussion of tokenization would be complete without considering the critical third leg of payments: merchants. Some banks with large merchant networks have piloted tokenization implementations based on merchant-managed directories. Using this approach, the merchant acquirers redirect proprietary tokens to be de-tokenized before submitting the transactions to the authorization networks. Push payment solutions follow a similar approach. In push payments, the card credentials are held in the cloud and submitted to the card networks after receiving a request from the merchant and authorization from the cardholder.
A downside to these approaches is the restricted merchant acceptance. While the implementations may involve large numbers of merchants, they are essentially quasi-closed loops, and often require software changes at the POS device. The greatest drawback is that neither approach, merchant directories nor push payment, aligns with the EMVCo token framework and ultimately are limited in their global reach. This alone may seal their fate, although solutions that allow for such a model could be very valuable in the future.
The thought and work that has gone into tokenization is evident. The concept has the support it needs to succeed, not to mention a very solid business case for protecting merchants while allowing bankers to add value where they excel above all others – trust and security. More importantly this gradual change to the payment ecosystem will keep data breaches from being a regular feature on the nightly news.