Account servicing payment service providers (ASPSPs) are required to allow that payment initiation service providers (PISPs) and account information service providers (AISPs) rely on the authentication procedures provided by them to the payment service users (PSU) in accordance with Article 97 PSD2. Furthermore, Article 30(2) RTS requires ASPSPs to ensure that AISPs and PISPs can rely on all the PSU authentication procedure(s) provided by an ASPSP to its PSUs. As clarified in EBA Opinions on the implementation of the RTS (EBA/OP/2018/04 and EBA/OP/2020/10), this implies that where the redirection method is used to carry out the authentication of the PSU, all the authentication procedures offered directly by the ASPSP to its PSUs should be supported also in a redirection scenario. If the interface provided by the ASPSP does not support all these authentication procedures, then this would be a breach of Article 30(2) RTS and an obstacle under Article 32(3) RTS.

A possible interpretation of these rules leads to the consequence that, if a PSU is using the services of an AISP/PISP via either a mobile app or a mobile browser app provided by the latter, the ASPSP which has implemented a redirection should enable the PSUs to authenticate not only via the ASPSP’s mobile app but also via an ASPSP’s mobile browser authentication page. This means that ASPSP should provide not only  an “app-to-app" redirection but also a “mobile app-to-mobile web browser” and a “mobile web browser -to- mobile web browser” redirection.

"App-to-App" redirection allows the TPP to redirect a PSU from the TPP application to the ASPSP’s mobile app, installed on the PSU’s device, where the TPP can transmit details of the request and connect the PSU into the ASPSP app authentication screen or function. The PSU is then authenticated using the same authentication method (credentials) as normally used when the PSU directly accesses its account using the ASPSP’s app (Soft OTP, pin-code or biometrics when activated).

On the other side, in a “mobile app-to-mobile web browser” and a “mobile web browser -to- mobile web browser” redirection scenario, where the PSU does not have the ASPSP’s mobile app, there should be a redirection to the ASPSP’s mobile browser website so that the PSU can authenticate with the ASPSP, using the authentication method for a mobile web browser.

Some ASPSPs have decided not to offer directly to their PSUs access to their electronic banking via mobile web browsers, due to duly justified security reasons.

The question is whether in such a situation these ASPSPs are required to allow a redirection of the PSUs to an ASPSP’s mobile web authentication page, which they consider as less secure.

The duly justified security risks determining why some ASPSPs are reluctant to offer a mobile web browser authentication page are summarized here below:

1. 1. The security of a mobile app is much higher than the security of a mobile browser. Opening up a mobile browser environment leads to a decrease in security levels.
   2. Reasons:
      1. No access through 'insecure' systems.  Access via rooted or jailbroken devices (smartphones and tablets) is blocked as these devices are more susceptible to malicious software. The mobile app contains software to detect whether a mobile device is jailbroken or rooted.  It even detects if there is software installed to mask this. Bypassing the mobile app will prevent this check from happening and thus deny access. 
      2. Lack of context information when using a mobile browser. Context information which is essential for a correct risk assessment. The mobile app collects a lot of contextual information about the device, such as the version of the OS, the patching level etc. which is considered during the risk analysis. When using a mobile browser this information is not available for fraud monitoring, which means the risk of abuse cannot be sufficiently assessed. Therefore, fraud monitoring will block requests initiated via a mobile browser more frequently.
      3. Mobile browsers are much more vulnerable to phishing, because the web address is normally not displayed. Many (publicly available) studies have been published on this subject.
      4. Because the ASPSP cannot have a contractual relationship with the AISP/PISP, the ASPSP has no legal possibility to require AISP/PIPSs to provide the necessary device profiling (such as the device fingerprint), that the ASPSP requires in its direct relationship with the PSU.

Furthermore the EBA/OP/2020/10 of the 4th June 2020 on obstacles paragraph 16 and 17 states that where the PSU is using the AISP/PISP’s services in a mobile web browser environment, and not via the AISP/PISP’s app, this is not considered an obstacle if the PSU is redirected to the ASPSP’s mobile browser authentication page to enter their credentials, provided that this is the only way in which PSUs authenticate when directly accessing their payment accounts via the ASPSP’s mobile web browser environment. If we reverse this reasoning (a contrario reasoning) this means that if the PSU is using the AISP/PISP’s services via the AISP/PISP’s mobile app it should not be considered an obstacle if the PSU is redirected to the ASPSP’s mobile app to enter its credentials, provided this is the only way in which PSUs authenticate when directly accessing their payment accounts via the ASPSP’s mobile app. Argument that is further enhanced by the fact that this is the only way to provide secure access.