# 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:
- understand the success and take-up of the Open Banking service
- assess the performance of the API services as they are perceived from the TPPs' perspective
- measure the drop out rates for each group of services
- forecast volumes and user growth to allow capacity planning and ensure sufficient support services, and
- 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).
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:
- Generic (Core): MI which is required by all participant TPPs
- 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
- PISP Only:
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.
# 6. Regulatory and Legal Considerations
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
- TPP MI Reporting Data API Specifications v3.1.11
- OBL v3.1.11 of the API Standards (opens new window)
- OBL v3.1.11 of the ASPSP MI Specifications (opens new window)
# 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 |
# 8.1.1.4 PSU and Consent Adoption per ASPSP brand
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 |
# 8.1.1.5 PSU and Consent Adoption
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.
# 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.
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.
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.
# 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 |