FMAR - From Registration to Characterisation

_{First published: 28 March 2026 · Status: DRAFT}

​

1. Executive Summary

The Flexibility Market Asset Registration (FMAR) programme, as currently conceived, is a manual registration system. Flexibility Service Providers (FSPs) and asset owners will be required to declare asset types, technical parameters, and capability data when registering flexible assets across Great Britain’s 20+ local and national flexibility markets. This paper proposes a fundamentally different approach - one that eliminates the need for technical self-declaration almost entirely. It argues that half-hourly smart meter data, already flowing through Elexon’s Data Integration Platform (DIP), contains sufficient information to automatically detect, classify, and continuously characterise the technical capability of flexible assets at the meter point level. The human registration act should be reduced to a single, simple commercial declaration: which FSP holds dispatch rights over which assets, at which meter points. This approach does not require a change to the FMAR programme’s governance, mandate, timeline, or working group structure. It proposes a better technical architecture within the same programme - one that is faster to deliver, more accurate, self-maintaining, and directly aligned with Elexon’s existing data assets. The paper sets out the business case, the technical design, the data pathway, and the mechanism for managing FSP-disputed capability assessments. It concludes with a specific request for the FMAR Design Workshop Series to consider this architecture as the basis for the system design.

---

​

2. The Problem with Manual Registration

​

2.1 The Scale Ambition

The scale of the task that FMAR must enable is not trivial. Consumer-led flexibility must grow from 2.5GW today to 12GW by 2030 - a five-fold increase in five years. By 2035, NESO estimates approximately 20 million electric vehicles and 10 million heat pumps will be connected to GB distribution networks. Flexible energy use is estimated to save between £30 billion and £70 billion in system costs between 2020 and 2050. Achieving these outcomes requires that assets enter flexibility markets at a rate and scale that manual registration processes cannot plausibly support. The architecture of FMAR must be designed for millions of assets, not thousands.

​

2.2 The Registration Burden Today

The current market entry experience for FSPs illustrates the structural problem that FMAR is intended to solve. Each DSO operates its own procurement platform with its own registration format, prequalification questionnaire, and technical data requirements. An FSP operating a multi-region portfolio must complete this process separately for each DSO, for each asset, on each platform. As one FSP summarised their experience entering the market: This is not a process inefficiency that can be resolved by creating a better form. It is a structural problem: the information being collected is the wrong information, gathered in the wrong way, at the wrong point in time.

​

2.3 The Data Quality Problem

Manual registration does not merely impose a cost at the point of entry - it creates a persistent data quality problem throughout the life of an asset. Self-declared technical parameters become stale. Assets are upgraded, replaced, or decommissioned without corresponding updates to registration records. Baseline capability declarations made at registration may not reflect actual asset behaviour under operating conditions. A register populated by self-declaration degrades. A register populated by observed data improves over time.

​

2.4 The Invisible Asset Problem

Perhaps the most significant limitation of a registration-led approach is the population of assets that simply never register. An EV charger whose owner has no awareness of flexibility markets, or whose FSP finds the administrative overhead of registration disproportionate to the revenue opportunity, will never appear in a manual register. These assets are precisely the population FMAR needs to unlock to achieve the 12GW target. Meter data can identify these assets. A manual form cannot.

---

​

3. The Open Banking Parallel

The energy industry frequently references Open Banking as a model for data-driven market reform. The parallel is instructive here, and more precise than it is usually applied. Before Open Banking, mortgage lenders and credit providers required applicants to self-declare income, expenditure, and financial commitments. These declarations were time-consuming to produce, expensive to verify, and prone to error and misrepresentation - both intentional and inadvertent. The declared data was a snapshot that immediately began to age. Open Banking replaced self-declaration with observed transaction data. Rather than stating income, an applicant consents to sharing their account transaction history. The lender derives income, expenditure patterns, risk indicators, and affordability assessments directly from the data - continuously, at scale, and with far greater accuracy than any self-declared form could achieve. Revealed energy behaviour - the actual pattern of consumption, generation, ramp rates, and response to price signals observable in half-hourly meter data - is more accurate than any technical parameter declared on a registration form. It is more current, because it updates continuously. It is more scalable, because it requires no human input. And it is more trustworthy, because it reflects what assets actually do rather than what their owners claim they can do. This is not a theoretical proposition. The technical methods to derive asset capability from smart meter time-series data are well-established in the academic and commercial literature. EV charging detection, heat pump classification, battery storage identification, and demand response characterisation from half-hourly meter data have all been demonstrated at scale. What has not yet been done is to apply these methods systematically within a regulatory asset registration framework. FMAR is the opportunity to do so.

