P3 • Efficacy of consumer authentication step

‘App-to-App’ redirection allows the TPP to redirect a PSU from the TPP application to the ASPSP’s mobile app, 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.

Other pages in this section

1. Version Control

V0.127 Jun 2018 OBIE API Delivery TeamDraft for information only
V0.202 Jul 2018 OBIE API Delivery TeamFor industry consultation & feedback including RLWG, PMG, PAG, SWFG, DWG
V0.312 Jul 2018 OBIE API Delivery TeamUpdate based on consultation feedback for approval at IESG. 
V1.013 Jul 2018 OBIE API Delivery TeamFinal version for approval at IESG on 19 Jul 2018
V1.120 Jul 2018 OBIE API Delivery TeamUpdate following IESG meeting

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:

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. 

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

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


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.

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

    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 ASPSPAs 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 ASPSPAs 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 
    UC3:  low friction while refreshing AISP consentAs 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 lookup
    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,

    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 

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

    *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

    8.2 Dependencies

    8.3 Constraint

    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.

    IDDescriptionMoSCoWRationaleRegulatory AlignmentImplementation
    1The OBIE's Solution(s) must allow the ASPSP to publish the following information on the redirection authentication procedure supported by the ASPSP
  • Support for App-to-App based redirection
  • Methods of SCA supported
  • MRegulatoryCMA Order
    P3/P4 Evaluation Letter Action P3-A6, P3-A7, P3-A8, P3-A9 
    2The 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.
    MRegulatoryCMA 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).
    3The 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)
    MRegulatoryCMA 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).
    4The 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)
    MRegulatoryCMA Order and EBA Opinion Paper
    P3/P4 Evaluation Letter Action P3-A5, P3-A10
    5The 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).
    MRegulatoryCMA Order
    P3/P4 Evaluation Letter Action P3-A5, P3-A9
    6The 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)
  • MRegulatoryCMA Order

    P3/P4 Evaluation Letter Action P3-A5, P3-A9
    7The 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.MRegulatoryCMA 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)


    1 BBA report
    2 Caci Report
    3, 4 Mastercard and University of Oxford Collaborate on New Research Initiative
    5 Chris Skinner blog