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.

On 6th July 2023, a Major Switching Incident occurred with the Central Switching Service ((CSS) operated by the Switching Operator and CSS Service Provider, the Smart Data Communication Company (DCC)). It prevented the successful completion of that day’s planned electricity and gas, supply switches and new registrations. The CSS was stabilised post-incident and any new requests submitted after 9 a.m., 6th July were processed successfully. Through the collective action of the Switching Operator and industry parties, the CSS sent the missing industry messages to give effect to the intended switches and new registrations during the period of the 2nd to the 8th of August 2023. Priority 1 (P1) Major Switching Incidents of this nature are required to be resolved within 4 hours; however, DCC reported it took 1,605.6 hours in this instance. This incident had significant impacts on multiple industry parties and end consumers, demonstrating a clear need for improvement in the arrangements managing switching services and response to major incidents. The Retail Energy Code Company ((RECCo) with the assistance of its Code Manager) completed an end-to-end incident review; to identify the root cause, consider the efficiency and effectiveness of the incident management response, assess the improvements required, and identify appropriate actions for risk mitigation. With the overarching objective that by delivering the identified review recommendations, these actions should limit the possibility, or minimise the impact of, any future major switch incidents.

Market Participants require functionality that improves efficiency, reporting and allows Consumer issues to be addressed sooner and more accurately.

Failures by the CSS to generate Market Messages can result in a breakdown of the Switching process. As the CSS cannot re-generate Market Messages that should have been sent but were not, this results in message asynchronisation, and breakdown of CSS functions and processes, resulting in substantial impacts for those involved – Difficulties for the REC Parties using the CSS, and difficulties for Consumers, where the Switch process is impacted.