# TPP MI Data Reporting Requirements v3.1.11

# 1. Purpose

The purpose of this document is to provide a consolidated view of the requirements for the provision of MI Reporting Data from TPPs participating in the Open Banking Ecosystem in relation to the functionality introduced by the OBL API Specifications.

The proposed TPP MI provision is directly related to the objective of this roadmap item which is the:

  • "timely" provision of MI to the Trustee and the ecosystem", and
  • the activity of "improved MI provision and reporting"​ as per the roadmap definition. The new MI data submission requirements will allow TPPs to submit MI data sets to OBL in a timely manner, where required.

Please note that the MI Reporting from TPPs is not a direct requirement under the CMA Order or the Payment Services Regulations 2017. This MI is to be submitted to the Open Banking Limited (OBL) by TPPs voluntarily, so as to enable the OBL to measure the performance and adoption of the OBL API Services offered by ASPSPs, as experienced by the receiving organisations and/or their end-users.

It is however clearly mentioned in the roadmap item definition as "TPP-facing OB Standard to be implemented by TPPs (on a voluntary basis, supported by ICO Code if possible and if appropriate)."

The MI will be used to help OBL to:

  1. understand the success and take-up of the Open Banking service
  2. assess the performance of the API services as they are perceived from the TPPs' perspective
  3. measure the drop out rates for each group of services
  4. forecast volumes and user growth to allow capacity planning and ensure sufficient support services, and
  5. understand usage patterns for potential future product development.

Please refer to section 9 in the Appendix for the full roadmap item definition.

# 2. Not in scope of this paper

The paper does not cover the following:

  • Monitoring of fraud

These items will be addressed either at a later date and/or via a separate activity.

# 3. Adoption Management - Additional TPP perspective

In order for OBL to be able to monitor the adoption of the Open Banking services in the ecosystem and take necessary actions as appropriate, it is vital to measure the usage of the Open Banking APIs. One aspect of this is achieved by receiving detailed MI Reporting data from ASPSPs. However, in addition to receiving ASPSP MI Reporting data, OBL and the ecosystem would benefit from receiving adoption management MI from TPPs. This will provide a different perspective of increased business value and will also allow reconciliation of the ecosystem data when combined with the ASPSP MI Reporting data.

Monitoring the adoption has multiple aspects:

  • Measuring the availability of the APIs as perceived by the TPPs and their end-users. Unavailable services, especially during peak demand may seriously impact the adoption of the OBL services. (Please refer to section 8.3 about challenges of measuring this.)
  • Measuring the performance of the APIs as perceived by the TPPs and their end-users. This includes endpoint-level response times but also total end-to-end response time as experienced by the end-users.
  • Measuring the volumes of the various API calls. This allows OBL to analyse the total volumes of each of the OBL services used by each TPP (including mandatory and optional) and the growth rate of these volumes so that OBL can identify which services are being adopted by PSUs for the whole of the ecosystem. All the endpoints supported by the OBL specifications which have been used by TPPs need to be included so that all propositions that have gone live are monitored. Please note that where ASPSPs have implemented both optional and mandatory endpoints, provision of MI for optional endpoints used by TPPs is important to understand the utilisation and performance of these endpoints.
  • Measuring the efficacy of redirection (and decoupled models). Understanding the success and drop-out rates of the redirection (and decoupled models) introduced by Open Banking Standards is critical to the successful adoption of the Open Banking services in the ecosystem. These figures will highlight if further enhancements may be required to the customer journeys.
  • Measuring the PSU Adoption and the Consent Adoption of Open Banking services and the intensity of their usage is critical in order to assess the impact of the Open Banking Standards to the ecosystem as per the CMA Order.
  • Measuring other aspects of the AIS and PIS services such as overall Payment Adoption by payment type, refunds, the optional revocation notifications, the payment status across the payment processing chain, the request for the application of SCA exemptions, the AIS access to corporate accounts and finally the 90-days re-authentication enhancements.

