EMV and CNP Fraud

With every EMV rollout, merchants and cardholders are being told the same old story: that the EMV will efficiently reduce (or eliminate) card-present fraud but that the fraud will most likely quickly and rapidly shift toward the card-not-present (CNP) channel. This is the direct result of the simple fact that EMV doesn’t protect card numbers during the EMV card-present transactions at POS and that those card numbers, if stolen from unprotected POS devices, could likely be used on CNP channels. Due to the way current EMV cards are currently personalized and issued, maintaining the EMV status quo shouldn’t be justified anymore.

‍

Potential improvements to EMV card issuing/personalization

‍

There may be simple process improvement steps that payment networks, card issuers, and their personalization bureaus could introduce to their EMV card issuing and personalization process in order to prevent fraud shifting and ‘leaking’ from card-present to CNP channel:

‍

First, they could (and should) personalize the EMV card’s chip payment application(s) with the ‘payment token’ (instead of real PAN, which is the case today). The issuer of such ‘tokenized EMV card’ (or personalization bureau on its behalf) can obtain the ‘payment token’ from the Tokenization Service Provider or TSP (usually payment network plays this role) as part of the EMV card data preparation step(s). As a result, the obtained ‘payment token’ would be mapped to the real EMV card’s real PAN inside TSP’s Token Vault server.

‍

Next, they will continue to physically emboss the EMV card with the real PAN, which is visible to the consumer together with the expiry date (front of the card) and regular CVV/CVC value (back or front of the card).

‍

Last, if they chose to introduce improvement #1 to the EMV card personalization process, then they could (and should) enforce the following rules associated with TSP’s mapping records:

‍

1. POS ‘card-present’ payment EMV transactions (when ISO 8583 message contains valid ‘DE55,’ representing full EMV data block, with EMV cryptogram value) should only be allowed with ‘payment token’ as the acceptable ‘card number.’ As part of the payment authorization, TSP normally intercepts and de-tokenizes the ‘payment token’ (after verifying the DE55 content’s integrity) into the real PAN before sending the authorization request to the card issuer for final approval (this is exactly what’s been done in Apple Pay/Android Pay/Samsung Pay NFC payments authorization flows).
2. ‍
3. Online e-commerce, i.e., the CNP transactions (when ISO 8583 message doesn’t contain ‘DE55,’ representing the EMV data block) should only be allowed with real PAN.

‍

This enforced de-coupling of the payment channels would eliminate the possibility of real card numbers being stolen from the card-present POS devices and then re-used on the CNP channel.

‍

This could further significantly reduce (or even eliminate) PCI certification and yearly audit expenditures for card-present merchants since, in the case of EMV transactions, their POS equipment and servers would deal with ‘payment tokens’ only. That would likely provide clear and tangible incentives to brick-and-mortar merchants for a rapid move toward upgrading their in-store POS equipment toward becoming fully EMV-compliant and fund it with those PCI savings.

‍

This may even open the ability for e-commerce merchants to enable their mobile apps for frictionless ‘tap & pay’ in-app payments without worrying about PCI DSS compliance of their mobile apps since those apps will also deal only with ‘payment tokens.’ For consumers, the in-app ‘tap & pay’ online payments would be a frictionless way to pay for online purchases since it would eliminate any need to key card data. In such payment scenarios, the merchant’s mobile app closely mimics the in-store payment process as a simple pass-thru extension of the online merchant’s virtual online POS. In terms of security and interchange, those in-app ‘tap and pay’ transactions should be treated equally as Apple Pay in-app payments.

‍

This may also put additional motivation (and pressure) on card issuers to rapidly replace all outstanding ‘mag stripe only’ cards with such ‘tokenized’ EMV cards.

‍

Why aren’t these (or similar) EMV card-issuing process upgrades then being already considered and implemented as part of the US EMV rollout? At this time, only payment networks, card issuers, EMV payment associations, and (or) their trusted advisors may be able to elaborate and explain the main reasons behind proceeding with US EMV rollout using outdated status quo processes, which aren’t addressing known but unnecessary CNP channel fraud exposures.

‍

Maybe something like this nature could potentially sneak into one of their New Year Resolution lists? It’s probably not too late.