Customer Experience Guidelines

Authentication Methods

This version is:

Published 2 years ago 31 Mar 2020

One of the primary objectives of the Customer Experience Guidelines is to provide simplification and consistency across all Open Banking implementations. As such, we have defined a core set of authentication methods that can and should be used, subject to the scope and flexibility of any payment initiation and/or account information services provided by TPPs.

Other Journeys in ‘v3.1.5’.

Redirection based authentication

Redirection based authentication has a range of possible experiences for a PSU based on whether the PSU has an ASPSP app or not, and the device on which the PSU is consuming the TPP (AISP/PISP/CBPII) service.

The FCA have made clear in their Approach document that PSUs must be able to authenticate using the authentication methods they are accustomed to using  via the banking application (‘app’) on a mobile phone if accessing accounts via a TPP.

We have used one example of an AISP and PISP journey to demonstrate how redirection flows must work. These apply to variations in AIS/PIS/CBPII journeys related to the order of application of SCA and are covered in sections 5, 6 and 7.

Browser Based Redirection – AIS

User Journey   PSU Authentication with the ASPSP using browser based redirection from an AISP for an AIS request. This enables a PSU to authenticate with their ASPSP while using an AISP for an AIS service, using the same web based authentication method which the PSU uses when accessing the ASPSP web channel directly. This…

This version was published 2 Years & 3 Months ago 31 Mar 2020

Browser Based Redirection – PIS

User Journey   PSU Authentication with the ASPSP using browser based redirection for a PIS request. This enables a PSU to authenticate with their ASPSP while using a TPP for the PIS service, using the same web based authentication method which they use when accessing the ASPSP web channel directly. This model works when the…

This version was published 2 Years & 3 Months ago 31 Mar 2020

App Based Redirection – AIS

User Journey   PSU authentication with the ASPSP using the ASPSP mobile app installed on the same device on which the PSU is consuming the AISP service. This enables the PSU to authenticate with the ASPSP while using an AISP for an AIS service using the same ASPSP app based authentication method which they use…

This version was published 2 Years & 3 Months ago 31 Mar 2020

App Based Redirection – PIS

User Journey     PSU authentication, with the ASPSP using the ASPSP mobile app installed on the same device on which the PSU is consuming the PISP service. This enables the PSU to authenticate with the ASPSP while using a PISP for a PIS service using the same ASPSP app based authentication method that they…

This version was published 2 Years & 3 Months ago 31 Mar 2020

App to Browser Redirection

App-to-browser redirection – AIS It is possible that a PSU using a mobile device does not have their ASPSP mobile app installed, or their ASPSP does not provide an app at all. In these instances, the TPP app will need to launch the native mobile browser in order to present the PSU with their ASPSP’s…

This version was published 2 Years & 3 Months ago 31 Mar 2020

App-to-browser redirection – AIS

App-to-browser redirection – AIS It is possible that a PSU using a mobile device does not have their ASPSP mobile app installed, or their ASPSP does not provide an app at all. In these instances, the TPP app will need to launch the native mobile browser in order to present the PSU with their ASPSP’s…

This version was published 2 Years & 3 Months ago 31 Mar 2020

Browser-to-app redirection

App-to-browser redirection – AIS It is possible that a PSU using a mobile device does not have their ASPSP mobile app installed, or their ASPSP does not provide an app at all. In these instances, the TPP app will need to launch the native mobile browser in order to present the PSU with their ASPSP’s…

This version was published 2 Years & 3 Months ago 31 Mar 2020

Effective use of redirection screens

App-to-browser redirection – AIS It is possible that a PSU using a mobile device does not have their ASPSP mobile app installed, or their ASPSP does not provide an app at all. In these instances, the TPP app will need to launch the native mobile browser in order to present the PSU with their ASPSP’s…

This version was published 2 Years & 3 Months ago 31 Mar 2020

Decoupled authentication

A major addition to the Open Banking standards known as “Decoupled” authentication, where typically the PSU uses a separate secondary device to authenticate with the ASPSP. This model allows for a number of innovative solutions and has the added benefit of allowing a PSU to use their mobile phone to authenticate. Taking advantage of biometrics for SCA, where they are engaging with a PISP through a separate terminal, such as a point of sale (POS) device.

We have used examples for a PIS journey, but the same principles apply for AIS and CBPII journeys.

Under the Decoupled standard, the following customer experiences are available

Decoupled Model A: Static PSU Identifier

PSU provides a static identifier to the TPP (AISP/PISP/CBPII) which is passed to ASPSP to identify the PSU   User Journey   A decoupled authentication flow, where the PSU provides a static identifier to the TPP (AISP/PISP/CBPII) which is used by the ASPSP to notify the PSU, such that the PSU can authenticate using the…

This version was published 2 Years & 3 Months ago 31 Mar 2020

