Changes to an ASPSP’s infrastructure, configuration or software

At any time, an ASPSP may need to make changes to any element of their system, including implementation of a new version (as described above). This includes the adding/removing of functionality or fields within an existing version. This may or may not require downtime.

In such cases, TPPs may need to update and re-onboard their application, and then re-test it in order to continue offering services via the ASPSP. This could result in increased costs, reduced revenue, and potentially customer loss, since services that PSUs rely on may be interrupted without prior warning.

For example, if the ASPSP has implemented a new authorisation server, TPPs will need to ask their PSUs to re-authenticate with the ASPSPs. PSUs could lose service entirely if there is any delay in a TPP re-connecting to the ASPSP. PSUs may have to re-authenticate to renew long lived consent (e.g. for the TPP to continue to access the PSU’s data).

Where ASPSPs make such changes they should:

• Give TPPs a minimum of three months’ notice of any such change, unless this is an emergency situation (Article 30(4) RTS).
• Document emergency situations where changes were made and make the documentation available to their NCA.
• To facilitate this, ASPSPs should report all changes to OBIE that could require TPPs to update/edit their code, where notice of any change will be added to the central noticeboard for the ecosystem.
• Re-run all relevant conformance tools.