Proposition P4 – Authentication step aligned to PSD2


1. Version control

Version

Date

Authors

Comments

V0.1

 

OBIE API Delivery Team

Initial draft for internal review

V0.2

 

OBIE API Delivery Team

For industry consultation & feedback including RLWG, PMG, PAG, SWFG, DWG

V0.3 OBIE API Delivery TeamUpdate based on consultation feedback for approval at IESG
V1.0 

OBIE API Delivery Team

Final version for approval at IESG on 

2. Roadmap item 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 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:

  • 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 CACI1.

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 store2 where self-service tills worldwide grew 600% over last 10 years3
  • Of sales completed on a mobile device, smartphones account for around 18%, while tablets account for 82%4 
  • In the U.K., where smartphone e-commerce visits have eclipsed desktop visits, desktop (5.85%) still converts better than smartphones (2.83%)5
  • The number of connected devices( IoT) by 2020 around the world is estimated to be 20.4 billion 6 

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. 

Source:  1 CACI Report,  retaileconomics.co.uk, consulting group RBR, 4IMRG Capgemini m-Retail Sales Index, 5 Monetate research, 6Gartner research

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 alternative 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 a 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 a 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 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 involves 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:


Model AModel BModel CModel D
Requires PSU to authenticate on mobile ASPSP appYYYY
Best suited for TPP apps on laptops/browsersY
YY
Best suited for TPP apps on IoT/ePOS devices/customer not present
Y
Y
Does not require PSU to surrender ASPSP details to TPP
YYY
Does not require TPP to have a PSU accountYYY

Model D supports the widest possible number of use cases and offers the lowest friction. However, it is dependent on the PSU having an account with the TPP, and for the PSU to have 'bound' or 'linked' their TPP account with an identifier known to their ASPSP. This linking can be set up by the TPP using a Redirection authentication or using any one of the other Decoupled authentication flows.

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.

ID

Description

Met

UC1:  Model D

Refreshing AISP consent

As a customer using a personal finance manager tool

I would like to be notified through my ASPSP app when the tool's access to data from my accounts is about to expire

so that I can instantly refresh the access by authentication with my ASPSP app

Fully

UC2: Model C

Initiating payment using TPP generated code

As a customer making in-store purchases with retailers

I would like to complete the purchases by simply scanning a code presented at the self-service till using my ASPSP app

so that I do not have to share any of my ASPSP details with the retailer

Fully

UC3: Model B

Initiating payment using code provided by the PSU's

As a customer making small value purchases in store 

I would like to be able to complete the payment by simply scanning a one-time use code, generated through my ASPSP app, I have pre-authorised for an amount up to a maximum limit*

Note: This enables an ASPSP to manage the application of SCA and relevant exemptions in the competitive space

Fully

UC4:  Model D

Initiating payment using PSU's identity with the TPP through any TPP channel

As a customer making  purchases with my regular retailer

I would like to link my retailer loyalty card with my ASPSP customer ID

so that I can initiate future payments with the retailer (online/instore/telephony) simply using my loyalty card and instantly authorising these with my ASPSP app

Fully

UC5: Model D

Remote authorisations

As a manager in the accounts team

I want to use an accountancy package to validate an invoice received and have this paid immediately by the relevant person in my organisation

who can instantly authorise this remotely through their business banking app

Note: This is an example where the authoriser's unique customer identifier with the ASPSP is linked within the accountancy package. The accounts team can initiate this from their desktop and the authoriser can authorise this remotely. 

Fully

UC6: Model D

IoT based purchases

As a customer using smart speakers that interact through voice commands,

I would like to use my ASPSP customer ID while setting up the smart speakers for payments

so that I can initiate future purchases through simple voice commands and have these authorised instantly using my ASPSP app

Fully

UC7: Model D

Request to pay - instant authorisation

Customer not present

As a member of a local football club,

I would like to link my ASPSP customer ID with the club account

so that the club can send me payment requests for different events which I can pay instantly by authorising these using my ASPSP app

Fully

UC8: Model D

Request to pay - deferred authorisation

Customer not present

As an SME,

I would like to link my ASPSP customer ID with the government's tax service

so that I can receive notifications for tax payments on my ASPSP app which I can authorise through the  ASPSP app before the expiry period of the request

Fully

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 standard 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 Constraints

  • 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 processed as a one-step authentications 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. 

ID

Description

MoSCoW

Rationale

