P3 • Efficacy of consumer authentication step

• 1. Version Control
• 2. Roadmap Definition
• 3. Market analysis
  • 3.1 App-to-App based redirection 
  • 3.2 Adapting ASPSP journeys to reduce unnecessary steps
• 4. Use cases
  • 4.1 App-to-App redirection
  • 4.2 Removing unnecessary friction in redirect flows
    • 4.2.1 AISP consent setup – removes  authorisation step in ASPSP domain, which displayed mandatory cluster information
    • 4.2.2 Refreshing AISP access after 90 days 
    • 4.2.3 Removing unnecessary step in payments
    • 4.2.4 Providing supplementary information in payment journeys 
  • 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. 

An Evaluation (P3) assessed whether current customer authentication user journeys contain unnecessary steps, thereby presenting a barrier to adoption by TPPs and PSUs. Additionally, the Evaluation considered whether the authentication journeys met the requirements of the PSRs. It found examples of unnecessary step across all journeys, and presented a number of recommendations:

• Recommendation 1: Improve existing Redirection journeys
• Recommendation 2: Journeys need to be tailored for different customer situations
• Recommendation 3: Require App-to-App Redirection in mobile app-originated journeys
• Recommendation 4: Develop a 2-step consent model in addition to a 3-step consent model
• Recommendation 5: Develop Customer Experience Guidelines
• Recommendation 6: Requirement for ongoing monitoring of the implementations

This paper addresses recommendations 2, 3, 4, and 5 above. Please refer to the P3/P4 Evaluation Letter from the Trustee dated 10 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.

Specifically, regarding recommendation 3, the Trustee has confirmed that App-to-App redirection is a core action and consequently special dispensation was granted at IESG (27/6/18) to progress App-to-App redirection 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 OBIE definition of App-to-App is:

‘App-to-App’ redirection allows the TPP to redirect a PSU from the TPP application (in a mobile web browser or mobile app) to the ASPSP’s mobile app, installed on the PSU’s device, where the TPP is able to transmit details of the request along with PSU preferences (e.g. product type, one-step authentication) and deep link the PSU into the ASPSP app login screen or function. The PSU is then authenticated through their app using the same credentials/methods as normally used when the PSU directly accesses their account using the app (typically biometric). This must not involve any additional steps (such as being redirected first to a web page to select which ASPSP app to use) and must not require the PSU to provide any PSU identifier or other credentials to the ASPSP if their current ASPSP app does not require this. Where the PSU does not have the ASPSP’s mobile app, they should experience a redirection flow which should not involve additional steps than would be the case when the PSU authenticates with the ASPSP directly (e.g. be redirected to the ASPSP’s mobile website).

This definition is consistent with the EBA Opinion, RTS, Art 30(2) and PSD2 97(5) which states that all methods/procedures of SCA provided to the PSU need to be supported when a TPP is used.

The Customer Experience Guidelines (recommendation 5) will cover App-to-App redirection (recommendation 3), journeys tailored for different customer situations (recommendation 2), and for a 2-step consent model in addition to a 3-step consent model (recommendation 4) for all redirection flows.

This paper defines the overall the proposition for technical specifications, Customer Experience Guidelines, and requirements for management information (MI) reporting (all of which are Standard Implementation Requirements), 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

3.1 App-to-App based redirection

Customers are increasingly using mobile apps for banking, payments and e-commerce and prefer biometrics for authentication as suggested by the numbers below:

1. There has been a 354% increase in current account channel interactions from 2012-17 for apps^[1]BBA report
2. 72% of the UK adult population will bank via a phone app by 2023^[2]Caci Report.
3. 93% customers transacting on mobile prefer biometrics to passwords and 92% banks worldwide want to adopt it^[3]Mastercard and University of Oxford Collaborate on New Research Initiative.
4. Biometric verification can reduce check-out time by 85%, resulting in an estimated 70% drop in cart abandonment ^[4]Mastercard and University of Oxford Collaborate on New Research Initiative

TPPs have made clear during the evaluation process that a seamless and non-obstructive authentication process would be critical for the adoption of Open Banking. This is evidenced by the TPP views that the current authentication methods are not seen as “seamless and non-obstructive^[5]Chris Skinner blog. And, to ensure adoption by PSUs and TPPs, it is essential that the PSU should be able to use their ASPSP app-based authentication, which is typically biometric when using a TPP.

This can be achieved using App-to-App redirection when the PSU is consuming the TPP services on the same device where a biometric authentication can make the experience seamless and irrespective of whether the PSU has used that TPP before. 

When the PSU consumes TPP services on a device other than the one that has the ASPSP app, a decoupled authentication approach offers the best experience (see Proposition P4).

3.2 Adapting ASPSP journeys to reduce unnecessary steps

