value_prop

As Card-Not-Present (CNP) transactions have become more common and convenient, especially via mobile devices, there has been a corresponding increase in online fraud. According to the Verizon 2016 Data Breach Investigations Report, 63% of confirmed data breaches involve using weak, default or stolen passwords.

International card networks (at EMVco), regulators (for example in Europe under PSD2 and in India), and other rulemaking bodies (such as the National Institute of Standards and Technologyand the PCI Security Standards Council) have taken a keen interest in reducing fraud through multi-factor authentication. These parties also recognize that transaction approval rates drop off with additional friction in the user experience.

To address this balance, EMVCo designed 3-D Secure 2 to consist of two flows:

• frictionless flow: risk assessment by the issing bank based on data about the transaction, merchant, and users's device; and
• challenge flows:: strong customer authentication (SCA) by the issuing bank.

When the risk assessment indicates confidence in the transition, the issuing bank can indicate that SCA is not required and that the bank expects to authorize the transaction without requiring further cardholder authentication. The issuing bank can also determine that SCA is required for additional confidence in the transaction.

This design seeks to:

• Reduce CNP-related fraud
• Increase transaction approval rates while minimizing friction in checkout flows.
• Provide a way for relevant parties to comply with new Secure Customer Authentication mandates in Europe, India, Australia, Korea, Hong Kong and elsewhere.
• Provide room for different ecosystem stakeholders to offer value-added services.
• Allow flexibility in implementation. For example, because their compliance expectations differ, large and small merchants (and their payment service providers) may implement the flows differently.

These benefits apply to all ecosystem stakeholders: consumers, merchants, payment service providers, issuing banks, and card networks.

Note that in this design issuing banks manage the risk assessment and SCA, yet those actions occur while the user is interacting with the merchant site. In practice, the flows are initiated while the user is visiting the merchant site and involve backend communications between merchants, payment service providers, the card networks, and issuing banks. This approach offers several advantages, including not requiring users to install software to enable the protocol. On the other hand, merchants do need to integrate custom code and specialized UX elements and this integration can be complex.

Web technology has evolved since the original design of 3-D Secure 2. In particular Payment Request API and Web Authentication API move some functionality traditionally offered through merchant Web pages into the user's domain, including their browser and other software. As a result, this task force has convened to determine whether this "move to the user side":

• Can help achieve more easily or at lower cost some of the goals of 3-D Secure 2 as specified, and
• Whether modifications to future versions of 3-D Secure would make it easier to achieve objectives in combination with these new Web technologies.

In particular, the task force is exploring whether:

• There are opportunities to simplify and improve merchant-initiated flow implementations through W3C's payment and authentication APIs. This includes whether there are opportunities to improve the user experience.

• Browser initiation of 3-D Secure flows could foster deployment while reducing the integration impact on merchants. In addition, user preferences for frictionless or challenge flows have the potential to offer additional privacy options to users.

• Payment handler initiation of 3-D Secure flows could foster deployment by reducing the integration impact on merchants.

This task force is also looking more broadly at strong authentication. In particular, seeking to understand related PSD2 requirements, the role of the Web Authentication API, and how all of this relates to Payment Request API.