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 APIs, 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 record.
- 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:
| Ref | Scenario | TPP Interface | ASPSP Interface | Notes | Impact for PSU |
|---|---|---|---|---|---|
| 1 | Same Device (B<->B) | Web/Mobile Browser | Web/Mobile Browser | This pattern should be supported out of the box by all TPPs and ASPSPs using a standard web URI. | None. |
| 2 | Same Device (A<->B) | Mobile App | Mobile Browser | 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. | None (in competitive space for TPPs to implement deep links). |
| 3 | Same Device (B<->A) | Mobile Browser | Mobile App | 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. | None (as long the ASPSP implements deep links). |
| 4 | Same Device (A<->A) | Mobile App | Mobile App | 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. | None (in competitive space for TPPs to implement deep links and will require ASPSPs to do so too). |
| 5 | Cross Device | Desktop Browser | Mobile App | 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). |
| 6 | Cross Device | Mobile App | Desktop Browser | This is not a realistic scenario, since one would not expect a PSU to 'jump' from a TPP app on their phone to authenticate with their bank on a desktop web browser. In reality, this scenario will be met by either 2 or 4 above. | None as n/a. |
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
The requirement is to create a seamless journey for the PSU which bypasses the built in browser (e.g. Safari) on their mobile device. This can be done 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.
For the initial redirect to the ASPSP app, there are two things the ASPSP's developers would need to do: a) configure the redirect URL on their web server b) configure their mobile app to accept the redirects. For the redirect back to the TPP, this is entirely in the competitive space for the TPP, as they may wish to redirect back to a 4th party or merchant.
The method for deep links is covered here for iOS and Android.
- https://developer.apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html
- 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.
|  |
| 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.
|  |  |
| Monzo App | Monzo App |
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 linking.