Is a process that requires Third Party Providers (TPPs) to upload an electronic IDentification, Authentication and trust Services (eIDAS) certificate for receiving additional client credentials before first access to a payment account provided by an Account Servicing Payment Service Provider (ASPSP) to be considered an “additional registration” and therefore an obstacle?
During our assessment of dedicated interfaces (APIs) we noticed dedicated interfaces from ASPSPs that require TPPs to upload a valid eIDAS certificate onetime before they can access a payment account provided by a specific ASPSP for the first time to receive account information or initiate a payment. After this initial call, which is sometimes described as “TPP onboarding”, a TPP receives client credentials from the ASPSP, which need to be provided with every following call and additionally to the eIDAS certificate. The general authorisation process in this context is technically based on the OAuth 2.0 Authorization Framework. The process seems to run automatic in the sense that all required information can be provided as part of a technical server request. If an eIDAS certificate gets obsolete, the obsolete eIDAS certificate has to be replaced with a new, valid one. To achieve this, the TPP has to transfer it once via a certificate upload service to receive new client credentials.
Most ASPSPs do not require such additional steps with their dedicated interfaces. We assume that this type of registration derives from the used OAuth 2.0 Authorization Framework, which works with such client credentials. However, in the context of PSD2 dedicated interfaces, such additional client credentials seems to be unnecessary, as identification of the TPP can be based on eIDAS certificates only.
Article 32(3) of the Commission Delegated Regulation (EU) 2018/389 provides that dedicated interfaces should ‘not create obstacles to the provision of payment initiation and account information services. Such obstacles may include, among others,…. requiring additional authorisations and registrations in addition to those provided for in Articles 11, 14 and 15 of Directive (EU) 2015/2366’.
Paragraph 49 of the EBA Opinion on obstacles under Article 32(3) of the RTS on SCA&CSC (EBA/OP/2020/10) clarified that not all registrations required by account servicing payment service providers (ASPSPs) are automatically an obstacle, and that if the registration is technically required to enable a secure communication with the ASPSP, is processed in a timely manner and without creating unnecessary friction in the customer journey, then it would not necessarily amount to an obstacle.
Paragraph 50 of the aforementioned Opinion further clarified that additional registrations required by ASPSPs for third party providers (TPPs) to be able to access the payment service users’ (PSUs) payment accounts, or the ASPSPs’ production interface, that go beyond what is technically necessary in order to ensure secure access to payment accounts under the conditions of the RTS, are an obstacle under Article 32(3) of the Delegated Regulation.
In this respect, article 34(1) of the Delegated Regulation is clear that payment service providers (PSPs) shall rely on eIDAS certificates for the purpose of identification as referred to in Article 30(1)(a). This means that no other requirements beyond the eIDAS certificate, such as the provision of client credentials, are required for the purpose of identification in accordance with the Delegated Regulation.
Therefore, a process whereby TPPs are required to upload their eIDAS certificate before the first access request, and each time the certificate is replaced by a new one, in order to receive client credentials, and to provide these client credentials to the ASPSP for each access to the PSUs’ payment accounts, constitutes an obstacle, unless such steps are technically required to enable a secure communication with the ASPSP, are processed in an automated and timely manner and do not create unnecessary friction in the customer journey.