‘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
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.
Customers are increasingly using mobile apps for banking, payments and e-commerce and prefer biometrics for authentication as suggested by the numbers below:
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-obstructiveChris Skinner blogASPSP 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).
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).
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.
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.
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.
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.
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.
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.
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
The following are few example use cases which can benefit through App-to-App redirection and reduced friction within both AIS and PIS journeys.
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,
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.
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)
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.
The following metrics will be required to measure adoption:
Volume of authentications initiated by the PSU and categorised by each of the following categories:
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.
Research and primary interactions with consumers and TPPs has revealed a number of undesirable features of the customer journey
P2 • Two way notification of revocation Previous
P4 • Authentication step aligned to PSD2 Next