Based on the above, OBL can apply product management methodologies and make informed decisions on the life cycle of the APIs. This may include the following:

  • apply forecasting methods to predict expected volumes and user growth in order to perform capacity planning, provide input to PAY UK for the underlying payment systems, and ensure sufficient support services are in place
  • produce enhancements on the Standards in relation to certain key propositions
  • share useful information and insight with the whole ecosystem using consolidated data dashboards
  • collect multiple sources of data to ensure data validation and consistency of all reported MI
  • use as a reference for the evaluation of the impact of the Open Banking Standards to the UK ecosystem as per the CMA Order.

# 4. The importance and value of 'Profiling the Ecosystem'

The Open Banking ecosystem is rapidly growing in both volumes of traffic and complexity.  Multiple participants are required to provide a single service to the end-user.  Under these circumstances, a view of the overall ecosystem behaviour is vital to assure the quality of service.  In addition to the rapidly growing complexity, overall traffic volumes are predicted to grow exponentially through 2021 and beyond.  The graphs below show the current volume projections (as of June 2021).

TTFB

Having information from all participants enhances the level of support and value-add services Open Banking is able to provide to participants.

Benefits for TPPs

  • Volume projections and developing call patterns allow OBL to advise participants about their own test and roll-out plans.
  • Regular and frequent reporting from TPPs and ASPSPs allows OBL to identify and analyse on potential unplanned downtime issues.  This is important because, on several occasions, when TPPs experience service interruptions, it is not always clear where the issue lies, and OBL can help identify this via providing 'live' dashboards
  • Quality of service can be monitored more effectively
  • Other potential issues can be more promptly identified, by detecting trends before actual incidents occur
  • The optional granularity of reporting permits identification of daily or weekly peaks, that could impact upon the system
  • Analysis of call patterns across participants would allow OBL to advise on participant job scheduling
  • OBL endpoint monitoring of ASPSP endpoints can be correlated with combined participant reporting to provide further visibility of overall ecosystem behaviour
  • Trend analysis performed by OBL and shared with TPPs to forecast demand and build their new business cases
  • Automated reporting via enhanced data submission mechanism makes reporting simpler and easier

# 5. High-Level requirements

