# MI Data Reporting Requirements v3.1.2
# 1. Version control
| Version | Date | Authors | Comments |
|---|---|---|---|
| V0.1 | 02 Apr 2019 | API Delivery Team | Initial draft |
| v0.2 | 18 Apr 2019 | API Delivery Team | Draft after industry consultation for review by IESG |
# 2. Purpose
The purpose of this document is to provide a consolidated view of the MI provision requirements for ASPSPs participating to the Open Banking Ecosystem in relation to the functionality introduced by v3.1.2 Technical Specifications.
This MI isrequired under the CMA Order, Therefore, this MI is to be submitted to Open Banking Implementation Entity (OBIE) by the CMA 9, to meet the provisions of Schedule 1, Article (2) (j) of the CMA Order, so as to enable the OBIE Trustee to "monitor compliance by the Providers with the Order".
Under the CMA Order, the MI will be used to help the Trustee and the CMA to: (1) understand the success and take-up of the Open Banking service, (2) confirm ASPSPs are meeting their MI obligations with the requirements in the CMA order and (3) understand usage patterns for potential future product development.
With the development of the Open Banking standards in line with the Open Banking Revised Roadmap, there is an introduction of additional API endpoints to deliver the new capabilities. The v3 MI requirements for the CMA9 must be extended to cover the new API endpoints supported by each ASPSP and the additional metrics required for monitoring the adoption of these new endpoints.
# 3. Not in scope of this paper
The paper does not cover the following:
- Data quality
- Monitoring of fraud
These items will be addressed either at a later date and/or via a separate activity.
# 4. Adoption Management
In order for OBIE 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. Monitoring the adoption has multiple aspects:
Monitoring the availability of the APIs to ensure compliance to the CMA Order (section 14.1 "continuously available").
Monitoring the volumes of the various API calls. This allows OBIE to measure the total volumes of each of the OBIE services offered by each ASPSP (including mandatory and optional) and the growth rate of these volumes so that OBIE can identify which services are being adopted by PSUs for the whole of the ecosystem and for each ASPSP individually. All the endpoints supported by the OBIE specifications need to be included so that all propositions are monitored. Please note that where ASPSPs have implemented both optional and mandatory endpoints, provision of MI for optional endpoints is important to understand the utilisation and performance of these endpoints.
Monitoring the efficacy of redirection and decoupled models. Understanding the success rates of the redirection and decoupled models introduced by OBIE 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.
Monitoring the number of TPPs onboarded for Open Banking with each ASPSP and the number of TPPs deregistered (churn). This is currently covered by the MI requirements for v1 and provides OBIE with a TPP adoption growth rate both for the whole of the ecosystem and by each ASPSP individually.
Monitoring other aspects of the AIS and PIS services such as the optional revocation notifications, the payment status across the payment processing chain,the request for the application of SCA exemptions and the AIS access to corporate accounts.
Based on the above, OBIE can apply product management methodologies and make informed decisions on the life cycle of the APIs.
# 5. High-Level requirements
The high-level requirements for MI include:
Modifications to existing V3 MI resulting from v3.1, v3.1.1 and v3.1.2 standards. These include:
- New endpoints required as part of the Technical Standards
- New metrics introduced for the monitoring the adoption of roadmap item propositions P2, P8, P9 and P22
Additional MI requirements included in the Trustee letter requesting MI by ASPSPs on 15th Nov-18
Alignment between Operational Guidelines and MI Requirements
# 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 OBIE 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.
The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 states the requirement for ongoing monitoring of the implementations with particular metrics including API availability and customer experience.
The Trustee letter of 15th Nov 2018 to the CMA9 ASPSPs, requesting a set of specific MI metrics to be reported to OBIE in order to monitor PSU adoption of the OBIE API services adoptions and performance and availability of APIs against Online Banking and Mobile Banking PSU channels.
One of the ways by which OBIE is enabling the Trustee to monitor compliance is through the provision, by the API providers, of MI on the utilisation of their Open Banking APIs.
Moreover, the provision of MIhas been contractually agreed by ASPSPs enrolling into Open Banking.
# 7. Considerations
# 7.1. Constraints
- N/A
# 7.2. Reference documents
- OBIE v3.1, v3.1.1 and v3.1.2 of the API technical specifications
- OBIE Read/Write API Reporting and MI Service Level Agreements
- Trustee letter requesting MI by ASPSPs 15th Nov-18
- OBIE Operational Guidelines v1.1
# 7.3. Assumptions
- The implementation dates of the v3.1.2 MI Requirements for ASPSPs which relate to new functionality included in this release (i.e. new endpoints) will be in alignment with the implementation dates for the various roadmap items for v3.1.2 standards. There is no agreed timeline for implementation of these items. Please note, that other MI requirements included in this proposition paper, which do not relate to this functionality are subject to implementation timelines as stated in the Reporting implementation column of section 8.1.
# 7.4. Dependencies
- N/A
# 8. Appendix
# 8.1 Detailed Product Requirements
These are stated as requirements of the OBIE solution to enable support for key customer use cases.
Requirements marked as 'M'(Must) are in scope of the OBIE solution. All other requirements are listed for future consideration. The final column indicates whether each requirement is 'mandatory', 'conditional' or 'optional' for implementation by ASPSPs and/or TPPs. These terms are defined here: Categorisation of requirements for standards and implementation (opens new window).
# 8.1.1 Changes to Data Dictionary API EndPoint List - New Endpoints
| ID | Description | MoSCoW | Rationale | Regulatory Alignment | Reporting implementation |
|---|---|---|---|---|---|
| 1 | CoF for PISPs Predefined API Endpoint List must be updated with the following endpoints: * GET /domestic-payment-consents/{ConsentId}/funds-confirmation * GET /international-payment-consents/{ConsentId}/funds-confirmation * GET /international-scheduled-payment-consents/{ConsentId}/funds-confirmation This will allow the above endpoints to be reported for performance and availability, performance outliers and daily volumes. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 | CMA9 mandatory Report in alignment to implementation for v3.1 |
| 2 | Inclusion of Account Name Predefined API Endpoint List must be updated with the following endpoints: * GET /accounts/{AccountId}/parties This will allow the above endpoints to be reported for performance and availability, performance outliers and daily volumes. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 | CMA9 mandatory Report in alignment to implementation for v3.1.1 |
| 3 | Notifications from ASPSPs to AISPs Predefined API Endpoint List must be updated with the following endpoints: * POST /event-subscriptions * GET /event-subscriptions * PUT /event-subscriptions/{EventSubscriptionId} * DELETE /event-subscriptions/{EventSubscriptionId} * POST /event-notifications * POST /events This will allow the above endpoints to be reported for performance and availability, performance outliers and daily volumes. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 | CMA9 mandatory if endpoints implemented as part of v3.1.2 |
| 4 | Payment Status Predefined API Endpoint List must be updated with the following endpoints: * GET /domestic-payments/{DomesticPaymentId}/payment-details * GET /domestic-scheduled-payments/{DomesticScheduledPaymentId}/payment-details * GET /domestic-standing-orders/{DomesticStandingOrderId}/payment-details * GET /international-payments/{InternationalPaymentId}/payment-details * GET /international-scheduled-payments/{InternationalScheduledPaymentId}/payment-details * GET /international-standing-orders/{InternationalStandingOrderPaymentId}/payment-details * GET /file-payments/{FilePaymentId}/payment-details This will allow the above endpoints to be reported for performance and availability, performance outliers and daily volumes. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 | CMA9 mandatory if endpoints implemented as part of v3.1.2 |
# 8.1.2 New Adoption Metrics for Data Dictionary and MI Template
| ID | Description | Expected response | MoSCoW | Rationale | Regulatory Alignment | Reporting implementation |
|---|---|---|---|---|---|---|
| Proposition P2 | ||||||
| 1 | Number of TPPs using push and pull (basic and aggregated) notification methods | Will be provided by Daily volumes once endpoint list is updated with relevant endpoints. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 | CMA9 mandatory if functionality is implemented as part of v3.1.2 |
| 2 | Volume of successful and failed notifications of revocation of consent at TPPs - (received by ASPSPs) | This is provided by existing MI via daily volumes of DELETE /account-access-consents/{ConsentId} endpoint | M | |||
| 3 | Volume of successful and failed notifications of revocation of access at the ASPSPs using basic polling - (requested by TPPs) | New metric required as stated in the metric description. | M | |||
| 4 | Volume of successful and failed notifications of revocation of access at the ASPSPs using aggregated polling - (requested by TPPs) | New metric required as stated in the metric description. | M | |||
| 5 | Volume of successful and failed notifications of revocation of access at the ASPSPs using real-time push notifications - (pushed by ASPSPs to TPPs) | New metric required as stated in the metric description. | M | |||
| 6 | Volume of successful and failed notifications of revocation of access at the ASPSPs using push notifications for offline TPPs - (pushed by ASPSPs to TPPs) | New metric required as stated in the metric description. | M | |||
| Proposition P8 | ||||||
| 7 | Volume of payment transactions where SCA exemption is requested, categorised by the type of exemption requested. | New metric required as stated in the metric description. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 | CMA9 mandatory if functionality is implemented as part of v3.1.2 |
| 8 | Volume of payment transactions where SCA was specifically requested by the TPP. | New metric required as stated in the metric description. | M | |||
| Proposition P9 | ||||||
| 9 | Number of TPPs making and GET status call and receiving status of payments of all types and various stages using Open Banking | Will be provided by Daily volumes once endpoint list is updated with relevant endpoints. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 | CMA9 mandatory if functionality is implemented as part of v3.1.2 |
| 10 | Volume of reported pending payments with status âPendingâ, generated by each payment type | New metric required as stated in the metric description. | M | |||
| 11 | Volume of failed payments with status âRejectedâ, generated by each payment type | New metric required as stated in the metric description. | M | |||
| 12 | Volume of accepted payments with status âAcceptedSettlementInProcessâ, generated by each payment type | New metric required as stated in the metric description. | M | |||
| 13 | Volume of successful payments with status "AcceptedSettlementCompleted" generated by each payment type | New metric required as stated in the metric description. | M | |||
| 14 | Volume of successful payments with status "AcceptedCreditSettlementCompleted"â, generated by each payment type, where applicable. | New metric required as stated in the metric description. | M | |||
| Proposition P22 | ||||||
| 15 | Number of AISPs accessing "corporate account(s)" (i.e. accounts held by businesses) | New metric required as stated in the metric description. | S | Customer | N/A | CMA9 optional if functionality is implemented as part of v3.1.2 |
| 16 | Number of rejected access by ASPSP due to insufficient authority to view corporate account(s) via AISP | New metric required as stated in the metric description. | S |
# 8.1.3 Amendments for Trustee letter requesting MI by ASPSPs Nov-18
| ID | Description | MoSCoW | Rationale | Regulatory Alignment | Reporting implementation |
|---|---|---|---|---|---|
| 1 | Add the following metric to the reporting template for Online Banking and Mobile Banking: "Average availability expressed as percentage of total hours in a month split between core (06:00 â 24.00) and non-core hours (00.00 â 06.00) by brand per month" | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 Trustee letter requesting MI by ASPSPs 15th Nov-18 | CMA9 mandatory Report as per Trustee Letter 15 Nov-18 |
| 2 | Add the following metric to the reporting template for Online Banking and Mobile Banking: "Total number of new PSUs split between consumers and SMEs per month" | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 Trustee letter requesting MI by ASPSPs 15th Nov-18 | CMA9 mandatory Report as per Trustee Letter 15 Nov-18 |
| 3 | Add the following metric to the reporting template for Online Banking and Mobile Banking: "Total cumulative number of PSUs split between consumers and SMEs per month" | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 Trustee letter requesting MI by ASPSPs 15th Nov-18 | CMA9 mandatory Report as per Trustee Letter 15 Nov-18 |
| 4 | Add the following metric to the reporting template for Online Banking and Mobile Banking: "Average availability expressed as a percentage of total hours in a month by brand per month" | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 Trustee letter requesting MI by ASPSPs 15th Nov-18 | CMA9 mandatory Report as per Trustee Letter 15 Nov-18 |
| 5 | Add the following metric to the reporting template for Online Banking and Mobile Banking: "Downtime for each brand per month" | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 Trustee letter requesting MI by ASPSPs 15th Nov-18 | CMA9 mandatory Report as per Trustee Letter 15 Nov-18 |
| 6 | Number of API calls per day per endpoint, split by core/non-core This will allow OBIE to calculate a weighted average of the response times when creating a monthly consolidate response time for each end point. This will also allow OBIE to calculate the average response times by brand per month, the average availability expressed as a percentage of total hours in a month by brand per month and other metrics as required in the Trustee letter of 15th Nov-18. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 Trustee letter requesting MI by ASPSPs 15th Nov-18 | CMA9 mandatory Report as per Trustee Letter 15 Nov-18 |
| 7 | Report mean value in addition to median value response times V3 MI requirements response times are based on median value while OGs response times are based on mean values. For being able to have comparable figures, OBIE would require to receive both median and mean values of the response times in the Performance and availability tabs and the Response Outliers tab. This will also allow OBIE to calculate the average response times by brand per month and other metrics, as required in the Trustee letter of 15th Nov-18. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 Trustee letter requesting MI by ASPSPs 15th Nov-18 | CMA9 mandatory Report as per Trustee Letter 15 Nov-18 |
| 8 | Include total TTLB and TTFB per endpoint per day. Also include total response payload The above data are included in the OGs reporting. This will allow the MI reporting to perform the same averaging calculations as performed in the OGs reporting template. This will also allow OBIE to calculate the average response times by brand per month and other metrics, as required in the Trustee letter of 15th Nov-18. | M | Regulatory | CMA Order Schedule 1, Article 2(j) & The Trustee letter of 10th July 2018 to the CMA, section 2.1.6 CMA Order Schedule Article 14.1 Trustee letter requesting MI by ASPSPs 15th Nov-18 | CMA9 mandatory Report as per Trustee Letter 15 Nov-18 |
# 8.1.4 Alignment between Operational Guidelines and MI Requirements
There are some variances between the calculations used in the MI Reporting Requirements of ASPSPs to OBIE and the OBIE Operational Guidelines, especially in the areas of measuring and reporting availability and performance. In the interest of consistency of reporting, comparability of figures and streamlining of reporting implementations for ASPSPs, OBIE wants to align the definitions of these calculations. The changes required are shown below and will be reflected in the next version of the MI Reporting Data Dictionary.
| ID | Description | Reporting implementation |
|---|---|---|
| 1 | Availability - Downtime definition Align the definition of unavailability with the one in Operational Guidelines as per the following: OGs section 2.1.1 * At a minimum, downtime should be measured if: - Any ASPSP authorisation and/or resource server is not fully accessible and accepting all valid TPP requests as defined by EBA Guidelines 2.4c. - Any ASPSP downstream system required to support these API endpoints is also not responding in a way which effects the availability of the ASPSP authorisation and/or resource servers. - Any of the ASPSP screens and/or functionality of the PSU authentication flow is not available to enable PSUs to grant TPPs access to their account(s). - This should include all 5xx errors. - This should include both planned and unplanned downtime during each day. - Even if this only effects some TPPs and/or PSUs, downtime should still be reported, i.e. partial downtime should still be measured as downtime. - This should include any vendor/supplier failures in the case where the ASPSP has contracted the vendor/supplier to deliver a related service, e.g. -_ the ASPSP's own hosting provider,_ - any QTSP the ASPSP has selected for their own certificates, - a third party directory service (e.g. the OBIE Directory). However, this should exclude errors resulting from issues outside of the ASPSP's direct control, such as any of the following: * Issues with TPP software, infrastructure or connectivity. * Lack of response/availability from an individual QTSP resulting in the inability of the ASPSP to check validity of a TPP's eIDAS certificate, since it is the TPP who has selected the QTSP. The above guidelines relate only to how ASPSPs should calculate downtime. ASPSPs must be mindful of their own regulatory obligations under the PSD2 regulatory framework and eIDAS Regulation. | CMA9 mandatory Update reporting by Sept-19 |
| 2 | Version Reporting Add the following requirement as per OGs section 2.2.2 "Where ASPSPs support more than one major or minor API version in production, each version must be reported separately. For example, v3.0 and v3.1 must be reported separately. However patches, for example v3.1.1, should be reported as aggregate together with the relevant major or minor release (i.e. together with v3.1)" | CMA9 mandatory Update reporting by Sept-19 Note: Version reporting will not be mandatory for all the MI Reporting data. Please refer to the Data Dictionary for more details for mandatory and optional version reporting. |