Payments Compliance Resources

PSD2, SCA, and 3DS2: Understanding The Basics Of Upcoming Regulations

Making sense of upcoming payment regulations in Europe can be confusing. In this post we explain the basics of PSD2, SCA, and 3DS2

Written by
Luke Evans
Publication Date
April 21, 2019
Social Share
Don’t miss our latest news and updates
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Regulations affecting online commerce have been coming fast and furious lately it seems. Although months or even years apart, the preparation that goes into each one make them feel much closer together. So much so that the work to implement these items over time all tends to blend together.

Not so long that our memories have faded yet from GDPR implementation, we now can see more regulation in Europe on the horizon that may affect your business. If you do business in Europe, or with European citizens, it’s likely you’ll be affected.

Regulations, Old and New

The Payments Services Directive (PSD) that began as far back as 2005 when first conceived released a major update in 2018 when it was repealed and replaced by PSD2. PSD2 will bring new requirements for payment transactions and anyone doing e-commerce in Europe will have to make changes to their operation.

The credit card brands also come into play in regard to upcoming regulations as well. Visa, Mastercard and others are implementing mandates around something called 3D Secure 2 (3DS2), which is something you’ll need to know about as well.

We will explain those issues and more in this series of blog posts in the coming weeks to help you understand: what is coming and when, how might it affect you, and what you can do about it.

There is certainly a lot of information out there and it can be complicated, so we’re aiming to simplify it a bit for you.

In this post we’ll begin to break it down into something that’s manageable to understand. If you would like to dig deeper into each topic, source links will be provided. Our discussion will focus on card not present payments, but the regulations can affect card present transactions as well.

First, who is the EBA?

The European Banking Authority is an independent EU Authority, established to regulate and supervise banks in Europe. They are the ones that provide guidance on payment services in the form of technical standards, guidelines, opinions, and other publications.

The interpretation of the PSD2 regulation starts here and then gets doled out to the representative implementors like the banks, payment service providers (PSPs) and third parties (TPPs). If anyone has questions or a concern with the regulation, this is the group that addresses those issues. They are given this authority by the European Commission.


To understand the Payments Services Directive and PSD2 you need to understand that its creation stems from initiatives of the European Union. Why? To establish a Single Euro Payments Area, or SEPA, and regulate how payment services should operate in Europe (not to be confused with SEPA Direct Debit). .

Its purpose is to increase competition by ensuring participation by banks and non-banks alike. Its also ensuring consumer protection by controlling the obligations between users and providers.

PSD2 dictates rules that European providers must follow and was adopted on January 13, 2017, however final rules and aspects of the security directive were only ratified in March 2017 and will begin implementation in September 2019. One of the biggest changes with this regulation is that banks have to open up their systems and data to third parties.

This will bring about new use cases and applications to fulfill a part of the competitive goal. Some openness was already happening, but this sets the requirement in stone. There will also be new requirements for user identification in order to reduce fraud. This is to protect consumers, and banks for that matter, in this new age of openness.

We discussed PSD2 in a recent episode of Payments Dialog focused on European Payments.

SCA: Strong Customer Authentication Under PSD2

The most important component or change for user identification coming with PSD2 is the requirement of Strong Customer Authentication. This requirement dictates that consumers must authenticate using additional parameters.

Gone are the days of only a username and password. This was something the user knew (or in many cases could not remember). One step authentication is becoming more and more insecure, as it only required something “known” which could be obtained or hacked with relative ease.

Now, customers will need to identify themselves with two of three categories. The categories are knowledge, possession, and inherence. Often referred to as, something you know, something you possess, and something you are.

via Cardinal Commerce

Since this is a banking regulation, this obviously falls to payments as well, since banks are effectively behind all of the payment transactions. Of course merchants are concerned about this because already transactions have a set success rate. What happens when additional requirements are placed on users to complete an online transaction? Most assume that success rates will fall.

PSD2 Exemptions

Ah, but what about the exemptions you ask? What if I just exempt all my transactions? Not so fast. If all of them could be exempted then that really defeats the directive, so only a few types will be allowed. And even those have uncertainty as the different participants work with the EBA to determine exactly how they will be implemented.

