3ds2.0

Using 3-D Secure 2.0 to Help Comply with PDS2

Digital commerce is growing,

having increased 24% year-over year in 2017, based on based on VisaNet authorization data. On the other hand, card-not-present fraud and declines rose 19% and 20%, respectively, during the same time period. This is a big problem for merchants – and for card issuing banks – one that has been compounded by increasing regulation in the payments space.

Solving for market drivers and regulations

As the industry evolves, an increasing number of market factors are influencing how card-not-present transactions are processed and managed. In addition to growing fraud, certain countries or regions also face regulations. One regulation impacting card-not-present commerce is Europe’s Second Payment Services Directive (PSD2). The European Union has clear objectives to increase payment security, and within the PSD2 regulation, there is a specific article regarding strong customer authentication (SCA). SCA places strict requirements around payment authentication and will apply to digital payments when both the card issuer and merchant are in the EEA. SCA will be mandatory as of September 2019 for any business accepting customer-initiated payments with Europe via digital means.

Meeting the SCA requirement is defined as having at least two of the following three elements:

  • Something only the customer has
  • Something only the customer know
  • Something only the customer is

SCA exemptions include:

  • Recurring transactions, where SCA is used when a payer creates, changes or initiates for the first time, a series of recurring payments. SCA is not required on subsequent transactions of the same amount to the same payee.
  • Trusted beneficiaries, where SCA is used when a payer creates or changes a list of trusted beneficiaries through the issuer. SCA is not required for transactions with a merchant on their trusted beneficiary list.
  • Low-value transactions, for remote electronic payment transactions that do not exceed EUR 30, the cumulative amount of the previous remote electronic payment transactions by the payer since the last application of SCA does not exceed EUR 100, and the number of previous remote electronic payment transactions does not exceed five.
  • Transaction risk analysis, for remote electronic payment transactions that the issuer identifies as low risk according to specific transaction monitoring mechanisms defined in the European Banking Authority’s Regulatory Technical Standards for PSD2.

Knowing when SCA is required or when an exemption can be applied can create a complex payment management problems for merchants and card issuers.

The European Banking Authority (EBA), the organization behind the PSD2 SCA requirement, has not named a specific technology that issuers and merchants must use to authenticate, but as we near closer to the implementation date of September 2019, the industry is moving towards a standard answer to fulfill SCA requirements.

Over the past decade, we have seen the widespread adoption of new devices – such as tablets and smartphones – enable consumers to shop from anywhere, at any time. Because of this, the payments industry decided to revisit and innovate the security protocol 3-D Secure, which was created in the early 2000s. The industry group EMVCo released specifications for EMV3-D Secure (commonly known as 3-D Secure 2.0) in late 2016 to address industry feedback on how 3-D Secure needed to evolve. These new specs have improved on the original with a better consumer experience, support for non-PC browsers and sharing 10 times more data with issuers to empower better risk management decisions.

Implementing 3-D Secure 2.0 for SCA

3-D Secure 2.0 is a good way to help maintain low fraud, increase good orders and comply with regulations such as PSD2 without jeopardizing the overall consumer shopping experience. The expected results are more confidence in the transaction for both issuers and merchants and less fraud and false declines.

Leveraging the 3DS 2.0 protocol, the card networks have built programs providing benefits to merchants and issuers who participate. For example, Visa’s 3-D Secure program and Mastercard’s Identity Check both offer merchants a shift in liability to issuer banks when participating in their program. The issuers receive access to enriched data to drive more informed decisions and the cardholder can be silently authenticated the majority of the time (except in regulated markets where strong authentication is always required). In many network 2.0 programs, static passwords and activation during shopping are no longer permitted and the transition to one-time passcodes and biometrics is now a best practice.

For transactions that the issuer determines are risky and cannot be authenticated using the risk-based approach, rather than declining the transaction, the cardholder is asked for more information in the form of a step-up. The step-up can be a one-time passcode delivered via SMS or email, or a biometric like fingerprint or facial scan.

In addition to the 3DS 2.0 specs and the network programs, participants need a method to enable the protocol and programs and that is where the solution providers come in. Solution providers offer merchant capabilities, a 3DS Server and Software Development Kits (SDKs), and issuer capabilities, an Access Control Server (ACS). Some providers, such as CardinalCommerce, offer all three.

