Introduction

At IESG on 21 March 2019, a question was raised about 'resilience challenges with PIS' use cases and 'how this could be measured'. The Implementation Trustee set an action for TDA to address the issue of resilience and report back to IESG. In parallel, TDA had already been looking at a number of other issues which were causing loss of access for TPPs.

There were also a number of other related issues being raised at the same time in various forums (including the TDA, API Forum, Testing Working Group and the EBA Working Group) relating to overall ecosystem resilience, including dependencies on the directory, lack of consistent approach to implementation, drop off rates during authentication and overall lack of functionality. Therefore, when TDA members were asked to comment on resilience, a number of these other issues were raised as being equally, if not more, important for certain use cases. TDA members have thus contributed to create a long list of these issues.

Ecosystem resilience

While the overall ecosystem has a dependency on the OBIE Directory, the impact is low if this is not available for periods of time, as ASPSPs must not block access to authorised TPPs based solely on Directory outages and should cache (locally in their systems) any critical directory services, especially if they chose to rely on the data from these to be highly available and/or validated for every API call.

When considering the availability and performance of an ASPSP's dedicated interface, there is a clear expectation to ensure the provision of functional KPIs that are matched with the best KPIs across the direct customer interfaces. If this is not the case, this could impact a TPPs ability to access the PSU's payment account, resulting in a disruption of payment services being provided to the PSU. Even if the ASPSP is meeting its regulatory obligations consideration should be given to the needs to a well-functioning ecosystem and the needs of the other participants who will be impacted by poorly performing APIs regardless of regulatory compliance.

Issues

This list of issues is not in itself designed to create additional regulatory requirements, but rather sets out a number mitigating actions for each which are either labelled as a must (typically because there is a corresponding regulatory requirement which has been referenced below) or a should (where this is a recommendation from OBIE). Most, if not all, of these issues exist in other EU markets; however the scope is the UK ecosystem at this time.

There are also a number of risks which are not covered here. Perhaps the biggest of these is the lack of availability of eIDAS certificates, and the lack of a consistent approach to how ASPSPs will accept and validate these. OBIE is currently conducting research on this topic to understand this risk and whether this is potentially an issue to be added to this list.

key	impact categories	summary	description	rag

Loading...

Refresh

Agreed actions

The UK ecosystem is still young, especially regarding the introduction and take-up of PISP services, therefore these issues should be subject to regular review. The following actions were agreed by the Implementation Trustee at IESG on 25 July 2019:

These issues are to be made public on the OBIE Developer Zone. All of these issues are well known, widely reported, and complete transparency is the best way to encourage positive remedial actions.
Actions and status will be tracked as a standing agenda item at TDA, and only escalated to IESG where relevant.
All participants should continue to report specific issues (e.g. relating to a specific TPP-ASPSP integration) to OBIE via a service desk ticket.

Regulatory references

(1) RTS -SCA

Article 32(2): "Account servicing payment service providers that have put in place a dedicated interface shall define transparent key performance indicators and service level targets, at least as stringent as those set for the interface used by their payment service users both in terms of availability and of data provided in accordance with Article 36. Those interfaces, indicators and targets shall be monitored by the competent authorities and stress-tested."
Article 32(3): Account servicing payment service providers that have put in place a dedicated interface shall ensure that this interface does not create obstacles to the provision of payment initiation and account information services. Such obstacles, may include, among others, preventing the use by payment service providers referred to in Article 30(1) of the credentials issued by account servicing payment service providers to their customers, imposing redirection to the account servicing payment service provider's authentication or other functions, requiring additional authorisations and registrations in addition to those provided for in Articles 11, 14 and 15 of Directive (EU) 2015/2366, or requiring additional checks of the consent given by payment service users to providers of payment initiation and account information services.
Article 33(5): For this purpose, account servicing payment service providers shall ensure that the payment service providers referred to in Article 30(1) can be identified and can rely on the authentication procedures provided by the account servicing payment service provider to the payment service user. Where the payment service providers referred to in Article 30(1) make use of the interface referred to in paragraph 4 they shall:

(2) EBA Guidelines on the exemption from Contigency Mechansim

Guideline 2: Service level, availability and performance
2.1. The ASPSP should define key performance indicators (KPIs) and service level targets, including
for problem resolution, out of hours support, monitoring, contingency plans and maintenance
for its dedicated interface, that are at least as stringent as those for the interface(s) made
available to its own payment service users (PSUs) for directly accessing their payment accounts online.

(3) EBA Guidelines on the exemption from Contigency Mechansim - Commentary

Ref 1 "...The EBA is of the view that the dedicated interface should not be compared with the ‘equivalent’ customer interface, given that the data and availability of the dedicated interface should be the same regardless of the channel used by the PSU for accessing the services of the AISP or the PISP. Instead, the EBA believes that, in accordance with Article 32(2) of the RTS, if the ASPSP offers more than one customer interface and has different KPIs and service level targets for the said customer interfaces, the KPIs and service level targets for the dedicated interface should match the best of the KPIs and service level targets across all the interfaces made available by the ASPSP to its PSUs for directly accessing their payment accounts online..."

(4) FCA Approach Document

17.33 For AIS,we expect ASPSPs to make the same information available to a customer via an AISP as would be available to the customer if they accessed their account online directly with the ASPSP...To give some examples,we would expect the following sorts of information

information relating to the account, including the name(s) of the account holder(s) and the account number;

Browser not supported