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, and all alternative options have been explored, TPPs may 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).

Under the Payment Services Regulations 2017 (PSRs), only a TPP (on behalf of a PSU) is allowed to cancel consents. All ASPSPs are able to do is limit access (i.e. adjust the access token to prevent access). The PSRs 71(7) state that that can only be done in very specific situations, namely if there is a risk of unauthorised or fraudulent access to a payment account. ASPSPs must communicate to customers that they are going to deny access to a TPP and must also inform the FCA immediately.

ASPSPs need to ensure they take into account their regulatory obligations under the Payment Services Regulations. For example, Regulations 71(7) and 71(8) on denial of access to a payment account by ASPSPs to AISPs or PISPs.

Additionally, EBA Q and A 2018/4309 confirms that ASPSPs cannot revoke consents and are only entitled to deny an AISP or PISP access to a payment account on its own initiative for justified and duly evidenced reasons relating to unauthorised or fraudulent access to the payment account by that specific PISP or AISP.

Therefore, when making infrastructure, configuration or software changes, ASPSPs should endeavour to minimise any impact on TPPs and their PSUs.

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 Open Banking Ltd (OBL) 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.