A journey in ProcessOut's flight journal

PSD2: How will the new Strong Customer Authentication (SCA) requirements impact your business?

by Alexandre Sullet on

The Payment Services Directive 2 (PSD2) is a directive conducted by the European Commission to regulate payment services. In a precedent article, we introduced the challenges related to PSD2. The major change is now that any transaction is subject to Strong Customer Authentication (SCA) unless it is subject to an exemption.

The major impact for customers is a significant rise in friction during the transaction journey.
Let’s now understand what will change to your business!

What is Strong Customer Authentication?

Strong Customer Authentication (SCA) is a process that allows banks to cross-check information from users by using at least two elements among “KHI”.

  • K: Something the customer knows. It could be a password, a PIN code, a question…
    Note that Card Numbers, CVC, Expiration Date are note considered as valid information for Authorities
  • H: Something the customer has. It could be a phone, a token generator, a secured key or any device.
  • I: Something the customer is. It can be any biometric data, such as fingerprint, facial recognition…

Chart: Strong Customer Identification

This SCA process will replace current 3D Secure Authentication, currently known as the multiple digits text message sent by the Issuer to the customer after getting redirected to a secured page by the Merchant.

When is the Strong Customer Authentication triggered?

This regulation will be applied to any new transaction initiated by a customer, and will only be effective if both the merchant and the customer’s bank is located in the EU.

However, transactions can be exempted from SCA if they match some of the following criteria :

  1. If the transaction is a commercial card, PSD2 does not apply
  2. If the transaction is already exempted by the Acquirer or the Issuer: At any moment, the Acquirer or the Issuer can exempt a transaction if he decides to. Mainly because a fraud scoring method they designed (often with Machine Learning & Deep Learning) score the transaction as really safe.
  3. If the merchant is on the customer’s bank whitelist: Any customer can ask his bank to add a merchant on a whitelist in order to remove SCA with this merchant.
  4. If the transaction is recurring (therefore initiated by the merchant): When a customer subscribes to a recurrent service (e.g. with monthly billing), he will have to process to a SCA for the first authorization and then, if the amount is still the same for the following transactions, the transaction will be exempted.

For the cases where the merchant initiates the transaction itself (also known as Merchant Initiated Transactions (MIT) or offline transactions: where the user isn’t browsing the website/application), the SCA is out of the scope. This means that SCA will not be required for MITs: this is not an exemption, it simply is out of scope.

For any other case, the transaction will have to pass the Transaction Risk Analysis (TRA) test.

Therefore, we can sum up this as a schema like below:

DSP1 & Fraud : SCA rules

What are the Transaction Risk Analysis (TRA) rules?

Even if we can see this new regulation as a decision tree, this does not fully explain when a Strong Customer Authentication will be triggered. These rules have been determined to help Acquirers & Issuers to decide if they have to trigger a SCA or not. In the end, Issuers are the only decision-makers regarding the activation of SCA.

Some exceptions can, therefore, be asked by the Acquiring bank & accepted or not, depending on the following rules:

  1. For transactions inferior to 30€: To keep having a frictionless user experience, “low-value” payments are exempted if the customer has made less than 5 payments in the last 24h or if the sum of his payments in the last 24h is inferior to 100€.
  2. Transactions with an amount superior to 30 and inferior to 100: The higher the volume, the higher the risk. Therefore, the Chargeback Rate of the Acquiring Bank and the Issuing Bank is calculated, averaged and if the rate is under 13 bps (0.13%), the transaction should be exempted.
  3. Transactions with an amount superior to 100 and inferior to 250: Similarly, if the average chargeback rate is inferior to 6 bps (0.06%), the transaction should also be exempted.
  4. Transactions with an amount superior to 250 and inferior to 500: Getting close to high amounts, will indeed need a lower chargeback rate. This last is reduced to 1bps (0.01%) when transactions are between 250 and 500€.

Finally, if the transaction is above 500€, a SCA will always be asked by the Issuing Bank.

What should happen most of the time can also be resumed as a decision tree:

Transaction Rick Analysis (TRA) tree

A notable thing to notice is that, even if the transaction respects any case where the SCA is not supposed to be triggered, it can still be! This is because of the Risk-Based Authentication (RBA) used by Acquirer & Issuers.

What is Risk-Based Authentication?

Exemptions are also based on the Risk-Based Authentication (RBA). RBA is a fraud analysis process where the Issuer (or the Acquirer) calculate the risk of fraud for a transaction and determine whether the bank wants to apply SCA or not.

Generally, if the fraud risk is low, the bank concerned will ask for an exemption. On the other hand, even if the transaction is less than 100€ and the average Chargeback Rate between the Issuer and the Acquirer is below 13 bps (so the bank is eligible to ask for an exemption) but the RBA is considered high-risk, they can still trigger SCA.

How the RBA is calculated?

Each actor has his own method of calculation. As long as SCA will require new fields about the customer compared to the previous 3D-Secure (adding customer information, browser information, device information..), an algorithm created can be really complex and can differ from one actor to another. It is often calculated with Machine Learning algorithms or with Anomaly Detection, Velocity Checks, Email Verification, etc…

What are the keys to keep in mind?

Strong Customer Authentication (SCA)

The SCA will replace the currently known 3D-Secure by allowing new identification methods like fingerprint, facial recognition just like Apple Pay is doing when using biometric data.


SCA will be triggered for each new transaction by default, this is, therefore, a heavy process for any customer. But you can still be exempted in some cases:

  • General exemption
    For example: whitelisting or recurrent transactions with the same amount can be exempted
  • Transaction Risk Analysis (TRA) rules

These rules can help Issuer deciding whether they have to trigger a SCA or not.

Merchant Initiated Transactions

MITs fall out of the scope of the SCA. They will not be subject to the new authentications.


To avoid any SCA spamming, any customer can ask his bank to whitelist a merchant. If the customer is used to buy on a specific merchant, adding this merchant on a whitelist will keep the payment process easier for him.

Risk-Based Authentication (RBA Scoring)

Transaction scoring is still a thing. Acquirer and Issuers can combine knowledge of a cardholder to determine if they can ask for an exemption or not.


Keep in mind that even if a transaction follows previous schemas or should be exempted, this does not mean that it will be. Issuers can still decide to trigger an SCA if they have any doubts about the transaction.

As long as the one that asks for an exemption will bear liability, banks will be cautious when asking for it.