ECOES API for Export MPAN Creation at Scale
Date of latest update
Type
Issue
ID
I0228
Change Category
Change Path
Priority
Urgent
No
Latest Update
04/06/2026 - on 02 June 2026, the Technical Expert Panel approved via ex-committee vote to place I0228 on hold, until the outcome of R0321 is known.
Summary
Electricity Suppliers believe there is a significant bottleneck to Export Metering Point creation, which is resulting in them feeling unable to offer Export smart products to a wider audience of Consumer and scale low-carbon technology. The most effective solution is an API within the Electricity Enquiry Service (EES) that allows the Electricity Supplier to request the creation of an Export Metering Point. This could work for both Electricity Suppliers and Distribution Network Operators (DNOs) ensuring that scalable solutions are applied at both sides of the process.
Change Plan
Presented at Change Issues Group
Completed
Start:
Due:
Completion:
06 Mar 2025Status
Status
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Problem Statement
A restriction of 50 Export Metering Points per DNO per day, with no two DNOs operating the bulk request process in the same way, is overly burdensome to Electricity Suppliers and creating a barrier for Consumers getting an Export Metering Point assigned to their Premise. This is ultimately harming the effort the reach Net Zero.
Stages Selection
Stages Selection
SME
SME Role
Lead Technical Analyst
SME Role
Lead Assurance Analyst
SME User
vaishnsharma@deloitte.co.uk
Issue Proposal Form
Change Issues Group paper - presented March 2025
I0228 Change Report (Proposal Plan) V1.0 approved 21.04.26
I0228 Consolidated Information Request Responses V1.0 PUBLIC
I0228 Update to Plan V1.0 on hold, approved 04.06.26
Company Name
-
Review status
Review required
Agile Reporting within CSS
Date of latest update
Type
Change
ID
R0224
Change Path
Priority
Urgent
No
Latest Update
18/03/2026 - An update to plan has been published for consideration at the Technical Expert Panel on 25 March 26.
Summary
As part of the impact assessment process for R0115, it was identified that it is very costly and time consuming to make reporting changes within the CSS architecture. As such, we would like to explore enabling agile reporting within the CSS ecosystem, by creating a functionality that consolidates all necessary data into a single, centralised database.
Impacted REC Documents
Impacted REC Services
Impacted REC Parties and Market Participants
Status
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Problem Statement
Current CSS arrangements mean that REC Changes designed to facilitate access to CSS data are more onerous that they need to be. Current arrangements are costly and have relatively long lead-times. This Issue seeks to explore changing the way that the CSS data can be accessed.
Stages Selection
SME
SME Role
Lead Technical Analyst
SME User
maxime.van-eyseren@capgemini.com
SME Role
Lead Assurance Analyst
SME User
vaishnsharma@deloitte.co.uk
Proposal Form - Agile reporting within CSS
I0224 Change Report (Plan) (Approved) V1.0 21.01.25
Change Proposal Re-Plan Approved
Solution/Business Case report
R0224 update to plan 18.03.26
R0224 update to plan 19 May 2026
Company Name
-
Review status
Review required
ESME ID Update Rejections
Date of latest update
Type
Change
ID
R0222
Change Path
Priority
Urgent
No
Latest Update
22/09/25 - This Change Proposal has been implemented as part of the MHHS M8 22 September 2025 REC Release.
Summary
The Electricity Smart Meter Equipment (ESME) ID is a unique identifier that provides a designation for a Smart Meter. Electricity Retail Data Agent (ERDA) systems were updated as per the requirements in R0033 to not allow for multiple incidences of an individual ESME ID to be registered, and reject the update, even when a second incidence of an ESME ID would be legitimate, for example in the case of a re-use of Metering Asset or a crossed meter. This Issue seeks to resolve this feature of the ESME ID validation while maintain data accuracy.
Impacted Consumers
Status
Implementation Date
MHHS Programme Milestone M8 (Code changes delivered)
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed Solution Document
Document title
R0222 Data Spec DI51544 V1.0
Archive
Off
Problem Statement
ERDA data validation on the ESME ID Data Item in the D0312(MM00256) Market Message is imperfect, and can result in invalid rejections. This occurs when more than one incidence of an ESME ID is passed through individual ERDA system, as it only allows for a single occurrence, even if historic ones have been end-dated. In situations where a Metering Asset has been re-used, thus re-using the ESME ID, a rejection will occur, in an example of an unintended functionality of the validation system.
Stages Selection
SME
SME Role
Lead Technical Analyst
SME User
maxime.van-eyseren@capgemini.com
SME Role
Lead Assurance Analyst
SME User
vaishnsharma@deloitte.co.uk
Issue Proposal Form
I0222 Change Report (Plan) (Approved) V1.0 04.02.25
I0222 Change Report (IA) (Pre-Approval) V1.0 23.04.25
R0222 Change Report (Consultation) V1.0 01.05.25
R0222 Consolidated Consultation Responses V1.0
R0222 Change Report (Post-Vote) V1.0 25.06.25
Company Name
REC Code Manager
Review status
Review required
CSS Change to Allow Prevent of Registration by Market Segment
Date of latest update
Type
Issue
ID
I0194
Change Category
Change Path
Priority
Urgent
No
Latest Update
06/05/2025 - Code Manager presented solution development outcomes to Technical Change Panel on 30/04/2025 and confirmed that the issue has been resolved and will not be progressed further. An operational process will be put in place for the monitoring of Registrations by Market Segment.
Summary
To prevent a Supplier with exemptions in place that were approved, in BSC and REC PAB for Smart and Unmetered, from registering meter points other than those that they are Qualified in.
Change Plan
Change Proposal Plan approved
Completed
Start:
25 Jul 2024Due:
03 Dec 2024Completion:
03 Dec 2024Definition
In Progress
Start:
03 Dec 2024Due:
28 Feb 2025Completion:
Status
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed Solution Document
Document title
I0194 - Solution Report v1.0 23.04.2025
Archive
Off
Problem Statement
Suppliers who do not operate, or intend to operate, in the Smart or Unmetered Market Segments, will be seeking exemptions from the relevant MHHS Qualification requirements. At present, there is no mechanism in CSS to prevent Suppliers from registering Metering Points for which an exemption has been granted and for which they are therefore not qualified.
Stages Selection
Stages Selection
SME
SME Role
Lead Technical Analyst
SME User
maxime.van-eyseren@capgemini.com
SME Role
Lead Assurance Analyst
SME User
vaishnsharma@deloitte.co.uk
PAB281_01A_Modification Proposal Form.docx
I0194 - CSS Change to Allow Prevent of Registration by Market Segment.docx
PAB281_01_Request for Exemption from Suppliers v2.0.docx
352_04_Initial Written Assessment - v1.0.docx
I0194 Proposal Plan Change Report V2.0 (Approved) 03.12.2024.pdf
I0194 - Change Proposal Re-Plan v1.0 (Approved) 27.02.2025
Company Name
-
Review status
Review required
Add Enumeration Values to the DI51035 - Communications Provider Data Item
Date of latest update
Type
Change
ID
R0193
Change Category
Change Path
Priority
Urgent
No
Latest Update
This Change Proposal has been implemented as part of the REC Release on 27 June 2025.
Summary
As the valid list of Communications Providers is being removed from MDD, Elexon have raised a change to propose this list is added to the DI51035 - Communications Provider Data Item.
Status
Implementation Date
27 June 2025
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed Solution Document
Document title
I0193 Solution Document v1.0
Archive
Off
Problem Statement
For the industry to maintain an ongoing list of valid Communications Providers after it is removed from MDD, Enumeration Values will be added to the Communication Provider Data Item (DI51035).
Stages Selection
SME
SME Role
Lead Assurance Analyst
I0193 - Add Enumeration Values to the DI51035 - Communications Provider Data Item
I0193 Change Report (Proposal Plan) V2.0 (Approved) 17.09.2024
I0193 Consolidated Impact Assessment Responses PUBLIC V1.0
R0193 Change Report (For Consultation) V1.0
R0193 Consolidated Consultation Responses v1.0
R0193 Change Report (Final Recommendation) Post Approval V1.0
Company Name
-
Review status
Review required
DPI Extract from CSS
Date of latest update
Type
Change
ID
R0183
Change Category
Change Path
Priority
Urgent
No
Latest Update
11/03/2025 - The proposer has withdrawn the request due to the expected delivery of enquiry data in the same anticipated timescales & the continued pursuance of I0224. The adoption window has closed.
Summary
It has emerged that there are data quality issues relating to the Domestic Premises Indicator (DPI) Data Item, where MPxNs have been recorded as having the wrong DPI. This Change has been raised to identify a mechanism by which this issue can be resolved.
Change Plan
Solution Analysis and Development
In Progress
Start:
11 Jun 2024Due:
20 Sep 2024Completion:
Impacted Consumers
Impacted REC Documents
Impacted REC Services
Impacted REC Parties and Market Participants
Status
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed solution summary
- C1 - As a Consumer, I want industry data relating to my energy supply to be accurate, so that I do not experience any issues when switching or engaging with other consumer facing industry practices.
- M1 - As a CSS User, I want available DPI data to be accurate, so that when I engage with industry processes that require DPI data, I am confident that I am engaging with the right information. M2 - As the CSS, I want to provide accurate data to CSS Users, so that I am able to facilitate successful industry operations for my Users.
Problem Statement
Inaccurate DPI data available within industry data sources can result in less accuracy within REC processes that utilise this data, and poorer consumer outcomes. DPI data accuracy needs to be improved to ensure that industry processes and Consumers are not impacted.
Stages Selection
SME
SME Role
Lead Technical Analyst
SME User
maxime.van-eyseren@capgemini.com
SME Role
Lead Assurance Analyst
SME User
vaishnsharma@deloitte.co.uk
Change Proposal Form
R0183 Change Report V3.0 02.12.2024
Company Name
-
Review status
Review required
Clarity on use of on hold for switching issues, including the obligations of CSS Users
Date of latest update
Type
Change
ID
R0180
Change Category
Change Path
Priority
Urgent
No
Latest Update
25/03/26 - the Change Report (Final Recommendation) has been approved by the Technical Expert Panel for implementation on 06 November 2026. The appeal window has now closed.
Summary
Many Switching Incidents are on hold waiting for resolution. The Switching Operator puts these tickets on hold, which is an approved business process from the Switching Programme. This is not reflected in the obligations on SDSPs or other REC Service Providers, where there is no on hold concept. Further there are no obligations on CSS Users to respond in a timely basis. This means that the REC obligations do not reflect current practice, and many tickets remain open much longer than necessary.
Change Plan
Change Issue Group
Completed
Start:
03 Jun 2024Due:
01 Aug 2024Completion:
01 Aug 2024Impacted Consumers
Status
Implementation Date
06 November 2026
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed Solution Document
Document title
Option 1
Archive
Off
Document title
Solution Development Report
Archive
Off
Document title
Option 2
Archive
Off
Document title
Option 3
Archive
Off
Problem Statement
A lack of obligations is causing issues with open tickets relating to missing messages. Tickets placed on hold also require significant additional work for the Switching Operator, which could either be released as a cost saving or it could result in time freed up for improvement activities.
Stages Selection
SME
SME Role
Lead Technical Analyst
SME User
maxime.van-eyseren@capgemini.com
SME Role
Lead Assurance Analyst
SME User
amoden@deloitte.co.uk
Issue Form
Change Report - Proposal Plan V1.0
I0180 Extension to Plan V1.0 approved 09.07.25
I0180 Consolidated Party Impact Assessment Responses v1.0
I0180 Update to Plan V1.0 approved 10.12.25
R0180 Change Report (For Consultation) V1.0
R0180 Consolidated consultation responses V1.0
R0180 Change Report (Final Recommendation) V1.0 approved 25.03.26
Company Name
REC Code Manager
Review status
Review required
Improvements to CSS Business Process Logic
Date of latest update
Type
Change
ID
R0178
Change Category
Change Path
Priority
Urgent
No
Latest Update
17/06/2026 - The Code Manager has published an Update to Plan. This will be presented to the REC Technical Expert Panel at their meeting on 24 June 2026.
Summary
This change proposal is aimed towards rectifying a collection of issues that were identified with the CSS Business Process Logic. These have been identified as follows: 1. Deactivation of an active reg. whilst in-flight switch in progress 2. Deactivation of a prior cancelled registration 3. OFAF switch containing multiple MPxN
Impacted Consumers
Impacted REC Services
Impacted REC Parties and Market Participants
Status
Implementation Date
25 June 2027
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed solution summary
- Deactivation of an active reg. whilst in-flight switch in progress As mentioned previously, the ‘Deactivation of an active reg. whilst in-flight switch in progress’ issue did have an existing REC CP raised and therefore is further along the discussion process compared to the other two issues identified. Initial discussion outlined that the most appropriate solution for this change proposal should consider the business needs and the desired outcomes. It was noted that from a business perspective, if the switch has already been accepted, then it should still go through and not be cancelled. Therefore, the following points were raised: • It was acknowledged that there are multiple solution options/approaches that could potentially be employed to resolve this issue. As such, and to avoid being overly prescriptive, it is requested that CSS provider investigate all possible options and outline their recommendation for the most suitable approach, which would be developed/progressed further through the subsequent Impact Assessments. • However, the aim is for an effective solution to be developed which would ensure that the consumer is switched with the original effective date being used and that CSS systems could cater for such registration events whilst following the normal Gate Closure processes. • Where possible, the solution should also look to proactively mitigate the impact of this scenario, as opposed to working on a retrospective basis which can lead to the issue persisting over an extended period of time. It was also noted that consideration would need to be given to state of the meters as this would also have an impact on whether switches are able to progress: Therefore, the following points were raised: • The solution would need to consider how the incumbent supplier has deactivated the meter and whether it has been moved to a ‘terminated’ state or a ‘dormant’ state. o Dormant – The meter is inactive. Note that this is a temporary state and therefore the meter could be put back into service. o Terminated – The meter has reached end of life and cannot be reinstated. Note that this is a permanent state. • If the incumbent supplier has moved the meter into a ‘terminated’ state, the in-flight switch would then need to be cancelled. • However, for the ‘dormant’ state, the following two options would be available in terms of what could happen to the status of the meter and thus the in-flight switch: o Moves from ‘inactive’ to ‘active’ (continue with the switch) o Moves from ‘inactive’ to ‘cancelled’ (cannot continue with the switch)
- Deactivation of a prior cancelled registration and OFAF switch contains multiple of the same MPxN It is noted that the initial approach discussed was to add new Business Data Validation Rules (BDVR) to stop these issues from occurring. However, this was only discussed at high-level and therefore we request that the CSS provider confirm this approach and provide further details as this change proposal progresses.
Problem Statement
1) Deactivation of an active reg. whilst in-flight switch in progress: There are instances where the incumbent supplier is withdrawing prior to the ‘Supply Effective from Date’, causing the accepted switch to fail at Gate Closure which occurs at 17:00hrs. This creates the scenario in which there is no longer a losing supplier for the consumer to switch from, and therefore the switch process stalls and cannot be progressed. Therefore, this has a direct impact on consumers who have a switch request which has already been accepted but CSS is not able to progress further as the switch process stops. Indeed, there have been a total of 82 missing messages observed since 1st January 2023, of which 66 messages have been related to switches where there was no registered Supplier recorded at Gate Closure. The 30th September 2023 Gate Closure was particularly impacted by this scenario and resulted in 45 registrations which did not become effective on 14th October 2023 as planned. It should also be noted that the 1st October is one of the key contracting dates for large Industrial and Commercial (I&C) consumers, consequently increasing the impact to consumers in this instance. 2) Deactivation of a prior cancelled registration: This scenario occurs when the registered supplier of a MPxN (via the active registration) is the same supplier that cancelled a previous switch for the same MPxN. In this case there is the possibility that the supplier could attempt to deactivate the active registration by accidentally providing the cancelled registration identifier. Currently, CSS still accepts the deactivation request and erroneously changes the cancelled registration state from cancelled to inactive, sending out securedInactive messages. Currently, after an MPxN is disconnected, the Supplier is required to submit a deregistration request to CSS. Therefore, there is a possibility that the suppliers could submit this request for a cancelled registration not active registration. CSS would still accept this request as the Business Data Validation Rules (BDVR) lack coverage of this case; in such cases the Supplier may incorrectly believe that they have deregistered the MPANs. 3) OFAF switch containing multiple MPxN: This is the instance where the end user sends through a One Fail All Fail (OFAF) switch with the same MPxN contained within the payload 2 or more times. Multiple registration IDs are created for the same MPxN, and the registration is left in an incorrect state given a lack of appropriate BDVRs. Indeed, there has been a further reported incident regarding an OFAF transaction of the same MPxN. The primary MPxN was associated with a secondary MPxN and therefore two registrations were created for the primary and secondary MPxN, equating to four registrations in total. There was then an objection raised but this only cancelled 1 of the 2 registrations for each MPxN. The remaining 2 registrations proceeded through gate closure.
Stages Selection
SME
SME Role
Lead Technical Analyst
SME User
maxime.van-eyseren@capgemini.com
R0178 - Change Proposal Form
R0178 - Change Report (Proposal Plan) V2.0 (18.02.2025)
R0178 - Update to Proposal Plan V1.0 (Approved) 18.02.2025
R0178 - Consolidated Impact Assessment Responses (Non-Confidential) 18.03.2026
R0178 - Change Report (For Consultation) V1.0
R0178 - Update to Plan (17.06.2026) Pre-Approval
Company Name
REC Technical Services
Review status
Review required
Introduction of End of Gate Closure notifications
Date of latest update
Type
Change
ID
R0169
Change Category
Change Path
Priority
Urgent
No
Latest Update
15/09/2025 - following discussions at the August Change Issues Group, the Proposer has decided to withdraw R0169. The adoption window is closed.
Summary
This change seeks to introduce additional functionality within the CSS, to allow CSS users to be notified (by CSS) that the CSS has completed the processing of gate closure messages (i.e. sending of securedActive and securedInactive messages). CSS Users in receipt of this End-of-Gate-Closure (EoGC) notification are then able to commence any applicable downstream processing. It is recognised that an EoGC notification is of value to specific parties which have post-gate closure obligations, however the availability of an EoGC notification is to be made available for all CSS users.
Status
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Problem Statement
The completion of a gate closure event is not reported to CSS Users (at the time), and CSS Users which require to complete downstream processing must assume when the gate closure event has completed in order to initiate any downstream processing they require to complete.
Stages Selection
SME
SME Role
Lead Technical Analyst
SME User
caroline.milner@capgemini.com
Requirements for End of GC messages
R0169 - Introduction of End of Gate Closure Notifications (Change Proposal Form)
R0169 Change Report (Proposal Plan) V1.0 (Approved) 18.02.2025
Company Name
-
Review status
Review required
Access to SDES for Gas Networks
Date of latest update
Type
Change
ID
R0162
Change Category
Change Path
Priority
Urgent
No
Latest Update
21/10/2025 - the REC Change Panel approved the withdrawal of the proposal plan for R0162 and that this Change would be placed on hold while I0285 progresses.
Summary
Raising on behalf of the Gas Networks, who currently struggle to find who to email queries to within suppliers organisation. Suppliers and Electricity DNO's moved to SDES to ensure all communications were in a secure portal, with SLA's and for GDPR reasons, but Gas Networks do not have access to this portal, and not considered during the implementation of the system. They also obtain photo's when out on site to help resolve queries and would like somewhere to upload them to send to suppliers.
Impacted Consumers
Impacted REC Documents
Impacted REC Services
Impacted REC Parties and Market Participants
Status
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed Solution Document
Document title
R0162 Solution Development Report V1.0
Archive
Off
Problem Statement
Energy Suppliers and Distribution Network Operators (DNOs) moved to SDES to ensure all communications were in a secure portal, with SLAs and for GDPR reasons. Gas Transporters do not have access to this portal, and were not considered during the implementation of the system. As such, communications are not being sent as securely as possible.
Stages Selection
SME
SME Role
Lead Technical Analyst
SME Role
Lead Assurance Analyst
CP Form Access to SDES for Gas Networks
R0162 Change Report (Proposal Plan) V1.0 Approved 15.04.2025
R0162 Consolidated Impact Assessment Responses v1.0
R0162 Extension to Plan V1.0 approved 27.08.25
R0162 Rebaseline Plan (withdrawal) V2.0 approved 21.10.25
Company Name
Octopus Energy
Review status
Review required