Cardinal’s sole focus is on authentication and over 20 years has built a network of intelligence and rich data. This data is used in collaboration between merchants and issuers to increase authorization rates, limit false declines and reducing overall fraud. Cardinal’s enhanced data can be shared directly with the issuer not only for authentication, but authorization as well.

Getting better data

As part of 3-D Secure 2.0, both the issuer and the merchant collect data about the cardholder and the transaction so the issuer can make a more confident risk decision. For browser-based transactions, an issuer can collect dozens to hundreds of browser-based data elements through the 3DS Method URL, where they can run their own or third party device data collection services. From a specification perspective, a merchant can provide order details, such as amount, card number, currency code and then consumer details such as billing/shipping address, mobile phone, consumer email as a minimum set of data fields. A merchant can provide additional data as well, such as merchant risk information, like how long a consumer has had an account with the merchant, type of delivery information, gift card information, etc.

With all of this additional data, it’s arguable whether the payment processor needs to provide an advanced API to capture the new data points (compared to what was required with 3DS 1.0). Fortunately, the majority of the authorization flow remains the same as it is for version 1.0. The enriched data will be between the merchant and issuer directly through the 3DS 2.0 rails and components (such as a 3DS Server, Directory Server, ACS, etc). The outcome of this exchange will result in either a frictionless authentication or an identity challenge.

If the transaction resulted in a frictionless authentication flow, the issuer will generate a 3DS cryptogram (CAVV/AAV) that the merchant will need to pass during authorization. This cryptogram, plus PAN and amount, will help link the transaction from authentication to authorization.

For transactions that the issuer cannot authenticate using the risk-based approach, rather than declining the transaction, the issuer asks the cardholder for more information via a step-up. The step-up can be in the form of a one-time passcode delivered via SMS or email, or a biometric like fingerprint or facial scan.

One of the key advantages and value Cardinal Commerce provides to our customers is that we’ve removed and simplified a lot of the components that are required for merchants to seamlessly implement 3DS 2.0. In addition, CardinalCommerce also will support exemption management as part of PSD2 for merchants and issuers in the regulated market – such as Trusted Beneficiary exemptions and transaction risk analysis.

Our long history of doing authentication means that the systems we have built over the years have been improved as real-world situations developed and our customers requested added functionality to meet their business objectives. We have seen a lot of changes over the years and have adapted to meet market demands, and we’ve built each of our EMV 3DS components (3DS Server, 3DS SDK iOS/Android, and ACS) to support all of our customers and their purchase channels.

Why 3-D Secure 2.0 is a good choice

3-D Secure 2.0 provides card issuing banks with 10 times more data so that they can make more informed risk decisions, which reduces fraud, false declines and the need for two-factor authentication. This allows consumers to shop with limited checkout friction from any device they choose. It also complies with PSD2’s SCA requirement of transaction risk analysis to qualify for an exemption for low-risk transactions. If the transaction cannot be qualified as low risk, the transaction must be authenticated with SCA. When 3-D Secure 2.0 is used for SCA, if the issuer detects that the transaction is risky, the consumer can be challenged for more information, like a one-time passcode or a biometric identifier.

How to be 3-D Secure 2.0-ready?

There are four components to 3-D Secure 2.0: a DS (Directory Server), a 3DS server, an SDK (Software Development Kit) and an ACS (Access Control Server). Providers of each need to first pass compliance with an independent third party, like UL, then they must be certified by EMVCo and then they must be certified by each of the card networks before their solutions are deemed fully certified.

Cardinal has received certification for their 3DS server (merchant component), its ACS (issuer component) and its SDK (for mobile).

Get prepared for PSD2-SCA now

As the deadline for PSD2 approaches, the payments landscape is getting more and more complicated. To learn more about 3-D Secure 2.0 (EMV 3DS), how it solves for PSD2’s SCA requirement, or how Cardinal can help you reduce fraud, false declines and improve your consumers’ experience, visit www.CardinalCommerce.com.

Viewed 686 times / 1 views today
Posted in:
Author: Jaime Howard