# 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 in relation to functionality introduced by v3.1.8 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.7 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.7 MI, resulting from the v3.1.8 of the Standards published in March 2021. These include:
- New metrics introduced for monitoring the adoption of item propositions VRP enhancements.
- Errata updates reported by internal review and/or external stakeholders.
Note: None of the changes in v3.1.6 and v3.1.7 of the API specifications leads to any MI specification change.
# 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
# 6.3 Assumptions
- The implementation dates of the v3.1.8 MI Requirements for ASPSPs will be in alignment with the implementation dates for v3.1.8 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 New Adoption Metrics for Data Dictionary and MI Template
| ID | Description | Expected response | MoSCoW | Rationale | Regulatory Alignment | Reporting implementation |
|---|---|---|---|---|---|---|
| Proposition Variable Recurring Payments (VRP) | ||||||
| 1 | Type of VRP Consent: Allowed enumeration values: * Sweeping * Non-sweeping | New metric required as stated in the metric description. | M | Customer | Optional | |
| 2 | This is the total number of PISPs setup VRP Consent for the first time per the category of VRP, in the reporting period. | M | Customer | Optional | ||
| 3 | This is the total number of VRP consents requiring authentication per the category of VRP, by the PSU and the authentication have succeeded in the reporting period. | M | Customer | Optional | ||
| 4 | This is the total volume of VRP consents requiring authentication by the PSU per the category of VRP, and the authentication have failed in the reporting period. | M | Customer | Optional | ||
| 5 | This is the total volume of unique Long-lived Variable recurring payment access which have been revoked by PSUs per category of VRP, during the reporting period. | M | Customer | Optional | ||
| 6 | This is the total volume of successful payments per category of VRP in the reporting period. | M | Customer | Optional | ||
| 7 | This is the total volume of failed payments per category of VRP in the reporting period. | M | Customer | Optional | ||
| 8 | This is the total volume of VRP payments for sweeping where the ASPSP decided the Trusted Beneficiary Exemption could not be applied. | M | Customer | Optional |
# 7.1.2 Errata fixes based on Jira Tickets
| ID | Jira Ticket |
|---|---|
| 1 | Jira ticket CDRW-3708 - V3.1.5 Template has return 1A shown as 3a in Error OBIE internal bug fix to correct tab name in example template from "3A_PSU_Authentication_Interact" to "1A_PSU_Authentication_Interact" |
| 2 | Jira ticket OBSD-22001: CoF Endpoints - Discrepancy between Standards and Operational Guidelines reporting template LBG have raised the following query regarding a discrepancy in the categorisation of the CoF endpoints between the MI standards and the template for FCA reporting in the Operational Guidelines online. On the published endpoint list endpoints 75 and 76 are still categorised as CoF, However in the Operational Guidelines ASPSP Reporting Template v3.1.5 they are categorised as PISP |
# 8. Version control
| Version | Date | Authors | Comments |
|---|---|---|---|
| V0.1 | 24 Feb 2021 | API Delivery Team | Initial draft for internal review |
| V0.2 (RC1) | 4 Mar 2021 | API Delivery Team | Updated version to RC1, prior to TDA approval & IESG approval |
| V0.3 (RC1) | 18 Mar 2021 | API Delivery Team | Updated version to remove High Frequency based on TDA decision 233 |
| V0.4 (Final) | 25 Mar 2021 | API Delivery Team | RC1 to Final, after IESG approval |