According to Art. 66 and 67 PSD2 a PISP or AISP can only initiate a payment or access payment account information with the explicit consent of the payment service user (PSU).

Article 30(2)(a) also states that the interface developed by the ASPSP shall ensure that “a payment initiation service provider or an account information service provider shall be able to instruct the account servicing payment service provider to start the authentication based on the consent of the payment service user”.

As mentioned in paragraph 13 of the EBA opinion published in June 2018, “where AIS or PIS are provided to a payment service user (PSU) following a contract that has been signed by both parties, ASPSPs do not have to check consent. It suffices that AISPs and PISPs can rely on the authentication procedures provided by the ASPSPs to the PSU, when it comes to the expression of explicit consent.”

On that basis the TPP contacts the ASPSP and initiates a communication session. In such a session, no double check or second consent requirement may be introduced as this would hamper the frictionless functioning of the AIS or the PIS and go against the RTS and PSD2 as explained in the EBA opinion. In addition, Art. 32 (3) RTS points out, “additional checks of the consent” or “requiring additional authorisations” would hence amount to an illicit obstacle to the provision of AIS and PIS in violation of PSD2.

Variations around this principle have arisen in the market in particular with regard to whether banks can ex-ante ask their PSUs whether they want TPPs to access their accounts or not as well as whether the PSU for its convenience could revoke the consent given to a TPP with the bank as well as the TPP and in the first case for the bank to then pass on the information to the TPP.

In the case of the first, if the PSU would first have to actively declare to be willing to use services offered by TPPs towards his or her ASPSP, this would weaken the principle that all PSUs are entitled to use AISPs and PISPs and may discourage PSUs from using them or complicate the situation in cases where the PSU changes his mind and wishes to start using TPP services.  By the same token, also an opt-out from the use of PIS or AIS in a way that an ASPSP disables the use of such services would not be allowed. In that case, PSUs would no longer be able to rely on TPP unless they provided an additional authorization or additional consent that in our view goes beyond the authorisation agreed with the ASPSP in line with Art. 64 (2), 66 and 67 PSD2. As set out above, such additional consent or authorisation shall not be required and as highlighted in the EBA opinion ASPSPs may not check the consent provided by the PSU to a PISP/AISP. Doing it ex ante as suggested by some banks would similarly conflict with this principle. The PSU should remain free to decide whether or not to use an AIS or a PIS. Article 68(5) PSD2 enables the ASPSP to block AIS or PIS access only if this access is ‘unauthorised or fraudulent’.

In the second case, for the ASPSP to be able to revoke consent with an AISP/PISP on behalf of a PSU, ASPSPs would need to have access to consent information and be informed of which AISP and/or PISP the PSU has provided explicit consent to. This would contradict the legal principle highlighted in the EBA opinion that ASPSPs cannot and should not check the consent. In addition if ASPSPs were allowed to revoke the consent, it would mean that they are able to manage the PSU’s consent which, in our view, again conflicts with the principle highlighted in the opinion.