Structured against the published Response Log’s question set (Q001–Q015). This document does not use the log itself; it follows the same structure so it can be transposed into it directly.First published: 14 September 2026 · Last Updated: 16 September 2026
Response to Elexon’s FMAR Design and Implementation Consultation
For the full consultation pack visit Elexon’s FMAR consultation website and submit your response to FMAR.programme@elexon.co.uk by 17:00 on 9 October 2026
Status of this documentThis is a complete draft, not yet submitted to Elexon. The document has not yet been fully reviewed by the Auth.Energy team. Two items remain open and are tracked here rather than scattered through the response:
- Miro board (Business Processes & Use Cases). Every other artefact in the consultation pack — the main document, the 65-page Appendix in full, the Day 1 Minded-to Position feedback, the Logical Entity Relationship Diagram, the complete API Specification (all 21 endpoints, all 53 schemas), the full Data and Interface Specification workbook (Data Access Matrix, Logical Data Catalogue, Error Code Catalogue, Glossary, both ERD mapping tabs, Logical Interface Catalogue, Enumerated Data, and all 28 FMAR message definitions), and the full Design Guidance workbook — has been reviewed in full. The Miro board has not: it is a JavaScript-rendered canvas we cannot access directly, and our review is limited to the frames captured in manually-provided screenshots (the Level 3 use-case index, the Level 2 UI/API/DFS journey diagrams, the Asset Uniqueness Process, and the Asset Data Change and Conflict Resolution process). We have asked Elexon for a full export. The single highest-value gap is the full Use Case Description and sequence diagram for UC6 and UC7 (existing-asset registration) — the use cases behind Critical Issue 2 — which we have only in summary form via the authoritative FMAR003 message specification, not the Miro board itself. We will supplement this response if that export surfaces anything materially different from what the specification already shows.
- Q006 (cohort readiness) requires an organisation-specific answer not yet finalised, and is marked as such in place.
Introduction
The FMAR data model is a declaration-based system, and where a genuine automated safeguard against duplicate registrations does exist, the system’s own design routes the highest-risk scenario directly past it. The Logical Entity Relationship Diagram and Logical Data Catalogue both confirm the core asset attributes are FSP-declared, with a “Data Mastering Service” of FSP throughout the catalogue. Elexon’s own Logical Data Catalogue definesInstalled Generation Capacity (DE0028) simply as “The full-load generation of the Flexibility Asset in MW” — a plain declared number, with no confidence, tolerance, or data-quality field attached. In fairness to Elexon, the design is not blind to duplication risk on new asset registrations: the FMAR001 message runs a genuine three-dimension uniqueness match (import MPAN, technical resource type, metering arrangement), rejecting a true duplicate by default. But the Design Guidance workbook’s own Functional Requirements state that when this check flags a likely duplicate, “FMAR shall direct FSPs to the existing-asset flow (UC7)” (FR 147) — and that route, FMAR003, carries no equivalent check anywhere in its field list: only a non-blocking premises-type consistency flag and a self-declared Contractual Authorisation Indicator that “must be True for Registration to be accepted.” Any other FSP sharing that asset is notified only after the registration is already confirmed. Most strikingly, this consultation’s own Traceability to Ofgem’s Requirements states that “FMAR will validate new asset records against defined criteria to identify and prevent duplicate records” — a claim the FMAR003 specification does not support for the route the design itself sends flagged duplicates into. This is, as far as we can determine from the published specification, the literal mechanical explanation for how the Day 1 Minded-to Position’s own evidence — 28,000 duplicate Octopus Energy MPANs in the current Capacity Market delivery year, described as “over 10% of our eligible portfolio,” 11,000 duplicate MPANs with UKPN, and roughly 14,000 with NGED — could occur under a design built the same way. Elexon’s response to that evidence has been to stand up a Consistent Asset Allocation workstream rather than to revisit whether the redirect into an unchecked route is the right design. We return to this in full at Q001 and Q004.
This response also draws on our own published paper, FMAR — From Registration to Characterisation (28 March 2026), which set out an alternative architecture ahead of this consultation and which this response treats as still live.
Our full set of findings follows as a list of the most critical issues, then a complete answer to each of the fifteen consultation questions, and a final section covering matters that do not map cleanly onto any single question.
Top critical issues
1. The core FMAR data model is declaration-based end to end, confirmed at the API and data-catalogue level, with no field anywhere carrying meter-derived provenance, despite BSC Modification P483 (live November 2025) making most of the relevant technical parameters independently derivable or verifiable from data Elexon already receives.Installed Generation Capacity (DE0028) and Installed Demand Capacity (DE0094) are both catalogued with Data Mastering Service “FSP” and no accompanying quality field. Energy Conversion Type, Energy Source Type, and Demand Technology Type (DE0029, DE0030, DE0031) are likewise all mastered by “FSP.” A full-text search of the API Specification for “confidence”, “derive”, “meter data”, “MHHS”, and “provenance” returns zero results, and the one confidence-like mechanism the specification does have — the Asset Registration Validation Code (DE0038) — scores how well a submission matches existing FMAR records, not whether a declared technical parameter is physically plausible. Our March 2026 paper set out in detail how half-hourly MPAN data on the DIP, cross-referenced against AMSID asset-level metering under P483, can derive these parameters as continuously-updated distributions rather than static declared values, and flag implausible delivery claims. None of this capability appears anywhere in the Day 1 design as published, narrative, data catalogue, or API. We note, in fairness, that FMAR already has an architectural precedent for exactly this kind of independent verification: the Data Access Matrix shows that network and location attributes (Import/Export MPAN, Connection Voltage, GSP Group ID, Constraint Management Zone) are all submitted by the FSP as a “candidate value” but become authoritative only “once confirmed via the MPAN Validation Service/DNO validation checks (FMAR007–FMAR010)” — an automated, independent cross-check against DNO systems. The Design Guidance workbook states the same principle generally: “FMAR shall populate registration data fields from external trusted sources where possible” (FR 019). Extending this existing pattern to technical capability data, cross-referenced against DIP meter data rather than DNO network records, is a natural application of a design principle FMAR has already committed to, not a foreign concept we are introducing from outside the programme. The Appendix’s own Logical Data Model guide goes further and states the gap directly: “Day 1 FMAR will not uniquely identify technical resources (e.g. via manufacturer serial numbers); however, the recording of this information, for the utilisation in asset de-duplication / determining uniqueness processes, will be prioritised once the Asset Visibility solution is developed.” Elexon has therefore already identified finer-grained asset identification as necessary for effective de-duplication, and has already chosen to defer it — not to a technical assessment of alternatives, but to a separate, externally-dependent future programme with no confirmed timeline.
2. FMAR’s own Functional Requirements confirm that when a duplicate is detected on the checked (New-asset) route, the FSP is redirected by design into the one route that has no duplicate or authority check at all — and Elexon’s own Ofgem Traceability table claims the opposite of what its own specification describes. The Design Guidance workbook states plainly: “FMAR shall direct FSPs to the existing-asset flow (UC7) when an asset is found during deduplication checks” (FR 147), and separately, “SO Registration Platform shall redirect FSPs to the existing-asset flow (UC7) when FMAR identifies a duplicate asset” (FR 161). This is not a coincidental parallel path an FSP might stumble into — it is the designed, intended destination for exactly the scenario the system itself has just flagged as a likely duplicate. We understand the design logic (don’t create a second record for the same physical asset; instead register against the one that already exists), and in isolation that is sensible. The problem is what happens once an FSP lands there: the Data and Interface Specification’s FMAR003 (“Existing Asset Registration Request”) message carries no uniqueness, technical-match, or authority-verification field of any kind — only a non-blocking premises-type consistency flag (FMAR-ERR-BUS-032), a check that the referenced Asset Identifier exists (FMAR-ERR-NF-001), and the self-declared Contractual Authorisation Indicator, which “must be True for Registration to be accepted” (FMAR-ERR-BUS-031). FMAR003’s own Routing Rules confirm other FSPs sharing that MPAN or Asset Identifier are notified only “asynchronous[ly]” once the registration already shows “Registered.” In fairness to Elexon, the New-asset route (FMAR001) does run a genuine three-dimension uniqueness match (import MPAN, technical resource type, metering arrangement, per the Miro board’s Asset Uniqueness Process), rejecting a true duplicate by default and requiring an explicit, separately-actioned override to proceed — a real safeguard, which we credit. But that safeguard’s own success condition (detecting a likely duplicate) triggers a handoff into the one route where authority is taken entirely on trust. Most strikingly, this consultation’s own Traceability to Ofgem’s Requirements (Appendix Section 10) states, against Ofgem’s Functional Outcome 3 (Data Quality): “FMAR will validate new asset records against defined criteria to identify and prevent duplicate records.” On the evidence of Elexon’s own specification, this is only true of the New-asset route; the Existing-asset route the system itself redirects flagged duplicates into prevents nothing beyond a self-declared checkbox. We ask Elexon to reconcile this claim with its own FMAR003 specification, or to correct the Ofgem traceability table if the claim is not, in fact, accurate across both routes. The Day 1 Minded-to Position responses record “28,000 Octopus Energy MPANs were flagged as duplicates” in the Capacity Market, “over 10% of our eligible portfolio,” alongside “11,000 of our MPANs were flagged as duplicates with UKPN and almost 14,000 with NGED this year”; we do not suggest FMAR itself produced these figures, since it is not yet live, but they are direct evidence that a comparable declaration-based model already fails at this scale, and we consider the redirect-into-an-unchecked-route design the single most important finding in this response for that reason. Elexon’s own response to the duplication evidence commits to a Consistent Asset Allocation workstream with four objectives — “1. Avoiding duplication… 2. Clear accountability… 3. Fair and efficient switching… 4. Informed participation” — every one of which is a market-rules or process objective, and none of which, on the evidence reviewed, closes the specific gap identified here.
3. P483 creates a two-layer metering picture — a boundary meter Elexon already receives, and an asset meter the FSP alone controls and declares — and the API confirms FMAR has no mechanism to cross-check one against the other, nor is asset-level metering even consistently required. The AssetMetering schema’s amsid field (DE0035) is described in the API Specification only as: “DE0035 (Conditional: mandatory if used in Balancing Mechanism by a VLP).” For the great majority of DSO local-market assets, no AMSID is required at all, and the join key our March 2026 paper proposed for boundary-vs-asset-meter cross-referencing is not consistently populated by the API’s own validation rules. Ofgem explicitly acknowledged, in approving P483, that asset-level metering may amplify gaming risk relative to P415 wholesale market operation. FMAR’s current design leaves this risk entirely unaddressed at the data layer.
4. The API Specification is the outlier against two independent, mutually consistent business documents on who is permitted to set the Registration Override Indicator, and the two-step business process the Miro board describes for actually using it is not reflected in any of them. The API’s AssetRegistration schema lists registrationOverrideIndicator as one of three fields an FSP is required to submit on every new asset registration: "required": ["registrationOverrideIndicator", "assetRegistrationEffectiveFromDate", "contractualAuthorisationIndicator"]. Both the Error Code Catalogue’s FMAR-ERR-AUTH-003 and, independently, the FMAR001 message definition in the Data and Interface Specification workbook state the identical restriction in near-identical wording: the field “may only be set to true by a role authorised to apply a manual registration override (SO/FMAR operations), not by an FSP submission.” Two independent, business-authored artefacts agree with each other and disagree with the machine-readable API schema, which makes the API Specification the clearer candidate for correction. The Miro board’s Asset Uniqueness Process and Asset Data Change diagrams clarify that an override is, in practice, a two-step process: an FSP requests one after receiving a reject notification (“Request Override”), and the request is then actioned separately by SO/FMAR operations. That is consistent with the business-rule text, but none of the three artefacts — the API Specification, the Error Code Catalogue, or the FMAR001 message definition — describes this two-step process or the channel through which an override request is actually raised, actioned, and reflected back into a field the API schema otherwise requires every FSP submission to populate directly. We ask Elexon to correct the API Specification to match the two business documents, and to document the override request-and-approval process explicitly so an implementer working from the API Specification alone is not misled into believing FSPs can request a genuine override directly. A second, independent instance of the same pattern: the Data Access Matrix lists the Domestic Premises Indicator (DE0020) as externally mastered by “the domestic energy Supplier (via REC/MPAN data),” stating explicitly that “no FMAR-ecosystem role can create or update this value inside FMAR.” Yet the FMAR001, FMAR003, and FMAR004 message definitions all list DE0020 as a mandatory field the FSP submits directly, with the business rule that “new declarations are accepted” subject only to a non-blocking consistency flag against any existing value. Three independent message specifications agree with each other and disagree with the Data Access Matrix. We ask Elexon to reconcile this in the same review as the Registration Override Indicator point above.
5. Elexon’s own Data Access Matrix confirms the two fields that gate an asset registration’s legitimacy — the Contractual Authorisation Indicator and the Registration Override Indicator — have no specified data master, and can be created, read and updated by the FSP alone, with no independent party able to create or verify either. The Data Access Matrix lists the “Data Master / Owner” for both DE0062 and DE0041 as “Not specified in source.” The FSP column shows Create/Read/Update rights on both; the SO can only Read; DNOs and NESO have no access to either at all. FMAR-ERR-BUS-031 confirms the Contractual Authorisation Indicator’s only check is that it equals true: “Contractual Authorisation Indicator is not set to true,” with guidance stating “The FSP must confirm it holds a valid consumer contract/authorisation before FMAR will accept the registration” — confirmation, not verification. The same self-declaration pattern recurs at every other stage of the asset lifecycle we were able to review on the Miro board: UC4.1 (Asset Query, API) requires an FSP to “Declare FSP has contractual authority for asset search” before a lookup is permitted; UC9 (FSP de-registering from an asset) requires the FSP to “Submit de-registration request with asset data and ‘accept declaration authority’”; and UC8 (asset data change) requires the requesting FSP to “Accept ‘declaration authority’ to request and make changes to asset data in this service.” Registration, query, de-registration, and data-change are the four points at which an FSP interacts with an asset it may not, in fact, have authority over, and all four rely on the same self-declared checkbox rather than an independent check.
6. Elexon’s own RAID log confirms the exact governance gap this response identifies is still open, not a resolved design element. The Appendix’s Implementation Approach RAID summary lists, under “Finalised Design”: “Design elements such as asset de-duplication logic, data mastership, stewardship and change permissions, conflict resolution process, interface/API requirements, and registration arrangements, require further clarity to support implementation planning and participant readiness.” We would also note a tension with the Design Guidance workbook’s own stated design principle, “Data quality by design,” which commits to “enforcing strict validation rules, uniqueness constraints, and cross-system data consistency to intercept errors at the point of ingestion” — a standard the warning-only duplication check at Issue 2 does not, on the evidence, meet.
7. The rejection of a single, centrally-owned FMAR UI is argued on user-journey grounds, not on the underlying data-integrity risk the proposal was raised to address. An industry respondent to the Minded-to Position proposed a single direct FMAR UI for Day 1, “to avoid the cost, delivery dependency and data integrity risks of requiring every SO platform to build and maintain a conformant write integration.” The Appendix’s own account of alternatives considered states only that “Moving asset registration to a single platform would add another platform for UI-based FSPs to navigate, increasing complexity,” and does not engage with the data-integrity risk as raised.
8. Bulk upload was made optional for cost reasons, without the underlying question — whether batch declaration is the right paradigm at all — ever being asked. The consultation states bulk upload was downgraded from mandatory to optional “following stakeholder feedback on implementation cost and development overhead.” The batch API route is still a batch of the same declared fields addressed at Issue 1.
9. Domestic MPAN data governance is deferred to a future, unspecified integration with the Consumer Consent Solution (CCS), while Day 1 relies on FSP self-declared contractual authority as the access-control mechanism. Section 3.4 confirms Elexon “expects Article 6(1)(e) UK GDPR (public task) to be the primary lawful basis,” relying on FSP declarations of contractual authority rather than verified consumer consent — the same self-declaration pattern shown to be unchecked at Issues 2 and 5.
10. The asset data change and conflict resolution process defaults to applying a disputed change if an associated FSP simply does not respond in time, and for DFS users the entire process runs manually over email and support tickets rather than through any systematic, auditable channel. The Miro board’s Asset Data Change and Conflict Resolution process notes state plainly: “If other FSPs associated to the asset do not respond within the 7 day period then the requested change would automatically be applied and committed.” Where a dispute is raised, the mechanism is that “the affected FSPs must attempt to resolve the issue directly between themselves,” with “the consumer act[ing] as the final authority” only if they cannot agree — a sensible escalation path, which we credit positively. For DFS users specifically, the entire mechanism (UC5, “Data change request and conflict resolution (DFS file upload)”) runs as: “FSP A raises a support ticket proposing a change,” FMAR sends an “email notification to all associated FSPs requesting approval,” and the associated FSPs “resolve the proposed change between themselves,” with the outcome “confirmed to FMAR by email.” No system-of-record beyond a support ticket and an email thread is described for what is, in substance, a contested change to a shared, market-relevant asset record.
11. FMAR’s own end-to-end journey diagrams show the DFS bulk-upload route explicitly running a “de-duplicate” step across both new and existing assets in the same batch submission, which is not obviously consistent with the New/Existing route-dependent picture at Critical Issue 2. UC2 (“Asset registration and qualification (DFS file upload)”) states FMAR will “Validate and process the file in bulk, de-duplicate” before creating new assets and registering the FSP against existing ones, in a single step covering both. We were not able to establish, from the material reviewed, whether this collapses to the same New-asset-only Asset Uniqueness Process described at Critical Issue 2, or represents a distinct, more thorough check specific to the DFS batch channel. We ask Elexon to clarify whether the strength of de-duplication protection differs between the UI/API “New vs Existing” routes and the DFS bulk-upload route, given DFS is confirmed as the primary NESO route for Day 1.
Answers to consultation questions
Q001: Please provide your feedback on any significant technical or operational constraints or gaps you have identified with the design, which would prevent integration into your systems.
Our primary feedback is architectural, not an integration-blocking constraint in the conventional sense. We set it out below clause by clause, against the specific artefacts and fields it concerns, before addressing what we consider a genuine build-blocking issue. Logical Data Catalogue —Installed Generation Capacity (DE0028) and Installed Demand Capacity (DE0094). Defined respectively as “The full-load generation of the Flexibility Asset in MW” and “The full-load demand of the Flexibility Asset in MW,” both with Data Mastering Service “FSP.” Neither carries a companion field for confidence, tolerance, or provenance. The API Specification’s business-rule for both is simply FMAR-ERR-BUS-034: “Installed Capacity is not greater than zero” — a positivity check, not a plausibility check.
Logical Data Catalogue — Energy Conversion Type, Energy Source Type, Demand Technology Type (DE0029/DE0030/DE0031). All three carry Data Mastering Service “FSP” and Current Reference Data Source “PQC” (an enumerated reference list). The API validates only that the submitted value is “a valid type in reference data” (FMAR-ERR-SCH-008) — i.e. that the FSP picked a real option from the list, not that the option chosen matches what the asset actually is.
API Specification — full-text search. Searching the API Specification (OpenAPI 3.0.3, v0.6.0-draft) for the terms “confidence”, “derive”, “meter data”, “MHHS”, and “provenance” returns no matches. The nearest thing to a confidence mechanism, assetRegistrationQualityScore (DE0038), is scoped to record-matching only — see below.
Design Guidance workbook — Functional Requirements FR 147 / FR 161, and Appendix Section 10 (Traceability to Ofgem’s Requirements). FR 147: “FMAR shall direct FSPs to the existing-asset flow (UC7) when an asset is found during deduplication checks.” FR 161: “SO Registration Platform shall redirect FSPs to the existing-asset flow (UC7) when FMAR identifies a duplicate asset.” A flagged duplicate is, by design, routed into FMAR003 — the one message with no uniqueness check. Separately, Appendix Section 10 states, against Ofgem’s Functional Outcome 3, that “FMAR will validate new asset records against defined criteria to identify and prevent duplicate records” — a claim we do not think the FMAR003 specification supports for the route the design itself sends flagged duplicates into.
Data and Interface Specification, FMAR003 message definition (“Existing Asset Registration Request”). The full field list carries no equivalent to FMAR001’s uniqueness check: only a non-blocking Domestic Premises Indicator consistency check (FMAR-ERR-BUS-032), a check that the referenced FMAR Asset Identifier exists (FMAR-ERR-NF-001), and the self-declared Contractual Authorisation Indicator (FMAR-ERR-BUS-031). Its Routing Rules confirm other FSPs sharing the same MPAN or Asset Identifier are notified only “asynchronous[ly]” once the registration already carries a “Registered” status.
Miro board — Asset Uniqueness Process (New-asset route only). The diagram corroborates the above visually: a genuine three-dimension match (import MPAN, technical resource type, metering arrangement) runs on the FMAR001 New-asset route, rejecting outright only where all three match (“Scenario 5”) and requiring an explicit override to proceed. This is a real safeguard, which we credit. Our concern, set out fully at Critical Issue 2, is that it does not extend to FMAR003.
API Specification vs Error Code Catalogue — registrationOverrideIndicator (DE0041). The AssetRegistration schema requires it on every FSP submission ("required": [..., "registrationOverrideIndicator", ...]). FMAR-ERR-AUTH-003 describes it as “Reserved for SO/FMAR operations use; rejected if set by an FSP submission.” This is a direct contradiction between two normative artefacts of the same draft specification, and we treat it, uniquely among our findings, as a genuine integration blocker: we cannot build a conformant FSP-side integration against a required field whose own governing business rule says our submissions to it will be rejected. We ask Elexon to confirm which document is correct before Cohort 1 build activity proceeds.
Data Access Matrix — DE0062 (Contractual Authorisation Indicator) and DE0041 (Registration Override Indicator). Both list “Data Master / Owner” as “Not specified in source.” Both show the FSP column as “C,R,U” (Create, Read, Update). The SO column shows “R” only; DNO and NESO show ”–” (no access). FMAR-ERR-BUS-031 confirms the only check on the Contractual Authorisation Indicator is that it equals true.
Appendix Section 2.1, “Alternative FMAR Design (not progressed)”. States only: “FMAR reviewed a range of alternative designs for FMAR Day 1, including fully direct asset registration to FMAR for both API and UI FSP users,” with the only objection recorded being that direct UI registration “would add another platform for UI-based FSPs to navigate, increasing complexity.” No meter-data-derived or characterisation-based alternative is referenced anywhere in this section.
Taken together, we do not consider the above (aside from the DE0041 contradiction) an integration blocker for our own systems — we can build against the published API as specified. We raise it because we do not believe it should be accepted as the right long-term design simply because it is buildable, and because Section 2.1 confirms the alternative in our March 2026 paper has not been formally assessed. We ask Elexon to treat this as a live question for the remainder of this consultation period and to respond substantively to the five evaluation questions set out at the end of our March 2026 paper (reproduced in summary at Q004 below).
A secondary, genuine integration gap: the mechanism for cross-checking P483 asset-meter declarations against boundary-meter data does not exist anywhere in the current design, use cases, data catalogue, or API. If Elexon does not intend to build this centrally, we ask for explicit confirmation of that position and of who is expected to own detection of the gaming risk Ofgem identified when approving P483. Separately, we ask Elexon to confirm whether FMAR011 (Asset De-Registration Request) and FMAR012 (Asset Removal Request) are intended to carry any check that the submitting FSP is the one currently holding the registration being ended: the published field lists for both messages check only that the FSP account itself exists and is active, with no Contractual Authorisation Indicator or equivalent field, and no explicit business rule cross-referencing the FSP to the specific registration. If such a check exists in the running system, we ask that it be reflected in the specification; if it does not, we ask that one be added.
Q002: Do you need further information to design, build and test your systems and processes to integrate with FMAR that is not listed in this consultation?
Partly. We ask that a full export of the Business Processes & Use Cases Miro board be made available in a static, searchable format (PDF, image, or CSV) — Section 1.3 identifies it as essential reading, and a live, JavaScript-rendered canvas is not a practical format for a documented consultation response to be built against. We also ask for explicit confirmation of whether the characterisation-engine architecture proposed in our March 2026 paper has been formally assessed by the programme. Appendix Section 2.1 does not reference it — see Q001 — so if an assessment exists, we ask where it is documented. Separately, we ask Elexon to resolve the direct contradiction between the API Specification and the Error Code Catalogue over the Registration Override Indicator (see Q001) before Cohort 1 participants begin building against the published schema.Q003: Do you agree with Elexon’s proposed legal and governance approach for Day 1 migration and enduring FMAR operation?
Broadly agree with some refinements required. We have no substantive objection to the proposed legal basis — the consultation states Elexon “expects Article 6(1)(e) UK GDPR (public task) to be the primary lawful basis for its core migration processing,” with Article 6(1)(c) applying “where Elexon is subject to a specific legal or regulatory obligation” — as a starting position. Our concern is narrower: the enduring access-control model rests on FSP declarations of contractual authority, and the Data Access Matrix shows this field’s data mastership is “Not specified in source,” with FSP-only create/update rights. We ask Elexon to confirm what, if any, independent check exists or is planned on FSP contractual-authority declarations, and to address how the FMAR Day 1 legal basis is intended to interact with the separate Consumer Consent Solution (CCS) programme once operational, rather than treating CCS integration purely as a Section 3.5 future development with no defined trigger or timeline.Q004: In your opinion, what are the top five developments that should be in the scope of the next phase of FMAR?
In priority order:- A meter-data characterisation engine, sitting on the existing DIP feed, to derive and continuously maintain asset capability profiles rather than relying solely on FSP declaration. See our March 2026 paper for the full technical case. We ask that the programme formally evaluate the five specific questions posed at its end: whether separating commercial rights registration from technical characterisation is a more appropriate design principle than unified manual registration; whether the DIP can support a characterisation engine generating capability data without FSP input; whether a non-domestic-MPAN proof of concept is viable within the current timeline; whether the dispute-resolution framework we propose provides adequate market integrity protection; and whether cross-referencing MPAN boundary data against P483 asset-meter declarations should be formalised as an FMAR compliance function. We note that Elexon’s own Appendix already ties stronger asset-level identification to the future Asset Visibility programme (see Critical Issue 1); our proposal offers a route to the same outcome sooner, using data FMAR already has access to rather than waiting on a dependency outside the programme’s control.
- Extending the Asset Uniqueness Process to the Existing-asset registration route. At minimum, the Existing-asset route should run the same three-dimension match (or an equivalent check against the Contractual Authorisation Indicator’s underlying claim) that already protects the New-asset route, rather than relying solely on a self-declared authorisation flag for a route that, by definition, is used specifically when the asset is already known to exist.
- A systematic, automated cross-check of P483 asset-meter declarations against boundary-meter data, addressing the gaming risk Ofgem identified when approving P483.
- A defined, published methodology and firm timeline for the Consistent Asset Allocation workstream — the consultation states four times that these rules are “still being developed,” and the programme’s own RAID log confirms the relevant design elements “require further clarity.”
- Formal integration planning between FMAR and the Consumer Consent Solution (CCS), with a defined trigger date rather than an undated future development.
Q005: Are there any constraints that would prevent us from progressing the Implementation Approach?
One specific constraint: the contradiction between the API Specification and the Error Code Catalogue over the Registration Override Indicator (see Q001) needs resolving before Cohort 1 participants can build a conformant integration with confidence. Beyond that, we have not identified constraints that would prevent progression of the Implementation Approach as a sequencing and cohort-onboarding exercise; our wider reservations are about the underlying data architecture, not the phasing or governance mechanics of Option 4 itself.Q006: As we are proposing phased onboarding for participants, based on your readiness, which Cohort do you think you will be ready for?
[Organisation-specific — to be completed separately from this document.]Q007: What additional risks, assumptions, issues or dependencies can you identify that would help in the delivery of the implementation plan or the wider end-to-end plan?
Two RAID items not captured elsewhere in the consultation. First, the risk that the Day 1 data model, once baselined in November 2026, becomes materially harder to change once Cohort 1 design, build and test activity is underway — the characterisation-engine architecture proposed at Q004 needs evaluating within this consultation cycle if it is to be adopted natively rather than retrofitted. Second, the Registration Override Indicator contradiction: if unresolved, Cohort 1 participants risk building against a field whose actual governing behaviour differs from its documented API contract — precisely the kind of design-finalisation risk the programme’s own RAID log already flags as open.Q008: What opportunities do you see that could accelerate the implementation plan and wider end-to-end plan?
The characterisation engine proposed at Q004 can begin processing non-domestic DIP data immediately and in parallel with the agreements-register build — non-domestic MPAN data carries no GDPR complexity and represents the majority of contracted flexibility capacity today. This offers a proof-of-concept opportunity off the critical path of Cohort 1 delivery.Q009: Apart from the answers given above in this section, do you agree that the proposed Implementation Approach will enable your timely integration with FMAR?
Broadly agree with some refinements required, for the reasons given at Q001, Q005 and Q007.Q010: Do you agree with the proposed division of responsibilities between SOs and the FMAR service?
We have no substantive objection to the division of responsibilities as described in Appendix Section 5.2. We ask that the division of responsibilities for detecting and resolving duplicate or conflicting asset registrations during migration be made explicit, given the warning-only mechanism at DUP-003 is precisely the failure mode already evidenced in the Capacity Market.Q011: Do you agree with the proposed Migration Approach and believe you will be capable of conducting it?
Broadly agree with some refinements required. The migration approach’s reliance on SOs cleansing and de-duplicating their own source data before migration inherits the same declaration-based data-quality risk raised throughout this response. We ask whether migrated records are matched using the same three-dimension logic as the Asset Uniqueness Process (see Q001, Critical Issue 2), and if so, whether migration applies that check uniformly to every record, since Day 1 registration only applies it on the New-asset route.Q012: To what extent does the proposed FMAR accreditation approach provide an appropriate framework for organisations connecting to and operating within FMAR?
Broadly appropriate, with some refinements required. Accreditation, as designed, assures technical, operational, security and governance readiness to connect — it does not, and is not intended to, assure the accuracy of the technical asset data subsequently declared through that connection via the API’s self-attested fields and unspecified-mastership authorisation fields (see Q001).Q013: To what extent does the proposed approach to FMRs provide an appropriate framework for organisations to implement, connect to and operate within FMAR?
Broadly appropriate, with some refinements required. We consider it appropriate and proportionate for transitional FMR provisions to require DNOs and NESO to complete implementation, data cleansing, migration, testing, readiness assurance and cutover activities within the stated timescales. We ask that the Consistent Asset Allocation rules be given equivalent priority and a committed timeline within the FMR development sequence, rather than remaining an undated parallel workstream.Q014: Do you feel that the proposed support arrangements set out in this section and in Appendix Section 8 will provide you with sufficient support to fulfil your role effectively?
Partly. Appendix Section 8 sets out reasonable qualitative support arrangements — a 24/7 logging channel actively resourced during core hours (09:00–17:00, extending to 18:00 around go-live), a central Elexon Support channel, and enhanced one-to-one support during onboarding. What it does not set out, in contrast to the level of detail given elsewhere in this consultation for technical requirements, is any measurable service level: no incident severity classification, no target response or resolution times, and no consequence described if a target is missed. We ask that Section 8 be developed to include defined service levels for query and defect resolution, consistent with the “appropriate service levels” it already commits to in principle.Q015: Please provide any additional feedback on the information set out in this consultation, including any matters not specifically addressed by the questions above.
See “Other issues that do not map to a single consultation question,” below.Other issues that do not map to a single consultation question
Scope boundary confirmed on the Miro board. The board’s own User Journey to Use Case Mapping marks “Register Unit” and “Qualify Unit” explicitly as “Out of FMAR scope” — worth stating plainly here since neither the main consultation document nor the Appendix states this as directly. API Specification versioning. The reviewed API Specification is marked version0.6.0-draft. We ask Elexon to confirm the change-control and re-consultation arrangements for further draft revisions, given the field-level findings in this response are tied to the exact schema, error codes, and Data Access Matrix entries of this draft version, and the contradiction at Q001 needs resolving in whichever document is wrong.
Terminology consistency with the March 2026 paper. Our March 2026 paper used MPAN + AMSID as the join key for the agreements register. The Logical Data Catalogue’s own entity naming (Asset Metering System Identifier (AMSID), entity ASSET_LEVEL_METERING_POINT) is consistent with this join key, reinforcing that the missing piece is the derivation and cross-referencing layer, not the identifiers themselves.