AuthoriPay Guide to PSD2 Changes

Strong Customer Authentication, Dynamic Linking &
Access to Third Party Payment Providers

LAST UPDATED 19th August 2020

There is currently a lot of talk about upcoming changes, which are due to be implemented by PSD2. Here we highlight the nature of those changes, what impact they will have and what firms need to do as a result.

What changes are coming as a result of PSD2 ?

There are 2 significant changes being brought forward by PSD2, both of which you may have heard of:

  1. Strong Customer Authentication (SCA) and Dynamic Linking
  2. Access to Payment Accounts by Third-Party Payment Providers (TPPs)

Both will have a strong impact on Payment Service Providers who offer payment accounts that are accessible online, who must make the necessary changes before the recently extended deadline of 14th March 2021 if you are a UK firm and 31st December 2020 for EU firms.

Strong Customer Authentication AuthoriPay

Strong Customer Authentication (SCA) and Dynamic Linking

Although broadly known little is understood about the Strong Customer Authentication rules; what they entail and when they should be used. Here we will provide an overview of this:

When should Strong Customer Authentication and Dynamic Linking be used?

Payment service providers are required to apply SCA and Dynamic Linking whenever a customer remotely accesses their payment account to do one of the following:

  • Initiates an electronic payment instruction
  • Views Balance and/or Transaction History
  • Carries out any action, which may imply a risk of payment fraud or other abuses

What is a Payment Account?

In PSD2 a Payment Account is very simply defined as an account (not necessarily a bank account) which is used for the processing of payments. With the exception of face-to-face cash transfer services (such as Western Union) most Payment Service Providers will be offering an account to their customers for the processing of payments and therefore will fall under this definition.

What does it mean remote access?

In the context of SCA, remote access means access through an electronic distance channel, such as the internet (via an online portal) or through a mobile based application.

For the sake of clarity, payment instructions accepted by email or phone do not, as of yet, come under the SCA rues.

What about card payments?

For card payments, SCA will only be required where a cardholder initiates a payment through a merchant’s website (or other such ecommerce platform).

What is Strong Customer Authentication?

SCA rules mean that, in these circumstances, the customer will need to use 2 of the following 3 applicable security credential requirements:
Strong Customer Authentication AuthoriPay


Something the customer knows

Strong Customer Authentication AuthoriPay


Something the customer has

Strong Customer Authentication AuthoriPay


Something the customer is

Crucially, for SCA to work, the payment service provider needs to ensure that if a customer loses one of these credentials, then their account is still safe because the second security credential is still in place and isn’t compromised by the loss of the first one.

How this can affect a firm

A good example of this is with firms who offer online access via the internet (for example through a portal). Typically, customers would provide the following credentials:

  • A username, which in most cases is their email address; and
  • A unique password.

Here we have an issue in relation to SCA, because as it stands both would count as something the customer knows (knowledge). Therefore, we would only be using 1 of the required security credentials, not 2.
One way to make this compliant with the new rules would be to change the email address from being something the customer knows, to something the customer has (possession). In order for that to work, you would need to prove that the customer did access this email address. This could be done by using the email address in conjunction with a One Time Password (OTP).
In this scenario the customer would need to enter their email and unique password. The Payment Service Provider would then need to generate the OTP, to the email address for the customer to subsequently provide.
This is just one example of how SCA can affect a firm and there are may others that would need to be considered individually.
In addition to this, there is the concept of dynamic linking, which should be applied whenever an electronic payment is initiated.

Strong Customer Authentication AuthoriPay

What is Dynamic Linking?

The rules for dynamic linking specifically state that, when a payer instructs an electronic payment, measures must be implemented that meet a number of requirements, which are explained in the table below:
Dynamic Linking Requirement
What is means in practical terms
The payer is made aware of the amount of the payment transaction and of the payee;

In basic terms, this means that when making a payment, the payer must be shown the amount being sent and the name of the beneficiary. For example, if the customer is paying John Smith €1,000, then this must be clearly visible to them. It should be noted that the rules do not state how you must display this to the customer, so you have some flexibility here.

