Authentication Methods
Overview
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.
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.
Redirection based authentication
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.
Decoupled authentication
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
RTS SCA Exemptions
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.