Securing the Digital World

3D Secure 2.0: What the Protocol Means for Merchants

Apr 02, 2018 | by Rei Maoz |

It's no secret, many online merchants were reluctant to enroll with the original 3D Secure (3DS) 1.0 protocol due to unnecessary friction and the risk of card issuers/Access Control Servers (ACS) turning down legitimate transactions (false positives). Though merchants and card issuers share the same basic interest of allowing legitimate transactions with as little friction as possible while blocking fraudulent transactions, there is a gap of information which can potentially cause a merchant and a card issuer to reach conflicting decisions regarding the same transaction.

Take for example Alice and Bob. Alice likes taking care of her beloved dog, Charlie, and Bob likes running his pet store. Alice purchases Charlie's food (the good kind!) from Bob's store website once a month. She always buys the same brand, same size bag, delivered to the same address and pays with the same card. Bob knows Alice's order and Alice's card issuer, Great Bank, is happy to accept the charge. For months Alice, Bob and Great Bank enjoy trouble-free transactions while Charlie enjoys top-quality chow.

One day Alice gets an offer she can't refuse and applies for a new card from Greater Bank. When Charlie's food runs out, she logs on to Bob's website to order a new bag, this time using her new, shiny card. But to her dismay, the transaction is declined! The next morning she calls Greater Bank, establishes that it was really her who tried making the purchase and then proceeds to try again. This time, successfully (to Charlie's relief). It might look like nothing serious happened here but all of the parties involved would have benefitted from the same frictionless flow they were used to if Bob had updated to the latest 3DS 2.0 protocol.

So what happened? While Bob is still working with the legacy 3DS 1.0 protocol, Greater Bank's ACS is already doing risk-based authentication. All Greater Bank's ACS knew about the transaction was the data elements provided by the 1.0 protocol: Alice's card number, merchant name and ID, the amount and currency, the IP address it came from and the time it happened. Greater Bank's ACS did not know Alice since her card was new. Their Risk Engine considered the purchase amount high for that kind of store (remember, she buys a full month's supply of the good kind – plus, Charlie is a Great Dane). The transaction time also seemed a bit risky due to a number of innocent factors. Alice is a night owl, and uses her work VPN to stream UK television on Netflix. Despite being in the United States, the transaction appeared to originate from a UK IP address. While none of these factors alone screams FRAUD, when assessed together the ACS decided the transaction warranted a high-risk score and declined it.

But what could have happened if Bob kept up with the industry and participated in EMVCo 3DS 2.0? First, he could have ignored Greater Bank's decision and process Alice's purchase without her even noticing what happened in the background, though he would not have enjoyed the liability shift in case of fraud. Better than that, he could have used the protocol to provide Greater Bank's ACS with information that would have contributed to a more accurate risk assessment and most likely, an accepted transaction. For example, Bob could have used "3DS Requestor Prior Transaction Authentication Information = 01" to indicate that Alice has been transparently authenticated during her last purchase with him. He could have used "Address Match Indicator = Y" to indicate that the order's shipping and billing addresses were the same. He could have used "Cardholder Account Age Indicator = 05" to indicate that he knows Alice as a customer for longer than 60 days and he could have used "Reorder Items Indicator = 02" to indicate this is a recurring order. While a good ACS takes a number of factors into account when calculating a transaction's risk, any accurate piece of information provided by the merchant has the potential to turn a bad decision into a good one.

Unlike 3DS 1.0, the new EMV 3DS protocol presents an opportunity for merchants and issuers/ACSs to combine their customer behavior knowledge to form better decisions that benefit the legitimate cardholder, the card issuer and the merchant – translating into higher revenue while reducing operational costs and fraud losses. Or more simply put, merchants and issuers are enabled to stop fraud, not customers or transactions.

With EMV 3DS it is clear: merchant adoption is the deciding factor. If merchants get on board, issuers and ACS vendors will have no choice but to adapt. Issuers will not live with liability shift unless they can make informed, accurate decisions and their ACS providers will have to make the best use of the data the protocol provides in order to enable optimal decision making. An evolved, mature EMV 3DS ecosystem will benefit all…except fraudsters!

What is the outlook for card-not-present fraud? Explore the global state of 3D Secure 2.0 and gain insight into the key factors that issuers and merchants need to take into consideration as they plan their move to 3DS 2.0. Download the new analyst report from Aite Group, "3D Secure 2.0: Key Considerations for Card Issuers" now to learn more.

See what you could be saving in fraud losses in less than 30 seconds.