Flexibility market data: the new asset layer

Registration data is the precondition for stacked flexibility revenues. That single sentence explains why Great Britain has spent the last two years building institutions whose only product is a register.

Start with the problem. A battery sitting behind a distribution connection can, in principle, earn from several places at once: a DNO flexibility tender to defer a local reinforcement, a NESO reserve product, the Balancing Mechanism, and wholesale trading. Each of those buyers historically ran its own onboarding: its own forms, its own technical evidence, its own identifiers, its own view of what the asset was. A 10 MW battery could exist as four different records in four different systems, with no guarantee that the capacity figures agreed. For a large developer that was an overhead. For a 200 kW site with one part-time analyst it was a barrier to entry, and the small sites are precisely where most of the untapped flexibility sits.

Ofgem's answer has two parts, and it is worth keeping them separate because they are often conflated. The first is an institution. In July 2024 Ofgem appointed Elexon as the GB market facilitator, an independent coordinator for distributed flexibility markets. The policy framework decision that defines the role followed in June 2025, and the facilitator began operating from early 2026. Its job is coordination rather than dispatch: standardising how flexibility markets describe themselves, publishing common definitions and processes, and making it possible for a small provider to find the revenue routes available to a given asset in a given place without reading fourteen separate procurement handbooks.

The second part is a dataset. FMAR stands for Flexibility Market Asset Registration. It is an Ofgem programme, not an Elexon product, although Elexon was appointed delivery body on 7 March 2025. Ofgem confirmed the design in its March 2025 decision, and the register is due to launch in 2027. The principle is register once, participate many times: an asset owner records the asset and its technical characteristics in one national place, and every flexibility market that needs to know about that asset reads the same record.

Read the map with the settlement chain from stage 2 in mind. The facilitator sits between the markets and the registers. It does not buy flexibility and it does not instruct assets. It shapes the common language those transactions are expressed in, and FMAR supplies the reference data that language points at. The relationship to settlement is the useful analogy: Elexon does not trade electricity either, but every trade eventually has to reconcile against the records Elexon holds.

Note what FMAR is not. It is not a market, so nothing is bought or sold through it. It is not a dispatch platform, so no instruction is issued from it. It is not a performance record, so it does not tell you what an asset delivered last winter. It is the identity and capability layer, and the reason that matters is stacking. Revenue stacking is only safe when every buyer can see the same asset, the same connection point and the same capacity, because otherwise the same megawatt gets promised twice. That problem is exactly what section 19.2 is about.

When the national system operator and a local network both want the same asset at the same moment, one of them has to give way, and the rules that decide which one are called primacy. The ENA Open Networks programme publishes the primacy rules framework that GB operates to.

The conflict is structural rather than accidental. NESO buys flexibility to balance the national system: it is solving a frequency or a national margin problem, and it does not much care where in the country the response comes from. A DSO buys flexibility to manage a specific piece of local network: it needs the response at that substation, on that feeder, or the service is worthless. The same battery can satisfy both needs, so both will contract with it, and on a small number of days both will want it in the same half hour. Sometimes the two instructions are compatible. Sometimes they point in opposite directions, and importing to relieve a national surplus while the local network needs you to stop importing is a genuine physical contradiction.

Primacy resolves that in advance rather than in the moment. The framework establishes which need takes precedence in defined circumstances, and just as importantly it establishes what the two parties must tell each other and when. That second half is the data engineering. A primacy rule that nobody can operationalise is a policy document. A primacy rule with an agreed conflict notification, an agreed identifier for the contested asset and an agreed time window is a working control.

In practice, conflict data has a recognisable shape. There is an asset identity, which is the reason FMAR is the enabling condition for everything else in this module. There is a location, expressed against a network connection point rather than a postcode, because the network cares about topology. There is a contracted window, which is the period each buyer has bought availability for. There is a service type, so the parties can tell whether the two requirements are physically compatible or mutually exclusive. And there is an outcome record, which says who took the asset and what the other buyer did instead.

Two scenarios are worth holding in your head. In the first, a DSO has contracted a battery to hold a feeder within limits during a planned outage, and NESO wants the same battery for a national reserve requirement in the same window. The local need is specific, physically located and cannot be met from elsewhere. In the second, an aggregator has offered the same portfolio of domestic assets into both a local flexibility tender and a national service without telling either buyer, which is not a primacy conflict at all. It is a registration failure, and it is the failure mode a single asset register exists to make visible.

The takeaway for a data professional is that primacy turns an institutional relationship into a schema. Every clause in the framework has to become a field that somebody populates, on a timescale short enough to matter, or the rule does not bind anything.

