1. Purpose

The purpose of this document is to provide a consolidated view of the requirements for (a) an Enhanced Mechanism for MI Data Submission to OBIE and (b) the provision of MI Reporting Data from TPPs participating in the Open Banking Ecosystem in relation to the functionality introduced by the OBIE API Specifications.

The proposed new mechanism for MI Data Submission is an enhancement to the existing mechanism which is currently in place and used by ASPSPs to submit MI Reporting Data to OBIE. The enhanced MI Submission Mechanism will be available to be used by both ASPSPs and TPPs for the automated, where possible, submission of MI Data to OBIE.

The proposed new mechanism is directly related to the objective of this roadmap item which is the:

• “timely” provision of MI to the Trustee and the ecosystem”, and
• the activity of “improved MI provision and reporting”​

as per the roadmap definition. The new data submission mechanism will allow ASPSPs and TPPs to submit MI data sets to OBIE in a timely manner, where required.

Please note that the MI Reporting from TPPs is not a direct requirement under the CMA Order or the Payment Services Regulations 2017. This MI is to be submitted to the Open Banking Implementation Entity (OBIE) by TPPs voluntarily, so as to enable the OBIE to measure the performance and adoption of the OBIE API Services offered by ASPSPs, as experienced by the receiving organisations and/or their end-users.

It is however clearly mentioned in the roadmap item definition as “TPP-facing OB Standard to be implemented by TPPs (on a voluntary basis, supported by ICO Code if possible and if appropriate).” 

The MI will be used to help OBIE to:

1. understand the success and take-up of the Open Banking service
2. assess the performance of the API services as they are perceived from the TPPs’ perspective
3. measure the drop out rates for each group of services
4. forecast volumes and user growth to allow capacity planning and ensure sufficient support services, and 
5. understand usage patterns for potential future product development.

Please refer to section 10 in the Appendix for the full roadmap item definition. 

2. Not in scope of this paper

The paper does not cover the following:

• Monitoring of fraud

These items will be addressed either at a later date and/or via a separate activity.

3. The need of an Enhanced Mechanism for MI Data Submission to OBIE

3.1 Existing Reporting Challenges with ASPSPs

The following challenges exists with the  MI Reporting of ASPSPs to OBIE:

• Incorrectly reported data: MI Reported data included in the reporting templates has included have been including incorrect data on several occasions. OBIE has been working with the ASPSPs for over 2 years now to improve the quality of the data by introducing simple data validation rules in the template but these rules cannot pick up all cases.
• Inconsistent data: There are cases where data included in one table of the reporting template does not match data reporting in another template. Thus, reported data is inconsistent generating confusion in relation to specific reports such as drop out rates.
• Data reported too slow: On several occasions, MI data received by OBIE, is not able to produce useful analysis, insight and forecasting before reaching the mid of the next reporting month. This reduces the value of any of the analysis produced by OBIE and shared with the participating ASPSPs.       

3.2 Data Reporting Risks

• Risk of Input Error: Human error can occur, which can create a risk of errors in the input process. In several cases, inaccuracies may be harmless, especially if they are in a field in a spreadsheet with little meaningful value.  However, there could be misinterpretations with data, especially if handwritten.
• Risk of Incorrect Formatting: Data entry is arguably one of the most impressive organisational tools, when carried out correctly. With all information arranged accordingly, finding relevant data can be quick and easy. Sometimes though, manual input can present a problem where statistics and figures are filed wrongly, causing more time to be taken to rectify the problem. When tasked with a large range of information, manual in-putters can make the slightest of mistakes and key facts into the wrong fields, rendering them almost useless.
• Increased Costs: Whilst manual data entry may seem like a relatively low cost operation on the face of things, this isn’t always the case. The many hidden costs of in-house entry can often outweigh the benefits of internal input. Input can be a time-consuming task requiring additional financial and time resources, which may be needed elsewhere in the business. As well as this, if an error does occur somewhere down the line, it may not be able to be instantly fixed, taking even more time away from core business activities.

Designing and implementing a new Enhanced Mechanism for MI Data Submission to OBIE will address the existing challenges and will eliminate some of the aforementioned risks. 

