InNutshell: The Revised Payment Service Directive (PSD2)-2

7 min readJul 26, 2022

This post is 2nd in the PSD2 series, and explains few other terms used in context of PSD2, like SCA, RTS, CSC, TRA, and talks about the authentication requirements of this regulation. You can read the 1st part here.

More terms

RTS — Regulatory Technical Standards
SCA — Strong Customer Authentication
CSC — Common & Secure Communication
TRA — Transaction Analysis

RTS — Regulatory Technical Standards

RTS are the rules that the payment service providers must adhere to in order to comply with the PSD2 Regulation. These rules cover SCA and CSC.

SCA (String Customer Authentication)

This requirement dictates that consumers must authenticate using additional parameters. Now, customers will need to identify themselves with two of three categories. The categories are

Knowledge — something only the user knows
Possession — something only the user possesses
Inherence — something the user is

Before SCA, issuing banks could only challenge customers with a single static password. These new dynamic data points verify users’ identities more accurately. You can now combine other data points, as long as they are from at least two different categories. For example:

Facial recognition or fingerprint (something they are) with your smartphone (something they own)
A code sent to their smartphone (something they own) with a personal password (something they know)

Authorise Transaction (Fingerprint + Smartphone)

SCA in practice

Implementing SCA differs depending on the payment method.

For credit and debit cards, 3D Secure is usually applied. E-Wallets and other local payment methods often provide their own SCA-compliant authentication step. Learn more about these two types below.

3D Secure (3DS1)

The protocol 3D Secure provides an extra layer of authentication to verify the customer’s identity. It’s supported by most European debit and credit card companies. Once the customer completes the SCA step, the issuing bank, not the business, becomes liable for any fraudulent chargebacks.

3DS1 has few other issues as well, eg

The user flow switches from App to a webpage
Page may not load, respond
Branding from App to 3DS page
Liability for Fraud is shifted from Merchant to the Issuing Bank

3D Secure 2 (3DS2)

3D Secure 2 (3DS2) provides a more user-friendly experience than 3D Secure 1 (3DS1). 3DS2 is the improved standard introduced by EMVCo and the major card schemes. It provides a new approach to authentication through a wider range of data, biometric authentication, and an improved online experience, especially for mobile. It addresses many of 3DS1’s issues while bringing benefits across a broader set of use cases for businesses worldwide.

3DS2 flow divided into three parts:

Frictionless flow (when transaction is authenticated without further inputs)
Challenge flow (When customer inputs are needed)
Authorization flow

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.

In comparison with3D Secure 1, 3DS2 is more user-friendly (especially when it comes to mobile payments). Besides the design, the new protocol is fully compatible with mobile wallet apps and in-app transactions.

Frictionless SCA Experiences are Possible with Machine Learning (ML) models

Advanced fraud solutions based on digital fingerprinting, behavioral biometrics, all backed up by advanced Machine Learning (ML) models perform immensely well in real world applications, effectively performing SCA in an unobtrusive way, unseen by the customer.

Local payment methods and e-wallets

Apart from 3D Secure, you can also make sure you meet SCA requirements with local payment methods or wallets. These have the added advantage of increasing conversion rates in certain markets and use cases.

Across the EEA, we see local payment methods converting well, for example:

Bancontact Mobile in Belgium
iDEAL in The Netherlands
MobilePay, Vipps and Swish in Norway, Sweden, Denmark, and Finland
EPS in Austria
Blik in Poland
MBWay in Portugal

International e-wallets like Apple Pay and Google Pay™ also provide checkout flows that meet the new SCA requirements.

SCA: exemptions or out of scope transactions

SCA exemptions aim to keep the customer journey frictionless for specific payment scenarios. Out of scope transactions are not covered by the PSD2 mandate and don’t require SCA.

Below is a list of the most relevant exempt or out of scope transactions.

MITs (Merchant Initiated Transactions) — if a transaction is initiated by a merchant and a mandate was granted to him by the client. Example: collection of subscription payments for gym membership
MOTO (Mail Order, Telephone Order) — transactions made via mail/phone where a client is not present
“One leg out” transactions — if one of the issuer/acquirer is located outside the EEA
Anonymous transactions — when a customer paid for the transaction using an anonymous payment method (for example: a gift card)

Exemption rules

There is a simple rule: if no exemption applies, SCA is required and if exemption(s) apply you can chose to omit SCA, but the final decision to grant it is on the issuer

TRA (Transaction Risk Analysis) — Transactions through acquirer or issuer whose fraud level is below a certain threshold. Certain acquirers can look at the risk involved with each ‘in-scope’ transaction, to comply with the TRA requirements. If the acquirer thinks a transaction is low risk, it can request a ‘TRA exemption’ to try to skip SCA.

Low value transactions — an online payment below €30 and contactless payments of below €50 (in case of several payments, a cumulative limit is €150).

Corporate payments — transactions initiated from secure corporate cards

Fraud rate limits — payment providers need to deliver the evidence of the transaction fraud rates to the regulatory authorities every 90 days.

Whitelisted recipients — a customer can choose a number of merchants and assign them to a list of „Trusted Beneficiaries” with their card issuing bank. Then, they won’t have to carry out the additional step (SCA) while paying to that recipient.

But, the above exemptions are allowed only if the acquirer or issuer’s fraud rates are below the following thresholds:

0.13% for amounts between €0 to €100 EUR
0.06% for amounts between €100 to €250 EUR
0.01% for amounts between €250 to €500 EUR

In the end, the issuer decides whether to accept this exemption request or still enforce SCA.

CSC — Common & Secure Communication

Common and Secure Communication (CSC) seeks to promote competition and innovation among payment service providers by introducing:

TPP’s — Third Party Payment Service Providers — these guys do not have payment accounts for their customers but can provide the following services
AISP — Account Information Service Provider — a one stop shop for all of your payment accounts, irrespective of where they are held
PISP — Payment Initiation Service Provider — dudes who can make payments on your behalf
ASPSP — Account Servicing Payment Service Provider — the providers of the payment accounts for customers, including banks and other payment institutions

The Regulatory Technical Standards (RTS) define how access to the customers account is handled between ASPSP’s, AISP’s and PISP’s, namely by:

Customer Consent — customers must give explicit consent to the AISP or PISP
Secure Communication — ASPSP must provide AISP’s / PISP’s a secure communication channel in order for them to access the payment account — this essentially refers to:
APIs — Application Programming Interfaces
The API must allow TPPs to provide payment initiation or account information without difficulties
“More secure & sophisticated screen scraping” — Banks must grant access to TPPs using a dedicated interface (think electronic banking) with:
Additional TPP security authentication — allowing the ASPSP to know the TPP is accessing the account
Formal agreement from the customer on the access and use of their account
Compliance with the upcoming GDPR — General Data Protection Regulation