A Decoupled authentication allows a TPP to have the PSU authenticate with their ASPSP app when the PSU is consuming the TPP service on a device other than the one which has the ASPSP app, or even when the PSU is not present on the TPP channel.
Other pages in this section
The current OBIE standards support redirection authentication flows. A redirection approach has a specific TPP channel and device dependency and therefore cannot support channel agnostic use cases that involve telephony, POS, IoT devices, or where physical PSU interaction is either not possible or not required within the TPP channel. It is essential that the OBIE standards should be able to allow ASPSPs to provide obstacle-free authentication flows to support a wider range of TPP channels and devices.
An Evaluation (P4) was conducted by OBIE to access whether other authentication flows may provide a comprehensive solution to cover these out of band interactions and further facilitate compliance with RTS. This P4 Evaluation contained three recommendations:
This proposition paper addresses recommendation 2 above, which mandated the creation of a decoupled standard. Please refer to the P3/P4 Evaluation Letter from the Trustee dated 10th July 2018 for further details (the “Letter”). It should be noted that as of the date of this consultation the final text of the Letter is not yet available and is expected imminently. When the final text of the Letter is made available a short impact assessment will be undertaken to confirm this delivery exercise will meet the requirements of the Letter.
Nonetheless, the Trustee has confirmed that the provision of a decoupled standard is a core action and consequently special dispensation was granted at IESG (27/6/18) to progress decoupled through to discovery and delivery in parallel to the completion of the Evaluation process so as to not compromise the program delivery timeline.
As provided in the P3/P4 Evaluation letter, the OB definition of Decoupled is:
“A Decoupled authentication allows a TPP to have the PSU authenticate with their ASPSP app when the PSU is consuming the TPP service on a device other than the one which has the ASPSP app, or even when the PSU is not present on the TPP channel. In order for Decoupled to work with wider use cases, the standards must allow for four models:
Decoupled authentication can also occur where the TPP and ASPSP interaction are on the same device, but this does not offer a good user experience compared to a well-implemented redirect flow, and hence this method will not be covered by this proposition.
This paper defines the overall proposition for OBIE standards, including technical specifications, user experience guidelines, and requirements for management information (MI) reporting, to support decoupled authentication, so that participants (ASPSPs and TPPs) and stakeholders (FCA, HMT, CMA) have a common understanding about what is and is not in scope, and how this proposition will support regulatory requirements and key use cases.
The key principle for Decoupled authentication is that the PSU authenticates using their mobile banking app.
72% of the UK adult population will bank via a phone app by 2023 as per industry analyst CACICACI Report
Although the PSU will frequently interact with the TPP on the same device as the ASPSP interacts with the PSU, the PSU will also consume TPP services through diverse channels and devices other than the one they share with the ASPSP (Out of Band).
A decoupled approach to authentication offers a better customer experience for use cases that involve POS, IoT devices, telephony or where PSU interaction is either not possible or not required within the TPP channel.
The OBIE standard for Decoupled authentication will support four models of interaction which in turn will enable a wide number of customer use cases.
The standard will define:
The illustrations below are based on biometric authentication. Other non-biometric examples (e.g. one time passwords) will be covered in the Customer Experience Guidelines. However, these alternatives to biometrics can result in a sub-optimal customer experience in many cases.
This model is best suited to TPP apps with good user input options (e.g. website on PC/laptop) but also where POS terminals can scan debit card numbers and automatically resolve the ASPSP if these are used as customer identifiers.
The exact type of identifier supported by the ASPSP must be published by the ASPSP as in requirement 10.1.2.
Note: Model A, by design, can also support the transmission of PSU credentials (e.g. username and password) by the TPP to the ASPSP. OBIE do not recommend this and believe such usage should only be allowed where no alternatives exist and where this is supported by the ASPSP. This is not a fully embedded model, since any factors here should only be considered a hint and authentication should always be via the ASPSP interface (e.g. using biometrics in a mobile app).
This model is best suited to a TPP app that can “capture” the code from the ASPSP app (e.g. by scanning a QR code). Alternatively, the PSU can be prompted to type in an identifier in the TPP App. This may be a long series of characters and may result in a sub-optimal customer experience.
This model is best suited for TPP devices which can present an identifier which can be scanned by the ASPSP app (e.g. a QR code). Alternatively, the PSU can be prompted to type in the identifier in the ASPSP app. This may result in a sub-optimal customer experience.
The standard will define rules for the format of the identifier. Exact type of scannable identifier supported by the ASPSP will have to be published by the ASPSP as in requirement 10.1.2
This model is ideally suited where the services offered by the TPP involve POS, telephony, or where PSU interaction with the TPP is not possible through a graphical interface (IoT devices) or even when the PSU may not be present within the TPP channel.
The optimum customer experience and the use cases supported by decoupled approach depend on the relationship the PSU has with the TPP (AISP/PISP). The following table illustrates some of the differences between each model:
The following are a few example use cases which can be enabled through decoupled authentication. This list is by no means exhaustive.
Regulation 100(4) PSRs and Article 30(2) RTS require that ASPSPs allow TPPs to rely on all the authentication procedures provided by the ASPSP to the PSU. In addition, Article 32(3) RTS requires that ASPSPs implementing a dedicated interface must ensure that their interface does not create obstacles to the provision of PIS and AIS.
The EBA has clarified in its opinion paper (see paragraph 50) that this means all methods of SCA provided to the PSU need to be supported when an ASIP or PISP is used. If they were not, this would constitute an obstacle. The method (or combination of methods) that a particular ASPSP will, therefore, need to make available to TPPs will depend on the authentication or procedures it offers to its own PSUs.
Key evaluation criteria that OBIE have applied for this proposition (that respect the objectives of meeting regulatory requirements as well as being effective and proportionate) are:
The following principles, derived from regulatory references and the EBA opinion paper, were used while developing this proposition:
Therefore, if a PSU currently uses an ASPSP app-based authentication method when accessing the ASPSP channel directly, they should be able to use the ASPSP’s app-based authentication method when using a TPP, irrespective of the channel/device through which TPP offers the service.
Specifically, for an AISP or PISP services that involves POS or telephony, or where PSU interaction is not possible (IoT devices) or required, authentication through the ASPSP app can be supported only using a decoupled approach.
In order for ASPSPs to allow the PSU to be able to authenticate through the ASPSP app and support the wide range of TPP use cases, the OBIE standards must allow for all of the above-decoupled authentication methods if the PSU is not consuming the TPP service on the same device which has their ASPSP app (Out of Band).
The following metrics will be required to measure adoption:
Volume of decoupled authentications initiated by the PSU and categorised by each of the following categories:
These are stated as requirements of the OBIE solution to enable implementers to meet regulatory compliance and/or customer use cases.
Requirements marked as ‘M'(Must) are in scope of the OBIE solution. All other requirements are listed for future consideration. The final column indicates whether each requirement is ‘mandatory’, ‘conditional’ or ‘optional’ for implementation by ASPSPs and/or TPPs. These terms are defined here: Categorisation of requirements for standards and implementation.
As stated above, the Implementation Trustee instructed OBIE to develop a standard for decoupled authentication. Hence the majority of the requirements below are considered a ‘regulatory must’ for the OBIE standards under the CMA Order.
Research and conversations with consumers and TPPs have revealed a number of undesirable features of the customer journey:
P3 • Efficacy of consumer authentication step Previous
P5a • Future-dated payments and standing orders Next