---

​

4. The Proposed Approach

​

4.1 The Core Proposition

FMAR should comprise two distinct components, each doing a specific and separable job: The FSP interaction with FMAR becomes a single API call: “I hold dispatch rights over this asset (AMSID) at this meter point (MPAN), in this market, from this date.” Everything else is derived, not declared.

​

4.2 Component 1: Commercial Agreements Register

The agreements register is a thin, auditable ledger of commercial dispatch rights. It contains precisely the information that cannot be inferred from meter data — the commercial relationship between an FSP and an asset owner — and nothing else. BSC Modification P483, approved by Ofgem in August 2025 and live from November 2025, established that dispatch rights operate at the asset level, not the meter point level. Under P483, a Virtual Lead Party (VLP) or Virtual Trading Party (VTP) can hold rights over a specific asset behind a customer’s boundary meter — identified by an Asset Metering System ID (AMSID) — independently of how the site’s boundary meter is settled. This means multiple FSPs can legitimately coexist at the same MPAN, each holding rights over different assets at that meter point. The agreements register must reflect this reality: the join key is MPAN + AMSID, not MPAN alone. The register is append-only with full audit trail. There are no destructive updates — changes create new records, preserving history. Validation on submission is minimal: confirm the MPAN exists in the DIP, confirm the AMSID is a registered asset meter, confirm the FSP has a valid market participant ID. Three checks. The system does not attempt to validate technical capability — that is Component 2’s job.

​

4.3 Component 2: Meter-Data Characterisation Engine

The characterisation engine runs continuously against the half-hourly MPAN data flowing through the DIP. It produces and maintains a capability profile for every MPAN - whether or not that MPAN has ever appeared in the agreements register. This is the key distinction from a registration paradigm: the system knows about assets before anyone declares them.

​

Asset Detection

The engine uses established signal decomposition and machine learning classification techniques to identify asset types from load signatures in 30-minute interval data:

• EVs - detected via step-change load events of characteristic magnitude (3.7kW, 7kW, 22kW), with predictable charge-deplete cycles and time-of-day distributions
• Heat pumps - identified by cycling behaviour, temperature-correlated load, and characteristic steady-state power draw
• Battery storage - recognisable by simultaneous import/export transitions, arbitrage patterns, and net-zero operating periods
• Solar PV - visible from export signatures and generation correlation with irradiance
• Commercial demand response - identifiable from scheduled load reduction patterns aligned with market signals

​

Capability Parameter Derivation

Once an asset type is identified with sufficient confidence, the engine derives the technical parameters that flexibility markets require: Critically, these parameters are expressed as distributions and confidence intervals, not single declared values. This is more informative than any registration form — a buyer can see not just that an asset has a 7kW rated capacity, but that it delivers between 6.8kW and 7.1kW across 94% of observed charging events.

​

4.4 P483, Asset-Level Metering, and Gaming Detection

BSC Modification P483 introduced a structural complexity that makes the characterisation engine not merely useful but necessary for market integrity. Under P483, multiple FSPs can hold dispatch rights over different assets behind the same boundary meter. The boundary meter — the MPAN-level half-hourly read flowing through the DIP — reflects the aggregate behaviour of all assets at that site. The asset meter (AMSID), maintained by the FSP under P483, measures only the specific asset they control. This creates a two-layer metering picture at any P483-enabled site: The asset meter data is declared and maintained by the FSP. It is not independently verified at the boundary. This is precisely the condition under which gaming can occur — and Ofgem explicitly acknowledged this risk in their approval decision for P483, noting that the modification may amplify gaming risks in relation to P415 wholesale market operation. The characterisation engine creates a systematic, automated check that did not previously exist. By maintaining a continuously updated capability profile derived from MPAN-level boundary meter data, the system can compare:

