Tariff Interoperability

What this is about

DESNZ, through the Smart Secure Electricity Systems programme and in collaboration with RECCo, is consulting on Tariff Interoperability: a new obligation requiring every electricity supplier to publish its tariff pricing data in a standardised, machine-readable format through a defined API. The mechanism is a new TI Arrangements Schedule in the Retail Energy Code, supported by redlines to the REC Standard Definition Document, changes to the Energy Market Data Specification, and a corresponding obligation written into the Electricity Supplier Standard Licence Conditions. Energy Smart Appliances would read this common feed directly, rather than each manufacturer building bespoke integrations to each supplier's bespoke data format. Phase one runs through the REC and the Supplier SLCs, with implementation activities scheduled from post-consultation to early 2027.

The timing follows from the Clean Power 2030 Action Plan and the Clean Flexibility Roadmap, and builds on the 2024 *Delivering a Smart Secure Electricity System* consultation and its government response. The policy logic is that consumer-led flexibility cannot scale if every appliance vendor has to reverse-engineer thirty different supplier tariff pages. Standardise the data layer and an ESA can, in principle, read any tariff from any supplier and shift load automatically. That is the case being made. It is worth being precise about what this does and does not do. It builds the data plumbing for automated demand response. It does not change the tariffs that flow through that plumbing, nor the half-hourly price exposure that determines whether a household has anything to respond to in the first place. An appliance that can flawlessly parse a flat tariff still faces a flat price and will not move a single kilowatt-hour in response to system conditions. The interoperability layer is necessary for automated flexibility at scale; it is nowhere near sufficient. The binding constraint on consumer-led flexibility is the structure and penetration of time-varying tariffs, and this consultation deliberately leaves that untouched. That is a defensible sequencing choice, but it should be named: this is infrastructure for a flexibility market whose price signals are being decided elsewhere.

Options on the table

Mandatory standardised tariff API via the REC and Supplier SLCs

The single substantive proposal is a licence obligation on all electricity suppliers to expose tariff pricing data through a common API and a common data specification, governed by a new TI Arrangements Schedule in the REC. The REC carries the operational detail (governance, operations, performance standards for how tariff information is made available); the Supplier SLC carries the hard obligation that makes non-compliance a licence breach. The Energy Market Data Specification and the Standard Definition Document define the data items and message formats so that "tariff price" means the same thing across every supplier's feed. ESAs and the aggregators behind them consume one standardised interface instead of maintaining N bespoke integrations.

The distributional effect is straightforward and follows directly from the cost structure. The winners are flexibility aggregators and ESA manufacturers: they get a single uniform feed and the integration cost of reaching the whole supplier base collapses from N bespoke builds to one. The cost falls on suppliers, who must build, certify, and maintain conformant APIs and keep their published data accurate against the specification on an ongoing basis. This is a fixed compliance cost, and fixed compliance costs are regressive across a supplier base of unequal size. A large incumbent spreads the build and maintenance across millions of customer accounts; a small or new-entrant supplier carries broadly the same absolute cost across far fewer. The obligation therefore raises the per-customer cost of being small and tilts the competitive field toward incumbents, which is the standard consequence of any uniform technical mandate and the reason Annex C carries exemptions and derogations rather than a flat universal rule. The consultation explicitly seeks views on the scope of the obligation and on which suppliers or tariff types should qualify for relief, which is the right place to manage that asymmetry, though a poorly drawn exemption can equally entrench it by carving incumbents in and leaving small suppliers to choose between a disproportionate cost and a derogation that signals second-class tariffs to the aggregators deciding which feeds to consume.

There is no genuine second option presented. The consultation is not asking whether to mandate a standardised API; it is asking whether the specific drafting (scope, governance, data items, timeline) is right. The choice that matters is therefore at the parameter level, not the structural level.

Questions being asked

Supplier licence obligation

- Do you agree with the proposed draft Electricity Supply SLC changes, including the scope of obligations, exemptions, and derogations (Annex C)? *(This is the question that decides who actually carries the obligation. The substance is in the exemptions and derogations: which suppliers, and which tariff types, are in or out. Small suppliers and new entrants should engage here specifically, because the line between "obligated" and "exempt" is where the regressive fixed cost is allocated.)*

REC arrangements and governance

- Do you agree with the draft REC TI Arrangements Schedule covering governance, operations, and performance of how tariff information is made available (Annex D)? *(This sets the ongoing performance standards: availability, accuracy, update frequency of the published data. A weak standard makes the feed unreliable for aggregators; a stringent one raises the maintenance burden on suppliers. This is where the live operational cost is set, not the one-off build cost.)*

Technical specification

- Do you agree with the proposed data items, market messages, and API specification, and the Energy Market Data Specification changes (Annex E)? *(The real question is whether the data model is rich enough to represent the tariffs that matter. If the specification cannot cleanly express half-hourly, dynamic, or location-varying prices, it standardises the publication of exactly the tariffs that least need automating and constrains the products it is meant to enable.)* - Do you agree with the redline changes to the REC Standard Definition Document (Annex F)? *(Definitional plumbing. Worth checking that "tariff", "price", and "rate" are defined consistently with how they are used in settlement and elsewhere in the REC, so the standardised feed does not encode a different meaning of price than the rest of the code.)*

Implementation

- Do you agree with the proposed implementation timeline for the period from post-consultation to early 2027 (Annex G)? *(The build falls on suppliers and the lead time is short. The question to test is whether smaller suppliers can deliver a conformant API on this schedule without the timeline itself functioning as a de facto barrier, and whether the sequencing leaves ESA manufacturers enough certainty to build against a stable specification.)*

How to respond

The source text provided does not contain the response deadline, the submission email or portal, or a named contact. These details are in the consultation's covering letter (Letter and Annex A), which is referenced but not reproduced here. Before responding, retrieve the letter from the DESNZ Smart Secure Electricity Systems consultation page to confirm the closing date, the submission method (typically a DESNZ consultation email address or an online response form), and the policy contact. The consultation is led by DESNZ in collaboration with RECCo, so substantive points on the REC TI Arrangements Schedule and the Standard Definition Document will route through RECCo's governance processes, while points on the SLC obligation, exemptions, and derogations are for DESNZ. I have not invented a date or address; treat the deadline as unconfirmed until the letter is checked.

---

One framing point for anyone drafting a response. The strongest substantive intervention is not on the technical specification, where the consultation invites comment, but on the relationship between this layer and the tariffs that sit above it. The interoperability mandate is being justified by consumer savings from automated optimisation, yet those savings exist only where a tariff carries a time-varying price to optimise against. A response that accepts the API as necessary infrastructure but presses DESNZ to publish the matching trajectory for half-hourly tariff exposure and to confirm that the data specification can fully represent dynamic and locational prices addresses the part of the problem that actually determines whether any demand shifts. Standardising the pipe is the easy half. The question that decides whether consumer-led flexibility materialises is what price runs through it, and that question is conspicuously outside the scope of this document.