Switching and registration: the CSS data spine

Registration was consolidated so that switching could be a data transaction instead of a paper chase. That single sentence is the argument of this section. Before July 2022, the question of who supplies a given meter point was answered by different registers for different fuels, maintained by different parties, reconciled by messages passing between them. A switch was therefore a negotiation between systems that each believed slightly different things. The Central Switching Service (CSS) replaced that arrangement with one authoritative registration record covering both electricity and gas.

Two facts about the CSS are worth separating carefully, because they are the most common thing people get wrong. The CSS is operated by the DCC. It is governed by the Retail Energy Code (REC), whose code manager is RECCo. Operation and governance are different jobs. The DCC runs the service, holds the systems and meets the service levels. The REC defines what the service must do, who may connect to it, what obligations a registered party carries and how disputes are handled. When an exam question asks who runs the CSS and who governs it, it is testing whether you have kept those two apart.

At the core of the register sit two objects you already know. The first is the MPXN, the collective term for the electricity MPAN and the gas MPRN. The MPXN is the primary key of the whole retail market: every registration, every appointment, every settlement volume and every bill hangs off it. The second is the Retail Energy Location (REL) record, the address object that ties meter points to a physical premises. The REL is what allows the CSS to answer a question no single-fuel register could answer on its own: which electricity and gas meter points belong to the same property.

That pairing is the whole point of a two-fuel register. A dual-fuel switch is not two unrelated switches that happen to share a customer. It is one registration event against one location, carrying two MPXNs. Getting the REL right is therefore not administrative tidiness; it is the mechanism by which the market knows that the gas meter in the cupboard and the electricity meter under the stairs serve the same household.

Around this core sit the enquiry services. Market participants cannot simply read the central register at will; they query it through defined services. On the gas side that is the Gas Enquiry Service (GES), operated by Xoserve, which replaced the older Data Enquiry Service (DES) in July 2022 at the same time the CSS went live. DES is legacy. If you find a specification, a supplier runbook or a job description still naming it as a current route, you have found a document that has not been reviewed since the switching reforms landed. That is a useful signal about the rest of the document.

The takeaway for this section: the CSS is one register, two fuels, operated by the DCC under REC governance, keyed on the MPXN and anchored to a location by the REL, and reached through defined enquiry services rather than direct database access. Every failure mode later in this module is a failure of one of those five things.

The fastest way to understand registration data is to follow one switch through it. Take a domestic dual-fuel household moving from an incumbent supplier to a new one. The customer experience is a form and a confirmation email. Underneath, five distinct data movements happen in sequence, and each one touches a named dataset. Nothing in this trace is unusual; it is the ordinary path, which is exactly why it is worth knowing by heart.

Step 1: Enquiry

Before it can sell, the gaining supplier has to know what it is selling to. It queries the enquiry services to resolve the customer's address into meter points. For gas that is the Gas Enquiry Service, returning the MPRN, the supply point details and the current registration. For electricity the equivalent lookup returns the MPAN and its associated attributes. The datasets touched here are the registration record and the REL address record. This is the step where most switches quietly fail, because a customer types an address that does not match the address the register holds.

Step 2: CSS registration update

The gaining supplier submits the registration request to the CSS against the MPXNs identified in step 1. The CSS validates it, applies the objection window that the REC defines, and if nothing blocks it, updates the registration so that from the switch date the gaining supplier is recorded as the registered supplier for those meter points. The dataset touched is the central registration record itself. This is the only moment in the whole process where the market's answer to who supplies this meter point actually changes.

Step 3: Agent and service appointments

A registration change is not sufficient on its own, because a supplier does not read its own meters. For electricity under Market-wide Half-Hourly Settlement (MHHS) the gaining supplier appoints the service roles that will handle the meter point, including the Smart Data Service for a domestic smart meter and the metering service that owns the asset. For gas, the equivalent appointments are made under the gas arrangements against the MPRN. The datasets touched are the appointment records that tell every downstream system which organisation is entitled to retrieve data for that meter point.

Step 4: Industry notification

The registration change and the appointments then have to reach everybody who acts on them: the losing supplier, the network operators, the settlement systems and, for a smart meter, the DCC itself so that access rights on the device follow the new supplier. Under MHHS, settlement-relevant messaging for electricity flows across the Data Integration Platform (DIP). The dataset touched is the notification flow set. The important idea is that registration is a publishing event: one authoritative change fans out to many consumers, and each of those consumers has its own copy that can drift.