The TPP MI Reporting Data high-level requirements are shown below:

  • Categories: TPP MI Reporting will be split into 2 categories:

    1. Generic (Core): MI which is required by all participant TPPs
    2. Service Specific: MI which is related specifically to the type of TPP service offered (e.g. for PISPs, AISPs, CBPIIs or even TSPs) and may be lower priority/nice to have or reported on ad-hoc basis, as and when required for analysis of specific issues. This MI is for future consideration and will not be included in the initial version of the TPP MI Specification.
  • Generic (Core) MI will include the following types of reporting data elements:

    • Performance data: This data set will include measurements of the average response times of the various API endpoints and also the end-to-end service timings as experienced by TPPs and their PSUs.
    • Volumetric data: This data set will include measurements of the volumes of API endpoints calls including successes, failures, rejections, no-authorisations etc. TPPs will be reporting which ASPSPs those endpoints are made to, so that will be able to reconcile volumes against volumes reported from the ASPSPs.
    • Auth Efficacy data (Drop-out rates): This data set will include measurements similar to those reported by ASPSPs, including authentication success and failures per initiating channel (web or mobile), additional user interaction failures etc. In general, this is one of the sources for measuring the user drop-out rates per TPP and per ASPSP.
    • PSU & Consent Adoption data: This data set will include measurements similar to the ones recently introduced to the MI for ASPSPs, further to the proposal from the OFT. It includes a new and cumulative number of PSUs per service split by Retail and SME and also the number of consents (long and short term) to measure the intensity of the service adoption.
  • Reporting Granularity:  For some of the data elements such as performance and volumetrics, OBL is looking to introduce hourly reporting granularity instead of daily (which is what is used by ASPSPs split between core and non-core business hours). This will allow OBL to produce intra-day profiling of the usage of Open Banking APIs for the different services, per TPP and per ASPSP. Obviously, if real-time reporting is introduced, this granularity may be even finer.

  • TPP/TSP/ASPSP level: OBL will be introducing granularity of both reporting TPP and TSP at the endpoint level and also at the ASPSP level.

  • Free-format field: OBL is considering adding free format text entries in the reporting fields for the opportunity of TPPs raising specific issues or providing comments in free text format. This data element will be optional.

  • Data Sharing/Consuming: OBL will be using the data internally for data analysis, insight and forecasting. Moreover, OBL will be able to share with each TPP the historical data of their own submissions. However, OBL will be consolidating and anonymising all the data if any reports based on this are to be shared with other TPPs and the wider ecosystem. OBL may request permission from the TPPs if data is to be used in a different manner.

  • Alignment to CEF Framework: OBL will also be looking to receive the TPP MI Reporting data labelled in alignment to the Consumer Evaluation Framework especially in relation to the defined outcome area and the directly related propositions.

  • Reporting Data Format/Schema: A reporting data schema will be produced as part of the TPP MI Reporting Specification to allow data reporting.

  • Use of Gateway Data Logs: Alternatively to using a data schema for all MI Reporting requirements, OBL will also be looking to provide the capability of being able to receive redacted data logs directly from the participants' gateways. This will reduce the workload of formatting the data as per the appropriate data schema before submitting to OBL, making reporting simpler and easier. This approach may not be relevant to all required data however it is able to simplify certain groups of data required in high frequency, such as performance and availability data, volumetrics etc.

  • Reporting Frequency: Reporting frequency will depend on the capabilities offered by the reporting mechanism (e.g. API vs SFTP vs other methods) and can vary between real-time and other reporting periods (e.g. monthly, fortnightly, weekly or daily) depending on the abilities of participants, the types of data to be reported (performance/availability, volumetric, authentication efficacy, PSU & Consent adoption, payment adoption etc.) and the use of the data by OBL. This will be discussed and agreed with participants.

  • Data Quality: OBL will be encoding the endpoints, the TPP/TSP/ASPSP brand lists and other appropriate data in order to ensure high quality of reported data. This is in alignment with the existing MI Reporting Specification for ASPSPs. OBL will also be looking to introduce data validation rules (within the MI Specifications and/or the reporting mechanism, where applicable), to ensure further data quality.

  • Service Specific MI will include the following types of reporting data elements:

    • PISP Only:
      • Payments Adoption data: This data set specific for PISPs, will include payment initiation related data per payment type including the number of FPS, Bacs, CHAPS, SOs, and international payments.
      • Other: Payment Status, Payment SCA Exemptions, Payment Refunds
    • AISP Only: Revocation Notifications from ASPSPs, Corporate Account Access, 90-days re-authentication

Note: Service Specific MI is for future consideration and will not be included in the initial version of the TPP MI Specification. It is mentioned here for completeness.

The CMA Order contains the following points in relation to MI reporting:

  • Schedule 1, Article 2(j), states that it is the responsibility of the Trustee to "monitor compliance by the Providers with the Order".
  • Article 14.1 states that Providers must make up to date PCA and BCA transaction data sets continuously available without charge, for read and write access in accordance with the relevant provisions of the Read/Write Data Standard.

Thus, while there is a clear regulatory requirement of the Order for the Providers to allow the Trustee to monitor their compliance, there is no requirement for the Consumers of the API Services, i.e. the TPPs. * However, receiving data from TPPs would assist the Trustee not only in the task of monitoring the compliance of the Order, but also the effectiveness of the CMA Order to the ecosystem, its competitiveness and the positive impact to the business and consumer PSUs.

In conclusion, TPP MI Reporting is voluntary for TPPs but quite important for OBL to be able to improve the services offered to the ecosystem.

# 7. Considerations

# 7.1 Constraints

  • The data elements to be reported by TPPs are constrained to the information held by TPPs or provided back to TPPs by the ASPSPs. Thus, TPPs are not able to provide the same set of MI data as provided to OBL by ASPSPs
  • Some smaller TPPs may face resource constraints in being able to provide the MI Reporting to OBL
  • Some TPPs may have considerations in relation to sharing data which may be classified as 'business sensitive'

