24 April 2018
Milos Dunjic


Milos Dunjic - TD Bank Group

15Posts 93,603Views 15Comments

Can EMV Be Used To Eliminate CNP Fraud? - UPDATED

12 May 2016  |  4782 views  |  7

Traditional payments industry wisdom states that EMV is extremely effective solution for curbing down ‘card present’ (CP) fraud, but that EMV is at the same time completely ineffective in curbing ‘card not present’ (CNP / e-commerce) fraud. That’s because EMV cards continue to communicate the sensitive payment card data (like Primary Account Number / PAN and Expiry Date) to the POS terminals ‘in clear’ (i.e. unmasked). That is keeping the doors open for the sophisticated fraudsters to potentially steal that sensitive payment card data from merchant's computers and eventually use it in the e-commerce payments. Certainly there are suggestions and statistics showing that the CNP fraud levels are almost always increasing significantly every time major EMV rollout happened in a specific region or a country.

I believe it doesn’t have to be that way and that existing EMV technology stack already has everything in place to be very effective in significantly reducing (if not completely eliminating) fraud regardless of the payment channel or use case.

Let’s run through a hypothetical case of an EMV issuer, who may want to offer ‘special’ EMV cards capable of addressing the CNP fraud (in addition to CP fraud) and potentially gain competitive edge over other EMV issuers, who are continuing to issue ‘plain’ EMV cards.

High Level EMV Flow Overview 

Let me first quickly present at the highest possible level typical steps while executing the EMV transaction flow between EMV card and EMV enabled POS terminal. I assume usage of cheap non-DDA (i.e. only DES cryptography capable) EMV card. When such card is inserted (or tapped) on the POS terminal, the following steps are executed:

  • EMV Application Selection – in this step POS terminal determines which of the card applications, supported by both the card and terminal, will be used to conduct the transaction and selects it. EMV card in its response specifies what data POS terminal shall supply to the EMV card as parameters in the Initiate Application Processing step that follows (this set of parameters is known as ‘PDOL’ data set). NOTE: Merchant Category Code (MCC) is one of the typical parameters, which EMV cards request to be supplied by the POS terminal to the EMV cards inside PDOL data set. MCC data encodes the POS terminal environment characteristics and POS terminal capabilities.
  • Initiate Application Processing – in this step, EMV card receives requested PDOL parameter data from POS terminal and uses it to determine which EMV ‘profile’ (if there is more than one) should be uses for the current EMV transaction. EMV card then sends back to the POS terminal:
    • list of the EMV data items which POS terminal must read from the card (these are in fact simple pointers to card files and records inside the files, containing those data items)
    • complete set of steps to be supported for the transaction. NOTE: each of the different EMV profiles could potentially have a different card number associated with it. This (in combination with special MCC values) is in fact significant design point for the purpose of this analysis.
  • Read Application Data – in this step, the POS terminal reads all of the indicated EMV card data items, from the selected card profile (using pointers to files and records that were provided in the Initiate Application Processing card response). These card data items are necessary for the further transaction processing
  • Cardholder Verification – in this step, the POS terminal determines the cardholder verification method (CVM) to be used and performs the selected CVM. NOTE: usually for contactless transactions below preset limit this step is skipped and PIN or signature isn’t required
  • Terminal Risk Management – in this step, the POS terminal basically ensures that higher-value transactions are sent for online authorization and that even randomly selected low value transactions are required to be authorized online periodically (based on velocity checks)
  • Terminal Action Analysis – in this step, the terminal uses rules encoded by the card issuer inside the card EMV profile (which were read from the card in Read Application Data step) in combination with the rules encoded by the acquirer in the POS terminal, to determine whether the transaction should be approved offline, declined offline, or sent for online authorization. The POS terminal then proposes to the card how to complete and authorize the transaction (from the acquirer’s point of view).
  • Card action analysis – in this step, internal card velocity checking and other internal risk management are performed according to the rules encoded by the card issuer inside the card’s EMV profile (one used in the current transaction). The card EMV application then decides whether to agree with what POS terminal originally proposed (approve / decline transaction offline / online) or to force the online transaction authorization execution. Based on its internal decision, card then generates the appropriate response cryptogram type and returns it to the POS terminal. NOTE: since we are assuming that cardholders would be using ‘special’ EMV cards capable of eliminating fraud in in-store and e-commerce transactions, those cards will always need to force online transaction authorization, i.e. such EMV card will generate and return ARQC type cryptogram to POS terminal at this step
  • Authorization Request Submission – in this step POS terminal prepares the standard ISO 8583 Authorization requests and submits it for the online authorization processing. Ultimately the authorization request arrives at the issuer’s host computer (or a proxy for the issuer, like the Tokenization Service Provider server or TSP for example), which then verifies the card application cryptogram in the request, locates the cardholder account behind the card number and authorizes / declines transactions based on the available balance and the issuer host-based risk parameters and fraud detection filters. Then the issuer host computer also digitally signs and sends the final response back to the POS terminal. NOTE: the EMV card can verify the card issuer’s digital signature (called ARPC cryptogram) and therefore reliably confirm that the response came from the legitimate issuer host computer.
  • Issuer Authorization Response Authentication – in this step, the EMV card performs issuer host ARPC cryptogram verification to confirm that the response was provided by legitimate issuer host. The card then generates the second (i.e. final) response cryptogram and associated Cryptogram Information Data (i.e. TC cryptogram type if the issuer host APPROVED transaction, or AAC cryptogram type if the issuer host DECLINED transaction). This concludes the EMV transaction execution flow.

