PSD2 part 4: What it takes to be a payment service provider - The PSD2 Regulatory Technical Standards

In the last few years, we have seen new, innovative payment products and services offered by non-bank institutions. Many people are reluctant to use these new payment service providers because they don't know if they can trust them and if it's secure to use them.

The truth is that any institution aiming to provide payment services needs to comply with the strict requirements of PSD2, whether they are banks or not. And the application is far from easy.

How PSD2 changes the payments landscape

PSD2 is a directive that requires any institution offering payment services to be registered, regulated, and supervised. They also need to comply with strict security requirements and offer customer protection like traditional banks.

On the other hand, PSD2 requires EU banks and other account-holding institutions to open their systems to these new third-party payment providers. The directive indeed opened the road to new startups to create new and innovative products and services and compete with traditional banks.

The impact of the Regulatory Technical Standards (RTS)

The Regulatory Technical Standards (RTS) of PSD2 were developed by the European Banking Authority (EBA) to ensure customer protection but also effective and secure communication between account-holding institutions and third parties. They are actually the technical implementation requirements that all payment service providers need to apply in order to comply with PSD2. The RTS are directly applicable to Member States of the EU and there is no requirement to be transposed into national regulation.

Strong Customer Authentication (SCA) requirement

The RTS requires SCA to be applied by all payment service providers to verify the client's identity. The purpose is to ensure customer protection through an increased level of security.

What is SCA

SCA is the requirement that payment service providers will be validating the customer identity, using at least two of the following security measures:

Knowledge: Something only the customer knows i.e. a PIN or a password

Possession: Something that only the customer has i.e. phone, card etc

Inherence: Something only the customer is i.e. fingerprint, voice recognition etc.

SCA reduces the risk of fraud for electronic payments and protects the confidentiality of the customer's financial data. In some cases, payment service providers are allowed to exempt some transactions from SCA like low-value transactions, contactless payments, and where the risk of fraud is very low.

Cases where SCA needs to be applied:

SCA needs to be applied when the customer:

1. Accesses his account online,
2. Makes an electronic payment (online card payment or electronic transfer)
3. Carries out an action through a remote channel which may imply a risk of payment fraud or other abuses

Dynamic linking

SCA refers to customer authentication. The RTS, however, requires an additional element to ensure customer security - known as dynamic linking. This element aims to protect the client from man-in-the-browser attacks and malware modifications (a client sending a specific amount of money to a recipient ending up sending a much bigger amount to another unknown person due to fraud).

Dynamic linking generates a unique authentication code that links the amount to the recipient's details. In case there is a change to the amount or the recipient of the payment, the authentication code becomes invalid and the transaction is not completed. This unique authentication code is always unique, cannot be recovered, and can be used only once. It is performed right before the completion of a payment transaction.

Why this is important for Payment Service Providers

Customers under PSD2 are allowed to claim full reimbursement of the amount from their payment service provider in case of an unauthorized payment where his payment service provider did not perform SCA and if the payer did not act fraudulently. Therefore, payment service providers are obliged to meet all RTS requirements.

Common and secure communication requirement

The RTS also regulates how third-party providers will access the customer's account held with an account-holding institution through a secure communication channel.

According to the RTS, third-party providers require the explicit consent of the client before they access the customer's account data held with an account-holding institution such as a bank. Without explicit consent, TPPs cannot access, use, and process the clients' account data for the provision of their services.

Third-party providers are not allowed to access all data related to the account-holder but only the specific information required for the provision of their services. Also, every time the third-party provider needs to access customers' data held with account-holding institutions, it should identify itself. The account-holding institutions may rely on eIDAS certificates for the identification of third-party providers.

Account-holding institutions according to PSD2 are obliged to provide third-party providers the data they request for the provision of their services. This should be done however through a secure communication channel. This channel can be a dedicated communication interface (APIs) or an adjustment of the customer online banking interface in a way to enable third-party providers to identify themselves. Traditional screen-scraping is not allowed.

Final conclusions

Since the introduction of PSD2, we can see how quickly things change in the payment field. We continuously see new types of payment services providers, new products, better pricing.

New payment service providers in the EU are obligated to fully comply with PSD2 principles and apply RTS the same ways as traditional banks do. PSD2 indeed has disrupted the traditional field of payments by enhancing competition, driving innovation, and at the same time increasing customers' rights, enhancing security, and preventing fraud.