With every EMV rollout merchants and cardholders are being told the same old story - that the EMV will efficiently reduce (or fully eliminate) card present fraud but that the fraud will most likely quickly and rapidly shift toward 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 channel. Due to the way current EMV cards are currently personalized and issued, it is certainly true statement, but I certainly do not agree that maintaining the EMV status quo should be justified anymore - now and / or going forward.
Potential Improvements To EMV Card Issuing / Personalization
As far as I see it, 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 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 the 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 real PAN, which is visible to the consumer together with Expiry Date (front of the card) and regular CVV/CVC value (back or front of the card).
- Last, if they chose to introduce the improvement #1 to the EMV card personalization process, then they could (and should) enforce 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 ApplePay/AndroidPay/SamsungPay NFC payments authorization flows)
2. Online e-commerce, i.e. CNP transactions (when ISO 8583 message doesn’t contain ‘DE55’, representing EMV data block) should only be allowed with real PAN.
This enforced de-coupling of the payment channels would clearly 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 completely eliminate) PCI certification and yearly audit expenditures for card present merchants, since in 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 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 certainly frictionless way to pay for on-line purchases, since it would eliminate any need to key card data. In such payment scenarios, the merchant’s mobile app is closely mimicking 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 ApplePay 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? Well I am afraid that at this time, only payment networks, card issuers, EMV payment associations and / or their trusted advisors, may be able to elaborate and explain 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 not too late probably.