# MI Data Reporting Requirements v3.1.5
# 1. 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.4 and v3.1.5 of the API Specifications. This MI is required 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 Roadmap, there is an introduction of additional API functionality to deliver the new capabilities. Thus, the v3.1.2 MI requirements for the CMA9 must be extended to cover the new functionality supported by each ASPSP and the additional metrics required for monitoring the adoption of these propositions.
# 2. 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.
# 3. 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 de-registered (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 the PSU Adoption of Open Banking services and the intensity of their usage.
- Monitoring other aspects of the AIS and PIS services such as 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, OBIE can apply product management methodologies and make informed decisions on the life cycle of the APIs.
# 4. High-Level requirements
The high-level requirements for MI include:
- Modifications to existing v3.1.2 MI, resulting from the v3.1,4 of the Standards published in December 2019. These include: New metrics introduced for monitoring the adoption of item propositions P7 and 90-days re-authentication enhancements
- Errata updates reported by internal review and/or external stakeholders. Some of these have already been fixed on the MI Reporting V3 but have not been updated in MI Reporting v3.1.2
- Additions based on the initiative by the OBIE Office of the Trustee for PSU adoption reporting (CR – OBSD 11553 – PSU & Consents approved by PMG)
- Additions to Data Dictionary of conditions for data validation
- Alignment to OBIE Operational Guidelines for the inclusion of new EBA Guidelines regarding KPIs for availability and performance that an ASPSP should have in place for each their dedicated interface(s).
# 5. 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.
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 MI has been contractually agreed by ASPSPs enrolling into Open Banking.
# 6. Considerations
# 6.1 Constraints
- N/A
# 6.2 Reference documents
- OBIE v3.1.4 of the API technical specifications
# 6.3 Assumptions
- The implementation dates of the v3.1.5 MI Requirements for ASPSPs which relate to new functionality included in the v3.1.4 release will be in alignment with the implementation dates for the various roadmap items for v3.1.4 standards. There is no agreed timeline for implementation of these items.
# 6.4 Dependencies
- N/A
# 7. Appendix
# 7.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 the 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.
# 7.1.1 New Adoption Metrics for Data Dictionary and MI Template
| ID | Description | Expected response | MoSCoW | Rationale | Regulatory Alignment | Reporting implementation |
|---|---|---|---|---|---|---|
| Proposition P7 - Payment Refunds | ||||||
| 1 | Number of PISPs requesting PSU's account details to be provided by the ASPSPs as part of the payment journey, during the reporting period. | 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 the functionality is implemented as part of v3.1.4 |
| 2 | The volume of payments for which ASPSPs provided PSU's account details to the PISPs for refund purposes, during the reporting period. | 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 the functionality is implemented as part of v3.1.4 |
| Proposition 90-Days Re-authentication enhancements | ||||||
| 4 | Number of AISPs using the delegated 90-days re-authentication process during the reporting period. | 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 the functionality is implemented as part of v3.1.4 |
| 5 | The volume of successful re-authentication by PSU via the AISP, including PSU, calls to action (i.e. SCAs) and actual access refreshes. | 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 the functionality is implemented as part of v3.1.4 |
| 6 | The volume of re-authentication overdue for renewal where the PSU did not re-authenticate. | 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 the functionality is implemented as part of v3.1.4 |
# 7.1.2 Errata fixes based on Jira Tickets
| ID | Jira Ticket |
|---|---|
| 1 | Jira ticket OBSD-8754 - Error identified in the Data Dictionary for V3 MI Reporting documentation Reported by AIB, this is an error in the following wording: 4.7.11 "This is the total number of successful endpoint calls that have not been presented to the PSU for authorisation..." The word not should not be used in the above wording |
| 2 | Jira Ticket 8756 - Minor error in Data Dictionary for V3.1.2 MI Reporting - DRAFT 2 in Table 4.1 Description In Table 4.1 the following items have stated inconsistently that the elapsed reported time format should be in hours and minutes and not in format hh: ss. 4.1.5: references to hh: ss should be changed |
| 3 | Jira Ticket OBSD-9094 - Data Dictionary V3 PSU Adoption requires an update to correct the error Under 4.4 PSU Adoption, in the table TAB 4. PSU Adoption under the heading Format/Values/Comments, the following needs to be corrected: For 8. Unique PSUs used both AIS and PIS Services for the first time, the Conditions currently read: Conditions 1. Unique PSUs used both AIS and PIS Services for the first time >= PSUs used AIS Services for the first time 2. Unique PSUs used both AIS and PIS Services for the first time >= PSUs used PIS Services for the first time 3. Unique PSUs used both AIS and PIS Services for the first time <= PSUs used AIS Services for the first time + PSUs used PIS Services for the first time This should be: Conditions 1. Unique PSUs used both AIS and PIS Services for the first time <= PSUs used AIS Services for the first time 2. Unique PSUs used both AIS and PIS Services for the first time <= PSUs used PIS Services for the first time For 9. Total unique PSUs used both AIS and PIS Services, the Conditions currently read: Conditions 1. Total unique PSUs used both AIS and PIS Services >= Unique PSUs used both AIS and PIS Services for the first time 2. Total unique PSUs used both AIS and PIS Services >= Total PSUs used AIS Services 3. Total unique PSUs used both AIS and PIS Services >= Total PSUs used PIS Services 4. Total unique PSUs used PIS Services <= Total PSUs used AIS Services + Total PSUs used PIS Services This should be: Conditions 1. Total unique PSUs used both AIS and PIS Services >= Unique PSUs used both AIS and PIS Services for the first time 2. Total unique PSUs used both AIS and PIS Services <= Total PSUs used AIS Services 3. Total unique PSUs used both AIS and PIS Services <= Total PSUs used PIS Services |
| 4 | Jira Ticket OBSD-9479 - Add Faster Payments as an allowed value for payment type under Payments Adoption As discussed at the PMG meeting this week, banks can now submit Faster Payments as an allowed payment type on the Payments Adoption tab. Thus the data dictionary should now be updated to reflect this. |
| 5 | Jira Ticket MI-25 - Need to add Brand ID for HSBC Business to the data dictionary Can you please make the amendments to the data dictionary. We have HSBC Business down as ID 17 and HSBC renamed to HSBC Personal |
| 6 | Jira Ticket 12446 - Add Mandatory column to the API Endpoint list on the MI Reporting Data API Specification v3.1.2 page The API Endpoint list on the MI Reporting Data API Specification v3.1.2 page currently does not contain a Mandatory column: V3.1.2 API Endpoint List (opens new window). Ideally, it should probably have a Mandatory column in a similar fashion to the v3 API Endpoint list: V3.1 API Endpoint List (opens new window) |
| 7 | Jira Ticket OBSD-13344 - Barclays queries around Additional Metrics fields Barclays has requested the following clarifications on some of the Additional Metrics MI report tabs, specifically Revocation Notification from ASPSPs and Payment Status: Additional Metrics - Revocation Notifications from ASPSPs 1. For the column "Volume Notification of Revocation", based on the description here should it be "Volume of Failed Notification of Revocation"? 2. "Volume Notification of Revocation"- Are we just reporting the Basic Polling and aggregated polling endpoints where there has been a technical or business error (code 400-599)? Reason for asking is when we have an error we don’t have a response to know what the consent status was at the time the request was made. 3. Confusion re: data dictionary- Definition for Number Of AISPs says- "This is the number of individual AISPs initiating payments and checking their payment status." Assume this is an error given the mix of accounts and payments? Can you confirm the correct definition? Additional Metrics- Payment Status 4. Are we right to assume that for reporting the payment statuses, optional GET payment detail endpoint would also be considered if and when they are implemented (as per the list below)? – please can you confirm • 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 |
| 8 | Jira Ticket OBSD-14849 - Add "Unknown" enumeration value as an allowed ASPSP Authentication Channel for Auth Efficacy in the v3.1.5 MI Data Dictionary We’ve received feedback from several banks that their authentication journey often does not contain data on authentication channel for users who abandon or fail the authentication (i.e. the authentication channel is not logged until the authentication is successful). Obviously we would like them to develop the required reporting and tracking to have all journeys tracked, but in the meantime we do still want these journeys submitted. At the moment however there is no allowed enumeration value for these journeys. Could you add "Unknown" as an allowed enumeration value for ASPSP Authentication Channel in the Authentication Efficacy report in the v.3.1.5 MI data dictionary? |
# 7.1.3 Additions from CR – OBSD 11553 – PSU & Consents
The details of the PSU Adoption definitions and the impact assessment of CR OBSD11553 can be found in the Confluence page IA - PSU & Consents definitions implementation impact assessment - OBSD-11553 (opens new window)
The Data Dictionary and MI specifications will be updated as follows:
- A new table is to be created named 4-A Enhanced PSU Adoption. The table is to include definitions, data format and validation conditions
- A new table is to be created named 4-B PSU Consent Adoption. The table is to include definitions, data format and validation conditions.
# 7.1.4 Additions to Data Dictionary of conditions for data validation
In the existing versions of the Data Dictionary, there are current conditions that are included for data validation. These are included to ensure that certain data values will not be provided if they invalidate certain logical and numerical rules. These conditions currently refer to data elements belonging to the same tables. However, there are cases where data elements in one table could actually be compared with data elements in another table in order to check the consistency of data reporting and rules validation. These cross-table data validation conditions are to be added as part of these MI requirements set.
# 7.1.5 Alignment to OBIE Operational Guidelines
As OBIE Operational Guidelines have been updated for further alignment to the EBA Guidelines in relation to availability and performance, the ASPSP MI reporting to OBIE also needs to be updated to reflect this and also increase the alignment of the reporting information. Thus, the Performance and Availability section of the Data Dictionary will need to be updated to include further clarification, definitions and information of how the average response time will be calculated using the data submitted by ASPSPs. An additional optional table for the separate reporting of the PSU Authentication time will also need to be included.
# 8. Version control
| Version | Date | Authors | Comments |
|---|---|---|---|
| V0.1 | 18 Nov 2019 | API Delivery Team | The initial draft for consultation |
| V0.2 | 20 Jan 2020 | API Delivery Team | Updated with CR, errata and OBIE Operational Guidelines changes the alignment |
| V0.2 | 28 Jan 2020 | API Delivery Team | Further additions to the requirements for internal review |
| V0.3 | 13 Feb 2020 | API Delivery Team | Draft 1 version, prepared for public consultation |
| V0.4 | 13 Mar 2020 | API Delivery Team | Draft 2, updated based on public consultation and prepared for IESG review. |
| V0.5 | 26 Mar 2020 | API Delivery Team | The final version, further to IESG approval |