Sources of friction

Feedback from TPPs and consumers have highlighted a number of sources of friction which are problematic. These are summarised in 10.2 below.

E-commerce payments provide a useful guide as to how PSU respond to friction in a digital experience. 

• 86% of all global shoppers on mobile abandoned their carts

• 52% of all merchants surveyed believe that friction in the checkout is the main reason for consumers abandoning their shopping cart 

There is an increasing trend towards the one-step payments revolutionised by Amazon and adopted by iTunes, Relay, Facebook, Twitter, Snapchat, Instagram, Pinterest. 

• 45 % of companies surveyed are working towards this

Providing supplementary information for consumer

Research conducted by OBIE has shown merit in the ASPSP displaying the details of the completed payment order due to factors like the need for positive friction, standardisation of experience and the needs of the vulnerable in society.

Taking into consideration the market and customer preference for one-step payments as well as the preference of many customers for positive friction, OBIE have taken a balanced view on reducing friction. The OBIE solution gives the control to the customers to choose the level of friction as illustrated in the proposed solutions in sec 4.2. whilst also giving the flexibility to the ASPSPs, in certain scenarios, to be able to display the information which is necessary for a better PSU outcome.(Sec 10.2 requirement 8).

4. Use cases

The OBIE standard will support App-to-App redirection, as well as guidelines which remove unnecessary friction, to thereby enable a wide number of customer use cases.

4.1 App-to-App redirection

Note: The illustration below depicts an App-to-App redirection using biometric authentication. Other non-biometric examples of App-to-App based redirection (PIN, credentials) will be covered in detail in the customer experience guidelines.

1. PSU selects ASPSP at checkout within the TPP app without providing their payment account details. 
2. A redirection invokes the ASPSP app on the same device where the PSU authenticates with the ASPSP app
3. PSU is taken straight to the screen (deep-linked) where, if the PSU has multiple accounts, they can select an account and confirm this preferred account for making the payment on the same screen.
4. PSU is redirected straight back to the TPP app on the same device

Note: 

PSUs who have the ASPSP mobile app installed on the same device where the PSU is consuming the TPP app/mobile site will have their ASPSP mobile app invoked, and those who don’t will be re-directed to the (mobile) website to authenticate.

The PSU must not be required to enter any customer identifier (customer ID etc) irrespective of whether the PSU is using the TPP for a one-off transaction or has an account with the TPP. 

This applies to both PIS and AIS (see 4.2.1) flows.

4.2 Removing unnecessary friction in redirect flows

4.2.1 AISP consent setup – removes authorisation step in ASPSP domain, which displayed mandatory cluster information

Rather than classifying journeys for 2-step and 3-step consent model which are applicable only to PIS service, this paper collectively addresses the main objective of recommendations 2,4 and 5 of the evaluation which is to look for opportunities to reduce friction in both AIS and PIS journeys where appropriate apart from the authentication step. 

This section refers to specific solutions on how this would be achieved in practice-based for various scenarios for both AIS and PIS. 

The solutions proposed depict App-to-App redirection for the authentication step. However, all the reduced steps in ASPSP journey other than the authentication step apply to web-based redirection as well.

The customer experience guidelines will cover further variations of each of these solutions in detail.

1. PSU consents to the TPP for the AISP access within the app
2. A redirection invokes the ASPSP app on the same device where the PSU authenticates with the ASPSP app
3. PSU is taken straight to the account selection screen (deep-linked) where, if the PSU has multiple accounts they can select an account. The PSU is not displayed all the clusters as a mandatory step on the same screen, however, a link to the details of the clusters must be provided so that the PSU can choose to view more details
4. PSU is redirected straight back to the TPP app on the same device

4.2.2 Refreshing AISP access after 90 days

1. PSU is within the TPP app where  the AISP access is about to expire
2. TPP requests the PSU to refresh this access
3. A redirection invokes the ASPSP app on the same device where the PSU simply authenticates with their ASPSP
4. The AISP access is restored and PSU is directed straight back to the TPP app on the same device

Note: The consent for the provision of the account information service and the length of this service will be agreed contractually between the AISP and PSU. This period is distinct from the requirement to authenticate the PSU at least every 90 days, when applying the RTS, Article 10 exemption. This solution enables the ASPSP when applying this exemption to re-authenticate in order to refresh the access where there is no change in the connected payment account(s) and the data clusters.

4.2.3 Removing unnecessary step in payments

Where all details of the payment order (including the PSU’s account number) are passed from the TPP to the ASPSP, once the PSU has been authenticated, irrespective of the SCA method used (e.g. biometric, PIN, credentials), the PSU must then be directed back to the TPP screen without any further steps taking place, unless the supplementary information requirements in (Sec 4.2.4) apply.