Decoupled Model B: ASPSP Generated Identifier

PSU provides an ASPSP generated unique identifier to the TPP (AISP/PISP/CBPII) which is then passed back to ASPSP to identify the PSU   User Journey   Demo journey A decoupled authentication flow where the PSU provides a dynamic identifier generated with their ASPSP to the TPP (AISP/PISP/CBPII) which is then used by the ASPSP to…

This version was published 2 Years & 3 Months ago 31 Mar 2020

Decoupled Model C: TPP Generated Identifier

PSU provides a TPP (AISP/PISP/CBPII) generated unique identifier to the ASPSP to identify the request from the TPP   User Journey     A decoupled authentication flow where the PSU provides a dynamic identifier generated with their ASPSP to the TPP (AISP/PISP/CBPII), which is then used by the ASPSP to identify the PSU through the…

This version was published 2 Years & 3 Months ago 31 Mar 2020

Decoupled Model D: PSU with a TPP Account

TPP (AISP/PISP/CBPII) passes the PSU’s stored unique identifier to the ASPSP to identify the PSU User Journey A decoupled authentication flow where the TPP (AISP/PISP/CBPII) provides the ASPSP a stored PSU identifier, generated by the ASPSP from a previous PSU transaction. This is used by the ASPSP to notify the PSU such that the PSU can…

This version was published 2 Years & 3 Months ago 31 Mar 2020

RTS SCA Exemptions

SCA -RTS includes a number of exemptions from the application of strong customer  authentication, which include payments made to trusted beneficiaries, low value payments and payment based on transaction risk analysis. The application or not of SCA and the exact implementation of an SCA exemption is at the ASPSP’s discretion.

This section highlights the OB API Standard capabilities to allow PISPs to provide sufficient information about a transaction and about the PSU (if available) to enable the ASPSP to determine whether or not the exemptions are applicable.

The EBA notes that “there would appear to currently be three main ways or methods of carrying out the authentication procedure of the PSU through a dedicated interface, and APIs in particular, namely redirection, embedded approaches and decoupled approaches (or a combination thereof). In the cases of redirection and decoupled approaches, PSU’s authentication data is exchanged directly between PSUs and ASPSPs, as opposed to embedded approaches, in which PSU’s authentication data is exchanged between TPPs and ASPSPs through the interface.”

PSD2 requires strong customer authentication to be performed in certain circumstances. The RTS requires that this application of strong customer authorisation is based on the use of elements, which are categorised as knowledge (something only the user knows), possession (something only the user possesses) and inherence (something the user is). These elements require adequate security features, which include ensuring that they are applied independently, so that the breach of any element does not compromise the reliability off the other.

ASPSPs implementing redirection should note that the FCA Approach document  (Payment Services Regulations 2017 and the Electronic Money Regulations 2011) states it is not aware of any reason for ASPSPs to request strong customer authentication more than once when facilitating authentication for a single session of access to account information or a single payment initiation.

The Open Banking 2.0 standards specified redirection authentication flows only and the current ASPSP implementations of redirection are predominantly browser-based, whereby the PSU is redirected from the TPP app or website to the ASPSP’s website in order to authenticate. It is essential that when redirection is implemented it also allows for the PSU to use their ASPSP mobile app to authenticate, if the PSU uses this method of authentication when accessing their ASPSP’s channel directly.

Redirection has a specific TPP channel and device dependency and therefore cannot support channel agnostic use cases that involve telephony, POS, and IoT devices, or where physical PSU interaction is either not possible or not required within the TPP channel. These use cases can be supported using a decoupled approach to authentication.

In view of the above, the Open Banking 3.0 standards will support both redirection and decoupled authentication to allow a PSU to use the same authentication mechanisms while using an AISP or PISP as they use when accessing the ASPSP directly.

The general principles that apply relating to authentication are:

1. ASPSPs authenticate: PSU needs to go through a strong customer authentication (SCA) at their ASPSP in order for a TPP request (i.e. access to information or payment initiation) to be actioned by the ASPSP.

2. PSUs must have their normal authentication methods available:
A PSU must be able to use the elements they prefer to authenticate with their ASPSP if supported when interacting directly with their ASPSP.

3. Parity of experience: The experience available to a PSU when authenticating a journey via a TPP should involve no more steps, delay or friction in the customer journey than the equivalent experience they have with their ASPSP when interacting directly.

4. Strong Customer Authentication: It is not expected that SCA would be required more than once when facilitating authentication for a single session of access to account information or a single payment initiation.

5. No Obstacles: ASPSPs must not create unnecessary delay or friction during authentication including unnecessary or superfluous steps, attributes, or unclear language, e.g. advertising of ASPSP products or services, language that could discourage the use of TPP services or additional features that may divert the PSU from the authentication process.