The idea of PSD2 is to give consumers more rights with their data and security as well as update the regulatory standards that are more than 15 years old. So, not only will the users be able to breathe a bit easier when conducting their business online, but with the addition of AISPs and PISPs, we also have far more options.

Account Information Service Provider (AISP)

AISPs provide consolidated information on one or more payment accounts held by the payment service user with either another payment service provider or with more than one payment service provider.

Payment Initiation Service Provider (PISP)

PISP is a service to initiate a payment order at the request of the payment service user concerning a payment account held at another payment service provider.

As far as security goes, before PSD2, if a user had a weak password and was hacked, it was the user’s fault and their issue. Hopefully, the firm worked with the user to restore any losses that occurred from the hack for the sake of PR alone.  

Click here to get our report on the most important aspects of customer  authentication

However, the new directive puts the responsibility of Strong Customer Authentication (SCA) on payment service providers and their partners. Yes, that means that if a user has a weak password, no two-factor authentication, and is hacked, the blame is placed on the firm providing the service. And the company must restore any loses the customer encountered by the next business day.

And in some cases, even strong password and 2FA might not help as the standard set by GDPR states that the security measures need to be in accordance with the associated risks as stated in Article 32 sections 1 and 2:  

  1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
    1. the pseudonymisation and encryption of personal data;
    2. the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
    3. the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
    4. a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.

  2. In assessing the appropriate level of security account shall be taken in particular of the risks that are presented by processing, in particular from accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed.
Click here to get our report on the most important aspects of customer  authentication

So, risk assessment goes hand in hand with the implementation of the appropriate security measures and the security provisions need to provide ongoing security, not just a one-time fix.

Some of the easier to implement and standard security updates to take up in the first place are:  

  • Change signup and login processes to force 2FA

The shift in responsibility will likely encourage any firm that handles payments, or sends and receives funds in any way, to force two-factor authentication. While the number of firms offering 2FA has increased in the last few years, it’s often hard to find where to enable it, and it’s not necessarily encouraged.

Instead, the option is there if the user wants it, somewhere in the account settings. Users who do not use 2FA see it as inconvenient and do not believe that they are at risk (they are though). Thus, firms do not want to force 2FA as it impedes the service convenience.

  • It’s time to change that.

The basic definition of “strong customer authentication” is presented in article 4(30) of PSD2. It states that authentication must be based on the use of two or more possible authentication elements, categorised as:

●     Knowledge (i.e., something only the user knows, such as a password)

●     Possession (i.e., something only the user has, such as a token or device)

●     Inherence (i.e., something only the user is, which a fingerprint or a face scan proves)

How does a firm “force” 2FA? Well, take two elements from the list above: knowledge and possession. As the username and password is already part of the signup and login process (knowledge), then requiring that users provide a mobile phone number so that the service could send an SMS PIN code to the device (possession) would mean that two steps are covered, thus making it 2FA. If current users have not provided a mobile phone number, ask for it with their next login and verify the number immediately, ensuring future protection.

Click here to get our report on the most important aspects of customer  authentication

Next, you could direct the user to the account page, encouraging them to use a time-based one-time password (TOTP) app like Verigator and begin using TOTP codes to authenticate. This part would be challenging to force, but TOTP is more secure than SMS PIN codes. It’s because of the mitigated data transmission between the code generator and code receiver, making transmission interception that much more difficult and less likely to happen.

However, SMS is still better than only using a password and proves possession. Plus, it’s easy to implement and manage. Also, the authentication process can trigger an SMS PIN code every time a user logs in, no matter what, so it’s simple to get this process started as a bare minimum for 2FA, adding additional options such as more secure protocols to prevent data breaches.


We've always recommended that users use 2FA every time they log in and again when they execute a sensitive transaction, like a payment, change their personal information or access any new parts of a service.

From January 2018, 2FA is mandatory by law under these regulations, and the structured rules are available via the PSD2 add-on the Regulatory Technical Standards (RTS).

Raili Liiva
2019-08-07 00:00:00 UTC