# 7.2 Assumptions

  • Sufficient number of TPPs and/or TPP data will be provided OBL so that there is sufficient information to represent the ecosystem.
  • Sufficient number of ASPSPs and TPPs will be using the enhanced reporting mechanism and its capabilities for frequent (or near-real-time reporting) to allow OBL to provide 'live' dashboards.

# 7.3 Dependencies

OBL will have mechanisms and the operational processes in place to receive the MI Reporting from participants and to process the submitted data.

# 7.4 Reference documents

# 8. Appendix

# 8.1 Detailed Requirements

Note: For the detailed requirements of the Enhanced MI Data Submission Mechanism (ASPSPs & TPPs), please refer to A2(c)(ii) Enhanced MI Data Submission Mechanism Solution Design

The following MoSCoW classification has been used for the requirements:

  • Must - This is essential to be delivered in the TPP MI Reporting.
  • Should - This is non-essential but highly desirable to be delivered in the TPP MI Reporting.
  • Could - This will be nice to have it delivered in the TPP MI Reporting.
  • Would - This presents lower business value compared to the other types of data fields.

# 8.1.1 Generic (Core) MI

# 8.1.1.1 Overall Performance

Submission Frequency: High

The following data table is required to be submitted to OBL in a higher than normal frequency. This could be daily or several times during each day. The actual value will be agreed between OBL and participating TPPs.

TAB: 1A. Overall Performance
ID Description MoSCoW Data Usage
1 Report Date Must As Is or Consolidated
2 Report Time Should As Is or Consolidated
3 TPP Brand ID Must Anonymised or Consolidated
4 "On behalf of" / TSP Brand Name Should Anonymised or Consolidated
5 ASPSP Brand ID Must As Is or Anonymised or Consolidated
6 Retail or Business PSU Should As Is or Consolidated
7 Endpoint ID Must As Is or Consolidated
8 Total Number of API Calls Must As Is or Consolidated
9 Successful API Calls (200, 201 or 204 codes) Must As Is or Consolidated
10 Failed API Calls Business Reasons (4xx codes) Must As Is or Consolidated
11 Failed API Calls Technical Reasons (5xx codes) Must As Is or Consolidated
12 Failed API Calls No response Must As Is or Consolidated
13 API Calls generating Rejection Status Should As Is or Consolidated
14 Total TTLB Response Time (Time to Last Byte) Must As Is or Consolidated
15 Total TTFB Response Time (Time to First Byte) Should As Is or Consolidated
16 Total Response Payload Size Could As Is or Consolidated
17 Minimum TTLB API response time - (Best case) Should As Is, or Anonymised or Consolidated
18 Maximum TTLB API response time - (Worse case) Should As Is, or Anonymised or Consolidated
19 Perceived API Unavailability Must As Is, or Anonymised or Consolidated
(Please refer to section 8.2 about challenges of measuring this)
20 Version Should As Is or Consolidated
21 CEF Outcome Area Should As Is or Consolidated

# 8.1.1.2 End-to-End Response Times

Submission Frequency: Normal

The following data table is required to be submitted to OBL at normal frequency. This is currently considered to be on a monthly basis. The actual value will be agreed between OBL and participating TPPs.

TAB: 1B. End-to-End Response Times

ID Description MoSCoW Data Usage
1 Report Date Must As Is or Consolidated
2 Report Time Should As Is or Consolidated
3 TPP Brand ID Must Anonymised or Consolidated
4 "On behalf of" / TSP Brand Name Should Anonymised or Consolidated
5 ASPSP Brand ID Must As Is or Anonymised or Consolidated
6 Retail or Business PSU Should As Is or Consolidated
7 API Service Must As Is or Consolidated
8 Total Number of Requests Must As Is or Consolidated
9 Time Period (Please refer to section 9.2) Must As Is or Consolidated
10 Total Time Period Duration Must As Is or Consolidated
11 Free Format Text Could As Is or Anonymised
12 Version Should As Is or Consolidated
13 CEF Outcome Area Should As Is or Consolidated

# 8.1.1.3 Auth Efficacy

Submission Frequency: Normal

