Customer research reinforced the trust and reassurance that ASPSPs can provide through notifications. Whether this is a one-off, for example, the first time a PSU connects their ASPSP to a TPP, or every time a new connection is made, it is up to ASPSPs to determine.
Other Journeys in ‘Dashboards’.
Independent customer research from Ipsos MORI showed a strong desire from real customers for intelligent notifications from both TPPs and ASPSPs.
We have purposefully not mandated the use of notifications as it is not possible to dictate to participants how to communicate with their customers. However, we strongly encourage all participants to test and refine the use of notifications to ensure both that:
Customer research reinforced the trust and reassurance that ASPSPs can provide through notifications. Whether this is a one-off, for example, the first time a PSU connects their ASPSP to a TPP, or every time a new connection is made, it is up to ASPSPs to determine. Of course, notifications should always be used sparingly and saliently, but we offer a variety of methods ASPSPs and TPPs can use to educate and inform PSUs about the availability of Dashboards (as per recommendations). Importantly, we also offer guidelines on allowing PSUs to turn off such notifications.
Figure 1: Example notification to educate customers about their Dashboard
One of the areas of concern regarding Dashboards is limited awareness of them amongst PSUs. Based on research, we emphasize the importance of ASPSP Access Dashboards being known, but the principles apply equally to TPPs and their Consent Dashboards. The most obvious time to do this would be either following their first successful Open Banking-enabled service connection or the first time they login after sign-up.
The information could also be more generic as part of, for example, an app update: this would mean it is less targeted but would not require ASPSPs to develop the capability to identify and contact first time users. In-app tutorials are commonplace and can be easily skipped by users who are not interested:
A simple and effective way to build confidence in the ecosystem identified through independent research would be to ensure customers know that the ASPSP is aware of the connection and the connection has been executed successfully, particularly the first time the PSU is connecting to the relevant ASPSP.
This is in addition to the confirmation screen during the authentication journey, and so the timing could be a day or so after, or the next time the PSU logs into their direct online channels. This also provides a security benefit if a PSU doesn’t recognise the connection. This could be done in a variety of ways, for example during login or on a home page feed, or through a durable medium such as SMS, email or private bank message.
Figure 2: Example notification from ASPSP confirming a successful connection
At the very least, both TPPs and ASPSPs must display on the Consent and Access Dashboard respectively when a connection has gone past 90 days but still has a valid consent and needs to be refreshed.
TPPs are already utilising these today and this can be done in a variety of ways. The most common approach seems to be an email, app notification or SMS with a link through to the Consent Dashboard.
Figure 3: Example reminder from TPP about need to refresh
If ASPSPs do choose to do inform a PSU about an upcoming expiry, it would also provide a good opportunity to educate them about the Access Dashboard specifically and/or Open Banking more generally.
Figure 4: Example email from ASPSP to remind PSU about refresh requirement
If performed as an app notification it can also be used as a starting point for the refresh journey as shown in Customer Alert.
Figure 5: Example notification to start a refresh journey
For TPPs, it is encouraged that when access is revoked, they explain to the PSU what will happen with the data obtained up to that point. This should be done once consent has been revoked and could also be done with a follow-up email.
Figure 6: Example information about the deletion of data
Figure 7: Example to opt-out of any notifications relating to Dashboards
It is important that PSUs are not presented with contrasting information on their Consent and Access Dashboards. There are a series of technical solutions in place that are designed to ensure the TPP is notified of a change made through the Access Dashboard, particularly revocation of access. The most common issue that occurs today is where a PSU revokes access at the ASPSP Dashboard and the TPP Dashboard is not updated at the same time.
These solutions can be split into “push” notifications from ASPSP to TPP, and “pull” notifications whereby the TPP “asks” the ASPSP if there have been any changes to the status of access tokens.
Functionality to enable ASPSPs to notify TPPs in real-time (i.e., immediately) when a PSU cancels their access at their ASPSP Dashboard or other account access changes have taken place.
Figure 8: Real-time notifications
PSU cancels access from the ASPSP Access Dashboard
The PSU follows the journey on TPP Access Dashboard & Revocation to cancel access to their account for a specific TPP. ASPSP should confirm to the PSU that access to the account(s) has been cancelled.
Real Time Push Notification from ASPSP to TPP
The ASPSP should notify the TPP in real-time (i.e. immediately) after the PSU cancels their access at their ASPSP Access dashboard. The implementation of the real-time mechanism is defined in the OBIE technical specifications.
Push Notification for Offline TPPs (ASPSP to TPP)
ASPSPs should also be able to use push notification mechanisms to notify TPPs whose systems are offline that PSUs cancelled their access using the ASPSPs’ access dashboards. This removes the requirement for TPPs to have systems up and running 24×7 in order to receive real-time push notifications from ASPSPs. Once the TPPs’ systems are available again, ASPSPs should push again any notifications required to the TPPs, so that TPPs can update their systems.
In addition to PSU cancellation of access, ASPSPs should be able to notify the TPPs when access to the account(s):
is no longer available due to changes in the state of the access token for any valid reason (e.g. token has expired, a token has been suspended by the ASPSP due to fraud etc.) and could provide the reason code, if appropriate.
Notification to PSU by TPP
Provision of notification of revocations from ASPSPs to TPPs, upon TPP request. It allows a TPP to request an aggregated set of access revocations and other account access events related to multiple access consents from multiple PSUs during a specific period.
TPPs should utilise aggregated polling to try and ensure the Consent Dashboard reflects revocation that occurs through the ASPSP Access Dashboard in real-time or as close to it as possible.
Figure 9: Aggregated polling notifications
Multiple PSUs revoke access from the ASPSP Access Dashboard
Multiple PSUs, during a period of time, follow the journey for TPP Access Dashboard &B Revocation to revoke access to their account for a specific TPP. For each PSU access, revocation, the ASPSP should confirm to the PSU that access to the account(s) has been revoked.
ASPSP generates access revocation events in their events repository
For all PSUs access revocations, the ASPSP should generate an access revocation event in the events Repository organised per each TPP.
In cases where the TPP has subscribed to access revocation events for aggregated polling (or push notifications), the ASPSP should generate an access revocation event in the events Repository organised per each TPP.
Aggregated ‘Polling’ / Pull Notification of ASPSP by TPP
Please note that in case of access revocation, there is no change to the underlying consent resource. However, the event type is the same for both events, i.e. consent-authorization-revoked.
In addition to PSU revocation of access (event UK.OBIE.Consent-Authorization-Revoked), ASPSPs should be able to notify the TPPs for the below 2 events:
Note: This functionality makes much more efficient usage of the ASPSPs and TPPs network bandwidth as multiple single polls, especially with no change of access status, are avoided. Moreover, it allows TPPs to receive all the required notifications without the need to implement systems with high availability (e.g. systems running 24×7) or systems based on real-time push notifications, providing full flexibility to TPPs about the timing they want to receive the notifications based on their business models.
Notification to multiple PSUs by TPP
This functionality enables the TPP to notify the ASPSP in real-time (i.e., immediately) after the PSU revokes their consent at their TPP Consent Dashboard, provided that the TPP takes immediate action upon the PSU revocation. The current Open Banking Read/Write specifications enable a TPP to use the ‘DELETE’ API endpoint and notify the ASPSP that the PSU has revoked their consent. The implementation of the ‘DELETE’ API endpoint is mandatory for ASPSPs.
Note: For TPPs, when the PSU revokes their long-lived consent at the Consent Dashboard, TPPs must not call any protected data resource which falls within the scope of the consent originally granted. The TPP must delete the underlined account access or domestic VRP access or confirmation of funds check consent resource with the ASPSP by using the ‘DELETE’ endpoint as soon as practically possible.
We note that subsequent use of the access consent could have implications under both GDPR and the PSRs. As, such, we would expect TPPs to have robust controls in place to ensure that upon cancellation of consent by the PSU that no further
To regain access, the TPP must obtain explicit consent from the PSU.
Figure 10: Real-Time notifications (TPP to ASPSP)
PSU cancels consent from the TPP Consent Dashboard
The PSU follows the journey on TPP Consent Dashboard & Revocation to cancel consent to their account for a specific ASPSP.
Real Time Pull Notification from TPP to ASPSP
The TPP must notify the ASPSP in real-time (i.e. immediately) by calling DELETE API.
The ASPSP must reflect the status as cancelled in the ASPSP access dashboard in real-time (i.e. immediately) after the TPP has called the DELETE API.
This is the provision of pull notification (polling) for TPPs to poll the status of their account access at relevant ASPSPs for one specific PSU consent arrangement and access token. This functionality enablesTPPs to update their records and to notify PSUs, if required, that their access at the ASPSP is no longer valid. The current Open Banking Read/Write specifications enable the TPP to use the ‘GET’ API endpoint to poll the ASPSP and check the status of their account access.
It should be noted that this simple mechanism of checking account access using basic polling is very inefficient in its use of network bandwidth for both TPPs and ASPSPs. Basic polling may not be scalable enough to support the growing ecosystem of open banking if the volume of account access consents grows significantly. The implementation of the ‘GET’ API endpoint is mandatory for ASPSPs.
Note: When the PSU cancels access at their ASPSP and the TPP receives the notification of the cancellation, while the consent agreed with the PSU remains valid, the notification will serve as a clear indication that the PSU has cancelled the account access. As such, the TPP should consider either a.) contacting the PSU to ask whether they wish to cancel their consent as well, or b.) removing the consent automatically and notifying the PSU. TPPs should consider the most appropriate approach based on their terms and conditions with the PSU and their service offering.
Figure 11: Basic Polling / Pull Notification
Real Time Pull Notification by TPP from ASPSP
The TPP must be able to poll the status of their account access at relevant ASPSP and notify the PSU if their access is no longer valid.
PSU must be able to see the same status “Cancelled” on both consent and access dashboard
In the context of this document, the following definitions apply:
‘Real-time’ notification enables the best conceivable customer experience:
However, enabling only ‘real-time’ revocation presents certain challenges as outlined below:
In conclusion, enabling both real-time notifications and polling ensures that the system is flexible enough to accommodate all use cases and business models, enabling participants to tailor their systems to best suit the needs of their PSUs and adding to the stability of the overall system.
CBPII Access Dashboard Previous
Customer Experience Checklist Next
What the research says Click for customer research
What the research says