Security and PSD2

Sergi Lao
Flanks
Published in
4 min readFeb 10, 2020

Objectives of the PSD2​

The PSD2 returns to the users, real owners of the data, the right to choose who should have access to them. In this way, the new normative regulates access to financial data being only regulated entities who can access the information as long as they have and can demonstrate the user’s prior consent.

One of the main objectives of the PSD2 is the security of the users, for this reason, it requires strong client authentication, risk analysis, transaction risk and communication through secure channels.

Objectives of the PSD2

Strong Client Authentication (SCA)

To carry out the strong client authentication (SCA), multi-factor authentication is used, consisting of the combination of two (or more) elements that have one of the following characteristics:

  • Knowledge: Something that the user knows, such as a code, a password or a unique identifier.
  • Possession: Something that the user has, such as a token, a mobile device, dni-e, etc.
  • Inherence: Something that the user is, something characteristic of the person such as footprint, iris, voice or face.
Strong Client Authentication (SCA)

The combination of these characteristics is important. Two or more independent elements must be requested which have one of the 3 characteristics mentioned previously. It should be noted that the objective of multi-factor authentication is that the violation of one of the factors does not compromise any of the remaining factors. The authentication code mustn’t be sent or transmitted through the same channel through which the authentication process was initiated, that is if the user initiated access through their mobile application that the authorization code is not sent through the same application because if this channel is compromised the entire authorization process would be vulnerable.

PSD2 and GDPR

Likewise, PSD2 governs the use of strong client authentication both to authorize access to data and to carry out transactions under a certain criterion. As we usually find a trade-off between usability and security, for this same reason this criterion is established, to minimize the impact on the user experience.

Talking about management of the data, the PSD2 has many things in common with the GDPR, in both cases, the user must give explicit consent for the processing of the data, likewise, the user must also have the right to modify and revoke the access. They also agree on transparency and, therefore, on the obligation on the part of third-party service providers to notify users when a security incident occurs.

One of the differences of the GDPR concerning the PSD2 is that the latter requires the re-authorization of access every 90 days so that if this reauthorization is not performed, the access is revoked after this period. This implies that when an AISP is given access for the first time, it can only access the information generated in the last 90 days, and to access previous information a new explicit consent by the user will be required.

It would be ideal to adopt simple authorization standards such as OAuth 2.0 with the extension of the OpenID Connect profile since through this standard authorization could be carried out without the need for the user to communicate their credentials to the service provider companies.

Regarding secure communication, PSD2 applies the mutual authentication mechanism between financial entities (ASPSP) and service providers (AISP, PISP) ​​through the use of eIDAS, which is a European system of recognition of electronic entities so that the authenticity of both ends of the communication can be verified.

With the application of all these measures and the respective mechanisms, the PSD2 aims to improve the protection of users, payment transactions and anti-fraud protection. Not forgetting that all entities defined by the PSD2: AISP, PISP, and ASPSP must comply with strict standards and security controls at the architectural and operational levels to carry out their activity.

Terms and concepts to be developed in-depth in the following articles:

  • AISP: Account Information Service Provider
  • PISP: Payment Initiation Services Provider
  • ASPSP: Account Servicing Payment Service Provider
  • SCA: Strong Customer Authentication
  • PSD2: Payment Service Directive 2
  • GDPR: General Data Protection Regulation

Get in touch

If you want to talk about how Flanks can help you, visit our website for further information or contact us by email. Finally, if you want to discover how our Financial Data Aggregation API works, visit our platform and register to try it out.

Financial Data Aggregation API

Originally published at https://blog.flanks.io on February 10, 2020.

--

--