• What the FSP’s asset meter declares the asset delivered during a dispatch event
• What the boundary meter observed at the MPAN during the same period

Where a site has a single P483 asset, these should be broadly consistent — the asset’s contribution should be visible as a load change in the boundary data, adjusted for baseline consumption. Where they are persistently inconsistent, two explanations exist: either the asset meter data is inaccurate, or the declared flexibility was not genuinely delivered from that physical asset. Where a site has multiple P483 assets under different FSPs, the picture is more complex — the boundary meter sees the net effect of all assets. The characterisation engine’s disaggregation capability becomes the only independent means of attributing observed load changes to specific assets, and therefore of detecting whether any individual FSP’s declared delivery is plausible given the total boundary signal. This framing has direct relevance to the FMAR design. The current approach — collecting self-declared technical parameters at registration — has no mechanism to detect systematic misrepresentation of asset capability or delivery. The characterisation engine, cross-referencing boundary meter observations against asset-level declarations, provides that mechanism continuously and automatically.

---

​

5. System Architecture

​

5.1 API Design

The capability store exposes a read API consumed by all market participants. Access control is fundamental to the design:

• DNOs and NESO query aggregate capability by geographic area or constraint zone - no individual MPAN commercial data exposed
• FSPs query their own portfolio capability only - scoped to their declared agreements
• Market platforms receive capability envelopes for tendering purposes - asset-level data without FSP relationship information
• Ofgem receives system-level visibility dashboards - aggregated market health data

​

5.2 Technology Stack

---

​

6. Data Pathway and Legal Basis

​

6.1 Building on the DIP Today

The characterisation engine does not need to wait for the Smart Data Repository (SDR). The DIP is live, processing over one billion messages since August 2025, and already sharing half-hourly MPAN-level data with third parties under a bilateral agreement framework. The Elexon-ElectraLink agreement, established in February 2026, provides the direct legal and operational precedent: Elexon sharing DIP-sourced half-hourly data for purposes that extend beyond settlement. Elexon’s position as FMAR delivery body under an Ofgem statutory mandate provides an even stronger justification for processing DIP data for characterisation purposes than the commercial data-sharing rationale that underpinned the ElectraLink arrangement.

​

6.2 Non-Domestic MPANs First

Non-domestic MPANs - industrial and commercial sites - present no GDPR complexity. MPAN-level consumption data for business premises is not personal data. Non-domestic assets also represent the majority of contracted flexibility capacity today. Beginning the characterisation engine with non-domestic MPANs delivers immediate market value with no regulatory friction.

​

6.3 Domestic MPANs via DAR

Domestic MPAN data is personal data under UK GDPR, as it can be linked to a household. The characterisation engine’s approach to domestic data is architecturally sound: the engine processes time-series data briefly, but what it stores and exposes is derived technical parameters - capacity distributions, availability profiles, ramp rates - not personal consumption records. These derived parameters are technical characteristics of an electrical connection point, not personal data in any meaningful sense. The legal basis for domestic data processing strengthens progressively: initially public task (Elexon operating under Ofgem mandate), then upgraded to explicit consumer consent via the Digital Accounts and Records (DAR) framework as that programme matures. The system architecture does not change between these phases - DAR adds a consent verification step to the data pipeline, not a redesign.

​

6.4 DNO Connection Data

DNO connection data - grid location, connection capacity, G98/G99 status - is necessary for the capability store to provide network-topology-aware capability assessments. This data is currently held by DNOs and not systematically shared. FMAR’s statutory mandate provides a clear policy lever to require DNOs to make this data available as an open feed. The FMAR programme should include this as an enabling activity within the existing working group structure.

---

​

7. Capability Assessment and Dispute Resolution

A common question in response to data-derived capability assessments is: what happens when an FSP disagrees with the system’s characterisation of an asset they represent? The answer is designed to be simple, proportionate, and self-correcting.

​

7.1 FSP Override

An FSP may at any time submit a revised capability parameter for any MPAN within their declared portfolio. The override is accepted and reflected immediately in the capability store, tagged as FSP-declared rather than system-derived. The system continues to observe actual meter data against the declared parameter.

