Proposition P3 - Efficacy of consumer authentication step

1. Version control







OBIE API Delivery Team

Draft for information only



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. 


OBIE API Delivery Team

Final version for approval at IESG on 

V1.1 OBIE API Delivery TeamUpdate following IESG meeting

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

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 apps1
  2. 72% of the UK adult population will bank via a phone app by 20232 .
  3. 93% customers transacting on mobile prefer biometrics to passwords and 92% banks worldwide want to adopt it. 3
  4. Biometric verification can reduce check-out time by 85%, resulting in an estimated 70% drop in cart abandonment 3

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

Source:  BBA report, 2 CACI report3Mastercard and University of Oxford Collaborate on New Research Initiative, Chris Skinner blog

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 1 with almost 29% abandoning because the process is too long 2
  • 52% of all merchants surveyed believe that friction in the checkout is the main reason for consumers abandoning their shopping cart 3
  • Adding one field in checkout process had cost Expedia $12m 4 due to drop-offs

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

  • 45 % of companies surveyed are working towards this 5  with 56% customers in favour of one-click type purchasing 6 

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

Source: Data from BarillianceKlarna and Ovum research, 4 Zdnet article5 University of Reading research , 6 Streamline research Worldpay 2013 

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


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

  1. At checkout the TPP uses account details provided by the PSU or stored by the PSU with the TPP to initiate the payment
  2. A redirection invokes the ASPSP app on the same device where the PSU simply authenticates with their ASPSP 
  3. Payment is successful and PSU is redirected straight back to the TPP app on the same device
  4. 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 required 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. 




UC1: low friction in AISP with no account selection at ASPSP

As a customer using a credit card comparison tool which has requested only my credit card details from my ASPSP

I would like to grant this access by being able to simply authenticate with my ASPSP with whom I have a single credit card

UC2: low friction in AISP with no consent replayed by the ASPSP

As a mobile ASPSP customer using a personal finance manager tool on the same mobile device

I would like to grant access to the data requested by the tool quickly and seamlessly by simply authenticating with my ASPSP app and selecting the accounts which I want to share 



low friction while refreshing AISP consent

As a mobile ASPSP customer using a personal finance manager tool on the same mobile device

I would like to refresh the tool's expired access to the data from my accounts 

by a simple biometric authentication with my ASPSP app


UC4: E-commerce 

Providing Supplementary Information when overdrawn 

As a mobile ASPSP customer usually making purchases using a  biometric authentication with my ASPSP app

I would still want my ASPSP to request a confirmation if any of the purchases could cause my account to be overdrawn.


UC5: P2P payments using a proxy

Providing Supplementary Information for confirmation of payee feature offered by ASPSP where rules apply to individual PSU, like number of lookups

Confirmation of payee  details provided by ASPSP 

As a mobile ASPSP customer using a TPP mobile P2P app  to pay someone using their mobile number  

I would like to initiate the payments by seamlessly authenticating with my ASPSP app  

but would want to proceed with the payment only after my ASPSP confirms the payee name 


UC6: International payments

Providing Supplementary Information for fees and charges

As a mobile ASPSP customer using an international money transfer app on my mobile

I would like to seamlessly authenticate with my ASPSP app to make the payment 

but would want to proceed with the payment only after I have reviewed the fees, charges and conversion rates offered by my ASPSP. 


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 Constraints

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





Regulatory AlignmentImplementation

The OBIE's Solution(s) must allow the ASPSP to publish the following information on the redirection authentication procedure supported by the ASPSP

  1. Support for App-to-App based redirection
  2. Methods of SCA supported



CMA Order

P3/P4 Evaluation Letter Action P3-A6, P3-A7, P3-A8, P3-A9 


The OBIE's Solution(s) must allow ASPSPs to be able to

redirect the PSU from a TPP app/website to the ASPSP app on the same device without requiring to the PSU to provide the TPP with any details (customer id/username) other than which bank they want to authenticate with.

Note: It is assumed this applies to users who have installed and registered the banking mobile app on their device.


CMA Order and EBA Opinion Paper

P3/P4 Evaluation Letter Action P3-A6, P3-A7, P3-A8

Conditional (mandatory if the ASPSP provides a mobile app and the PSU has installed and registered the app on their device).


The OBIE's Solution(s) must allow TPPs to launch an authentication on the ASPSP application using App-to-App based redirection such that

the ASPSP app is invoked by the TPP app/website with all the necessary information needed to navigate the PSU directly to

the appropriate functionality within the ASPSP app without adding unnecessary navigation steps in the process.

(See 10.2 Sources of unnecessary friction)


CMA Order and EBA Opinion Paper

P3/P4 Evaluation Letter Action P3-A6, P3-A7, P3-A8


Conditional (mandatory if the ASPSP provides a mobile app and the PSU has installed and registered the app on their device).


The OBIE's Solution(s) must allow ASPSPs to enable the PSUs

who do not have the ASPSP app to complete the authentication through a web-based redirection approach  

which should not involve unnecessary steps than the authentication steps required by the PSU when accessing the ASPSP web-channel directly

(See 10.2 Sources of unnecessary friction)


CMA Order and EBA Opinion Paper

P3/P4 Evaluation Letter Action P3-A5, P3-A10


The OBIE's Solution(s) must allow

a PISP to transmit to the ASPSP the PSU consent which contains all the information about the payment order (including payee , amount and debtor account details) so that

  • the ASPSP can display the amount and the payee during the authentication step 
  • the payment order can be executed by the ASPSP once the PSU authenticates with the ASPSP* and no further confirmation/information step(s) are introduced in the the ASPSP flow (except where required pursuant to Requirement 6).

CMA Order

P3/P4 Evaluation Letter Action P3-A5, P3-A9


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

CMA Order

P3/P4 Evaluation Letter Action P3-A5, P3-A9


The OBIE's solution must allow ASPSPs to setup each brand/segment separately if the PSU can currently authenticate with the brand/segment directly so that, while using an AISP/PISP, the PSU is redirected (whether to the ASPSP's mobile app or web to authenticate) to the appropriate brand/segment and does not have to make further selection of brand/segment after redirection.


CMA Order and EBA Opinion Paper

P3/P4 Evaluation Letter Action P3-A5, P3-A7

8The OBIE's Solution(s) must allow ASPSPs to provide MI on metrics and adoption as per section 9 above.MRegulatoryEBA draft Guidelines & RTSMandatory 
9OBIE solutions must support the identification of the TPP channel (app or web) initiating the authorisation requests to the ASPSPsMRegulatoryEBA draft Guidelines & RTSMandatory

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)