P4 • Authentication step aligned to PSD2

• 1. Version Control
• 2. Roadmap Definition
• 3. Market analysis
• 4. Use cases
  • 4.1 Supported models
    • 4.1.1 Model A:  Static PSU identifier –  PSU provides a static identifier to the TPP which is passed to ASPSP to identify the PSU
    • 4.1.2 Model B: ASPSP generated identifier – PSU provides an ASPSP generated unique identifier to the TPP which is then passed back to ASPSP to identify the PSU
    • 4.1.3 Model C: TPP-generated identifier – PSU provides a TPP-generated unique identifier to the ASPSP  to identify the request from the TPP 
    • 4.1.4 Model D: PSU with a TPP account   – TPP passes the PSU’s stored unique identifier to the ASPSP to identify the PSU
  • 4.2 Models compared 
  • 4.3 Customer use cases 
• 5. Regulatory references
  • 5.1 PSRs and RTS
  • 5.2 EBA opinion
• 6. Evaluation criteria
• 7. Product requirements
• 8. Considerations
  • 8.1 Assumptions
  • 8.2 Dependencies
  • 8.3 Constraint
• 9. Measuring adoption
• 10. Appendix
  •  10.1 Detailed Product Requirements
  • 10.2 Sources of unnecessary friction

1. Version Control

2. Roadmap Definition

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:

• Recommendation 1: The CMA9 should remain focused on doing Redirection well
• Recommendation 2: Develop standards supporting Decoupled authentication
• Recommendation 3: Continue to assess the market

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 10^th 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:

• Model A: Static PSU identifier –  PSU provides a static identifier to the TPP which is passed to ASPSP to identify the PSU
• Model B: ASPSP generated identifier – PSU provides an ASPSP generated unique identifier to the TPP which is then passed back to ASPSP to identify the PSU
• Model C: TPP generated identifier – PSU provides a TPP generated unique identifier to the ASPSP  to identify the request from the TPP
• Model D: PSU with a TPP account  – TPP passes the PSU’s stored unique identifier to the ASPSP to identify the PSU

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.

3. Market analysis

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 CACI^[1]CACI 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).   

• 82% of retail sales are done in store

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. 

4. Use cases

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:

• Technical specifications to enable all of these models, including allowed format for identifiers (e.g. QR codes, alpha numeric codes), which identifiers can be used in each model, how long identifiers are valid for, etc.
• Customer Experience Guidelines for a variety of use cases.

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.

4.1 Supported models

4.1.1 Model A: Static PSU identifier – PSU provides a static identifier to the TPP which is passed to ASPSP to identify the PSU

1. PSU selects their ASPSP and provides a static identifier (user id, debit card number, sort code and account number) into the TPP website/app (TPP stages consent with ASPSP in the background).
2. ASPSP sends a push notification to the PSU on their mobile device(s).
3. PSU opens the notification (which opens their banking app) and authenticates (generally biometrics).
4. PSU confirms the account access or payment order request (where applicable).
5. TPP receives token from ASPSP and informs PSU that account access or payment initiation is successful.

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).

4.1.2 Model B: ASPSP generated identifier – PSU provides an ASPSP generated unique identifier to the TPP which is then passed back to ASPSP to identify the PSU

1. PSU is prompted by TPP website/app to open their ASPSP app.
2. PSU opens their banking app and authenticates (SCA using biometrics).
3. PSU uses a code generator in their banking app to display a one-time code. The one-time code could be represented as a QR code.
4. PSU uses the TPP website/app to scan or enter the code (TPP stages consent with ASPSP in the background).
5. This prompts the ASPSP to send a push notification to the PSU on their mobile device. PSU authorises the account access or payment order request (where applicable).
6. TPP receives token from ASPSP and informs PSU that account access or payment initiation is successful.

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.

4.1.3 Model C: TPP-generated identifier – PSU provides a TPP-generated unique identifier to the ASPSP to identify the request from the TPP

1. PSU selects their ASPSP in TPP website/app (TPP stages consent with ASPSP in the background). TPP provides PSU with a unique identifier (QR/Barcode or text string).
2. PSU opens their banking app and authenticates (generally biometrics) .
3. PSU scans/enters the unique ID (using built in QR/Barcode scanner or typing the ID in the ASPSP app) where the link is created with the consent staged by the TPP. 
4. PSU confirms the account access or payment order request (where applicable).
5. TPP receives token from ASPSP and informs PSU that account access or payment initiation is successful.

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

