Core Market Data Improvement
MOSL’s 2021-24 Business Plan outlines its Data Insight programme to address the causes of poor-quality data and develop tools to access, analyse, cleanse, and enrich this data. As part of this, MOSL has developed a data cleanse plan for core market data. This plan sets out how MOSL will work with data owners to improve the quality and completeness of core customer and asset data, incentivise ongoing maintenance and high standards for data quality, and to provide a platform for enriching core customer data.
Scope and objectives
The data cleanse will initially focus on improving the quality of ‘core market data’, which is defined as the data required to fulfil key market obligations or functions, including: market entry; metering; asset maintenance and customer switching.
The objectives of the market data cleanse are the following:
Retailers to be able to efficiently find, onboard, tender or switch a customers or customer supply points using Central Market Operating System (CMOS) data
- Trading parties to be able to efficiently find a meter, take a meter read, and successfully submit that meter read into CMOS.
The data items included within the scope of the market data cleanse are shown in the table below:
The data cleanse plan is the result of extensive analysis of central market data, input from subject matter experts across the market and an industry consultation. It should be read in conjunction with the following publications:
- Request for Information (RFI): Core Market Data Cleanse: This contains in-depth analysis of data quality issues and findings from subject matter experts, along with detailed consideration of the underlying causes of data quality issues and options for resolving them
- Summary of responses to the Core Market Data Cleanse RFI: This summarises the findings from the RFI, including details on the impact of poor quality data, the benefits associated with improving core data quality and views on the next steps for resolving data quality issues.
- Incentivise core data quality: Data quality is currently not measured and there are no formal incentives for data owners to improve or maintain data quality. We will incentivise data owners to improve data quality by providing a market data quality dashboard, to capture and monitor data quality and trading party performance, highlight issues, and facilitate peer comparison across the market. This will be used as the basis for initiating Additional Performance Indicators (APIs) for certain priority data items in the first instance, namely UPRN, VOA and GIS coordinates. We will engage with trading parties to understand the challenges they face in resolving data quality issues in a timely manner. Performance rectification tools will be used at a later date where there has been little or no improvement
- Data sharing: There is currently no mechanism for end-users, such as retailers and Meter Reading Service Providers (MRSPs), to update data in the central system, which means that better quality data is often held outside of CMOS and unavailable to other potential users. We will look to establish a process for data users to share data using a pilot data sharing exercise before consulting with the market on the steps towards a market-wide data sharing programme. This also aligns to a data sharing workstream within the Strategic Metering Review
- Options for user-verification: There is currently no mechanism for capturing the accuracy of data, which also means accuracy cannot be monitored or incentivised. We will investigate the options for obtaining end-user verification of the accuracy of data and incorporating this information into the central system
- Meter manufacturer and CMOS validation: Inaccurate and inconsistent meter manufacturer details and inappropriate volume validations are stopping legitimate reads from being successfully submitted into CMOS. This impacts the quality of consumption data in CMOS, but also causes additional costs to retailers due to timely and resource intensive investigations and rework. We will develop a cost-benefit analysis of potential solutions before consulting with trading parties and raising potential code changes
- Purpose of customer name data: The purpose and value of Customer Name and Customer Banner Name data items is unclear, leading to inconsistent maintenance by trading parties and potentially conflicting uses. The maintenance of this data may be unnecessary or could be driving unnecessary costs. We will identify the uses of customer name data and consider whether changes to CMOS or the market codes (or both) are needed to render these data items fit for purpose.
The plan covers the 12 months between March 2021 and February 2022. The first three to six months will be focused on sharing further information with the market on the problem areas and highlighting data issues that have been uncovered as part of our analysis. This will be done by using the data quality dashboards and will form the basis for peer comparison. As part of this, we will engage directly with trading parties where we have observed a high level of data issues to better understand what activities are required to resolve issues and the expected time and cost.
Following this ‘bedding-in’ period, we will consider the use of performance rectification tools based on Additional Performance Indicators (API) to be agreed with the MPC and incorporated into MOSL’s Market Performance Operating Plan (MPOP) for 2021/22.
We will start to consider options for data users to share data directly with the market and incorporating end-user verification to capture the accuracy of data items. In addition, we will begin a review of the codes and CMOS to improve the use of meter manufacturer data in CMOS validation and clarify the purpose of customer name data.
Data quality dashboards
To support this activity, data quality dashboards have been published on the MOSL Portal. The dashboards highlight measurable data quality (i.e. completeness and validity) and data issues of core data items. The data issues cover specific indicators of inaccuracy or concern for each data item. For example, a UPRN that has a different postcode to the premises it has been assigned or a GIS coordinate that is exactly on the postcode centre.