The following data table is required to be submitted to OBL at normal frequency. This is currently considered to be on a monthly basis. The actual value will be agreed between OBL and participating TPPs.

TAB: 2. Auth Efficacy

ID Description MoSCoW Data Usage
1 Report Month Must As Is or Consolidated
2 TPP Brand ID Must Anonymised or Consolidated
3 "On behalf of" / TSP Brand Name Should Anonymised or Consolidated
4 ASPSP Brand ID Must As Is or Anonymised or Consolidated
5 API Type Must As Is or Consolidated
6 API Request TPP Channel Should As Is or Consolidated
7 ASPSP Authentication Channel Should As Is or Consolidated
8 Consents requiring Authentication Must As Is or Consolidated
9 Consents abandoned by PSU before redirection Must As Is or Consolidated
10 Consents abandoned by TPP before redirection Must As Is or Consolidated
11 Authentications Succeeded Must As Is or Consolidated
12 Authentications Failed Must As Is or Consolidated
13 Average journey time Must As Is or Consolidated
14 Version Should As Is or Consolidated
15 CEF Outcome Area Should As Is or Consolidated

Submission Frequency: Normal

The following data table is required to be submitted to OBL at normal frequency. This is currently considered to be on a monthly (or sooner e.g. weekly) basis. The actual value will be agreed between OBL and participating TPPs.

TAB: 3. PSU and Consent Adoption

ID Description MoSCoW Data Usage
1 Report Month Must As Is or Consolidated
2 TPP Brand ID Must Anonymised or Consolidated
3 "On behalf of" / TSP Brand Name Should Anonymised or Consolidated
4 ASPSP Brand ID Must As Is or Anonymised or Consolidated
5 Retail or Business PSUs Should As Is or Consolidated
6 API Service Must As Is or Consolidated
7 Active PSUs Must As Is or Consolidated
8 Active SME Businesses Must As Is or Consolidated
9 One-off Consents Must As Is or Consolidated
10 Long-lived consents -Outstanding consents BoP Must As Is or Consolidated
11 Long-lived consents -Revoked consents Must As Is or Consolidated
12 Long-lived consents -Expired consents Must As Is or Consolidated
13 Long-lived consents -Consents Requiring Reauthentication Must As Is or Consolidated
14 Long-lived consents -Refreshed consents Must As Is or Consolidated
15 Long-lived consents -New consents Must As Is or Consolidated
16 Long-lived consents - Outstanding consents EoP Must As Is or Consolidated
17 Long-lived consents - Total Refreshed consents Must As Is or Consolidated
18 PSUs used OB API Services for the first time Must As Is or Consolidated
19 Total PSUs used OB API Services Must As Is or Consolidated
20 Version Should As Is or Consolidated
21 CEF Outcome Area Should As Is or Consolidated

Submission Frequency: Normal

The following data table is required to be submitted to OBL at normal frequency. This is currently considered to be on a monthly (or sooner e.g. weekly)basis. The actual value will be agreed between OBL and participating TPPs.

TAB: 4A. PSU and Consent Adoption

ID Description MoSCoW Data Usage
1 Report Month Must As Is or Consolidated
2 TPP Brand ID Must Anonymised or Consolidated
3 "On behalf of" / TSP Brand Name Should Anonymised or Consolidated
4 Retail or Business PSUs Must As Is Consolidated
5 API Service Must As Is or Consolidated
6 Active PSUs Must As Is or Consolidated
7 Active SME Businesses Must As Is or Consolidated
8 PSUs used OB API Services for the first time Must As Is or Consolidated
9 Total PSUs used OB API Services Must As Is or Consolidated
10 CEF Outcome Area Should As Is or Consolidated

# 8.1.2 Service Specific MI (FUTURE CONSIDERATION)

Note: Service Specific MI is for future consideration and will not be included in the initial version of the TPP MI Specification. It is mentioned here for completeness.

# 8.1.2.1 PISP Only

# 8.1.2.1.1 Payments Adoption

TAB: 5. Payments Adoption

