# MI Data Reporting Requirements
# 1. Purpose
The purpose of this document is to provide a consolidated view of the MI provision requirements for ASPSPs participating in the Open Banking Ecosystem focusing on errata fixes based on tickets raised by participants and Trustee actions.
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 3.1.9 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 with 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.
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.9 MI to include:
- Additional clarification or errata updates reported by internal review and/or external stakeholders.
# 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
- N/A
# 6.3 Assumptions
- The implementation dates of the v3.1.10 MI Requirements for ASPSPs will be in alignment with the implementation dates for v3.1.10 of the OBIE Standards.
# 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 Errata fixes based on Jira Tickets
| ID | Jira Ticket |
|---|---|
| 1 | Jira ticket CDRW-4119: Errata fix to remove residual cross validation rule for PIS-VRP from Auth Efficacy tab |
| 2 | Jira ticket CDRW-4113: Update to PSU adoption tab: Total Digitally Active Users in a reporting period |
| 3 | Jira ticket CDRW-4120: Update PISP response time calculation logic to: a). remove file payment endpoints from calculation in Tb, Tg, Th. b). apportion the total OIDC calls in the same ratio as AIS and CBPII consents for PIS consents for Va&e and Vd. |
| 4 | Jira ticket CDRW-4121: Change related to 90days to remove 90day re-authentication MI and references |
# 8. Version control
| Version | Date | Authors | Comments |
|---|---|---|---|
| V0.1 | 14 Feb 2022 | API Delivery Team | Initial draft for Industry consultation |
| V0.2 | 15 Mar 2022 | API Delivery Team | Final for TDA approval |
| V0.2 (Final) | 25 Mar 2022 | API Delivery Team | Final for IESG approval |