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.
(A duplicate comment may have been posted by the WordPress login process, and it seemed to have been eaten. If a duplicate appears, I apologize for the error.)
As long as the liability for CNP fraud is placed on merchants, it is not the bank’s money and so they have little incentive to solve this issue. Sure they have to issue a new card but big whoop, cheaper than the $200 of retail that just got lifted. The only people who can solve this problem are the people who issued these cards in the first place, not the millions of merchants trying to use their idiot product.
If the rule changed, so issuing banks were liable for CNP fraud, this problem would be fixed tomorrow.
As someone who has worked in ecommerce for many years, I have little sympathy here. The tools provided are not adequate: AVS simply does not work (good luck getting your Taiwanese customers to validate), the CVN is stolen anyway, and add-ons like Verified by Visa suffer from inscrutable implementations that rely on lightly-maintained systems from issuing banks that drive your conversion rates to zero because there is zero customer education and it is not an industry-wide mandate. As I’ve watched PCI DSS balloon over the years to dozens of requirements, I can’t help but shake my head that ultimately it is fantastically absurd to expect millions of merchants all across the planet to keep a number embossed in plastic a secret for a lifetime, when this should entirely be the problem of the person who embossed the number into the plastic and said it’s good for something.
For a while I thought a non-bank entity would solve this problem. But PayPal screwed it up by having customer service on par with the cable companies. I thought Apple Pay would do it, but they can’t seem to see beyond the walled gardens of Cupertino. After two-ish decades of e-commerce and a complete failure to address the issue by the issuing banks, I am convinced the problem will either (1) never be solved in our lifetimes (that is, consumers will continue to pay for CNP fraud as a hidden tax on product price) or (2) be solved through an act of Congress that mandates a secure standard API, which currently can’t even keep the government running.
Though Amazon scares me, the optimist in me hopes they will be big enough one day to compel a standard that bypasses the issuing banks. Whoever figures it out, hoo boy they will disrupt.
But it’s not going to be Visa or Mastercard on their own volition, that’s for sure. They simply don’t care, because they don’t have to pay for it.
The brands’ answer to CNP fraud is 3D Secure. The first version of which was not widely accepted. A new version is available, but I have yet to see any adoption of that scheme – yet. IMVHO, dynamic PAN/CVV are much more reliable than 3D Secure, but time will tell as to what wins out.
For a CNP transaction, how does the proposed application (assuming secure connections and encryption) with “dynamic PAN” and “dynamic CVV” improve on the current anti-fraud measure of requiring the CVV? Would such an application also require entry of the PIN? Alternately, is there today any online function from the card issuers that would enable verification of the PIN by the customer (assume a method for the customer to keep the PIN private) for a “PIN verified” response into the CNP transaction without requiring the additional step of “dynamic PAN” and “dynamic CVV”?
With all of the stolen sensitive authentication data (SAD) running around, gathering the card verification value (CVV) at the time of the transaction is no guarantee that the transaction is not fraudulent and the banks and brands know that fact. That is what is behind their 3D Secure scheme. But that is also not a guarantee either, but it’s better than just blindly accepting CHD/SAD. The problem with CNP acting like CP is the fact that there is a device required at the customer end and not all customers are going to have such a device which means your organization is going to not allow anyone without such a device to shop with you.
Does the “Verified by Visa” feature where you enter a password registered with Visa during checkout also fill the MFA CNP gap? I’ve seen that used on some ecommerce sites, but not widespread. I suppose it’s the API issue again.
Yes, it is kind of an API issue that only Visa has and no other card brand.
I’m kind of surprised you did not mention 3-D Secure in this post. With EMVCo being handed the reigns for various card brand programs (Verified by Visa, Mastercard SecureCode, American Express 3-D Secure), the first thing EMVCo did was merge them all together (good) and put the EMV stamp on it (bad) calling it EMV 3-D Secure v2.0. Now you have more confusion around EMV and card-not-present.
Until I see the 3D Secure standard actually implemented, I will hold my comments.