ID Description MoSCoW Data Usage
1 Report Month Must As Is or Consolidated
2 Report Time Should As Is or Consolidated
3 TPP Brand ID Must Anonymised or Consolidated
4 "On behalf of" / TSP Brand Name Should Anonymised or Consolidated
5 ASPSP Brand ID Must As Is or Anonymised or Consolidated
6 Payment Type Must As Is or Consolidated
7 PSU Authorisations for single Domestic Payments Must As Is or Consolidated
8 Successful single Domestic Payments Must As Is or Consolidated
9 Single Domestic Payments failed for Business Reasons (4xx codes) Must As Is or Consolidated
10 Single Domestic Payments failed for Technical Reasons (5xx codes) Must As Is or Consolidated
11 Single Domestic Payments Rejected Must As Is or Consolidated
12 Total payments included in Bulk/Batch files Must As Is or Consolidated
13 Successful International payments involving currency conversion Should As Is or Consolidated
14 Free Format Text Could As Is or Anonymised
15 Version Should As Is or Consolidated
# 8.1.2.1.2 Other
TAB: 6. PISP Only Optional/Adhoc MI
ID Description MoSCoW Data Usage
1 Report Month Could As Is or Consolidated
2 TPP Brand ID Could Anonymised or Consolidated
3 "On behalf of" / TSP Brand Name Would Anonymised or Consolidated
4 ASPSP Brand ID Could As Is or Anonymised or Consolidated
5 Version Would As Is or Consolidated
Payment Status
6 Payment Status Could As Is or Consolidated
7 Volume of Payments Could As Is or Consolidated
Payment SCA Exemptions
8 Payment Exemption Requested Could As Is or Consolidated
9 Volume of Payments requested SCA exemption Could As Is or Consolidated
10 Volume of Payments granted SCA exemption Could As Is or Consolidated
Payment Refunds
11 Volume of payments with Synchronous Refund Information Could As Is or Consolidated

# 8.1.2.2 AISP Only

TAB: 7. AISP Only Optional/Adhoc MI

ID Description MoSCoW Data Usage
1 Report Month Could As Is or Consolidated
2 TPP Brand ID Could Anonymised or Consolidated
3 "On behalf of" / TSP Brand Name Would Anonymised or Consolidated
4 ASPSP Brand ID Could As Is or Anonymised or Consolidated
5 Version Would As Is or Consolidated
Revocation Notifications from ASPSPs
6 Notification Method Used Could As Is or Consolidated
7 Volume of Successful Notification of Revocation Could As Is or Consolidated
8 Volume of Failed Notification of Revocation Could As Is or Consolidated
AIS Corporate Account Access(OPTIONAL)
9 Volume of Successful Corporate Account Access Would As Is or Consolidated
10 Volume of Rejected Corporate Account Access Would As Is or Consolidated
90-days re-authentication
11 Volume of successful re-authentications Could Mandatory
12 Volume of overdue re-authentications Could Mandatory

# 8.2 Measuring End-to-End Response times

Using Open Banking Standards, a service request from a TPP, for example, a payment initiation requested by a PISP, requires a number of API endpoint calls in order to be completed. While reporting at the endpoint level has undoubted business value, OBL would also like to receive measurements of the end-to-end journeys for PIS, AIS and CBPII as they will be experienced by the TPPs end users. The diagram below shows the various steps and the endpoint calls for initiating a payment, which is in the most complex case between AIS, PIS and CBPII.

In the web sequence diagram below, we have split the total end-to-end time Ttot into a number of different time period steps, namely T1, T2, T3, T4, T5, and T6. This is to provide granularity but also flexibility for a reporting TPP to have the option to include or exclude the PSU interaction time from the total end-to-end journey or the case where CoF was requested as part of the journey. Thus:

  • Ttot = T1 + T2 + T4 + T6 , (excluding the time of PSU interaction with the ASPSP for authenticating and other actions such as selecting a debit account, supplementary information etc) and no CoF
  • Ttot = T1 + T2 + T3 + T4 + T6 , (including the time of PSU interaction with the ASPSP for authenticating and other actions such as selecting a debit account, supplementary information etc) and no CoF
  • Ttot = T1 + T2 + T3 + T4 + T5+ T6 , (including the time of PSU interaction with the ASPSP for authenticating and other actions such as selecting a debit account, supplementary information etc) and performing CoF