Step 5: First reads and first bill

On the switch date, opening reads are established for both fuels. The losing supplier closes its account against those reads, the gaining supplier opens its account against the same reads, and settlement is told which supplier owns which half-hours. The datasets touched are the meter reading records and the settlement volumes. When a customer complains that they have been billed twice for the same week, the cause is almost always a disagreement about the reads at this step rather than anything wrong at step 2.

Trace that sequence twice and the architecture becomes obvious: enquiry resolves identity, the CSS changes the registration, appointments assign the operational roles, notification distributes the change, and reads settle the boundary. The register is fast and central. Everything that hangs off it is distributed, and distributed things fall out of step.

Once switching became a data transaction, data quality became the binding constraint. This is the pattern to carry out of the module: centralising a process does not remove its failure modes, it relocates them. The failures moved from process delay to record mismatch, and record mismatch is harder to see because nothing looks broken until a specific customer tries to move.

The institutional response has a date. In December 2024, Ofgem decided that the Centralised Registration Service would stay with the DCC rather than be re-competed or reassigned. That decision settled the question of custody. It did not settle the question of quality, so RECCo and the DCC followed it with a joint improvement plan covering 2025 and 2026, aimed squarely at the registration data that switching depends on. A regulator confirming an incumbent, and the incumbent then publishing a remediation plan with a named partner, is a reasonable proxy for an industry that knows exactly where its weakness is.

The dominant failure is address mismatch: the REL address held centrally does not agree with the billing address a supplier holds, or with what the customer types. Addresses in Great Britain are genuinely awkward data. Flats are numbered inconsistently, subdivided properties inherit their parent's record, new builds are registered before they are occupied, and businesses operating from residential premises carry two plausible descriptions of the same door. When the gaining supplier's enquiry at step 1 cannot resolve the address to the right MPXNs, one of three things happens. The switch is rejected outright. The switch is made against the wrong meter point, which is worse. Or the switch proceeds while an erroneous transfer sits underneath it, to be unpicked months later.

There is a second class of problem that is easy to miss. Registration data is published outward at step 4, so every consumer of it holds a copy. Copies drift. A network operator, a settlement system and a supplier can each be confident about a meter point while disagreeing with one another, and no single party sees the disagreement until an exception report surfaces it. This is why the industry keeps investing in the central record rather than in better reconciliation between copies: one authoritative record with good data is cheaper than many copies with good reconciliation.

For a data professional the practical lesson is that address and identity data deserve the treatment usually reserved for financial data: defined ownership, measured quality, published error rates and a remediation plan with dates. The joint RECCo and DCC plan is that treatment applied to the central register, and it is a reasonable model for how to argue for the same discipline anywhere else in the sector.

The organisation that operates the CSS and the smart metering network is itself on a clock. The current smart meter communication licence expires in September 2027. Ofgem decided the successor arrangements, known in the industry as DCC2, in April 2026, with the business transfer to the successor expected in November 2026. Three dates, in that order: decision, then transfer, then licence expiry. Getting the order right matters, because the transfer deliberately happens well before expiry so that the successor is running the service before the old licence ends rather than on the day it does.

A licence handover is not a system migration in the usual sense, and this is the distinction the module wants you to hold. The obligations move. The systems, data and operational responsibilities transfer as a business rather than being rebuilt from scratch. For registration data, the practical question is continuity of the record: the CSS registration and REL data must remain authoritative and unbroken across the handover, because there is no version of the retail market that can pause switching while a licence changes hands.

The second continuity question is the wide area network that carries smart meter traffic. That network is not one technology. The North region uses Arqiva long-range radio covering Scotland and northern England, while the Central and South regions, which include all of Wales, use Telefonica and Virgin Media O2 cellular. A successor licensee inherits both arrangements and the contracts behind them. Any interruption there does not just affect meter reads; it affects the device-level access rights that step 3 of a switch depends on, so registration and communications continuity are the same problem viewed from two angles.

The risk worth naming honestly is concentration. One organisation currently operates the central registration spine for both fuels and the communications network for the national smart metering estate. That concentration is what makes the service coherent, and it is also what makes the handover consequential. The sequencing Ofgem chose, with transfer roughly ten months ahead of expiry, is the mitigation. Whether it proves sufficient is a question the sector will answer in 2027, and it is the sort of question a data professional should be able to frame precisely rather than worry about vaguely.