In June 2020, the European Banking Authority (EBA) published an Opinion clarifying certain provisions of the Regulatory Technical Standards (RTS) on strong customer authentication (SCA). The Opinion of the EBA is dedicated to clarifying the setup of interfaces provided by account servicing payment service providers (ASPSPs) to third parties, specifically to account information service providers (AISPs) and to payment initiation service providers (PISPs). These interfaces must be set up in a way that imposes no obstacles on its use by these third parties.
RTS on SCA provides only a few examples of such obstacles (e.g. mandatory redirection for authentication). The EBA has repeatedly clarified what can be understood as an obstacle (for example in separate Q&As or opinions), but current market practices created a need for new interpretation and clarification.
The Opinion makes it clear that an access of third parties to interfaces provided by ASPSPs without any obstacles is a priority for the EBA. The EBA therefore appeals to national competent authorities (CAs) to strictly ensure compliance of interfaces provided by ASPSPs with the above-mentioned regulation. In a case where obstacles to third parties are identified, the CAs should contact the responsible ASPSP and ensure that any obstacles identified are removed in the shortest time possible.
The RTS on SCA establishes that a client of a third party must have access to the same method of authentication that is provided by the ASPSP to its own clients. Therefore, the setup of the authentication process for third party clients should be modelled according to the setup already used by the clients of the ASPSP. The authentication method for third party clients may not be more complicated than authentication for clients of the ASPSP (e.g. a requirement for more information or more steps to be taken would be considered an obstacle).
If the ASPSP offers authentication through the provider’s mobile application to its clients, the same should be offered to clients of the third parties. If it is not offered, the EBA will consider this an obstacle that breaches the RTS to SCA. In practice, this means that in order to proceed with user authentication, the user should be redirected from the application of the third party to the application of the ASPSP (which of course must be installed on the device) and after the authentication is done, the user shall be redirected back to the application of the third party without having to open or close it manually.
The EBA also deems it an obstacle for third party clients if double SCA is required for indirect transactions, in case of access to the account as well as in case of payment initiation. If PISP provides enough information for payment execution to the ASPSP, one SCA is sufficient. An exception to this rule (i.e. the only case where double SCA is acceptable) is when security measures are imposed on the side of the ASPSP. An example of such an exception is the situation where the ASPSP suspects a fraud and is also able to justify this suspicion to the CA. Double SCA is also acceptable if the client requires access to information on the account on top of the transaction, or if the third party cannot provide all required information to the ASPSP.
In general, the ASPSP is required to conduct SCA when the client requests access to their account online. An exception to this rule might be applied in relation to access to information about account balance or about account transaction history for the past 90 days. SCA is always necessary in case of first access to such information and then every 90 days since the last SCA. This exception applies to third party clients too. In other words, a user can access the above-mentioned information through the AISP if SCA has been conducted at least once in last 90 days by the ASPSP.
The providers of such account information have voiced a concern that the requirement of re-authentication every 90 days could discourage their clients from using their services. They believe that to satisfy the requirement in a user-friendly way, the ASPSP should outsource the execution of SCA to the third party, so that the users could conduct SCA directly through the AISP. In response to this concern, the EBA claims that this setup is acceptable, but that the ASPSP it is not obliged to do it. However, if the ASPSP does agree and decides to outsource the SCA to the third party, the ASPSP must fulfill all responsibilities that the outsourcing implies.
The EBA believes that an interface setup which requires a manual entry of the IBAN by the client is an obstacle to the third party, including both PISP and AISP. One way in which ASPSP can avoid this obstacle is to enable the client to select the account directly through the interface or website of the ASPSP (to which the user would be redirected). The account selection must not be more complicated compared to the account selection when the user initiates the payment or accesses their account directly through the ASPSP. However, this process can only be used by third parties with AISP licenses. Not providing a PISP client with this account selection process is not considered an obstacle.
The EBA has repeatedly confirmed that a setup of ASPSP that requires an opt-in consent to the provision of services by the third party is an obstacle. Similarly, requiring the third party to obtain additional permissions or registrations is considered an obstacle too (this practice is explicitly prohibited by the RTS). The EBA indicates that an exception applies to a situation where registration is necessary for the technical assurance of a secure communication between the ASPSP and the third party. However, registration (e.g. in the form of providing contact information of the third party) cannot be required specifically for the access of the third party to the account of the client at the ASPSP, unless such practice is agreed upon voluntarily between the two parties.
Seminars, webcasts, business breakfasts and other events organized by Deloitte.
