Dashboards

PSU Notifications

This version is:

This is the latest version Published 10 months ago 31 May 2023

Independent research by Ipsos MORI showed a strong desire from real customers for intelligent notifications from TPPs and ASPSPs. Here we make recommendations for the implementation of effective notifications.

Other pages in this section

Overview

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.

Educating customers about the existence of their Dashboard / TPP and ASPSP

Figure 1: Example notification to educate customers about their Dashboard

Main content image

One of the areas of concern regarding Dashboards is limited awareness of them amongst PSUs. Based on research, we emphasise 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.

Informing customers about a successful connection / ASPSP

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

Main content image

Reminding customers about upcoming 90-days expiration or already passed / TPP

Figure 3: Example reminder from TPP about need to refresh

At the very least, TPPs must display on the Consent Dashboard when a connection has gone past 90 days but still has a valid consent and need to be reconfirmed by the PSU.

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.

If performed as an app notification it can also be used as a starting point for the reconfirmation of the consent journey as shown in Customer Alert.

Figure 4: Example notification to start a reconfirmation of consent journey

Main content image

Deletion of already obtained data / TPP

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 5: Example information about the deletion of data

Opt-out / TPP and ASPSP

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 6: Example to opt-out of any notifications relating to Dashboards

Synchronisation between Consent and Access Dashboards

It is important that PSUs are not presented with contrasting information on their Consent and Access Dashboards when it comes to the status of the connection.

Due to the regulatory changes in the UK RTS, the ASPSPs does not need to authenticate the PSU every 90 days as the AISP will reconfirm consent every 90 days with the PSU instead. Since there is no requirement on the AISP to inform the ASPSP when they have reconfirmed consent with the PSU, it may be challenging for the ASPSP to show the PSU whether consent is active or not on their Access Dashboard.

We recommend that the ASPSP provides information on when data was last shared with the AISP (e.g. shown as ‘data last shared’ – date & time, today, yesterday, 7 days ago or 24 hrs ago, etc.) as this gives the greatest clarity to the PSU.

The ASPSP must ensure any messaging provided to the PSU is clear and consistent and presented in a manner that does not cause confusion.

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 access dashboard and the TPP consent 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.

A – Real Time / Push Notifications

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 7: Real-time notifications


 

CX and other processing requirements

1

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.

2

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 OBL technical specifications.

3

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):

  • has been suspended by ASPSP due to changes in the account access resource for any valid reason (e.g. CASS by PSU, joint holder cancelling access, account closed, etc.) and could provide the reason code, if appropriate.

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.

4

Notification to PSU by TPP

  • Upon receipt of the notification by the ASPSP, the TPP should notify the PSU, if required, that access to their ASPSP account(s) is no longer possible. TPPs should present the PSU with the implications of the access revocation in case there are ‘unintended’ consequences’. However, unintended consequences may not be applicable in many cases.
  • PSUs could then take their preferred actions such as continuing to use the service or stop. If the former, they will be required to authenticate again with their ASPSPs in order to provide access to the TPPs. If the latter, PSUs may also want to remove their consent with the TPPs.

B – Aggregated ‘Polling’ / Pull Notification

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 8: Aggregated polling notifications


CX and other processing requirements

1

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.

2

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.

3

Aggregated ‘Polling’ / Pull Notification of ASPSP by TPP

  • Similar to basic polling, aggregated Polling is about the provision of notification of revocations from ASPSPs to TPPs, upon TPP request, enabling TPPs to update their records and contact the PSUs, if required, at the point in time of the request. However, the key difference is that rather than focusing on a specific access resource’s status (via a GET request on that specific resource), aggregated polling allows a TPP to poll for the outstanding or awaiting events in the ASPSP’s events repository related to multiple access consents from multiple PSUs.
  • ASPSPs should provide to the polling TPP all the access resource status and other information stored in the repository for that specific TPP, upon TPP request.

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.OBL.Consent-Authorization-Revoked), ASPSPs should be able to notify the TPPs for the below 2 events:

  1. UK.OBL.Resource-Update – An event that indicates a resource has been updated.
  2. UK.OBL.Account-Access-Consent-Linked-Account-Update – An event that indicates an account linked to consent has move-in/out of scope of the consent.

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.

4

Notification to multiple PSUs by TPP

  • Upon receipt of the aggregated polling information by the ASPSP, the TPP should notify all the PSUs, when required, that their access to their ASPSP account(s) is no longer possible. TPPs should present to all PSUs the implications of the access revocation in case there are ‘unintended’ consequences’. However, unintended consequences may not be applicable in many cases.
  • PSUs could then take their preferred actions such as continuing to use the service or stop. If the former, they will be required to authenticate again with their ASPSPs in order to provide access to the TPPs. If the latter, PSUs may also want to remove their consent with the TPPs.

C – Real Time Notification from TPP to ASPSP on the cancellation of consent

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 no further

To regain access, the TPP must obtain explicit consent from the PSU.

Figure 9: Real-Time notifications (TPP to ASPSP)


 

CX and other processing requirements

1

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. 

2

Real Time Pull Notification from TPP to ASPSP

The TPP must notify the ASPSP in real-time (i.e. immediately) by calling DELETE API.

9c

3

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.

10e

D – Basic ‘Polling’ / Pull Notification of ASPSP from TPP

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 |


CX and other processing requirements

1

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.

2

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

Additional Information

Definitions

In the context of this document, the following definitions apply:

  1. Pull notification (also referred to as polling) is where the initial request for data originates from the client and there is a response from the server.
  2. Push notification is where the server notifies the client when there is an update in real-time.
  3. ’Real-time’ notification of the revocation is a system that triggers a message from ASPSP to TPP, or vice versa, immediately after the PSU revokes consent or access at the respective Dashboard.
  4. ’Polling’ is where the TPP calls the relevant ASPSP API end-point to determine whether their access to the PSU’s account(s) at a specific ASPSP is still valid.

The rationale for real-time notification of revocation

‘Real-time’ notification enables the best conceivable customer experience:

  1. It enables TPPs to immediately provide PSUs with information about the consequences of access revocation, ensuring that action can be taken before a service “fails”, if necessary.
  2. It reduces the chance of a PSU receiving confusing messaging (e.g., reminders or marketing) after revocation of access but before the TPP is aware of it.
  3. It “future proofs” the system against potential use cases or business models that are extremely time-sensitive.
  4. It protects the broader system from artificially inflated usage due to repeat “polling” simply for the sake of checking access is available.

However, enabling only ‘real-time’ revocation presents certain challenges as outlined below:

  1. ’Real-time’ systems require a potentially significant build and maintenance resources that may not be required for many use cases where ‘polling’ might be more than adequate. In these cases, forcing the use of ‘real time’ revocation may reduce the active use of the system.
  2. There is no ability to mandate that TPPs implement specific infrastructure to receive “real-time” messages, nor to set or measure performance SLAs of them.
  3. Even where ‘real time’ is the optimal solution, the ability to fall back on ‘polling’ adds to the robustness and availability of the service offered, especially for TPPs.
  4. ’Polling’ is a significantly simpler mechanism and one that is already enabled and supported by the Standard.

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.

What the research says

 

Click for customer research