EMV Setup To Address CNP Fraud

After the high level EMV transaction flow processing has been presented above, let’s analyze how can an EMV issuer (and the payment scheme behind it) enable their EMV payment rails for treating both in-store and e-commerce payments as ‘card present’? Note that the recommendations proposed here could equally be applicable to the use cases where the plastic EMV card is used and also in cases when the mobile wallet based on smartphone secure element is used. The key to achieving the end goal is simply in personalizing the EMV cards in a way that decouples card numbers, which are used for in-store and e-commerce payments.

The EMV issuer in this case issues and personalizes its EMV cards (or mobile wallets on top of smartphone secure elements) as ‘dual EMV profile’ card (note that this is perfectly achievable with current EMV standard technology).

Such ‘dual profile EMV card’ would contain:

  • In-Store EMV profile – this card profile is associated with the ‘In-Store PAN token’ (mapped to real PAN inside payment network’s TSP server). The ‘In-Store PAN token’ is basically dedicated card number to be used only when transactions are initiated at in-store / regular physical EMV enabled POS terminals. This EMV profile will be automatically selected by the card during Initiate Application Processing step, whenever POS terminal device supplies the MCC value in PDOL, which indicates ‘physical / in-store POS merchant environment’. Usage of the ‘In-Store PAN token’ during in-store payments with ‘dual profile EMV card’ will trigger intercepting of the ISO 8583 Authorization Request by payment network TSP and de-tokenization of ‘In-Store PAN token’ to the ‘real PAN’, before the final Authorization Request is sent to the card issuer host - exactly the same online authorization flow happening in case of ApplePay.
  • E-Commerce EMV profile – this card profile is associated with the ‘E-Commerce PAN token’ (mapped to the same real PAN inside payment network’s TSP server). The ‘E-Commerce PAN token’ is dedicated card number to be used only for e-commerce transactions (which can be ‘in app’ or regular web site e-commerce transactions). In such use cases cardholder's personal smartphone is used as e-commerce merchant EMV POS terminal 'extension'. The 'E-commerce EMV profile' will be automatically selected by the EMV card during Initiate Application Processing step, whenever the supplied MCC value indicates ‘personal POS card reader’ environment

NOTE: Real PAN is still normally embossed on the card, but should be completely disabled for direct usage for payments in payment network host and payment network TSP, i.e. its purpose should be limited to scenarios when cardholder needs to communicate to the card issuer’s representatives

E-Commerce Payment Flows With ‘Dual Profile’ EMV Card

For e-commerce payments the payment network supplies their certified ‘e-commerce POS app’ to be downloaded and installed on the cardholder’s smartphone. Alternatively payment network can also supply the in-app EMV payment API library to e-commerce merchants who prefer offering their own mobile apps to consumers. 

When cardholder indicates to the enabled e-commerce merchant's regular web site that they want to pay with ‘E-commerce EMV’, the e-commerce merchant web site encodes the transaction details into the QR code and displays it on the final checkout HTML page. This QR code contains ‘merchant URL’ (where the ISO 8583 authorization request with full EMV data in DE 55 shall be sent for online authorization), e-commerce merchant ID, applicable tax details, transaction amount, shopping card SKU details, etc. Cardholder then initiates the payment network supplied ‘E-commerce POS app’ on his smartphone and scans provided QR code. 

