Community

Latest reported ATM skimming fraud would not be possible with EMV cards enhanced with E@E-FPE FinTech innovation

Mainstream payments industry had chance with EMV long time ago to stop this kind of fraudulent exposure, but it caved in - trying to maintain backward compatibility with mag stripe. That's why today even EMV cards (having all neccessary cryptographic power they need) do not hide from POSs, ATMs (i.e. dynamicaly encrypt in format preserving ways, during transactions) sensitive ayment card data 

a) End To End Format Preserving PAN Encryption With EMV:

https://www.linkedin.com/pulse/extending-emv-protect-sensitive-card-data-pan-milos-dunjic?trk=mp-author-card

b) Enable Tokenization In Plastic EMV Cards 

https://www.linkedin.com/pulse/proxyemvpay-poor-mens-non-mobile-applepay-cousin-milos-dunjic?trk=mp-author-card

I see now what you call 'cheap' ... SDA cards, not DDA cards. I used 'cheap' not for card type, but to emphasize that there is no additional changes required to the DDA (or SDA) EMV applet software

David => 'cheap' was used because there is no need for changes to the current EMV applet implementation - only take full advantage of its features, which isn't the case today. Issuers could start issuing these cards to new cardholders and also replacing expired existing cards. As part of the process issuers advise 'lucky' cardholders of the 'new generation EMV cards', who own Android NFC phones (yes unfortunately no Apple owners) of the 'new card' special features and that they can be used for secure online payments, without danger of the real card number being exposed.

Of course unless all cards are replaced 'card not present fraud' will always be possibility but if issuers start addressing the issue at least the current problem will not grow bigger 

iaxept.com => not clear how you protect card PAN+expiry not being exposed to the mobile phone after consumer taps the card on the back of the NFC phone during online payment. That's why I have suggested that the card shall be tokenized during perso / manufacturing process and also even have dual profile which decouples the tokens for in-store from token for online payments 

Hi thanks for reading and commenting all valid points. Of course it goes without saying this is an idea aimed to trigger the broader discussion and show that mainstream payment industry did not do a proper and complete homework when they launched EMV. Missed opportunity. 

Great initiative by MaterCard. However I have found that the current Merchant Integration with MasterPass wallet could be significantly improved. Merchant side should be able to be reduced to

1. MasterPass side API to initiate online payment
2. Merchant side callback API - for Merchant receive 'MDES tokenized payment method credentials / shipping address / rewards' from MasterPass (representing the payment card and address linked to it, that consumer chose after logging into MasterPass wallet) => which Merchant then uses to submit the payment authorization request to their current Acquirer 
3. Merchant side callback API - for Merchant to finally receive the authorization response and status

This will greatly improve the MasterPass adoption chances, plus it will make compelling case to Merchants to become MasterPass acceptors knowing they do not have to worry about PCI DSS compliance anymore.