​

7.2 Evidence-Based Flagging

If ongoing meter data persistently contradicts the FSP-declared parameter — for example, an FSP declares a 50kW capacity asset that consistently delivers no more than 15kW across observed activation events — the system flags the discrepancy. The flag is not an automatic correction. It is a notification to the FSP and, where the divergence is material and sustained, to the relevant market operator. A sustained, material divergence between declared and observed capability constitutes a potential non-conformance under the market’s standard agreement and flexibility market rules. This is not a new enforcement mechanism — it maps directly onto existing prequalification and performance monitoring obligations. The system simply provides the evidence base that makes those obligations enforceable at scale. Under P483, this flagging mechanism takes on an additional dimension. Where an FSP’s asset meter declares a volume of flexibility delivered, but the MPAN-level boundary meter data — adjusted for baseline consumption — does not show a corresponding load change of plausible magnitude, the system flags the discrepancy as a potential delivery misrepresentation. This is the automated, continuous equivalent of the gaming check that Ofgem acknowledged was absent when approving P483. Two FSPs operating different assets at the same MPAN can each be assessed independently: the sum of their declared asset-level deliveries must be consistent with the total boundary meter signal. Where it is not, at least one declaration is suspect.

​

7.3 Confidence Thresholds

Not all characterisation outputs carry equal confidence. The system applies tiered confidence scoring to all derived parameters:

• High confidence (>90%) - parameter is used directly in market-facing capability profiles with no caveats
• Medium confidence (70–90%) - parameter is used but flagged; FSP is invited to confirm or correct
• Low confidence (<70%) - parameter is held internally; MPAN appears in the register with a ‘characterisation in progress’ status

Confidence increases with observation time and number of qualifying events. A newly installed asset will move from low to high confidence within a few billing cycles under normal usage.

---

​

8. Governance Continuity

This proposal does not require changes to the FMAR programme’s governance structure. All of the following remain unchanged:

• Ofgem’s statutory mandate for FMAR, as set out in the March 2025 decision
• Elexon’s role as Market Facilitator and FMAR delivery body
• The FMAR Design Workshop Series and Industry Experts Committee
• The BSC and DIP governance frameworks (DCAB)
• The programme timeline targeting delivery by Q3 2027
• The Flexibility Market Rules development process

What changes is the technical approach within that governance framework: specifically, the architecture of the system that Elexon designs and delivers. The design workshops already have a mandate to determine the technical approach. This paper proposes what that approach should be. The agreements register component - the human-facing element of FMAR - is a simpler and faster build than a full registration system. The characterisation engine is more complex, but it can begin processing non-domestic DIP data immediately, generating value and validating the approach before the main programme reaches detailed design. The two components can be developed in parallel, with the agreements register going live first and the characterisation engine’s outputs progressively enriching the capability store as confidence levels mature.

---

​

9. Our Proposal

We are proposing that the FMAR Design Workshop Series consider the architecture set out in this paper as the basis for the FMAR system design. Specifically, we are asking the programme to evaluate:

• Whether the separation of commercial dispatch rights registration from technical asset characterisation is a more appropriate design principle than a unified manual registration system
• Whether the DIP, as an existing and operating data source, can support a characterisation engine that generates asset capability data without FSP input
• Whether beginning with non-domestic MPANs on the existing DIP feed would provide a viable proof of concept within the current programme timeline
• Whether the dispute resolution and non-conformance framework described in Section 7 provides adequate market integrity protections to replace self-declared technical parameters
• Whether the cross-referencing of MPAN boundary meter data against P483 asset meter declarations should be formalised as a FMAR compliance function, addressing the gaming risk Ofgem identified in approving P483

We are available to present this proposal in detail at a forthcoming design workshop, and to support the programme in developing this architecture further.

---

​

Appendix: Key Data Fields Derivable from Meter Data

The bold rows represent the only fields requiring human input — three declarations covering the commercial relationship and asset identity. Every other parameter in the FMAR capability profile, including the P483 delivery verification check, can be derived and maintained automatically from data that already flows through Elexon’s infrastructure.