Omnichannel's Payments Revolution Will Sputter Without Tokenization

With all the innovation and momentum around consumer wallets and payments, payment security is a huge concern to banks, merchants, issuers, payment networks and any new wallet provider. Tokenization promises to keep payment data safe in transit and at rest.

As consumer adoption of disparate, diverse payment channels grows, more data is at risk along more points in the payments chain and the implications of a security breach intensify. Demonstrated by the number of high profile data breaches that have plagued the U.S. within the last couple years – adversely affecting reputable businesses from hotels to home improvement stores – payment data security is absolutely essential.

Up to this point, the shift to EMV measures that you’ve likely heard about only impacts select forms of payments (mainly contact EMV cards, contactless EMV cards and some mobile payments like ApplePay) and only covers data while in immediate transit from the point of sale (POS). That’s not to say that EMV-level security measures won’t eventually be extended to online transactions or stored payment data, but there are security gaps that need to be plugged more imminently. All of this sets up tokenization to be the next key cross-channel security solution for banks and their retailer counterparts.

As a baseline definition, tokenization aims to lower the value of sensitive data stored on mobile devices or on merchant servers and transmitted over networks during payment. Tokenization is a security technology that consists of replacing a payment card’s static credentials (like the 16-digit PAN and expiration date on a plastic card) with virtually substituted credentials that limit the impact of a data breach or sporadic attacks. Applying the technology provides protection for issuers, merchants and cardholders alike.

There are, however, two different types of tokenization that can sometimes be conflated. The first is the Payment Tokenization Technical Framework issued by EMVCo, which we will call payment tokenization. “Such tokens [can] be used by merchants or digital wallet operators, and can be stored in EMV chip cards and NFC devices,” to cover payment transactions themselves. The other form of tokenization is for card-on-file databases, those vast repositories of payment details that banks and retailers (online or brick-and-mortar) store to enable faster, more frictionless payments for repeat customers. This second type of tokenization, which we’ll call database tokenization, is offered by a number of technology providers, and thus is proprietary rather than standardized.

One of the major distinguishing factors between the two types of tokenization is that the former pertains to payment data “in transit” and the latter to payment data “at rest.” It’s imperative to note that securing both types of data is of utmost importance to financial institutions.

When card or mobile payment data is used to underwrite a transaction at a merchant’s POS, it needs to be protected against interception as it makes its way to the bank for instant verification and back to validate the purchase. Payment tokenization can secure that in-transit data.

Database tokenization can shore up the data at rest. To be sure, there are several benefits to storing that data – outcomes range from quick access to loyalty programs to predictive purchase behavior analytics – but if you’re going to be the guardian of that valuable information for so many consumers, it’s your responsibility to protect it by any means necessary. Visa and MasterCard do intend to eventually extend their tokenization methods to those stored card-on-file payment details as they sit on servers or in the cloud, but proprietary database tokenization is an important bridge in the meantime.

Aside from its utility for both data in transit and data at rest, there are a few main reasons why implementing tokenization just makes good sense for banks and other players in the payments ecosystem:

Whether payment card credentials are being provisioned onto an embedded secure element, a SIM card or a mobile application, payment tokenization (the first type) strengthens security. The token cannot be used beyond its pre-defined domain for use on a specific device, at a specific merchant or for specific types of goods and services, and hence it has minimal value to fraudsters.

Thanks to payment tokenization, emerging alternatives like host card emulation (HCE) have been endorsed by payment brands, finally opening the door to independent, bank-owned mobile payment apps. Banks and payment providers can create their own payment apps without necessitating access to tamper-proof mobile storage. Combining payment tokenization with additional security measures and risk mitigation techniques (like dynamic keys, use of trusted execution environments and strong cryptography) helps secure HCE-based app credentials on Android devices.

Before the introduction of payment tokenization, digitizing payment cards for increasingly popular mobile payment options often involved a review and approval process by the issuing bank, which could take anywhere from minutes to days. Banks and wallet providers have understandably been asking for a way to complete enrollment instantly and minimize registration abandonment. E-commerce, as a comparative example, can have an average abandonment rate of 75%, strongly linked to additional registration steps at checkout. These extra layers in the checkout experience are comparable to a lengthy enrollment process in other forms of omnichannel payments, in that both create friction and reduce the number of users that stick it out until the end of the process.

Payment tokenization has made customer enrollment to mobile payment applications near-real-time, which means customers can sign up and be ready to go on banks’ services within seconds – a huge factor in convenience and adoption.

The road to deploying both types of tokenization technology is fast and straightforward for all involved parties. Payment tokenization has no impact on physical retail POS terminals or on the acquiring side of payments. There’s no need for merchants to invest in new hardware or software and, for issuers, implementing tokenization is light-touch, with little impact to their existing infrastructure. Database tokenization has a similarly benign impact on back-end infrastructure for any type of organization storing card-on-file data.

Banks generally don’t have an issue with PCI Data Security Standards, but it can be a significant pain point for merchants. Since the standards apply to data in transit and data at rest, payment and database tokenization can be a helpful conduit toward compliance from two equally crucial angles.

Frankly, there are few reasons banks and payment innovators shouldn’t apply tokenization at multiple points to improve security; it even works in concert with and builds upon the aforementioned migration to EMV. Securing transactions with payment tokenization, whether contact, contactless or mobile, increases protection of payment data in momentary motion. Database tokenization extends those safeguards over the lifespan of that payment data.

The dynamic payments landscape brews healthy competition and innovation, giving banks and issuers plenty of options that align with their business and security strategies. While payment and database tokenization have many unique benefits and solve many security challenges, we have to remember that securing payments doesn’t stop here. Security is always a moving target as fraud techniques evolve. Even after tokenization becomes ubiquitous, financial institutions and their ecosystem counterparts should continue challenging themselves and ask: Beyond tokenization, what’s the next technology that can make omnichannel payments that much more secure for consumers and providers alike?

Naomi Lurie is Gemalto's director of mobile payments.