The authentication screen/ step in the domain of the ASPSP may show the amount and payee, which could assist the ASPSP to comply with any applicable dynamic linking requirements.

Note: The Customer Experience Guidelines will include examples of how this should work on mobile/desktop browsers and various mobile app biometric methods on iOS and Android.An additional step in the ASPSP journey will be required in some payment scenarios as explained below in 4.2.4.

4.2.4 Providing supplementary information in payment journeys

Additional confirmatory step in the ASPSP journey may be required after the authentication step in some scenarios where supplementary information may require for the PSU to be able to make an informed decision. 

The supplementary information may include:

• fees and charges
• interest rates
• currency conversion rates
• resolution of payee name if a proxy was used for the payee account (and/or to cater for 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)

The above example illustrates a balance transfer that could be initiated via a TPP tool. The balance transfer rates and offers are generally customised by ASPSPs at an individual PSU level, hence these can be presented by the ASPSP only after authenticating the PSU. 

Although the payer, payee details and the amount are known to the ASPSP before the PSU is authenticated, the ASPSP may need to introduce a step after authentication to display the rates, fees charges and terms etc associated with that payment. The PSU may then confirm these items in order to complete the payment initiation

4.3 Customer use cases

The following are few example use cases which can benefit through App-to-App redirection and reduced friction within both AIS and PIS journeys. 

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. 

Such obstacles may include, among others,

• Requiring additional authorisations and registrations in addition to those provided for in Articles 11, 14 and 15 of Directive 2015/2366,

• Or requiring additional checks of the consent given by payment service users to providers of payment initiation and account information services.

5.2 EBA opinion

The opinion of the EBA on the Implementation of the RTS of SCA, is stated as follows:

49. Redirection is mentioned in the RTS under Article 32(3), and its featuring in the RTS has generated some debate in the industry, with some market participants expressing the view that the reference suggested that redirection would be an obstacle to the provision of AIS and PIS. The EBA hereby clarifies that the RTS do not state that redirection per se is an obstacle to AISPs and PISPs providing services to their PSUs. Instead, the RTS state that it ‘may’ be so, if the ASPSP implements it in a manner which is restrictive or obstructive for AISPs or PISPs.

50. When determining which method(s) to use for the purpose of carrying out the authentication procedure, in line with Article 97(5) PSD2 and Article 30(2) of the RTS, all methods of SCA provided to the PSU need to be supported when an AISP or PISP is used. If they were not, this would constitute an obstacle. Therefore, which method, or combination of methods, any particular ASPSP needs to use will depend on the authentication 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)

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 EBA opinion paper, were used while developing this proposition 

• When using a TPP, the PSU should be able to use the same authentication procedures they use while accessing ASPSP channels directly 
• The manner in which an ASPSP implements redirection should not be restrictive or obstructive for TPPs.

OB standards and standard implementation guidelines should enable ASPSPs to implement the App-to-App redirection flow such that 

• a PSU who currently uses an ASPSP app-based authentication method when accessing the ASPSP directly must be able to use the same as part of the redirection flow
• a PSU who does not have an ASPSP app must experience a redirection flow which should not involve unnecessary steps that would be the case when the PSU authenticates with the ASPSP directly
• ASPSPs must adapt the authentication flows to reduce friction if no further information is either needed from the PSU or is required to be displayed for a better PSU outcome

*Note: The TPP must be able to send all the possible information for the ASPSP to be able to directly perform the request without introducing any additional confirmation or information steps.

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.
• The existing OBIE standards and security profile will support App-to-App (pending a security risk and threat workshop).

8.2 Dependencies

• For App-to-App, the PSU must have the ASPSP’s mobile app installed and registered.
• To make use of biometrics, the PSU must also have this configured in their mobile app.
• ASPSPs should setup a redirect URL (as a separate directory entry) for each brand/segment (e.g. for each different mobile app they offer) and register each app id at each URL. Users who have the mobile app installed will then have their mobile app invoked, and those who don’t will be re-directed to the (mobile) website to authenticate.
• The OBIE standards will be enhanced to include further clarification on how App-to-App should be configured, including for both iOS and Android (including flow diagrams if relevant).

8.3 Constraint

• The requirements for App-to-App are only for users and operating systems where the ASPSP supplies a mobile banking app, where the user has installed and configured the app, and where the underlying operating system supports App-to-App.

9. Measuring adoption

The following metrics will be required to measure adoption:

Volume of authentications initiated by the PSU and categorised by each of the following categories:

1. Initiating TPP channel (web, app)
2. ASPSP Authentication channel (web, app)
3. The authentications completed and abandoned by the PSU
4. For completed authentications, the authentications succeeded and failed 

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.

10.2 Sources of unnecessary friction

Research and primary interactions with consumers and TPPs has 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 on 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)