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)

Conclusions

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.