By J.D. Oder II, CTO and senior vice president of R&D, Shift4 Corporation
October 1, 2015: This date has been burned into the consciousness of the U.S. payments industry. This is the date that signals the liability shift for EMV adoption. It would seem on the surface to be a straightforward concept; migrate to EMV cards or possibly be held liable for fraudulent activity. What makes it complicated is the complexity of the market itself, comprised of merchants, processors and payment terminal manufacturers, independent software vendors, merchant banks, credit and debit card issuers and more.
The shift to EMV is not a particularly smooth one. Although U.S. merchants and issuers have already begun adopting EMV, there are frequent reports that a large number of U.S. merchants are not ready. Industry trade groups are contesting different aspects of the U.S. EMV liability shift, processors need more staff to complete certifications and,as it turns out, EMV won’t solve all of today’s security problems, namely the data breaches that retailers and others have been plagued with in recent years.
Misleading Information About EMV
The marketing of EMV has capitalized on the Target and Home Depot breaches to spur the migration, but that tactic has only added to the confusion surrounding the transition. And, as the EMV liability shift date gets closer — which at this time is not a mandate — the various parties pressuring merchants to immediately adopt EMV are creating a misplaced sense of panic, leading merchants to adopt the quickest EMV solution possible, not necessarily the best solution for their businesses.
As an example, EMV proponents are in some cases recommending the deployment of EMV solutions that don’t incorporate point-to-point encryption (P2PE) or tokenization. These technologies help prevent breaches and simplify PCI compliance. Further, they can help prevent sensitive payment card data from being stolen in the first place, which is the primary source of counterfeit cards. Additionally, the implementation of systems that can’t employ EMV with P2PE and tokenization may in fact put merchants in harm’s way, as it may expose their networks and other POS infrastructures to card data and change their PCI DSS landscape.
It’s gotten to the point that some merchants have been pressured to transition from an integrated payment solution to a standalone solution, simply because an organization they work with has certified for EMV with a standalone payment terminal, but not an integrated payment terminal. This move may get them ready for EMV by the liability shift, but is sacrificing key integrated payment functionalities that save them significant time and money worth it?
Merchants need to step back, take a breath, and consider the benefits compared with the cost.How could an EMV implementation that further exposes their environment to breaches be considered a move forward? Why would they even consider sacrificing the key time- and money-saving accounting and security functionalities of an integrated payment solution that contribute to the success of their business operations? The possibility of moving to an implementation of EMV that does not strategically support an organization’s business operations is especially concerning when all merchants get in return is protection from a very specific segment of fraud, counterfeit fraud,which they may not be liable for anyway.
This brings up a critical fact that is often overlooked or just misunderstood: a merchant’s current contract with their acquiring bank or merchant services provider (MSP) may not even take EMV into account. It is entirely possible that counterfeit fraud was traditionally considered “zero liability” (which is liability that was just part of the issuer doing business) and that a merchant’s agreements do not reflect or even anticipate a shift in counterfeit fraud liability. This means that, based on a merchant’s current contracts, it may not even be possible for the merchant to shoulder the responsibility for that fraud – unless that merchant signs a new contract waiving their protection from it. This is one very important reason why merchants need to be wary of any proposals that require them to re-sign a contract or get into a new contract with their MSP related to updates for EMV; any new or updated contract may also be asking the merchant to sign up for more liability than their current contract allows.
Who Stands to Lose the Most?
Of all those involved in the EMV liability shift, there are three groups that stand to bear the lion’s share of the burden: merchants, small card issuers and small merchant banks. Merchants must invest in EMV-compliant terminals and system solutions at a substantial cost. Small issuers and co-issuers are also burdened with the costly retooling of the cards they issue. EMV cards are much more expensive to produce than traditional magnetic stripe cards. And, if they issue contactless EMV cards, these can cost up to two times more than a typical EMV card. Finally, small merchant banks, independent sales organizations (ISOs) and agents have very little control or say over the makeup of the payments industry and stand to lose the most by this liability shift if they cannot influence change or get their merchant customers prepared for EMV.
Three EMV Implementation Strategies
It’s taken a long time for EMV to reach the U.S. This technology was created more than 20 years ago and doesn’t account for the proficiency with which hackers, some of whom are now working in large groups and are backed by nation-states, are compromising payment systems today.This means that a well-constructed EMV solution requires the use of layered security to protect sensitive cardholder data. Here are three crucial elements to implement during your EMV migration:
- EMV: Even though some in the industry have used questionable tactics to promote EMV,that doesn’t mean that EMV lacks merit for authenticating card-present transactions. Implement EMV in a strategic fashion with the layered security you need.
- P2PE: It is important to encrypt all transactional material—regardless of payment type—from the time it is keyed, swiped, inserted or tapped. Merchants should use a device that encrypts at the point a payment terminal interacts with a card so that no transactional information is ever in the clear and at risk of being stolen by hackers. This shrinks the merchant’s cardholder data environment to the secure device level, reducing much of the PCI DSS burden—a burden that remains with EMV. Again, EMV would not have stopped the breaches at Target or Home Depot, nor will it alone prevent future breaches.
- Tokenization: Removing all card data from the merchant environment is critical. It places the burden of storing that sensitive data on a vigilant and reliable organization that considers the security of their merchant customers’ transactions its primary job. To do this, merchants must implement a security- or storage-based tokenization solution, which protects the merchant’s environment by replacing sensitive cardholder data with non-decryptable information that is meaningless to hackers. This differs from emerging “payment token” solutions, such as those offered by mobile wallets, by providing security for merchant systems, not just individual consumers.
EMV alone is not a complete payment security solution, but it does have its place in a well-rounded security plan. Because marketing tactics have been misleading at times, it’s critical that merchants get clarity about what the October liability shift date means for them and which solution will work best for them. EMV on its own cannot stop data breaches, so a comprehensive approach will include P2PE and tokenization to remove sensitive payment card data from the merchant environment and render that data useless to hackers.
About the Author: J.D. Oder II serves as Shift4’s Senior Vice President of Research and Development and Chief Technology Officer. J.D. is a Certified Network Engineer with more than 15 years of experience. He leads Shift4’s systems operations and development efforts as well as the security and compliance teams. J.D. is the architect of the DOLLARS ON THE NET®payment gateway solution. He was also an early adopter/member of the PCI Security Standards Council.