4. Adoption Management – Additional TPP perspective

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. One aspect of this is achieved by receiving detailed MI Reporting data from ASPSPs. However, in addition to receiving ASPSP MI Reporting data, OBIE and the ecosystem would benefit from receiving adoption management MI from TPPs. This will provide a different perspective of increased business value and will also allow reconciliation of the ecosystem data when combined with the ASPSP MI Reporting data.    

Monitoring the adoption has multiple aspects:

• Measuring the availability of the APIs as perceived by the TPPs and their end-users. Unavailable services, especially during peak demand may seriously impact the adoption of the OBIE services. (Please refer to section 8.3 about challenges of measuring this.)
• Measuring the performance of the APIs as perceived by the TPPs and their end-users. This includes endpoint-level response times but also total end-to-end response time as experienced by the end-users.  
• Measuring the volumes of the various API calls. This allows OBIE to analyse the total volumes of each of the OBIE services used by each TPP (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. All the endpoints supported by the OBIE specifications which have been used by TPPs need to be included so that all propositions that have gone live are monitored. Please note that where ASPSPs have implemented both optional and mandatory endpoints, provision of MI for optional endpoints used by TPPs is important to understand the utilisation and performance of these endpoints.    
• Measuring the efficacy of redirection (and decoupled models). Understanding the success and drop-out 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. 
• Measuring the PSU Adoption and the Consent Adoption of Open Banking services and the intensity of their usage is critical in order to assess the impact of the OBIE Standards to the ecosystem as per the CMA Order.
• Measuring other aspects of the AIS and PIS services such as overall Payment Adoption by payment type, 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. This may include the following:

• apply forecasting methods to predict expected volumes and user growth in order to perform capacity planning, provide input to PAY UK for the underlying payment systems, and ensure sufficient support services are in place
• produce enhancements on the Standards in relation to certain key propositions
• share useful information and insight with the whole ecosystem using consolidated data dashboards
• collect multiple sources of data to ensure data validation and consistency of all reported MI
• use as a reference for the evaluation of the impact of the Open Banking Standards to the UK ecosystem as per the CMA Order.     

5. The importance and value of ‘Profiling the Ecosystem’

The Open Banking ecosystem is rapidly growing in both volumes of traffic and complexity.  Multiple participants are required to provide a single service to the end-user.  Under these circumstances, a view of the overall ecosystem behaviour is vital to assure the quality of service.  In addition to the rapidly growing complexity, overall traffic volumes are predicted to grow exponentially through 2020 and beyond.  The graphs below show the current volume projections (as of April 2020).

Having information from all participants enhances the level of support and value-add services Open Banking is able to provide to participants.

Benefits for TPPs

• Volume projections and developing call patterns allow OBIE to advise participants about their own test and roll-out plans.
• Regular and frequent reporting from TPPs and ASPSPs allows OBIE to identify and analyse on potential unplanned downtime issues.  This is important because, on several occasions, when TPPs experience service interruptions, it is not always clear where the issue lies, and OBIE can help identify this via providing ‘live’ dashboards 
• Quality of service can be monitored more effectively 
• Other potential issues can be more promptly identified, by detecting trends before actual incidents occur
• The optional granularity of reporting permits identification of daily or weekly peaks, that could impact upon the system
• Analysis of call patterns across participants would allow OBIE to advise on participant job scheduling
• OBIE endpoint monitoring of ASPSP endpoints can be correlated with combined participant reporting to provide further visibility of overall ecosystem behaviour
• Trend analysis performed by OBIE and shared with TPPs to forecast demand and build their new business cases
• Automated reporting via enhanced data submission mechanism makes reporting simpler and easier

Benefits for ASPSPs

• Trend analysis, daily profiling and volume forecasting allows ASPSPs to perform better capacity planning, and plan maintenance and upgrades
• Automated reporting reduces the operational overheads for compiling and submitting the MI Reporting to OBIE.
• Consolidated and reconciled MI allows ASPSPs to prove the reliability of their system and identify whether service issues are their own or related to TPPs
• Ecosystem insight may allow ASPSPs to identify services high on demand and consider offering improved enhanced services to TPPs. 
• Consolidated MI Data can assist ASPSPs to assess their performance against the competition and measure their market share and adoption of Open Banking services to PSUs. 

6. High-Level requirements

The high-level requirements for this proposition as split into 2 groups:

6.1 Enhanced MI Data Submission Mechanism (ASPSPs & TPPs)

Note: The detailed requirements for the Enhanced MI Data Submission Mechanism can be found in A2(c)(ii) Enhanced MI Data Submission Mechanism Solution Design – Final

The following high level requirements are related to the enhanced MI Data Submission mechanism and are relevant for both ASPSPs and TPPs.

• Reporting Mechanism: OBIE will be exploring the following options:
  • Fully Automated – API Based: Mechanism fully automated using API based processes over secure channels with endpoints called by participants (ASPSPs and TPPs) to submit the data directly to OBIE. The data will also be loaded automatically to OBIE’s databases, consolidated and can be used to feed directly into predefined dashboards and reporting tables and graphs.
    • Pros: Requires less/no operational overheads, can support real-time (or near-real-time) reporting by participants, is secure and robust, can support automated data validation, is future proof
    • Cons: Requires implementation by OBIE and participants (ASPSPs and TPPs) of API endpoints, requires technical resources to keep run and support, may not be widely adopted especially by smaller participants due to the cost of implementing and running, higher cost.
  • Other Reporting Mechanism Options: OBIE may also consider alternative options during the consultation period of the solution design specification. An initial set of proposed options can be found in the paper Design Options – Data Transfer Options

Note: Based on the received feedback, OBIE will be proposing a MI Data Submission design using Secure FTP (SFTP) as the delivery mechanism.

• Reporting Data Format/Schema:  A reporting data schema already exists for the ASPSPs MI Reporting and a new schema will be produced as part of the TPP MI Reporting Specification to allow data reporting using the Enhanced MI Data Submission mechanism for data exchange.
• Use of Gateway Data Logs: Alternatively to using a data schema for all MI Reporting requirements, OBIE will also be looking to provide the capability of being able to receive redacted data logs directly from the participants’ gateways. This will reduce the workload of formatting the data as per the appropriate data schema before submitting to OBIE, making reporting simpler and easier. This approach may not be relevant to all required data however it is able to simplify certain groups of data required in high frequency, such as performance and availability data, volumetrics etc.  
• Reporting Frequency: Reporting frequency will depend on the capabilities offered by the reporting mechanism (e.g. API vs SFTP vs other methods) and can vary between real-time and other reporting periods (e.g. monthly, fortnightly, weekly or daily) depending on the abilities of participants, the types of data to be reported (performance/availability, volumetric, authentication efficacy, PSU & Consent adoption, payment adoption etc.) and the use of the data by OBIE. This will be discussed and agreed with participants.
• Data Quality: OBIE will be encoding the endpoints, the TTP/TSP/ASPSP brand lists and other appropriate data in order to ensure high quality of reported data. This is in alignment with the existing MI Reporting Specification for ASPSPs. OBIE will also be looking to introduce data validation rules (within the MI Specifications and/or the reporting mechanism, where applicable), to ensure further data quality.

6.2 TPP MI Reporting Data (TPPs only)

The TPP MI Reporting Data high level requirements are shown below:

• Categories: TPP MI Reporting will be split into 2 categories:
  1. Generic (Core): MI which is required by all participant TPPs 
  2. Service Specific: MI which is related specifically to the type of TPP service offered (e.g. for PISPs, AISPs, CBPIIs or even TSPs) and may be lower priority/nice to have or reported on ad-hoc basis, as and when required for analysis of specific issues. This MI is for future consideration and will not be included in the initial version of the TPP MI Specification.
• Generic (Core) MI will include the following types of reporting data elements:
  • Performance data: This data set will include measurements of the average response times of the various API endpoints and also the end-to-end service timings as experienced by TPPs and their PSUs.
  • Volumetric data: This data set will include measurements of the volumes of API endpoints calls including successes, failures, rejections, no-authorisations etc. TPPs will be reporting which ASPSPs those endpoints are made to, so that will be able to reconcile volumes against volumes reported from the ASPSPs.
  • Auth Efficacy data (Drop-out rates): This data set will include measurements similar to those reported by ASPSPs, including authentication success and failures per initiating channel (web or mobile), additional user interaction failures etc. In general, this is one of the sources for measuring the user drop-out rates per TPP and per ASPSP.
  • PSU & Consent Adoption data: This data set will include measurements similar to the ones recently introduced to the MI for ASPSPs, further to the proposal from the OFT. It includes a new and cumulative number of PSUs per service split by Retail and SME and also the number of consents (long and short term) to measure the intensity of the service adoption.

• Reporting Granularity:  For some of the data elements such as performance and volumetrics, OBIE is looking to introduce hourly reporting granularity instead of daily (which is what is used by ASPSPs split between core and non-core business hours). This will allow OBIE to produce intra-day profiling of the usage of Open Banking APIs for the different services, per TPP and per ASPSP. Obviously, if real-time reporting is introduced, this granularity may be even finer.
• TPP/TSP/ASPSP level: OBIE will be introducing granularity of both reporting TPP and TSP at the endpoint level and also at the ASPSP level.
• Free-format field: OBIE is considering adding free format text entries in the reporting fields for the opportunity of TPPs raising specific issues or providing comments in free text format. This data element will be optional.
• Data Sharing/Consuming: OBIE will be using the data internally for data analysis, insight and forecasting. Moreover, OBIE will be able to share with each TPP the historical data of their own submissions. However, OBIE will be consolidating and anonymising all the data if any reports based on this are to be shared with other TPPs and the wider ecosystem. OBIE may request permission from the TPPs if data is to be used in a different manner.
• Alignment to CEF Framework: OBIE will also be looking to receive the TPP MI Reporting data labelled in alignment to the Consumer Evaluation Framework especially in relation to the defined outcome area and the directly related propositions.
• Service Specific MI will include the following types of reporting data elements:
  • PISP Only:
    • Payments Adoption data: This data set specific for PISPs, will include payment initiation related data per payment type including the number of FPS, Bacs, CHAPS, SOs, and international payments.
    • Other: Payment Status, Payment SCA Exemptions, Payment Refunds 
  • AISP Only: Revocation Notifications from ASPSPs, Corporate Account Access, 90-Days Re-authentication

Note: Service Specific MI is for future consideration and will not be included in the initial version of the TPP MI Specification. It is mentioned here for completeness. 

7. 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. 

Thus, while there is a clear regulatory requirement of the Order for the Providers to allow the OBIE Trustee to monitor their compliance, there is no requirement for the Consumers of the API Services, i.e. the TPPs. However, receiving data from TPPs would assist the OBIE Trustee not only in the task of monitoring the compliance of the Order, but also the effectiveness of the CMA Order to the ecosystem, its competitiveness and the positive impact to the business and consumer PSUs. 

In conclusion, TPP MI Reporting is voluntary for TPPs but quite important for OBIE to be able to improve the services offered to the ecosystem.  

8. Considerations

8.1 Constraints

• The data elements to be reported by TPPs are constrained to the information held by TPPs or provided back to TPPs by the ASPSPs. Thus, TPPs are not able to provide the same set of MI data as provided to OBIE by ASPSPs
• Some smaller TPPs may face resource constraints in being able to provide the MI Reporting to OBIE
• Some TPPs may have considerations in relation to sharing data which may be classified as ‘business sensitive’

8.2 Assumptions

• Sufficient number of TPPs and/or TPP data will be provided OBIE so that there is sufficient information to represent the ecosystem. 
• Sufficient number of ASPSPs and TPPs will be using the enhanced reporting mechanism and its capabilities for frequent (or near-real-time reporting) to allow OBIE to provide ‘live’ dashboards. 

8.3 Dependencies

• OBIE will have mechanisms and the operational processes in place to receive the MI Reporting from participants and to process the submitted data.

8.4 Reference documents

• A2(c)(ii) Logical Data Dictionary for TPP MI Reporting Specification – RC1
• A2(c)(ii) Enhanced MI Data Submission Mechanism Solution Design – Final
• OBIE v3.1.6 of the API Standards
• OBIE v3.1.5 of the MI Specification
• Design Options – Data Transfer Options

9. Appendix

9.1 Detailed Requirements

Note: For the detailed requirements of the Enhanced MI Data Submission Mechanism (ASPSPs & TPPs), please refer to A2(c)(ii) Enhanced MI Data Submission Mechanism Solution Design – Final

The following MoSCoW classification has been used for the requirements:

• Must – This is essential to be delivered in the TPP MI Reporting
• Should – This is non-essential but highly desirable to be delivered in the TPP MI Reporting
• Could – This will be nice to have it delivered in the TPP MI Reporting
• Would – This presents lower business value compared to the other types of data fields  

9.1.1 Generic (Core) MI

9.1.1.1 Overall Performance

Submission Frequency: High​

The following data table is required to be submitted to OBIE in a higher than normal frequency. This could be daily or several times during each day. The actual value will be agreed between OBIE and participating TPPs.

TAB: 1A. Overall Performance

9.1.1.2 End-to-End Response Times

Submission Frequency: Normal

The following data table is required to be submitted to OBIE at normal frequency. This is currently considered to be on a monthly basis. The actual value will be agreed between OBIE and participating TPPs.

TAB: 1B. End-to-End Response Times

9.1.1.3 Auth Efficacy

Submission Frequency: Normal

The following data table is required to be submitted to OBIE at normal frequency. This is currently considered to be on a monthly basis. The actual value will be agreed between OBIE and participating TPPs.

TAB: 2. Auth Efficacy

9.1.1.4 PSU and Consent Adoption

Submission Frequency: Normal

The following data table is required to be submitted to OBIE at normal frequency. This is currently considered to be on a monthly basis. The actual value will be agreed between OBIE and participating TPPs.

TAB: 3. PSU and Consent Adoption

9.1.2 Service Specific MI (FUTURE CONSIDERATION)

Note: Service Specific MI is for future consideration and will not be included in the initial version of the TPP MI Specification. It is mentioned here for completeness. 

9.1.2.1 PISP Only

9.1.2.1.1 Payments Adoption

9.1.2.1.2 Other

TAB: 5. PISP Only Optional/Adhoc MI 

9.1.2.2 AISP Only

TAB: 6. AISP Only Optional/Adhoc MI

9.2 Measuring End-to-End Response times

Using OBIE Standards, a service request from a TPP, for example, a payment initiation requested by a PISP, requires a number of API endpoint calls in order to be completed. While reporting at the endpoint level has undoubted business value, OBIE would also like to receive measurements of the end-to-end journeys for PIS, AIS and CBPII as they will be experienced by the TPPs end users. The diagram below shows the various steps and the endpoint calls for initiating a payment, which is in the most complex case between AIS, PIS and CBPII.

In the web sequence diagram below, we have split the total end-to-end time T_tot  into a number of different time period steps, namely T₁, T₂, T₃, T₄, T₅, and T₆. This is to provide granularity but also flexibility for a reporting TPP to have the option to include or exclude the PSU interaction time from the total end-to-end journey or the case where CoF was requested as part of the journey. Thus:

• T_tot = T₁ + T₂ + T₄ + T₆ , (excluding the time of PSU interaction with the ASPSP for authenticating and other actions such as selecting a debit account, supplementary information etc) and no CoF
• T_tot = T₁ + T₂ + T₃ + T₄ + T₆ , (including the time of PSU interaction with the ASPSP for authenticating and other actions such as selecting a debit account, supplementary information etc) and no CoF
• T_tot = T₁ + T₂ + T₃ + T₄ + T₅+ T₆ , (including the time of PSU interaction with the ASPSP for authenticating and other actions such as selecting a debit account, supplementary information etc) and performing CoF

TPPs may be able to report either T_tot = T₁ + T₂ + T₄ + T₆ and report T₃ and T₅ separately, or report on each time segment separately and allow OBIE to consolidate the resulting total end-to-end time. This will be discussed and agreed with TPPs.

Please note that the above timing segments include the TPP’s internal overhead and processing time taken during the end-to-end journey. This would be different from the reporting endpoint response times which they solely focus on the time period from sending the API endpoint call till receiving all the information included in the API endpoint response.  

9.3 Challenges of measuring “perceived” OBIE API unavailability by TPPs

Measuring perceived availability of the OBIE API Services offered by the ASPSPs, has several challenges and can only be achieved under very specific circumstances are explained below.

The challenge for TPPs measuring API service availability is originated from the fact that TPPs have no real visibility of when the actual service is in downtime or in uptime. TPPs can only report the experience they perceive from the outcome of an endpoint call. Thus, if an endpoint is not responded within a certain period of time (e.g. 15 sec) then a TPP will timeout on waiting for its response. The TPP may retry this a few more times and again timeout on waiting for the response, however this activity will not continue indefinitely and the TPP will finally abort trying to send the endpoint message. The TPP at a later point in time will try to make another endpoint call, and this may be successful and receive a response. However, the ASPSP service may have become available much earlier than the point in time the TPP will attempt to make another endpoint call, and thus, if the TPP has marked the perceived unavailability as the time period between the previously failed endpoint call until the next successful endpoint, then then accuracy of the perceived availability will heavily depend of the frequency of making the endpoint calls.

For example, if a TPP is making a group of endpoint calls twice a day (morning & evening with 12 hours interval) and the morning endpoint calls fail, while the afternoon calls are successful, the TPP will be reporting a “perceived unavailability” of 12 hours, while the true unavailability may have been only a few minutes in the morning during first group of endpoint calls. This is illustrated in the diagram below, where the assumption is that the TPP will start its perceived unavailability after 2 failed endpoints calls, and will stop this at the point of the first successful endpoint call, 12 hours later.

Similar issue exists if the TPP marks as a perceived unavailability only the cases where the endpoints fail during the reporting window. In the example shown below, the TPP times out within 15 seconds for each of the 2 endpoint calls and then stops trying to make any more calls until 12 hours later. In this case, the TPPs perceived availability would be 30 seconds, while the true unavailability of the ASPSP would be much longer, e.g. 2 hours.    

As stated earlier, the accuracy of the “perceived unavailability” would heavily depend on the spreading of the endpoint calls during the reporting window. However, if OBIE collects “perceived unavailability” data from multiple TPPs, we may be able to have enough data entries to profile the unavailability with enough characteristic information, especially for the PIS and CBPII services which are depending on the PSU payments usage patterns during the day and do not present the “batch” behaviours experienced by AISPs. This issue will be discussed with TPPs during early consultation and assess the feasibility of this approach.

Moreover, OBIE is looking to request TPPs to provide redacted  data sets of logging information from their own monitoring of the service availability especially during reporting periods where higher than normal error rates (time outs or 5xx errors) take place. 

Both the above points are illustrated in the diagram below. If OBIE collects several data from multiple TPPs spread across the reporting period, then OBIE may have enough perceived unavailability periods to reflect the real unavailability period sufficiently. Moreover, if OBIE collects data logs from TPPs with endpoint failures with timestamps, OBIE may be able to also calculate perceived  unavailability including any gaps between the TPPs’ endpoint calls and reflect unavailability with even more accuracy.

10. A2 (c)(ii) Roadmap item Definition

10.1 Objective

The Trustee and the ecosystem need to be able to access and use timely information about the APIs provided by ASPSPs.

10.2 Description & Work Activity

OBIE Preparatory Activity: From beginning of April 2020 until the end of October 2020.

• Draft Standards: an OBIE Discovery phase to include design of improved MI provision and reporting, with co-ordination of development with other regulators, to ensure consistent definitions and reporting requirements, commenced March 2020, to complete by end of June 2020.

Industry Consultation (including CMA9 Participation): for two months, to start at the end of the Crisis Impact Period.

Final Standards: to be published three months after the end of the Crisis Impact Period.

Voluntary TPP Implementation: to commence in November 2020.

• TPP-facing OB Standard to be implemented by TPPs (on a voluntary basis, supported by ICO Code if possible and if appropriate).

CMA9 Implementation:

• Mandatory CMA9 implementation of the OB Standard to be completed nine months after the end of the Crisis Impact Period.

Ongoing Monitoring:

• Ongoing monitoring and review of the MI, which may include input from the Customer Evaluation Framework (A2)(c)(iii), to start nine months after the end of the Crisis Impact Period.

11. Version control