The authentication code generated is specific to the amount of the payment transaction and the payee agreed to by the payer when initiating the transaction; Essentially this means that, when you authorise the payment, you must generate an authentication code that is specific to this transaction and cannot be used for any other transaction. The code generated can take any form you like, as long as you are able to tie it to the specific payment.
The authentication code accepted by the payment service provider corresponds to the original specific amount of the payment transaction and to the identity of the payee agreed to by the payer;

Put simply, the payment service provider can only use 1 authentication code per payment. Given the number of systems a firm uses to process a single payment, it could be possible that each one of those systems generates its own unique authorisation code.  The payment service provider must choose 1 only to act as the dynamically linked authorisation code.

Any change to the amount / payee results in the invalidation of the authentication code generated; Should the transaction amount or payee change, then the authentication code needs to be cancelled and a new one, meeting the requirement above, issued

Access to Payment Accounts by Third-Party Payment Providers

Strong Customer Authentication AuthoriPay

A result of the Open Banking Initiative, as of September 14th, 2019 Payment Service Providers who offer payment accounts that are accessible online to payers will have to allow regulated Third-Party Payment Providers (TPP’s) access their customers account, using their SCA credentials.

Little is known about this particular regulation, and here we will break down the following:

• What is a Third-Party Payment Provider?
• Who has to allow access to them?
• What are the specific requirements?

1. What is a Third-Party Payment Provider (TPP)?

A TPP is a new type of regulated payment service, which was officially introduced through PSD2 (although in reality they had existed long before then). TPP’s can be broken down into 2 types of service:

  • Account Information Service Providers (AISP)
  • Payment Initiation Service Providers (PISP)

Account Information Service Providers (AISP)

AISPs will use a customer’s SCA credentials to log into their account and collate transactional information and balance details. This can be used for a variety of reasons, such as expenditure analysis or overview of financial position.

Payment Initiation Service Providers (PISP)

PISPs will use a customer’s SCA credentials to log into their account and instruct a payment directly to the customer’s nominated beneficiary. PISP’s will never enter into possession of the funds themselves.

2. Who has to allow access to TPPs?

Officially, if you qualify as an Account Servicing Payment Service Provider (ASPSP) and allow customers remote access to their Payment Account, then you must allow access to TPPs also.
To clarify, an ASPSP is someone who provides and maintains a payment account for a payer. If you do not allow your customer to make payments (for example merchant acquirers, whose customers receive payments but do not make them) then this rule does not apply.

3. What are the specific requirements?

Firms need not only to allow access to TPPs, but also have procedures in place to check that they are regulated. There are specific things a Payment Service Provider must do before allowing access:

  1. Verify SCA Credentials and issue an access token
  2. Check the eIDAS Certificate of the TPP Provider
  3. Check regulatory status of TPP Provider

Firms can do this using a dedicated system (either in built or one bought of the shelf) or by simply allowing the TPP provider to use the same channel as the customer. Where firms use a dedicated system, they must inform the regulator and provide them details of how it works.

Strong Customer Authentication AuthoriPay

How this affects the payment landscape.

The diagrams below show the payments landscape both before and after the new PSD2 rules are implemented. It illustrates not only how much impact the new rules will have, but also how much work is involved to be compliant.

What do firms need to do?

As a result of these new rules, firms will need to analyse the services they offer, decide if they are within the scope and what the impact will be, then put a project in place to make sure they are compliant by the deadline.

There is a lot to consider and little time to get ready. For more specific information and advice relevant to your firm get in touch with us today.

Strong Customer Authentication AuthoriPay
Strong Customer Authentication AuthoriPay

If you’d like to discuss any aspect of your business and the implications of SCA then get your one hour’s free consultancy today!

Get in touch

    AuthoriPay Ltd, Milton Hall,  Ely Road, Cambridge,   CB24 6WZ.