MHHS Programme Changes required to Central Switching Service
Summary
This change has been raised by the Market-wide Half-Hourly Settlement (MHHS) Programme to implement the necessary Retail Energy Code (REC) changes in relation to a new Data Communications Company User Role for the Meter Data Retrieval service (MDR). The new role required by the MHHS Target Operating Model will be established by the Smart Energy Code Modification Proposal, SEC MP162. This REC change will provide the new system interfaces required for sharing the MDR’s Registration Data.
Latest update and next planned activity
Date of latest update
Latest Update
22/09/25 - This Change Proposal has been implemented as part of the MHHS M8 22 September 2025 REC Release.
Impacts Overview
Impacted Consumers
Electricity
Domestic
Non-Domestic
Impacted REC Parties and Market Participants
Distribution Network Operator
DCC
Impacted REC Documents
Schedule 1 - Interpretations and Definitions
Schedule 25 - Central Switching Service
Schedule 14 - Metering Operations
Schedule 23 - Registration Services
Schedule 26 - Switching Service Management
Impacted REC Services
Central Switching Service (CSS)
Other Industry Codes impacted
Balancing and Settlement Code (BSC)
Smart Energy Code (SEC)
Priority and rationale
Priority last updated on 29 May 2026
Solution development
Problem Statement
The MHHS Target Operating Model requires that the appointment data of the Smart Meter Data Retriever (SMDR) is available to the Smart Meter Data Service Provider (SMDSP), so that the SMDSP can provide SMDRs with access to the Smart Meters at Metering Points they are registered to. Currently the new SMDR role and appointment data do not exist in, nor can they be made available from, CSS as this is a new industry operating model.
Proposed solution summary
- As the SMDSP, I want to be able to validate that an SMDR is registered so that I can provide them with access to the Metering Points to which they are registered.
- As a SMDR, I want to be able to access the Metering Points I am registered to so that I can collect settlement data from those meters
- As the CSS Provider, I want the CSS to be able to receive notifications from the Registration Service on the appointment/de-appointment of an SMDR so that I can send the appointment data to the SMDSP. As the CSS Provider, I want the CSS to be able to provide SMDR appointment data to the SMDSP.
No documents available.
Change Plan
Analysis and Requirements Gathering started
Completed
Start:
29 Apr 2022Due:
05 May 2022Completion:
05 May 2022Present Updated Change Proposal Plan to REC Change Panel
Completed
Start:
05 May 2022Due:
21 Jun 2022Completion:
21 Jun 2022Service Provider Impact Assessment initiated
Completed
Start:
21 Jun 2022Due:
11 Jul 2022Completion:
05 Jul 2022Service Provider Impact Assessment completed
Completed
Start:
11 Jul 2022Due:
15 Aug 2022Completion:
10 Aug 2022Present extended Change Proposal Plan to Change Panel
Completed
Start:
15 Aug 2022Due:
06 Sep 2022Completion:
06 Sep 2022Requirement refinement and validation of Detailed Impact Assessment
Completed
Start:
06 Sep 2022Due:
27 Sep 2022Completion:
27 Sep 2022Provide extended Change Proposal Plan to Change Panel
Completed
Start:
28 Oct 2022Due:
31 Oct 2022Completion:
25 Oct 2022Preliminary Change Report Issued
Completed
Start:
27 Sep 2022Due:
28 Oct 2022Completion:
27 Oct 2022Responsible Committee Review of the Preliminary Change Report
Completed
Start:
31 Oct 2022Due:
01 Nov 2022Completion:
01 Nov 2022Consultation started
Completed
Start:
01 Nov 2022Due:
04 Nov 2022Completion:
03 Nov 2022Consultation ended
Completed
Start:
04 Nov 2022Due:
25 Nov 2022Completion:
25 Nov 2022Final Change Report issued
Completed
Start:
25 Nov 2022Due:
09 Dec 2022Completion:
09 Dec 2022Responsible Committee ex-committee decision
Completed
Start:
09 Dec 2022Due:
13 Dec 2022Completion:
13 Dec 2022Authority Determination
Completed
Start:
13 Dec 2022Due:
02 Feb 2023Completion:
02 Feb 2023Original submission
Change details
Ann Perry - MHHS Programme
29 Apr 2022
Change details
MHHS Programme Changes required to Central Switching Service
Ofgem’s Electricity Settlement Reform Significant Code Review (SCR) has concluded that settling all electricity consumers on a half-hourly basis would bring net benefits of up to £4.5bn by 2045. Ofgem has therefore concluded that Suppliers should be mandated to settle their electricity customers on a half-hourly basis.
Delivering the full solution for Market-wide Half-Hourly Settlement (MHHS) will require a new Smart Data Service which includes a Meter Data Retrieval (MDR) service which will retrieve data directly from smart meters as a new Data Communications Company (DCC) User Role as set out in Smart Energy Code (SEC) Modification Proposal 162 (MP162) ‘SEC changes required to deliver MHHS’ https://smartenergycodecompany.co.uk/modifications/sec-changes-required-to-deliver-mhhs/
SEC MP162 assumes that MDR registration data will be sent from the Central Switching Service (CSS) to the DCC Systems to enable the DCC to perform access control to smart meters for the new MDR User Role, to only allow registered MDR parties to successfully collect data from Smart Meters that they are registered against.
To assess and implement the changes to CSS necessary for the sourcing of MDR registration data (from the Meter Point Administration Service, MPAS), the reference of that data within MPAS and the subsequent sending of this data firstly to the CSS to record and store and then subsequently forward onto the DCC Systems, a Change Proposal is required.
This change is using the same service and system design principle as already exist for other Industry Registration data and DCCs use of this data for performing Access Control checks e.g. Supplier, Network Operator and registered Supplier Agent registrations against each Metering Point (MPAN or MPRN).
There will be a wider set of Retail Energy Code (REC) changes being progressed under the MHHS Programme that will cover all the necessary updates to deliver the MHHS Programme. This REC Change Proposal (CP) has been raised to progress the specific CSS system changes related to the MDR service. An impact assessment is required as early as possible, and the changes progressed and implemented in appropriate timescales, to minimise the risk of CSS changes impacting the critical path of the MHHS Programme. This was the same approach taken in raising MP162 to the SEC in advance of all of the SEC Code Changes being drafted.
Delivering the full solution for Market-wide Half-Hourly Settlement (MHHS) will require a new Smart Data Service which includes a Meter Data Retrieval (MDR) service which will retrieve data directly from smart meters as a new Data Communications Company (DCC) User Role as set out in Smart Energy Code (SEC) Modification Proposal 162 (MP162) ‘SEC changes required to deliver MHHS’ https://smartenergycodecompany.co.uk/modifications/sec-changes-required-to-deliver-mhhs/
SEC MP162 assumes that MDR registration data will be sent from the Central Switching Service (CSS) to the DCC Systems to enable the DCC to perform access control to smart meters for the new MDR User Role, to only allow registered MDR parties to successfully collect data from Smart Meters that they are registered against.
To assess and implement the changes to CSS necessary for the sourcing of MDR registration data (from the Meter Point Administration Service, MPAS), the reference of that data within MPAS and the subsequent sending of this data firstly to the CSS to record and store and then subsequently forward onto the DCC Systems, a Change Proposal is required.
This change is using the same service and system design principle as already exist for other Industry Registration data and DCCs use of this data for performing Access Control checks e.g. Supplier, Network Operator and registered Supplier Agent registrations against each Metering Point (MPAN or MPRN).
There will be a wider set of Retail Energy Code (REC) changes being progressed under the MHHS Programme that will cover all the necessary updates to deliver the MHHS Programme. This REC Change Proposal (CP) has been raised to progress the specific CSS system changes related to the MDR service. An impact assessment is required as early as possible, and the changes progressed and implemented in appropriate timescales, to minimise the risk of CSS changes impacting the critical path of the MHHS Programme. This was the same approach taken in raising MP162 to the SEC in advance of all of the SEC Code Changes being drafted.
The MHHS Target Operating Model will not work without making this change, therefore it is essential that this change is made and implemented within the necessary timescales of the MHHS Programme.
If DCC does not receive Industry Registration Data in relation to MDR parties, then DCC cannot validate any Service Requests received from MDR Users to request data to be collected from Smart Meters. This would not be in line with the existing DCC and wider Smart Metering Security design principles and introduce addition security risks.
DCC require design certainty in order to progress with its Design, Built and Test preparation and implementation activities. Testing with the new MDR parties is a key stage within the implementation phase and therefore an E2E design and co-ordinated and aligned implementation approach/plan is required in this area across industry participants in order to ensure the successful delivery of the MHHS Target Operating Model.
Industry Registration System changes, CSS and DCC Systems changes all need to be made in time to allow PIT, SIT and UIT activities to be completed successfully in advance of the intended Go-live for the DCCs support of the MHHS Service (targeted for the Feb 2024 SEC Release as per the discussions of the MP162 Working Group). In that case the MHHS Programme assumption is that the CSS changes would need to be delivered in the June ’23 REC Release but we would also like to Impact Assess the option of implementation into the November ’23 REC Release so all options can be considered in decision-making.
These assumptions need to be tested through more detailed planning and taking into account the Impact Assessment responses.
This change is not required in advance of the Switching Programme Go-Live date. It needs to be assessed and considered for implementation in a post-Switching Go-Live REC/CSS release that aligns with the MHHS Programme timetable, including testing and importantly testing with DSP and MPAS.
If DCC does not receive Industry Registration Data in relation to MDR parties, then DCC cannot validate any Service Requests received from MDR Users to request data to be collected from Smart Meters. This would not be in line with the existing DCC and wider Smart Metering Security design principles and introduce addition security risks.
DCC require design certainty in order to progress with its Design, Built and Test preparation and implementation activities. Testing with the new MDR parties is a key stage within the implementation phase and therefore an E2E design and co-ordinated and aligned implementation approach/plan is required in this area across industry participants in order to ensure the successful delivery of the MHHS Target Operating Model.
Industry Registration System changes, CSS and DCC Systems changes all need to be made in time to allow PIT, SIT and UIT activities to be completed successfully in advance of the intended Go-live for the DCCs support of the MHHS Service (targeted for the Feb 2024 SEC Release as per the discussions of the MP162 Working Group). In that case the MHHS Programme assumption is that the CSS changes would need to be delivered in the June ’23 REC Release but we would also like to Impact Assess the option of implementation into the November ’23 REC Release so all options can be considered in decision-making.
These assumptions need to be tested through more detailed planning and taking into account the Impact Assessment responses.
This change is not required in advance of the Switching Programme Go-Live date. It needs to be assessed and considered for implementation in a post-Switching Go-Live REC/CSS release that aligns with the MHHS Programme timetable, including testing and importantly testing with DSP and MPAS.
The implementation of the changes to the CSS system and service to reflect the MHHS Programme design in time to meet the MHHS Programme implementation timetable and plan as per the Impact section above. The current programme assumption is that this is required in the June 2023 REC Release or earlier to meet the timescales for testing but we would also like to Impact Assess the option of implementation into the November ’23 REC Release so all options can be considered in decision-making. These assumptions need to be tested through more detailed planning and taking into account the Impact Assessment responses.
The MDR service is only present within the Smart Segment and does not exist within either the Advanced or Unmetered Segments under the MHHS Target Operating Model. The business process diagram for change of service which includes the relevant exchanges has been published as part of Tranche 2 of the Design artefacts from the MHHS Programme, which is attached as a supporting document.
The relevant Business Process diagram is MHHSP-BP003-Change of Service - Data Service which is attached as a supporting document.:
The current assumptions on the design solution are:
• MDR ID will be available, for reference/validation purposes, as part of published ISD
• MDR will be identified by an MDR ID data item that will be registered to an MPAN.
• Only one MDR may be appointed for an MPAN for any single settlement day.
• Registration Service will Notify CSS of MDR Appointment Date as and when a new MDR party is appointed/ registered to an MPAN
• Registration Service will Notify CSS of MDR De-Appointment Date as and when an existing MDR party is de-appointed from an MPAN
• Registration Service will Notify CSS of MDR Appointment Date
• IA should consider how these transactions are best choreographed, taking into account any existing process constraints within CSS/DCC (i.e. two separate interactions vs. appointment of new MDR simply end dates the old)
• Validation of the MDR ID (including against Industry Standing Data) will be undertaken by the Registration System before being sent to the CSS.
• However, the IA should consider what additional validation, if any, should be undertaken by CSS. The DCC does not validate registration data today and there are no proposals under MP162 to undertake any additional validation.
• IA should consider and agree on how errors are managed – (i.e. managed by each sending/receiving party vs. ‘packaged’ and always passed back to Registration)
• The interfaces to and from CSS in the process diagram above will be via switching web-hook interfaces and not via the DTN or new Data Integration Platform.
• Following the go live of the CSS, DCC will receive registration data from a CSS interface to validate access control for the Registered Supplier Agent (RSA), this same interface will be used to validate the MDR.
It is noted that the MRD IDs will be introduced into operational Industry Standing Data once MDR parties are qualified in advance of migration, therefore MDR IDs will initially be used in testing from test data.
If there are further clarifications or alternative proposals for solutions, please provide feedback through the change process (e.g. through Impact Assessment) as these can be raised for consideration into the MHHS Programme.
The relevant Business Process diagram is MHHSP-BP003-Change of Service - Data Service which is attached as a supporting document.:
The current assumptions on the design solution are:
• MDR ID will be available, for reference/validation purposes, as part of published ISD
• MDR will be identified by an MDR ID data item that will be registered to an MPAN.
• Only one MDR may be appointed for an MPAN for any single settlement day.
• Registration Service will Notify CSS of MDR Appointment Date as and when a new MDR party is appointed/ registered to an MPAN
• Registration Service will Notify CSS of MDR De-Appointment Date as and when an existing MDR party is de-appointed from an MPAN
• Registration Service will Notify CSS of MDR Appointment Date
• IA should consider how these transactions are best choreographed, taking into account any existing process constraints within CSS/DCC (i.e. two separate interactions vs. appointment of new MDR simply end dates the old)
• Validation of the MDR ID (including against Industry Standing Data) will be undertaken by the Registration System before being sent to the CSS.
• However, the IA should consider what additional validation, if any, should be undertaken by CSS. The DCC does not validate registration data today and there are no proposals under MP162 to undertake any additional validation.
• IA should consider and agree on how errors are managed – (i.e. managed by each sending/receiving party vs. ‘packaged’ and always passed back to Registration)
• The interfaces to and from CSS in the process diagram above will be via switching web-hook interfaces and not via the DTN or new Data Integration Platform.
• Following the go live of the CSS, DCC will receive registration data from a CSS interface to validate access control for the Registered Supplier Agent (RSA), this same interface will be used to validate the MDR.
It is noted that the MRD IDs will be introduced into operational Industry Standing Data once MDR parties are qualified in advance of migration, therefore MDR IDs will initially be used in testing from test data.
If there are further clarifications or alternative proposals for solutions, please provide feedback through the change process (e.g. through Impact Assessment) as these can be raised for consideration into the MHHS Programme.
Impacts
Electricity, Domestic Prepayment, Domestic Credit, Microbusiness, Small and Medium Enterprise (SME), Industrial and Commercial (I&C), Other (please specify in the Additional information box below)
Switching experience, Billing accuracy, Trust and confidence, Other (please provide details in Additional information box below)
All electricity smart metered customers
Schedule 1 - Interpretations and Definitions, Schedule 25 - Central Switching Service, Schedule 14 - Metering Operations, Schedule 23 - Registration Services, Schedule 26 - Switching Service Management
-
No details provided
-
No details provided
-
Data Item Catalogue, Market Message Catalogue
This will impact the data specification of the CSS service and will impact the specification of the interfaces:
• from MPAS to CSS for the provision of MDR registration data; and
• from CSS to DSP for the provision of MDR registration data
Alongside the physical interface changes to add MDR related information to the existing interfaces, the solution should also consider where responsibility for any data translation (if required) should sit; whether any existing validation rules require amending or refining; error handling and which party has primary responsibility for resolution at each stage of the transfer.
• from MPAS to CSS for the provision of MDR registration data; and
• from CSS to DSP for the provision of MDR registration data
Alongside the physical interface changes to add MDR related information to the existing interfaces, the solution should also consider where responsibility for any data translation (if required) should sit; whether any existing validation rules require amending or refining; error handling and which party has primary responsibility for resolution at each stage of the transfer.
No details provided
-
Central Switching Service (CSS)
This proposed change to CSS is required on behalf of the MHHS Programme. Any further or consequential changes (e.g. enquiry services) are outside the scope of the MHHS Programme and should be considered separately.
Distribution Network Operators, DCC
The new MDR role as part of SDS within the MHHS Programme Target Operating Model and design.
Balancing and Settlement Code (BSC), Smart Energy Code (SEC)
All other Code Changes will be progressed by the MHHS Programme separately from this Change Proposal.
Yes
No details provided
Priority & timing
Yes
Without urgent status, there is a risk that the CSS changes cannot be made in time to meet the MHHS Programme Implementation Timetable (current assumption that these changes need to be in place in the June 2023 REC Release or earlier, but we would like to Impact Assess implementing these changes in the November 2023 Release as well). This is raised as a top risk within the MHHS Programme.
Once the Impact Assessment has been undertaken, the status of that risk can be reassessed, but until that time, this is very high probability and very high impact.
Once the Impact Assessment has been undertaken, the status of that risk can be reassessed, but until that time, this is very high probability and very high impact.
In accordance with the MHHS Programme Implementation Timetable and plan. DCC require the CSS changes to be made in time to allow PIT, SIT and UIT activities to be completed successfully as set out in the Impact section above. The current programme assumption is that this is required in the June 2023 REC Release or earlier to meet the timescales for testing but we would also like to Impact Assess the option of implementation into the November ’23 REC Release so all options can be considered in decision-making. These assumptions need to be tested through more detailed planning and taking into account the Impact Assessment responses.
No
No details provided
-
Activity
Proposed solution summary changed to As the SMDSP, I want to be able to validate that an SMDR is registered so that I can provide them with access to the Metering Points to which they are registered.As a SMDR, I want to be able to access the Meterin…
Proposed solution summary changed to As the SMDSP, I want to be able to validate that an SMDR is registered so that I can provide them with access to the Metering Points to which they are registered.As a SMDR, I want to be able to access the Metering Points I am registered to so that I can collect settlement data from those metersAs the CSS Provider, I want the CSS to be able to receive notifications from the Registration Service on the appointment/de-appointment of an SMDR so that I can send the appointment data to the SMDSP. As the CSS Provider, I want the CSS to be able to provide SMDR appointment data to the SMDSP..
Show moreImplementation Date has been updated to MHHS Programme Milestone M8 (Code changes delivered).
harriet.truss has been allocated as Lead Analyst.
Orphaned SME: Lead Technical Analyst has been allocated as SME.