Every product change is a data schema change for providers. Between 2024 and 2026 GB replaced most of its reserve product set, and a provider who tracked only the market headlines and not the schema consequences spent that period repeatedly discovering that yesterday's integration no longer submitted anything.

Take the replacements in order. Balancing Reserve went live in March 2024, providing NESO with headroom procured ahead of the Balancing Mechanism. Quick Reserve arrived in phase 1 in December 2024 and phase 2 in September 2025, taking over from Fast Reserve. Slow Reserve went live in March 2025 and took over from STOR, which ran on in parallel until it ended at 05:00 on 1 April 2026. The old names are gone: STOR and Fast Reserve are retired products, and any document, dashboard or course that still teaches them as live is describing a system that no longer exists.

The Demand Flexibility Service has followed the same direction of travel, from an emergency measure to a standing part of the toolkit. DFS became a year-round NESO service on 27 November 2024, which ended the assumption that consumer flexibility is a winter product to be stood up in November and packed away in March. On 9 April 2026 it went further: the service became bi-directional and zonal, with a participation threshold of 0.1 MW.

Unpack those three words, because each is a data consequence. Bi-directional means the service can call for consumption to go up as well as down, so a provider's baseline and performance calculation has to work in both directions, and the sign conventions in every downstream report have to be right. Zonal means location now carries value, so a portfolio has to be resolvable to a zone rather than treated as an undifferentiated national block, which pushes location data quality from a nice to have into a settlement input. The 0.1 MW threshold sets the floor for participation, which shapes how small an aggregated portfolio can usefully be and therefore how much per-site data a provider has to manage to reach it.

Underneath all of this sits the metering evidence, which is where this module leans on stage 2. A flexibility service is paid on what an asset demonstrably did against a baseline, and the demonstration comes from half-hourly data that has to be good enough to survive scrutiny. As Market-wide Half-Hourly Settlement migration completes, the same actual half-hourly reads that settle the market are the reads a flexibility performance claim rests on, which raises the evidentiary bar and removes some of the estimation arguments that used to be available on both sides.

FMAR launches in 2027. Until then, the best public record of what is already connected to the distribution networks is the Embedded Capacity Register, and learning to read one is the most directly employable skill in this module.

Each DNO publishes an ECR listing distribution-connected generation and storage above a size threshold, with the connection point, the capacity and the status of the connection. Electricity North West's register is a good worked example because its structure is typical. The register answers the first question anybody asks about a locality: what is already there. Before you model a flexibility opportunity, before you site a battery, and before you believe a claim about how much distributed resource a region holds, the ECR is where you check.

It is also worth being honest about its limits, because a register is only as useful as your understanding of what it excludes. An ECR records connected and contracted capacity, not what an asset is contracted to deliver into any flexibility market, and not what it actually delivered. Capacity below the publication threshold does not appear, which is most domestic solar. Registers are refreshed on a publication cycle rather than continuously, so a very recent connection may not be visible. And each DNO publishes independently, which means field names, categories and status vocabularies vary across the six DNO groups that publish them. Anyone building a national view is doing a reconciliation job first and an analysis job second, which is precisely the pain FMAR is meant to remove.

Storage co-location is the sharpest data edge case in this area, and it is worth working through slowly because it catches people who have understood everything else. Put a battery and a solar array behind the same connection, and the question of what the meter is telling you gets hard. From stage 1 you already know that import and export sit on separate registers, and that the import register never goes negative. Applied here, that means a single site-level flow figure cannot by itself tell you whether the battery discharged, the solar generated, or the site simply consumed less. Whether a co-located battery's charging is drawn from the array or from the grid changes the commercial and regulatory treatment, and separating those two things demands metering arrangements that resolve the components rather than only the net. The teaching point generalises: as more assets co-locate, net site data stops being sufficient evidence, and the flexibility market's appetite for component-level measurement grows accordingly.

Put the module together and you have the shape of a local flexibility brief, which is the deliverable this material is really preparing you to write. Such a brief needs the network context, meaning what is already connected in the area and where the network is constrained, taken from the ECR and the DNO's network development and DFES publications. It needs the revenue routes, meaning which national and local products the asset could serve and what each one now requires, which is the reserve and DFS picture from section 19.3. It needs the dispatch question answered, meaning how primacy would resolve a clash between the local and national buyer, from section 19.2. It needs the registration position, meaning what the asset is currently recorded as and what FMAR will require of it from 2027. And it needs an honest statement of the evidence, meaning what the metering can actually demonstrate, which is where co-location and half-hourly data quality decide whether the numbers in the brief will survive contact with a counterparty.