| Table of Contents | ||
|---|---|---|
|
Problem statement
There are a significant number of PSUs in the UK who only ever bank on a mobile app. These users fall into one of two categories:
- In some cases they may not know/remember their banking credentials (e.g. username and password), since these credentials will be stored in the app and they only ever authenticate via their finger print (for example).
- There are also a number who have a bank account which can ONLY be accessed via a mobile app, because the ASPSP has an 'app only' experience (e.g. with some challenger banks).
It is not clear how many users fall into each of the above categories, but it could well be several million users in the UK. And this number is likely to grow.
There is a perception that the current Read/Write API standards may not support PSUs who bank on a mobile app, and hence that these users may be discriminated against. This perception is NOT correct.
The API specifications are silent on how these PSUs should be catered for, as this is in the competitive space for TPPs and ASPSPs to implement a seamless user experience.
Scenarios
When using a service powered by Open Banking APIsAs 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).
There have been a number of technical and security challenges regarding the implementation of App-to-App. These are addressed below.
This document does not cover the standards nor implementation of de-coupled flows.
How the redirect flow works
When using a service based on the OBIE API standard for redirection, the PSU will be re-directed twice:
- From the TPP interface to the ASPSP interface (to authenticate and authorise). This redirect is defined by the ASPSP as the re-direct URL in the ASPSPs directory recordThe authorisation server URI is specified by each ASPSP in their .wellknown endpoint.
- Back from the ASPSP interface to the TPP interface (to complete any transaction with the TPP). This redirect is defined by the TPP in their software statement (using the field software_redirect_uris).
There are 6 core scenarios to consider:
...
This pattern should be supported by any TPP who has a mobile app where the user starts their journey.
The TPP should configure their URI and their mobile app to enable deep links according to the implementation notes below.
...
This pattern should be supported by any ASPSP who has PSUs who use their mobile banking app.
The ASPSP should configure their URI and their mobile app to enable deep links according to the implementation notes below.
...
This pattern should be supported by both the TPP and the ASPSP where the PSUs starts their journey on a TPP mobile app and uses their banking mobile app.
Both the TPP and the ASPSP should configure their URI and their mobile app to enable deep links according to the implementation notes below.
...
This pattern would require an 'out of band' communication from the PSUs desktop browser to their mobile device.
This would require 2 things: a) the ASPSP would need to create a web page/service which authenticates the PSU b) the ASPSP would need to configure an out of band communication to prompt the PSU to authenticate and authorise via mobile app.
...
None (as long as PSUs have web credentials with the ASPSP and the ASPSPs implement out of band comms).
...
NOTE: In the case where the TPP provides a service for a merchant or 4th party who uses a mobile app, it is entirely in the competitive space as to how the TPP manages redirections back to this merchant/4th party mobile app. The merchant/4th party should follow the implementation notes below.
Implications
OBIE do NOT believe there are any customer groups who would not be able to access Open Banking.
Many ASPSPs already implement out of band communications, e.g. as an additional authentication method via their mobile banking app when adding a new payee. These ASPSPs could use a similar method to cater for PSUs in scenario 5 above.
It is possible that some ASPSPs may not implement deep links. In this case, if their PSUs experience scenarios 3, 4 or 5, they will be prompted to authenticate via their web browser. To prevent this poor user experience, ASPSPs should implement deep links and/or out of band communications so as to be compliant with the CMA Order and not to discriminate against PSUs who only use their mobile app for banking.
Implementation of deep links
...
- specified by the TPP as part of the first redirect.
Implementation of deep links
A seamless journey for the PSU, which bypasses the built in browser (e.g. Safari) on their mobile device. This , can be done implemented for any URL, ie BOTH a) for the initial redirect which the TPP sends the PSU to on the ASPSP's servers, AND b) the redirect URL which the ASPSP sends the PSU back to after authentication/authorisation.
...
The method for deep links is covered here for iOS and Android.
- iOS: https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.htmlios/universal-links/
- Android: https://developer.android.com/training/app-links/index.html
There are many examples in use where redirects to mobile apps are supported. Two specific examples are:
Example 1
If a user installs the Medium app, and clicks on any links in an email from Medium on their mobile, they will be linked direct to the content within the Medium app.
...
...
...
Example 2
Using a Monzo app to login. The user is redirected from the Monzo app to a password reset email in their default email client app. The user is then redirected back to the login screen of the Monzo app and automatically logged in.
...
...
...
...
Recommendations
ASPSPs should also ensure that PSUs who only ever bank on via a mobile app do have a route to authenicate and authorise if they start the consent journey on a non-mobile device.
In order to provide the best possible user experience, developers from ASPSPs and TPPs should implement deep linkingIn the event that a PSU does have the app installed on their device, these methods will allow the PSU to be re-directed to a mobile web page.
Open Banking Directory integration
tbc
Security considerations
Security considerations are addressed here: https://tools.ietf.org/html/rfc8252.