4.1.4 Model D: PSU with a TPP account – TPP passes the PSU’s stored unique identifier to the ASPSP to identify the PSU

1. PSU has first ‘bound’ their TPP account or device to their ASPSP account, which could be done using a redirect flow or any of the above-decoupled models.  
2. PSU identifies themselves direct with TPP, e.g. via voice commands Google Home, Alexa or other IoT device, login to TPP website, scanning of a registered loyalty card, or access to a TV (TPP stages consent with ASPSP in the background, also passing through the PSU’s unique identifier).
3. ASPSP sends a push notification to the PSU on their mobile device.
4. PSU opens the notification (which opens their banking app) and authenticates (SCA using biometrics).
5. PSU authorises the account access or payment order request (where applicable).
6. TPP receives token from ASPSP and informs PSU that account access or payment initiation is successful.

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.

4.2 Models compared

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:

4.3 Customer use cases

The following are a few example use cases which can be enabled through decoupled authentication. This list is by no means exhaustive.

5. Regulatory references

5.1 PSRs and RTS

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. 

5.2 EBA opinion

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. 

6. Evaluation criteria

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:

1. Does the proposition meet the use cases from a PSU and a TPP perspective (from both an outcome and risk point of view)?
2. Is the proposition implementable at a reasonable cost?
3. Does the proposition comply with all relevant regulations?

7. Product requirements

The following principles, derived from regulatory references and the EBA opinion paper, were used while developing this proposition: 

• The TPP (AISP/PISP) may design the user experience for any device or channel (for example PoS, wearables, voice etc). 
• When using a TPP, the PSU should be able to use the same authentication methods and procedures they use while accessing ASPSP channels directly.
• The authentication procedures implemented by the ASPSP should not be restrictive or obstructive for TPPs.

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).

8. Considerations

8.1 Assumptions

• Some PSUs may have a device that allows multiple users to perform biometric authentication. It is for the device owner to ensure that other users of their device do not access mobile banking apps. This also applies to any device where users have stored passwords in their browsers.
• Whether or not a device potentially has multiple users, there should be no difference in behaviour for a TPP-driven journey as for a direct journey.

8.2 Dependencies

• Agreeing on existing industry standards to be used for the technical designs
• Depending on which of the above models is being implemented, TPPs and ASPSPs should have the ability to support scanning of codes for optimal customer experience with a fallback option of allowing entry of alpha numeric codes.
• The PSU must have the ASPSP’s mobile app installed and registered.
• To make use of biometrics (if supported by the ASPSP), the PSU must also have this configured in their mobile app.

8.3 Constraint

• Decoupled does not create an ideal user experience where the the device consuming the TPP service and the device with the ASPSP app are the same.
• The ASPSP does not receive the channel information(location, browser, app) as available in redirect model. 

9. Measuring adoption

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:

1. Decoupled model
2. Initiating device/channel type (app, web, IoT device, POS etc)
3. ASPSP Authentication channel (web, app)
4. The decoupled authentications completed and abandoned by the PSU
5. For completed decoupled authentications, the authentications succeeded and failed
6. The one-step decoupled authentication requested by the TPPs
7. The decoupled authentications requests are processed as one-step authentication by the ASPSPs

10. Appendix

10.1 Detailed Product Requirements

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. 

10.2 Sources of unnecessary friction

Research and conversations with consumers and TPPs have revealed a number of undesirable features of the customer journey:

1. Takes too long (e.g. longer than current online banking).
2. Too many steps (e.g. many more than their online banking).
3. Branded differently to the bank’s website (i.e. confuse the customer).
4. No clear signage to how to sign-up for online banking
5. Slow to load pages
6. Buggy pages, or random crashing
7. Use of language creating a level of fear, uncertainty, and doubt when consenting to share their data with TPPs
8. Use of too long/ complex/legalistic consent language that frustrates customer consenting to share data; frustrates customers, especially those using mobile devices
9. Asking for the same information twice
10. Asking for superfluous information, e.g. asking for a PIN when not needed
11. Opening a new browser window
12. Unnecessary interstitial pages or distractions around login controls (e.g. for advertising for other products or messaging around features)