In case of in-app enabled e-commerce merchant payments (via merchant's own mobile app, using embedded in-app payment API library, provided by payment network) there will be no QR code to be scanned, because the e-commerce merchant’s mobile app should already have all of the required shopping cart transaction details, which can easily be provided to the embedded payment network provided in-app payment API library.

Regardless whether the e-commerce payment is initiated via web site or in-app, from this point on the payment network ‘E-commerce POS app’ (or in-app payment API library embedded inside merchant mobile app) has all of the required transaction details to continue with the full EMV transaction flow locally after cardholder is asked to present (tap) their ‘dual profile’ EMV card to smartphone.

During Initiate Application Processing step the presented EMV card would obtain the MCC value in PDOL indicating the ‘personal POS card reader’ environment. Based on that MCC value, the EMV card selects its ‘E-commerce EMV Profile’ and supplies ‘E-commerce PAN token’ as part of the EMV transaction flow to the payment network ‘E-commerce POS app’ (or payment network in-app payment API library embedded inside merchant mobile app).

In all other aspects the regular EMV flow is normally executed locally between smartphone and EMV card, with few slight differences – like probably not asking the consumer for PIN on the smartphone, instead relying on applicable consumer authentication methods like: using smartphone biometric authentication chip, basic consumer passcode based authentication, etc.

After the EMV card provides the e-commerce ARQC cryptogram to the ‘E-commerce POS app’ (or embedded in-app API library), the online ISO 8583 payment authorization request is prepared and submitted to the e-commerce ‘merchant URL’. E-commerce merchant server normally forwards the received ISO 8583 request to its existing e-commerce processor, which send it to the payment network. Payment network will recognize the ‘E-commerce PAN token’ and forward request to its TSP, where EMV card cryptogram will be verified, and the ‘E-commerce PAN Token’ de-tokenized into the real PAN. Payment network then send the final de-tokenized’ authorization request to the card issuer for approval. Final authorization response is returned all the way back to the e-commerce merchant server (which eventually updates its web site confirmation page or merchant mobile app to notify the cardholder of the transaction outcome)


As can be seen the flow in e-commerce EMV payment cases fully mimics and resembles ‘in-store’ EMV payments (with some minor differences) and can therefore be considered as legitimate ‘card present’ payment case, because it is fully protected by the existence of the ‘unique per transaction’ EMV application cryptogram and also by enforced decoupling between card numbers that can be used for in-store and/or e-commerce payments. Potential for fraud is significantly reduced, if not completely eliminated.

Have a comment about this idea or how it can further be improved? By all means please drop me a note or comment for further discussion and engagement. 



Comments: (11)

Balasubramaniam Gd
Balasubramaniam Gd - DBS - singapore | 13 May, 2016, 01:45

Unfortunately for us in APAC the CNP countniues to grow unabatedly and most of it comming in from the US of A, the good part  being that it is still recoverable , and the trade off as to what is the business case in writing it off against the cost each indivigual charge back cost and effort.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Risto Savolainen
Risto Savolainen - iAxept - London | 13 May, 2016, 08:53

Milos, very interesting. We resoved the issue in a better way and using standard contactless EMV cards, no modifications needed. See iaxept.com.

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
David Griffiths
David Griffiths - Number19 Consulting - Hertford | 13 May, 2016, 10:09

An interesting idea I have to say, if a little complicated.  Here in the UK, DDA cards have been mandated for the last several years, so I'm not sure that I understand the "cheap" option.  It also seems to me that the issuer would need to replace their whole card book, so again I am not sure about "cheap".  And, there semms to be a lot of unnecessary tokenisation stuff going on, and there's a QR code at the front!  In principle, though, I might go with it.  iAxept looks intersting but uses the smartphone's NFC interface, which begs the iPhone question, and as far as I know, Apple won't even relese access to the NFC chip for their own internal projects.  

Ido believe that we agetting closer to a reasonable solution though ...

1 thumb up! 1 thumb up! (Log in to thumb up)
Milos Dunjic
Milos Dunjic - TD Bank Group - Toronto | 13 May, 2016, 11:58

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. 

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Milos Dunjic
Milos Dunjic - TD Bank Group - Toronto | 13 May, 2016, 12:07

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 

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
David Griffiths
David Griffiths - Number19 Consulting - Hertford | 13 May, 2016, 12:07

Yeah, but back in the mid 1990s, e-commerce fraud wasn't much of a problem, whereas retail fraud using magstripe cards was, and was growing rapidly! Replacing the magsripe card with an EMV card solved that. I think where the mainstream payment industry missed the opportunity was to let the US get away with magstripe for so long.  That should start a broader discussion ... 

1 thumb up! 1 thumb up! (Log in to thumb up)
David Griffiths
David Griffiths - Number19 Consulting - Hertford | 13 May, 2016, 12:15

Interesting Milos, back to first principles, and in defence of the iaxept process. If all e-commerce transactions were EMV as I think you propose, then each transaction would be protected by its own cryptogram.  The PAN then becomes pretty much irrelevant, just as it did in the retail world with chip cards.  If the PAN is protected by the ARQC, the PAN is no longer sensitive data (if indeed it ever was).  

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Milos Dunjic
Milos Dunjic - TD Bank Group - Toronto | 13 May, 2016, 12:21

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 

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
David Griffiths
David Griffiths - Number19 Consulting - Hertford | 13 May, 2016, 12:42

But we re not allowed to issue "cheap" cards in the UK, unless they are ATM only cards, and as I recall, back in 2002 a DDA cost 2x that of a SDA card, but now that differential is more or less nothing. Somone correct me if I am wrong - it's been a while since I looked closely at the rules and prices.

Also, it's not just about issuers issuing the cards, have you thought about the challenges faced by the acquirers (PSPs) and the merchants.  How many e-commerce merchants and their PSPs do you know who could support an EMV transaction without a serious upgrade to their transaction processing systems? I think it's pretty close to none.

And again, if you can get to the point where online payments are secure, who cares that the card number is exposed.  



Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Milos Dunjic
Milos Dunjic - TD Bank Group - Toronto | 13 May, 2016, 13:30

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

Be the first to give this comment the thumbs up 0 thumb ups! (Log in to thumb up)
Edward Leong
Edward Leong - DistruptiveHut - Singapore | 21 September, 2016, 07:32

Milos, total agreed with you idea. I think with recent the rise of the HCE as the prefer solution for mobile payment, this really kick off the mobile payment industry. HCE-ESE or HCE-Cloud is consider Card Present transaction for the in-store payment. In this case, i would say why not use the card present chip based emv cryptogram to service the in-app payment as well. By doing this, it provider more secure transaction for internet payment, furthermore the most important impact for me is, it can provide better UX to end user. Prior art, user always need to "add payment card - PAN + CVV2 + expiry date", many many in to the in-app wallet. If now A single digital wallet able to directly to link to any in-app via API (with multiple payment application) then this really able to provide factionless UX to end user when come to internet payment space. I guess international payment scheme cloud based payment - DSRP could be talking about all this. I foreseen the coming trend will be on-device digital wallet that able to converge both payment space; physical and internet by using the same wallet and same payment technology...                   

1 thumb up! 1 thumb up! (Log in to thumb up)
Comment on this story (membership required)

Latest posts from Milos

WANTED: Unified Contactless Kernel at POS

05 August 2017  |  11770 views  |  0 comments | recomends Recommends 0 TagsCardsInnovationGroupInnovation in Financial Services

Chequing Bank Account In The Age Of Digital Banking?

01 July 2017  |  7554 views  |  0 comments | recomends Recommends 0 TagsRetail bankingInnovationGroupInnovation in Financial Services

Payments Innovation - A Quantum World Of Payments

29 June 2017  |  8368 views  |  0 comments | recomends Recommends 0 TagsPaymentsInnovation

The Persistent Payment Fraud Challenge and What Can Be Done About It

06 May 2017  |  14751 views  |  0 comments | recomends Recommends 0 TagsCardsSecurity

Milos's profile

job title AVP, Payments Innovation Technology Solutions
location Toronto
member since 2016
Summary profile See full profile »
Technology executive fascinated with and focused on payments innovation. All opinions are my own and not of my current nor prior employers

Milos's expertise

Member since 2016
15 posts15 comments
What Milos reads
Milos's blog archive
2017 (7)2016 (8)

Who's commenting on Milos's posts

David Abbott
Nick Collin
Sadra Boutorabi
Paul Love