Regulatory alignmentImplementation
1

The OBIE's Solution(s) must allow the ASPSP to implement all four decoupled models:

  • Model A - where the PSU presents a static identifier to the TPP.
  • Model B - where the PSU presents a unique, one-time identifier to the TPP.
  • Model C - where the TPP presents a unique, one-time identifier to the PSU.
  • Model D - where the TPP presents the PSU's pre-existing unique identifier to the ASPSP.

M

Regulatory

CMA Order 

P3/P4 Evaluation Letter Action P4-A1, P3-A2

Optional
2

The OBIE's Solution(s) must allow the ASPSPs implementing Model A and B to provide the TPP with the instructions for the PSU on the customer identifier detail(s) they need to provide the TPP

for e.g. 

  • enter your 10 digit customer ID number
  • enter your 16 digit debit card number 
  • enter the login code generated from your mobile banking app
MRegulatory

CMA Order 


Evaluation Letter Action P4-A1, P4-A2

Optional
3

The OBIE's Solution(s) must allow the ASPSPs implementing Model A, B & D to receive a unique customer identifier from the TPP along with the consent requested by the TPP to the PSU. 

MRegulatory

CMA Order 

Evaluation Letter Action P4-A1, P4-A2

Optional
4

The OBIE's Solution(s) must allow ASPSPs implementing Model C to provide the TPP with a unique identifier that maps to the consent requested by the TPP to the PSU.

MRegulatory

CMA Order 

Evaluation Letter Action P4-A1, P4-A2

Optional
5

The OBIE's Solution(s) must allow ASPSPs implementing Model C to provide the TPP with the instructions for the PSU on how they need to use the identifier presented by the TPP.

e.g scan a QR code presented on the TPP screen with the ASPSP app

MRegulatory

CMA Order 

Evaluation Letter Action P4-A1, P4-A2

Optional
6

The OBIE's Solution(s) must allow

a PISP to transmit to the ASPSP implementing Model D to receive as part of the PSU consent all the information about the payment order and the PSU's preference* so that the PSU authenticates with the ASPSP app and no further information is displayed or confirmation required in the ASPSP app for execution of the payment order.

*Note: The TPP may if explicitly requested by the PSU, store account details and preference thereby enabling a one-step payment. This preference (including the account details themselves) can be transmitted to the ASPSP as part of the request.

Where static identifiers are used for the decoupled flow the additional confirmation step may be required

MRegulatory

CMA Order 

Evaluation Letter Action P4-A1, P4-A2

Optional
7

The OBIE's Solution(s) must allow ASPSPs implementing all the models to enable the PSU to complete the authentication process which should not involve unnecessary steps than the authentication steps required by the PSU when accessing the ASPSP channel directly.

(See 10.2 Sources of unnecessary friction)

MRegulatory

CMA Order 

Evaluation Letter Action P4-A1, P4-A2

Optional
8

The OBIE's Solution(s) must allow the ASPSP to provide the TPP with a unique long-lived customer identifier after the PSU has successfully been authenticated, which the TPP can use for initiating future authentication requests using Model B of decoupled approach 

Note: This applies to any authentication procedure used by the ASPSP

MRegulatory

CMA Order 

Evaluation Letter Action P4-A1, P4-A2

Optional
9

The OBIE's Solution(s) must allow ASPSPs to implement the redirection based authentication (both app-to-app and web-based) such that  even though the PISP has transmitted to the ASPSP all required information about the payment order, the ASPSP may still seek authorisation from the PSU for other relevant terms that are pursuant to the payment order, after authentication (but prior to execution).

For example, authorisation may be required because of the following:

  • fees and charges
  • interest rates
  • currency conversion rates
  • confirmation of payee
  • account to be overdrawn as a result of the payment
  • significant consumer risk identified by the ASPSP
  • information based on functionality implemented by ASPSPs in competitive space which provides a positive customer outcome(e.g. cashflow prediction engine)
MRegulatory

CMA Order 

Evaluation Letter Action P4-A1, P4-A2

Optional
10The OBIE's Solution(s) must allow ASPSPs to provide MI on metrics and adoption as per section 9 above.MRegulatoryEBA draft Guidelines, RTSOptional
11

OBIE solutions must support the identification of the PSU channels and devices (app, web, IoT device, POS etc) initiating the authorisation requests to the ASPSPs

M

RegulatoryEBA draft Guidelines, RTS Optional

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)