Housekeeping Amendments
Date of latest update
Type
Change
ID
R0192
Change Category
Change Path
Priority
Urgent
No
Latest Update
06/08/24 - Change Proposal approved for implementation on 06 September 2024.
Summary
The Code Manager has identified a number of typographical and formatting errors, as well as opportunities to provide clarity, improve consistency and accuracy across the REC Services and products. These changes have been assessed as meeting the criteria to be progressed via a Housekeeping Change Proposal.
Change Plan
Housekeeping Report Published
Completed
Start:
25 Jul 2024Due:
26 Jul 2024Completion:
26 Jul 2024Responsible Committee Decision
Completed
Start:
26 Jul 2024Due:
06 Aug 2024Completion:
Impacted Consumers
Status
Implementation Date
06 September 2024
| Included changes | Affected REC Items | |
|---|---|---|
| R0003 | Market-wide Half-Hourly Settlement Implementation |
Implementation Status
Date Raised
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed Solution Document
Document title
API GES Supply Point Switching Technical Specification v1.1
Archive
Off
Document title
Housekeeping legal text changes
Archive
Off
Problem Statement
This is a Housekeeping Change Proposal subject to the Housekeeping Change Proposal process, rather than the standard change process. The nature of the change is that it makes non-material changes to the REC Products to correct typographical and consistency errors. It also provides an opportunity to introduce necessary clarifications.
Stages Selection
Company Name
-
Review status
Review required
Changes to Terms of reference following acceptance of R0167
Date of latest update
Type
Change
ID
R0188
Change Path
Urgent
No
Latest Update
20/08/2024 - Approved for implementation on 06/09/2024.
Summary
This Housekeeping Change Proposal seeks to update the Terms of Reference of the REC Change Panel and the Performance Assurance Board, following the acceptance of R0167, to reflect Issues.
Impacted Consumers
Impacted REC Parties and Market Participants
Status
Implementation Date
06 September 2024
| Included changes | Affected REC Items | |
|---|---|---|
| R0003 | Market-wide Half-Hourly Settlement Implementation |
Implementation Status
Date Raised
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed Solution Document
Document title
REC Change Panel - Terms of Reference
Archive
Off
Document title
REC Performance Assurance Board (PAB) - Terms of Reference
Archive
Off
Problem Statement
This Housekeeping Change Proposal seeks to update the Change Panel and Performance Assurance Board, Terms of Reference to reflect that these Committees consider change Issues as well as Change Proposals.
Stages Selection
R0188 - Change Proposal Form
R0188 - Housekeeping Change Report (Post Approval)
Company Name
Rec Manager
Review status
Review required
Schedule 8 Review and Best Practice Guidance Development
Date of latest update
Type
Issue
ID
I0187
Change Category
Change Path
Priority
Urgent
No
Latest Update
26/06/2026 On 25 June 2026, the REC Change Panel approved this extension to plan.
Summary
Schedule 8 - Unbilled Energy Code of Practice has not been reviewed since its development for REC go-live. This Issue seeks to understand if there are any conflicts in the Schedule with best practice and identify any gaps or duplication. Alongside this, a best practice guidance document will be developed which is relevant, complete and aligned to current processes and obligations.
Change Plan
Proposal Plan Approved at Change Panel
Completed
Start:
Due:
Completion:
21 Jan 2025Impacted Consumers
Impacted REC Documents
Impacted REC Parties and Market Participants
Status
Status
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed solution summary
- A new version of Schedule 8.
- Implementation of a new Category 3 guidance document.
Proposed Solution Document
Document title
I0187 - Change Report (Proposal Plan) V1.0 (Pre-Approval) 09.01.2025
Archive
Off
Problem Statement
Schedule 8 - Unbilled Energy Code of Practice has not been reviewed since its development for REC go-live. The Schedule needs to be reviewed to ensure it is up to date, understand if there are any conflicts with best practice and identify any gaps or duplication.
Stages Selection
Stages Selection
I0187 - Change Proposal Form
I0187 - Change Report (Proposal Plan) V1.0 (Approved) 21.01.2025
I0187 - Change Report (Extension to Plan) Approved 17.06.2025
I0187 - Change Report (Extension to Plan) 02.09.2025
I0187 - Change Report (Extension to Plan) 13.01.2025 (Pre-Approval)
I0187 - Change Report (Extension to Plan) V1.0 Approved 25.06.2026
Company Name
Code Manager
Review status
Review required
Non dual-fuel Gas PSR Consumer
Date of latest update
Type
Issue
ID
I0186
Change Category
Change Path
Priority
Urgent
No
Latest Update
26/08/2025 - Update to Proposal Plan published. This will be presented to the REC Change Panel at their meeting on 02 September 2025.
Summary
Non dual-fuel Consumers who register upon the PSR, will have their PSR data flow across energy industry data flows to mean that all parties are aware of any PSR Needs Codes, allowing us all to provide equal access to our services and support. This will be achieved via the utilisation of existing processes and systems. Initially a pilot will take place for a minimum of 3 months between participating companies before extending this to the whole industry”.
Impacted REC Documents
Impacted REC Services
Status
Status
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Problem Statement
The majority of domestic customers in the UK are what are called in the industry ‘dual-fuel’ - this means that with two types of energy (electricity & gas) a domestic dwelling has a single supplier ie they pay their bill to one organisation. This ‘dual-fuel’ position has supported the industry improvements to Priority Services Register (PSR) data flows by allowing previous divides to be overstepped in terms of data flows between energy types. There is however a problem which this RECC request aims to resolve. That is, where a customer who has both fuel types, also has two suppliers and they want to register upon the PSR. This was always a ‘known’ gap shared with our regulator when the many improvements were implemented across the PSR and considered to be something that would be addressed at a later date. This ‘gap’ means that without the dual-fuel link, currently data flows do not complete across energy types via the supplier data flow triggers.
Stages Selection
Stages Selection
Change Proposal Form - Non dual-fuel Gas PSR Customer
I0186 - Change Report (Proposal Plan) V1.0 (Approved) 18.02.2025
Company Name
British Gas
Review status
Review required
Amendment Proposal: RECCo Access Provision to RECCo Services
Date of latest update
Type
Change
ID
R0185
Change Path
Priority
Urgent
No
Latest Update
08/08/2024 - the Proposer has withdrawn this Change Proposal.
Summary
RECCo is tasked with fulfilling several obligations. This proposal has been raised to amend some of the wording within the REC, which would benefit from reassessment. When the REC was originally drafted, references to RECCo in the code were originally intended to refer to the activities directly managed and overseen by the REC Board, and were considered separately to activities managed by the Code Manager.
Impacted REC Documents
Impacted REC Services
Impacted REC Parties and Market Participants
Status
Implementation Status
Date Raised
Date of Update to Priority
Solution Development
Problem Statement
RECCo is tasked with fulfilling several obligations. We are raising this proposal to amend some of the wording within the REC, which would benefit from reassessment.
When the REC was originally drafted, references to RECCo in the code were originally intended to refer to the activities directly managed and overseen by the REC Board, and were considered separately to activities managed by the Code Manager. There are specific references in the REC to the duties of both RECCo and the Code Manager to reflect this. One of these references prohibits RECCo from accessing the REC Services on the basis that it was not expected that the organisation would have a direct role in the operation and management of these services, outside of direct procurement and commercial management.
The role of RECCo has evolved since the initial drafting of the REC, with RECCo taking a more direct role in the operational management of various REC Services. RECCo is also the responsible code party for the relevant Code Manager deliverables, and is therefore responsible for contractually determining and managing the Code Manager’s access to REC Services.
While it was not originally envisaged that RECCo would access the REC Services, there are various roles where RECCo does act as a user of the REC Services. This includes managing the receipt of data from the Electricity Enquiry Service (EES), Gas Enquiry Service (GES) and Central Switching Service (CSS).
The current arrangements within section 5.2 of the REC Main Body, sections 13.X, schedule 12, EES & GES DAM sections/Appendix 1, along with broader REC obligations, would benefit from review and revision. This is crucial to ensure that RECCo has access to essential services for genuine operational requirements and to best enable parties to discharge their obligations in the most efficient way.
It also appears likely that the outcome of the Codes Reform programme will result in RECCo being issued a licence from Ofgem to operate as the Code Manager for the REC. The current wording may become misaligned with the granting of the ‘Code Manager Licence’ to RECCo, where RECCo would fulfil the role of the Code Manager which is required to access the REC Services as a REC Service User. This reflects a model that could better align with the operational structure of the REC.
When the REC was originally drafted, references to RECCo in the code were originally intended to refer to the activities directly managed and overseen by the REC Board, and were considered separately to activities managed by the Code Manager. There are specific references in the REC to the duties of both RECCo and the Code Manager to reflect this. One of these references prohibits RECCo from accessing the REC Services on the basis that it was not expected that the organisation would have a direct role in the operation and management of these services, outside of direct procurement and commercial management.
The role of RECCo has evolved since the initial drafting of the REC, with RECCo taking a more direct role in the operational management of various REC Services. RECCo is also the responsible code party for the relevant Code Manager deliverables, and is therefore responsible for contractually determining and managing the Code Manager’s access to REC Services.
While it was not originally envisaged that RECCo would access the REC Services, there are various roles where RECCo does act as a user of the REC Services. This includes managing the receipt of data from the Electricity Enquiry Service (EES), Gas Enquiry Service (GES) and Central Switching Service (CSS).
The current arrangements within section 5.2 of the REC Main Body, sections 13.X, schedule 12, EES & GES DAM sections/Appendix 1, along with broader REC obligations, would benefit from review and revision. This is crucial to ensure that RECCo has access to essential services for genuine operational requirements and to best enable parties to discharge their obligations in the most efficient way.
It also appears likely that the outcome of the Codes Reform programme will result in RECCo being issued a licence from Ofgem to operate as the Code Manager for the REC. The current wording may become misaligned with the granting of the ‘Code Manager Licence’ to RECCo, where RECCo would fulfil the role of the Code Manager which is required to access the REC Services as a REC Service User. This reflects a model that could better align with the operational structure of the REC.
Stages Selection
R0185- CP Form Amendment Proposal RECCo Access Provision to RECCo Services.docx
Company Name
RECCo
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
Schedule 14 - Metering Operations Footnote Review
Date of latest update
Type
Change
ID
R0181
Change Category
Change Path
Priority
Urgent
No
Latest Update
23/08/2024 - This change was successfully implemented as part of the August 2024 Extraordinary REC Release on 23 August 2024.
Summary
The footnotes within Schedule 14 - Metering Operations are not in the correct place, are missing or no longer relevant. This Change Proposal looks to correct issues within the footnotes and move them into the legal text to prevent this from happening when future Change Proposals impacting this schedule are implemented.
Change Plan
Change Proposal Plan and Impact Assessment Report issued
Completed
Start:
06 Jun 2024Due:
18 Jun 2024Completion:
18 Jun 2024Preliminary Change Report issued
Completed
Start:
18 Jun 2024Due:
19 Jun 2024Completion:
19 Jun 2024Consultation issued
Completed
Start:
19 Jun 2024Due:
19 Jun 2024Completion:
19 Jun 2024Consultation Close
Completed
Start:
19 Jun 2024Due:
10 Jul 2024Completion:
10 Jul 2024Final Change Report Issued
Completed
Start:
10 Jul 2024Due:
11 Jul 2024Completion:
11 Jul 2024Responsible Committee Decision
Completed
Start:
11 Jul 2024Due:
19 Jul 2024Completion:
19 Jul 2024Appeal Window Closure
Not Started
Start:
19 Jul 2024Due:
02 Aug 2024Completion:
Impacted Consumers
Impacted REC Documents
Status
Implementation Date
23 August 2024
| Included changes | Affected REC Items | |
|---|---|---|
| R0103 | Central provision of DCC Technical Contacts for requesting test certificates |
|
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed Solution Document
Document title
Metering Operations v4.1 footnote review legal drafting for PCR
Archive
Off
Document title
Metering Operations v4.1 footnote review legal drafting for FCR
Archive
Off
Problem Statement
REC parties are unable to ensure their processes and procedures correctly reflect their obligations as the footnotes within Schedule 14 - Metering Operations are not in the correct place, are missing or no longer relevant.
Stages Selection
R0181 Change Proposal Plan (Approved) 18.06.2024
R0181 Initial Assessment Report (Approved) 18.06.2024
R0181 Preliminary Change Report
Consolidated Consultation Responses
R0181 Final Change Report - approved 22.07.24
Company Name
Code Manager
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
Proposal for Limiting Queries in EES API Calls (Single Query per API Call)
Date of latest update
Type
Change
ID
R0179
Change Category
Change Path
Priority
Urgent
No
Latest Update
This Change Proposal has been implemented as part of the February 2026 REC Release.
Summary
This issue has been raised proposing to establish a limit on the number of queries permitted within a single Application Programming Interface (API) call. As there is potential for performance degradation and system instability that can occur when a large number of queries are made in a single API call to the Electricity Enquiry Services (EES) API. The aim would be to prevent overwhelming the system and ensure consistent response times and reliability. Therefore, this proposes implementing a limit of 1000 queries per single API call.
Change Plan
Request for Information
Completed
Start:
03 Jun 2024Due:
05 Jul 2024Completion:
05 Jul 2024Change Issue Group
Completed
Start:
05 Jul 2024Due:
01 Aug 2024Completion:
01 Aug 2024Impacted Consumers
Impacted REC Services
Impacted REC Parties and Market Participants
Status
Implementation Date
27 February 2026
Implementation Status
Date Raised
Fuel
REC Decision Maker
Date of Update to Priority
Solution Development
Proposed Solution Document
Document title
Request For Information (RFI)
Archive
Off
Problem Statement
The absence of a limit on the number of queries (batch processing) within a single API call could cause performance issues and system instability. As a result, system responsiveness may degrade when a large number of queries are made in a single call, impacting user experience and hindering the ability of the EES API to consistently meet user demands.
Stages Selection
SME
SME Role
Lead Technical Analyst
SME User
maxime.van-eyseren@capgemini.com
Issue Form
EES API Interface Specification REDLINE DRAFT for R0179
R0179 - Change Report - Final Recommendation Approved
R0179 Change Report (Consultation)
R0179 Consolidated consultation responses (non- confidential)
Re-baseline Change Plan 15.07.25
Consolidated IA responses (non-confidential)
I0179 Change Report (Impact Assessment)
Service Provider - Impacts Data
I0179 - Consolidated RFI Responses
Change Report (Proposal Plan)
Consultation on implementation date response
Change Report - Final Recommendation (new implementation date)
Company Name
RECCo
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