# 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 to the Open Banking Ecosystem focusing on errata fixes based on tickets raised by participants.
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.
# 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:
- 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
- OBIE v3.1.7 of the API technical specifications
# 6.3 Assumptions
- The implementation dates of the v3.1.7 MI Requirements for ASPSPs will be in alignment with the implementation dates for v3.1.7 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 | MoSCoW | Rationale | Regulatory Alignment | Reporting Implementation |
|---|---|---|---|---|---|
| 1 | Jira ticket OBSD-17365: Query on MI v3.1.5 Reported by Danske Bank, that they investigated data of one TPP and it appeared that bulk of consents created by the TPP are not consumed so the cross checks in Auth Efficacy vs Daily volumes will not match. Hence the below change in section 3.3 Auth Efficacy (OBIE) to include consents that have not been consumed by the TPP. ID#9 - Authentications Abandoned by PSUs (9.14/9.36) The total number of PSU consents to require authentication that has been abandoned by the PSUs. This means that PSUs do not undertake the authentication but instead have dropped the journey (they have left, closed the web page or app or allowed the authentication page to time out). Note: Consents that have not been consumed by the TPP need to be included. The example reporting template, validation_checks tab is also updated to fix a formula under 3_Auth_Efficacy item 3.2 as below: Replace Authentications Attempted by PSUs = Authentications Abandoned by PSUs + Authorisations Succeeded. with Authentications Attempted by PSUs = Authentications Succeeded + Authentications Failed. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 2 | Jira ticket OBSD-15976: V3.1.5 Data Dictionary: Clarification around the definition of PSU "consents" as relating to ASPSPs. - Reported by HSBC, seeking clarification on the term âconsentâ vs âaccessâ for ASPSP in section 3.4-B PSU Consent Adoption (OBIE). The below clarification has been added to section 3.4-B PSU Consent Adoption (OBIE) NOTE In order to differentiate between one-off and long-lived consents, it is proposed that ASPSPs assume one-offs are any consents with an expiry of less or equal to 15 days. The term âconsentâ is used from a PSU perspective. From ASPSPâs perspective, it is the access given by the PSU to the TPP. Hence reporting should still be the access data statistics. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 3 | Jira ticket OBSD-17559: MI315: Clarification required regarding FPS in Payments Adoption Tab. Reported by AIB, that Data Dictionary v3.1.5, section 3.5 Payments Adoption (OBIE), included FPS as a reporting payment type whereas the example reporting template stated that FPS is not included. The Example Reporting Template, tab â5_Payment Adoptionâ is updated to fix the issue and align with Data Dictionary. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 4 | Jira ticket OBSD-18061: MI Specification Queries- OBIE Internal review and also reported by HSBC, identified the data values for bulk/batch and International did not cover FPS. This is now amended in the Data Dictionary, section 3.5 Payments Adoption (OBIE) to add the below for payment type =FPS with NULL. ID#9 - Total payments included in Bulk/Batch files (9.46) ID#10 - Successful International payments involving currency conversion (9.47) Format/Values/Comments: Percentage number with no decimal points with a value between 0% and 100% If the payment type is Bacs: NULL If the payment type is CHAPS: NULL If the payment type is Bulk: NULL If the payment type is FPS: NULL The Example Reporting Template, tab â5_Payment Adoptionâ is updated to reflect the data values for FPS as NULL for both Bulk Payments & International payment types. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 5 | Jira ticket OBSD-16031: V3.1.5 Data Dictionary: including or excluding confirmatory PSUs in Multi-Auth transactions within PSU calculations.- Reported by HSBC, seeking clarity on not including other multi authorised PSUs in the PSU count. Tables 3.4 PSU Adoption and 3.4-A Enhanced PSU Adoption (OBIE) have been updated with note to provide more clarification. Multi-Authorisation Journeys In multi-authorisation journeys, after the first authoriser (i.e. the PSU providing consent and making the submission), subsequent authorisers (confirmatory PSUs in a multi-authorisation chain) do not need to be users of the PISP and hence they must not be counted as separate PSUs. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 6 | Jira ticket OBSD-17008: v3.1.5 Data Dictionary: clarification around 90 Days Re-Authentication delegated definition. - Reported by Lloyds Bank, seeking clarity on table 3.8.6 90-Days Re-authentication, ID#3 Number of AISPs, whether it should include only delegated SCA. We have added below note to the table. Note: These additional metrics are only used to report 90-days re-authentication done by AISPs using delegated SCA. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 7 | Jira ticket OBSD-19581: MI 3.1.5 8_6_Add_Met_90Days_Reauth- Reported by Nationwide, seeking clarity on table 3.8.6 90-Days Re-authentication, ID#3 & ID#4 Response same as #6 | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 8 | Jira ticket OBSD-17358: V3.1.5 MI Data Dictionary: Correction required to Section 3.9 'PSU Interface Performance and Availability (P & A)' wording.- Reported by HSBC, Table 3.9 PSU Interface Performance and Availability (P & A), core/non core hours and uptime reporting are referring to individual endpoints instead of âPSU Channelâ. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 9 | Jira ticket OBSD-17708: MI Reporting - v3.1.5 Reported by Nationwide, seeking clarification on table 3.8.1 Payment Status, ID#4 - Payment Status, whether âPendingâ status is a terminal state. We have added more clarity in the section with the below note: ASPSPs must only report on the listed status if it is one of the terminal states of the payment resource. For example, some ASPSPs consider âPendingâ as a terminal state whereas some do not. Hence reporting on âPendingâ status is enabled. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 10 | Jira ticket OBSD-17708: MI Reporting - v3.1.5.- Reported by Nationwide, seeking clarification on 4B_PSU_Consent_Adoption tab, on what is long-lived consent for PIS and whether it is for standing orders. We have updated the table to correct the data values for long-lived consent for PISP in the example template as long-lived consents are not applicable for PIS at this point. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 11 | Jira ticket CDRW-3711: Return 4A - Enhances PSU Adoption Validation Rule Update Required- Reported by OBIE MI Team, all business PSU's may not fall within a banks definition of SME, therefore the rule Active [Business PSU's] > 0 the Active SME Business > 0 may not always be true. We have updated the format values to incorporate this change. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 12 | Jira ticket CDRW-3713: Return 4B - PSU Consent Adoption - Update Required- Reported by OBIE MI Team , ID#8 - Long-lived consents - Expired consents updated to remove below note as CBPII/CoF consents also can have a expiry date. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 13 | Jira ticket OBSD-19523: MI Requirements Tab 8.4 v3.1.5 Template- Reported by Santander, seeking clarity on Tab 8.4 AIS Corporate Account Access ID#3. Tab 8.4 AIS Corporate Account Access ID#3 description is fixed to total number of AISPs requesting AIS access to corporate accounts. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 14 | Jira ticket CDRW-3712: Return 4B - PSU Consent Adoption - Review Required- Following the query from LBG, a potential issue with field 11 - Long-lived consents - Outstanding consents EoP has been identified. A review is required to determine whether the concept of 'Renewed Consents' exists in MI terms and therefore whether this should be included in the validation rule. Further guidance may be need to be issued to CMA9 as to how consent renewals should be treated and reported as a result. The Table 4B - PSU Consent Adoption definitions will be updated to provide more clarity and fix the existing issue. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 15 | Jira ticket OBSD-18607: HSBC OBIE MI PSU count specification clarification- HSBC would like clarification from the OBIE in regard to their MI metric requirement to provide a monthly count of PSUâs which used AIS / PIS for the first time. The current OBIE requirement stipulates this applies to all new PSU usage since the establishment of the channel, with no time-bound period to retrospectively set this requirement to. HSBC data retention policies limit the amount of time data is available for. As part of these policies, there is also stipulation in terms of what period of retrospective data needs to remain accessible vs. what period can be archived. Active queries / matching cannot be conducted on archived data. Can the OBIE please clarify what is the maximum amount of time during which a PSU is considered as a first time user? Given the above limitations, HSBC would like to suggest that the OBIE revise the new PSU metric to be time-bound to be measured within a 1 year period of retrospective data. OBIE will be responding to the ticket but will also be creating a single page paper with a proposal to be agreed in the IESG in December 2020. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
| 16 | Jira ticket OBSD-20810: Error in field Endpoint ID range in various tables in Data Dictionary and MI Specifications v3.1.5 Field Endpoint ID in various tables of the Data Dictionary is reporting incorrect range of the reported API endpoints. This needs to be corrected to avoid confusion in relation to the reported endpoints. | M | Regulatory | CMA Order Schedule 1, Article 2(j) | CMA9 mandatory if relevant functionality is implemented |
# 8. Version control
| Version | Date | Authors | Comments |
|---|---|---|---|
| V0.1 | 9 Oct 2020 | API Delivery Team | The initial draft |
| V0.2 | 10 Dec 2020 | API Delivery Team | Updated version, prior to IESG approval |