Here are the exemptions that are allowed under PSD2 rules around SCA (subject to additional details around the directive's exact requirements).

  • Article 12 - Unattended terminal for transport and parking
  • Article 13 - Trusted beneficiaries: This is generally where the consumer has already whitelisted the merchant to run transactions
  • Article 14 - Recurring transactions: Similar to 13, this is where the consumer has already given permission for the merchant to run subsequent recurring transactions
  • Article 15 - Credit transfers to self: Where the consumer and the payee are the same and both accounts are the same service provider
  • Article 16 - Low-value transactions: Where the amount of the remote electronic payment transaction does not exceed €30 and the cumulative amount of previous remote electronic payment transactions initiated since the last challenge does not exceed €100 or 5 consecutive individual remote electronic payment transactions.
  • Article 17 - Secure corporate payment processes and protocols
  • Article 18 - Transaction risk analysis: PSPs are allowed to notify authorities that they intend to use real time risk analysis to qualify certain transactions if they can show that the overall fraud rate is less than the required threshold. The thresholds are: 0.13% to exempt transactions below €100, 0.06% to exempt transactions below €250, and 0.01% to exempt transactions below €500.

Each exemption is separate, and only one needs to be requested even if multiple are eligible. As with any kind of exemption it is likely that some will carry more weight than others, but we believe this is something that will develop over time.

All that to say that even still if a PSP or a merchant request an exemption, the issuer might override that exemption and request SCA. Since the issuer has the most information, and a full view of the payers usage, they remain the authority in determining whether to require them to authenticate or not. Non-exemption can occur even for transactions where the consumer is not currently engaged in the flow, like the case with recurring transactions. Merchants will need to be prepared that there can be an “off-session” flow to have customers authenticate transactions that were not exempted whether it be SMS or email to pull them back to the application.

In the end all parties are invested in making sure the consumer is able to pay when they want to, and that fraud is reduced. It remains to be seen exactly how these policies around SCA could adjust over time to make that a reality. This requirement goes into effect September 14, 2019.

3DS (3D Secure)

3-D Secure (3DS) has been in existence for some time now, utilized in Europe as well as a firm requirement in other countries like India and South Africa. It was implemented as a secure authentication method for online transactions.

Later, EMV 3-D Secure was developed by EMVCo, the same organization that developed smart chips for credit cards. EMVCo is overseen by EMVCo’s six member organizations - American Express, Discover, JCB, Mastercard, UnionPay, and Visa.

Each brand adopts the current 3D secure protocol into their services, and has branded this service differently. Visa is Verified by Visa, Mastercard is Mastercard SecureCode, American Express is SafeKey, etc.

The first generation of the service provided for authentication of the user by the issuing bank (consumers were often redirected to the bank website to enter in a pin). This caused a rise in cart abandonment and a decline in success rates which limited adoption and merchant satisfaction.

3DS2 (3D Secure 2)

A new standard, 3D Secure 2, was created in 2015 by EMVCo and is now being promoted as a solution for SCA under PSD2. The main advantage is reduced friction in the user experience — to help solve for the aforementioned cart abandonment problem. The specification also calls for it to meet the standards needed for SCA in order for it to co-exist with the European requirements.

3DS2 will require merchants to send additional data with each transaction, so that the bank can determine if the cardholder is the actual transactor. If the data matches what the bank requires, then the transaction can continue on a “frictionless” flow and will not need user input. This will have to match with exemptions and what is allowable for SCA to qualify once SCA is in place.

If the data is not acceptable, and the transaction also didn’t meet an acceptable exemption, then the bank will respond with a “challenge” for user authentication. If challenged, 3DS2 has an improvement over 3DS removing the explicit redirect. The challenge can be presented in the customer application, or in the bank’s application on a mobile device if installed, providing for a better user experience.

3DS2 Timeline

Card brands are trying to reduce fraud which is a common goal of the directive. The larger the portion of the ecosystem that they can get to adopt 3DS2 as the solution for PSD2 the better. Which is why they have issued network mandates requiring issuers to implement 3DS2, to coincide with the release in September.

3DS2 will begin in Europe, but there are plans for the card brands to require it in other countries in the future. This diagram from Braintree summarizes the timing well.

Source: Braintree

What 3DS2 Means For Liability

Another important part of 3DS2 is liability shift. In order to provide additional incentive for merchants to adopt 3DS2, the card brands will be shifting liability from the merchants to the issuer if implemented. Therefore this is a very important solution for merchants to implement.

What’s the bottom line?

Everything there is to know about PSD2 and SCA is still under consideration. Interpretations of everything will have to wait until implementation in September. However, no one can wait that long to begin this compliance journey. You should prepare and have the right operations in place to ensure smooth execution.

The market is racing to compliance as we have so many times. As we all have experienced each time before there will be delays and leaps forward as the entire industry lurches into action to meet the deadline. Delays are already evident with many issuers and gateways lacking functional test gateways for 3DS2.

Spreedly is hard at work with our partners to ensure equal access to the benefits of 3DS2 and SCA compliance. Our intent is that merchants can be ready to handle these new requirements, avoid disruptions in transactions, and continue to collect revenue from their customers.

Stay tuned as we explore SCA and 3DS2 in more blog posts in the coming weeks.

Related Articles

Payments Compliance Resources

Reducing Development & Compliance Burdens with Payments Orchestration

How Payments Orchestration reduces the developmental and compliance burdens of regulatory change

Posted on Apr 20, 2023 by Rachel Fine

Payments Compliance Resources

The Major Building Blocks for A Risk Assessment

Growing a great risk assessment program for worthwhile results

Posted on Jun 27, 2022 by Aaron Finley

Payments Compliance Resources

Benefits of Performing Security Risk Assessments

Staying ahead of security risk by performing security risk assessments

Posted on Jun 15, 2022 by Aaron Finley