Juniper Research (not Juniper Networks) issued a report recently that stated that card not present (CNP) fraud would be $130B by 2023. In response, there were a lot of people asking where EMV was to address this issue? Apparently there are a lot of people that are confused about EMV including some that are directly involved in PCI compliance.
First a bit of background.
People need to understand that EMV as it is implemented anywhere today was originally developed for eliminating or minimizing card present (CP) fraud. Europe became a hotbed of CP fraud in the early 1990s after the fall of the Iron Curtain. To address this problem, Europay, MasterCard and Visa Europe (hence the acronym “EMV”) joined forces to develop the standard in an effort to minimize the CP fraud problem in Europe. EMV was introduced in the UK in 1996 and continued to rollout throughout Europe for the next decade.
Then there is the term “Chip and PIN” that people inadvertently confuse with EMV. Using an EMV card with a PIN is not a requirement as consumers in the US have discovered. The term “Chip and PIN” comes from that original UK rollout. The banks in the UK decided on requiring a cardholder to not only put their card into the card terminal but also to require a personal identification number (i.e., PIN) in order to complete a transaction. That standard has continued pretty much throughout the world with the exception of the US.
The next key thing to understand about EMV is that it is no more secure than the magnetic stripe it replaced. I know that fact might shock some people given all of the press EMV has gotten regarding security. Somewhere along the line, people began to believe that EMV by itself was more secure. I believe a lot of this misunderstanding was the result of other security technologies that were bundled as countries converted to EMV.
The biggest security feature was the requirement of a PIN for transactions. A PIN is essentially implementation of multi-factor authentication (MFA). The EMV card is the something you have, and the PIN is something you know. Both of which are also known as two factor authentication (2FA). 2FA is great for dramatically reducing CP fraud, but still does not protect the data being transmitted and likely stored by any point of sale (POS) solution.
What came next in the evolution of EMV was the addition of end-to-end encryption (E2EE) between the card terminal or point of interaction (POI) and the transaction gateway or processor. E2EE encrypts the sensitive authentication data (SAD) transmission from the POI to the processor meaning that any devices or networks between the two cannot access the data unless they have the encryption keys (which they will not if E2EE is properly implemented).
The final security feature that came to EMV was the addition of tokenization. Tokenization takes the primary account number (PAN) and converts it to a token which can then be returned to the merchant’s POS solution without the worry that it was storing cardholder data (CHD). Tokenization can be either be performed at the POI or by the processor upon completion of a transaction (most common).
With that as the background, I think most readers can start to understand why EMV and its currently used security features are not going to address the CNP fraud problem. All of those security features we are familiar require a CP environment and exactly how does that translate into a CNP environment? The answer is, they do not translate, at least easily.
It turns out that we have been here before with EMV although most people are probably not aware of that fact. Around 2000 to 2002, a few UK banks and a card brand thought about addressing the growing CNP fraud issue with EMV.
In the UK, Barclays and Standard Chartered came up with competing application programming interface (API) standards for eCommerce sites to use. Both Barclays and Standard Chartered paired their APIs with card readers that connected to PCs. Their solutions relied on the new EMV cards that were being issued in the UK and used Chip and PIN for conducting transactions.
At around the same time in the US, American Express was rolling out their first iteration of their Blue card. That card had a chip although it did not conform to the EMV standard. Customers that were in that Blue rollout also got a handy USB chip reader along with the card. As with the implementations in the UK, American Express also relied on Chip and PIN for completing transactions.
The idea with all of the schemes was to have consumers connect the reader to their computer and install some software for the reader. Then when making a purchase online the consumer would insert their EMV card into the reader, key their PIN through the computer’s keyboard and complete the purchase. No different than in a traditional brick and mortar store.
Unfortunately, there were some issues with all of these approaches. The largest of which was that the APIs were all different. As a result, the consumer could not make a secured payment unless the online merchant supported the payment API the consumer had installed on their local PC. In the case of American Express, they had signed on Amazon as a merchant, but Amazon was a very small but up and coming fish in the eCommerce world at the time. In the case of the UK, the banks had only signed a very few small online UK merchants. As a result, with no large eCommerce merchants on board no API gained critical mass to win out. The end result was that by 2003 the EMV CNP experiment had effectively died.
To those observant readers, I earlier alluded to the fact that there are other EMV security features that might be useful for addressing CNP fraud.
There are two features in the EMV standard that could be used and those are dynamic PAN and dynamic card verification value (CVV). These two EMV fields are included in every EMV card but are not currently used. The reason is that using them would require significant programming on the transaction processor’s end to make them work. But using them would still require a card reader solution for eCommerce given the cards in circulation today.
Obviously with CNP, what is needed is a solution that would not require a card reader and therefore a standard API.
In the age of mobile applications, it would be relatively easy for an app to provide the dynamic PAN and dynamic CVV for entry into a Web site. Granted this app would have to communicate with a bank or processor to ensure the generation of valid dynamic values, but it should be no more difficult than what RSA or Symantec do for multifactor authentication.
Another option would be to provide a browser widget or a whole PC application that would generate the dynamic PAN and dynamic CVV while the user was purchasing items online.
But what about people that do not have smartphones or prefer physical cards? What immediately came to my mind is something like the FUZE, Edge or Dynamics cards. While all of these are currently not EMV capable, they are expected to be at some point. They all come with displays that could easily display the dynamic PAN and dynamic CVV just as from a smartphone. Unfortunately, all of these electronic cards require a smartphone but could probably be easily adapted to program from a Web site through a PC since they need to be charged.
The bottom line is that there are solutions to the problem.
PCI Guru 