TPPs may be able to report either Ttot = T1 + T2 + T4 + T6 and report T3 and T5 separately, or report on each time segment separately and allow OBL to consolidate the resulting total end-to-end time. This will be discussed and agreed with TPPs.

Please note that the above timing segments include the TPP's internal overhead and processing time taken during the end-to-end journey. This would be different from the reporting endpoint response times which they solely focus on the time period from sending the API endpoint call till receiving all the information included in the API endpoint response.

TTFB

# 8.3 Challenges of measuring "perceived" OBL API unavailability by TPPs

Measuring perceived availability of the OBL API Services offered by the ASPSPs, has several challenges and can only be achieved under very specific circumstances are explained below.

The challenge for TPPs measuring API service availability is originated from the fact that TPPs have no real visibility of when the actual service is in downtime or in uptime. TPPs can only report the experience they perceive from the outcome of an endpoint call. Thus, if an endpoint is not responded within a certain period of time (e.g. 15 sec) then a TPP will timeout on waiting for its response. The TPP may retry this a few more times and again timeout on waiting for the response, however this activity will not continue indefinitely and the TPP will finally abort trying to send the endpoint message. The TPP at a later point in time will try to make another endpoint call, and this may be successful and receive a response. However, the ASPSP service may have become available much earlier than the point in time the TPP will attempt to make another endpoint call, and thus, if the TPP has marked the perceived unavailability as the time period between the previously failed endpoint call until the next successful endpoint, then then accuracy of the perceived availability will heavily depend of the frequency of making the endpoint calls.

For example, if a TPP is making a group of endpoint calls twice a day (morning & evening with 12 hours interval) and the morning endpoint calls fail, while the afternoon calls are successful, the TPP will be reporting a "perceived unavailability" of 12 hours, while the true unavailability may have been only a few minutes in the morning during first group of endpoint calls. This is illustrated in the diagram below, where the assumption is that the TPP will start its perceived unavailability after 2 failed endpoints calls, and will stop this at the point of the first successful endpoint call, 12 hours later.

TTFB

Similar issue exists if the TPP marks as a perceived unavailability only the cases where the endpoints fail during the reporting window. In the example shown below, the TPP times out within 15 seconds for each of the 2 endpoint calls and then stops trying to make any more calls until 12 hours later. In this case, the TPPs perceived availability would be 30 seconds, while the true unavailability of the ASPSP would be much longer, e.g. 2 hours.

TTFB

As stated earlier, the accuracy of the "perceived unavailability" would heavily depend on the spreading of the endpoint calls during the reporting window. However, if OBL collects "perceived unavailability" data from multiple TPPs, we may be able to have enough data entries to profile the unavailability with enough characteristic information, especially for the PIS and CBPII services which are depending on the PSU payments usage patterns during the day and do not present the "batch" behaviours experienced by AISPs. This issue will be discussed with TPPs during early consultation and assess the feasibility of this approach.

Moreover, OBL is looking to request TPPs to provide redacted data sets of logging information from their own monitoring of the service availability especially during reporting periods where higher than normal error rates (time outs or 5xx errors) take place.

Both the above points are illustrated in the diagram below. If OBL collects several data from multiple TPPs spread across the reporting period, then OBL may have enough perceived unavailability periods to reflect the real unavailability period sufficiently. Moreover, if OBL collects data logs from TPPs with endpoint failures with timestamps, OBL may be able to also calculate perceived unavailability including any gaps between the TPPs' endpoint calls and reflect unavailability with even more accuracy.

TTFB

# 10. A2 (c)(ii) Roadmap item Definition

# 10.1 Objective

The Trustee and the ecosystem need to be able to access and use timely information about the APIs provided by ASPSPs.

# 11. Version control

Version Date Authors Comments
V0.1 14 Feb 2022 API Delivery Team Initial draft
V0.2 (Final) 30 Mar 2022 API Delivery Team Final