For the full consultation pack visit RECCo Consultation website and submit your response to consumerconsent@retailenergycode.co.uk by 19 October 2026
Change note (17 September 2026):
Updated to reflect that RECCo has acknowledged the Standards Definition Document was missing from the consultation bundle as originally published on 7 September 2026, and has since republished the pack with it included. Q14 has been revised to comment on the substance of the now-published document, and now sets out a working assumption, to be confirmed with RECCo, that gas is not in fact in scope for this Change Proposal and that the missing Gas Data Access Matrix and the gas-related references identified at Q3 (§13.5) and Q12 are accordingly a drafting holdover rather than a live design decision. Those two sections have been revised to match. References to the missing Standards Definition Document in the Introduction, critical issue 1, and Q1 have been updated accordingly.
Updated to reflect that RECCo has acknowledged the Standards Definition Document was missing from the consultation bundle as originally published on 7 September 2026, and has since republished the pack with it included. Q14 has been revised to comment on the substance of the now-published document, and now sets out a working assumption, to be confirmed with RECCo, that gas is not in fact in scope for this Change Proposal and that the missing Gas Data Access Matrix and the gas-related references identified at Q3 (§13.5) and Q12 are accordingly a drafting holdover rather than a live design decision. Those two sections have been revised to match. References to the missing Standards Definition Document in the Introduction, critical issue 1, and Q1 have been updated accordingly.
Introduction
This response is based on a detailed review of the full consultation pack: the main consultation document, Annexes A–E (including the Business Process Diagrams, the CCS Arrangements Schedule, the CCS Service Definition, the CCS API Technical Specification, the Consumer Experience Guidelines, the Energy Market Data Specification, the Proposed ISDP Assessment Approach, and the redlined Schedules 1, 9 and 10), and the machine-readable OpenAPI specifications published separately via the RECCo Developer Portal. Two points of general application before turning to the individual questions. First, on scope: this consultation cannot be fully tested against its own substance, because significant parts of that substance are not yet published or not yet finished. Several documents referenced throughout the pack as carrying the actual normative requirements (a Security Profile, an SSF Profile, a Supplier ID&V Security Profile, a CCS Error Resolution Paths document, and the Revocation Reason Catalog) are not included in this consultation bundle. The Energy Market Data Specification annex is explicitly described as “an illustrative view,” with the underlying data items only receiving their final alignment after this consultation closes. The Consumer Experience Guidelines’ illustrative screens are marked as a placeholder to be added post-consultation. The ISDP assessment’s tier-assignment methodology is stated to still be under consideration, with the outcome to be “informed by stakeholder feedback received through this consultation”, meaning the mechanism that determines cost exposure for applicants does not yet exist either. We would also record, for completeness, that the Standards Definition Document was in fact absent from the consultation bundle as originally published on 7 September 2026, notwithstanding that the main consultation document states at §8.11.3 that it “is included in Annex E.” RECCo has since acknowledged this directly and republished the consultation pack with the document added, noting on the consultation webpage that “the Standards Definitions document in Annex E was missing when the consultation was originally uploaded on 7 September 2026, but this has now been amended.” We welcome RECCo’s prompt correction and address the document’s substance in full at Q14 on the basis of the version now published. We raise the episode here only because it illustrates the wider point: a consultation bundle assembled to this degree of complexity needs a more robust process for confirming completeness before publication, particularly given how much of this pack depends on cross-references between documents. We ask RECCo to treat the general point as substantive independent of this specific instance: a consultation response can only be as good as what is available to respond to, and several other important design decisions, addressed above, still cannot be meaningfully tested at this stage. We recognise that this consultation is not necessarily the last opportunity for industry input. RECCo’s own drafting states that the REC Change Proposal (R0318) will progress through the standard REC change process, which itself “includes consultation on the proposed REC drafting” ahead of Code Manager consideration and submission to the Authority for determination. A further, separate REC Change Proposal is also confirmed for the Performance Assurance Reporting Catalogue, to follow this CCS drafting. Neither of these forecast consultations is described, anywhere in the current pack, as the mechanism by which the outstanding documents identified above (the Security Profile, the SSF Profile, the Supplier ID&V Security Profile, the CCS Error Resolution Paths document, the Revocation Reason Catalog, the finalised Energy Market Data Specification, or the finished Consumer Experience Guidelines screens) will be brought back to industry for comment. RECCo’s own wording elsewhere in the pack, that these items “will be developed following this consultation” and that RECCo “will finalise” several of them administratively, suggests the opposite: that they may be settled without further public consultation at all. We ask RECCo to confirm explicitly which of the outstanding documents will be subject to consultation at the R0318 drafting stage, and which RECCo intends to finalise without one. Second, on overall architecture: the design as drafted is materially more centralised, and imposes materially higher barriers to participation, than the stated policy intent. Ofgem’s April 2025 Decision confirmed a hybrid, decentralised model. As drafted, however, the Consumer Consent Service (CCS) sits as a live, load-bearing dependency in every permission grant, revocation, dispute, and even (via the CCS-integrated Account Holder Verification capability) Tariff Interoperability data access, meaning the behaviour of the system, regardless of how the architecture is described, is centralised. This is compounded by an accountability structure that places extensive, strictly-enforced obligations on Authorised Third Parties (ATPs) and Energy Data Holders (EDHs), up to and including formal Event of Default status for breach, while RECCo and its CCS Provider face no equivalent consequence for missing their own service levels, and the CCS Provider itself is fully insulated from any direct obligation to CCS Users. We return to both points in detail below. Our full set of findings follows this introduction as a list of the most critical issues, then a complete answer to each of the fifteen consultation questions (each restating, in context, any of the critical issues that bear on it, alongside every other relevant point), and a final section covering matters that do not map cleanly onto any single question.Top critical issues
1. The consultation cannot be properly tested against its own substance. Multiple documents stated to carry the actual normative rules (the Security Profile, the SSF Profile, the Supplier ID&V Security Profile, the CCS Error Resolution Paths document, and the Revocation Reason Catalog) are referenced throughout but not published in this bundle. The Energy Market Data Specification and the Consumer Experience Guidelines’ illustrative screens are both explicitly provisional, to be finalised only after this consultation closes. The ISDP risk-tiering methodology is stated to be undecided, with the outcome to depend on this very consultation. We would also note, for the record, that the Standards Definition Document was itself absent from the bundle as originally published on 7 September, despite the consultation document stating it was included; RECCo has since acknowledged this, added the document, and republished the pack, which we welcome. Nothing in RECCo’s forecast of future consultation activity, whether the standard consultation built into the R0318 change process or the separate future Change Proposal for the Performance Assurance Reporting Catalogue, is described as the route by which the remaining gaps above will be closed. 2. The architecture is centralised in practice, contrary to the stated hybrid/decentralised model. CCS sits as a single point of failure across permission granting, revocation, dispute resolution, and (via CCS-integrated Account Holder Verification) Tariff Interoperability access, an outcome at odds with Ofgem’s April 2025 Decision and with RECCo’s own description of the design. 3. RECCo and its CCS Provider face no meaningful consequence for their own failures, while CCS Users face severe ones for equivalent failures. The CCS Service Definition sets genuinely precise service levels (incident-resolution targets, response times, disaster-recovery objectives) with no service credit, compensation, or remedy attached if missed. The CCS Provider may revoke a CCS User’s security certificate in its sole discretion, reporting to RECCo only after the fact, with no described right of challenge or compensation for the User affected. By contrast, breach of the equivalent obligations by a CCS User is a formal Event of Default, carrying certificate revocation and REC Performance Assurance Board sanction. The CCS Provider itself has no direct obligation to CCS Users at all: every Provider obligation is expressed as something RECCo has arranged via a private service-provider contract invisible to and unenforceable by the Users who depend on the platform. 4. Liability for CCS’s own errors sits entirely with the ATP or EDH that relied on them. This is a distinct and, in our view, more significant point than the data-accuracy question addressed elsewhere in this response. CCS itself asserts critical facts on which the legal validity of a Permission depends: identity outcome, occupancy confirmation, and the Registrable Measurement Point match produced using the Electricity and Gas Enquiry Services. If that matching is wrong, for example if CCS matches the wrong property or the wrong meter, the resulting Permission is built on a defective premise, yet nothing in the drafting suggests RECCo bears any liability for this: the exposure falls on the ATP or EDH that relied in good faith on CCS’s own output to obtain and evidence consent. This is a materially different and more serious question than whether an EDH’s underlying energy-data values are accurate, because it concerns the correctness of the consent mechanism CCS itself operates and mandates. 5. There is no fallback when automated occupancy verification fails, and this is a recurring, foreseeable-volume problem, not a rare edge case. Occupancy verification relies on credit-reference address records that lag a house move by roughly six to eight weeks on average, a gap RECCo’s own drafting acknowledges can leave a genuine, recently-moved consumer unable to complete verification “at that time,” with only an undefined “digital step-up route” offered and no manual or documentary fallback. Given ONS data indicating that around one in ten of the UK population moves house in a given year, this is a material population, not a marginal case, and it recurs because the Arrangements Schedule requires every consumer to re-verify occupancy at least every three years for the life of the service, with no stated consequence for a failed re-verification cycle. 6. The one safeguard against coercive-control risk in multi-occupancy households is real but structurally backwards, and does not appear in the document meant to guide how it is delivered. The Consumer Experience Guidelines confirm, without qualification, that a consumer can see permissions linked to their address granted by someone else. The only mitigation identified anywhere in the pack is a requirement that the person granting permission be told that other occupants may object, asking the potential source of coercion to voluntarily disclose to the person who may need protecting from them. This requirement exists only in the Arrangements Schedule’s Appendix 1; it does not appear anywhere in the Consumer Experience Guidelines themselves. 7. No party is accountable for the accuracy of the Energy Data actually shared through CCS. RECCo gives no warranty as to EDH data accuracy, and its own monitoring and reporting approach is explicitly stated not to measure that accuracy at all. This is not simply a policy choice: no REC-governed data item exists anywhere in the Energy Market Data Specification for the actual energy values themselves (as opposed to the permission and token payloads), meaning there is no field for an estimated-versus-actual flag, no format constraint, and no provenance information for the substantive data a consumer’s permission actually releases. 8. Barriers to participation are disproportionate to the size and nature of many prospective CCS Users, and unpredictable in advance. Some of the Low-Risk evidence requirements reflect pre-existing statutory obligations rather than CCS-specific asks: a Data Protection Impact Assessment is already required under UK GDPR Article 35 for likely high-risk processing, and a documented process for handling data subject rights requests reflects an existing obligation under Articles 15 to 22. We do not regard evidencing these as an unreasonable barrier in themselves. The barrier lies elsewhere: a documented risk register, a documented staff training policy, and a description of physical security measures are demanded from every applicant regardless of size with no statutory equivalent requiring them in this form; the highest tier requires a formal Data Governance Committee and a RACI matrix, realistic for a large supplier and a serious stretch for the “insulation scheme, local authority, or energy charity” archetypes the Consumer Experience Guidelines themselves name as important users; and because the methodology for assigning an applicant to a risk tier has not been published, no applicant can know in advance what tier, and therefore what cost, they will actually face. 9. The permission dispute and revocation mechanism is immediate, asymmetric, and irreversible, with no intermediate option. A verified occupier’s query terminates another occupier’s permission immediately, with no pre-suspension check and no way to undo data already shared. Per the Business Process Diagrams, raising a query against an unfamiliar permission itself triggers revocation as part of the same step; escalation is only available afterwards, as a further, optional action once the permission has already been terminated. There is no route that allows a consumer to find out more, or to raise a concern without ending the permission, before deciding. This also raises an unaddressed legal question: whether CCS’s own instant-termination mechanism could itself put an Authorised Third Party in breach of a separate contract with the consumer it was serving, notwithstanding that the ATP is not a party to the underlying dispute. 10. RECCo’s position on mandatory CCS participation is inconsistent across the documents, and collides with its own funding model. CCS use is already mandatory today for Electricity Suppliers for Tariff Interoperability purposes; explicitly not mandatory “at this stage” for SEC Other Users, with clear intent signalled that this will change; and separately expected to be mandated for EDHs generally through the wider Data (Use and Access) Act secondary legislation, outside RECCo’s own governance entirely. This runs directly against the funding rationale set out for the initial charging period, which explicitly depends on CCS participation remaining voluntary. RECCo does not address what happens to that funding rationale once mandation arrives by a route RECCo does not control. 11. The security architecture’s complexity is not obviously proportionate to the operational reality it protects. The redesigned model (FAPI 2.0, mutual TLS, 30-minute maximum access tokens, resource-scoped tokens per Energy Data Holder) is justified on proportionality and latency grounds. The sole Energy Data Holder in scope for the Minimum Marketable Product, however, updates its underlying settlement data once per day. We ask RECCo to clarify what data-freshness requirement this security model is actually sized for, given the data it protects does not change more than once every 24 hours. 12. The design insists on establishing full verified identity where only occupancy, or account-holder status, is operationally required, which we consider a breach of the data-minimisation principle. What CCS actually acts on for a Metered Data Permission is whether the individual currently occupies the relevant premises, not who they are by name; for Tariff Interoperability, what matters is account-holder status, again not identity as such. Yet the design requires full identity verification regardless. This is not a hypothetical concern: the API Technical Specification confirms that consumer identity “hints” an ATP supplies to assist matching (name, email, mobile number) are explicitly discarded before reaching the Energy Data Holder, with only the CCS’s own verified identity and address data taking precedence, meaning the identity established is not itself needed by the party ultimately relying on the Permission. We ask RECCo to justify, by reference to the UK GDPR data-minimisation principle, why establishing full identity is necessary at all where the operative fact is occupancy or account-holder status, and to consider whether a narrower verification scoped to that operative fact would meet the same assurance need with less personal data collected.Answers to consultation questions
Q1: Do you agree the products identified in Figure 9 and Part B represent the full scope of REC drafting required to deliver CCS MMP?
No. In our view the scope is incomplete in two respects. First, several documents that this consultation and its supporting Annexes treat as authoritative are not themselves in scope for this round and are not published: the Security Profile and SSF Profile (both stated to prevail over the illustrative API specifications where the two differ), the Supplier ID&V Security Profile, the CCS Error Resolution Paths document, and the Revocation Reason Catalog (a value list that is a required field on every revocation request, yet is stated to be “maintained by RECCo separately” and is not enumerated anywhere). We ask that these four items be brought into scope and published alongside the underlying REC products they support. Separately, we note that the Standards Definition Document, stated at §8.11.3 to be included in Annex E, was in fact absent from the bundle as originally published on 7 September; we welcome that RECCo has since acknowledged this and republished the pack with the document included, and have reviewed the republished version at Q14. We also ask RECCo to confirm whether the four documents still missing will be brought back to industry through the consultation that forms part of the standard R0318 change process, since nothing in the current pack states that they will, and RECCo’s own wording elsewhere (“will be developed following this consultation”, “RECCo will finalise”) suggests some may instead be settled administratively. Second, we do not believe the products in scope adequately address two structural questions that affect the design as a whole: (i) the centralisation of the architecture in practice, discussed in the introduction above and expanded at Q3; and (ii) the overall proportionality of the barriers to entry created across the ISDP approach, Schedule 9, and the technical specification taken together, discussed at Q5/Q6 below and in the Commercial Reasonableness assessment. We would also note, as a general scope point, that while the Product Roadmap (Annex C) sets out a Now/Next/Later structure indicating the general direction of travel for each capability area, the roadmap itself states plainly that it “is directional, not a delivery plan” and that “inclusion in the roadmap does not commit RECCo or industry to delivery dates, sequencing or funding.” This leaves the practical end state, what CCS will actually look like once the Later horizon is reached, undefined in anything more concrete than direction of travel. A short, concrete statement of the intended end state, distinct from the roadmap’s explicitly non-committal horizons, would help respondents assess whether the interim design decisions in this consultation are heading in a coherent direction. Finally, on mandation: the consultation pack treats the question of whether CCS use will become mandatory inconsistently. It is already mandatory today for Electricity Suppliers for Tariff Interoperability purposes (per the CCS Arrangements Schedule’s own applicability table); RECCo states it is not mandatory “at this stage” for SEC Other Users, while signalling clear intent that this will change; and the wider Data (Use and Access) Act secondary legislation is expected to mandate EDH data-sharing generally, entirely outside RECCo’s own governance. We ask RECCo to set out a single, coherent position on the intended trajectory of mandation as part of the scope of this REC Change Proposal, given how directly it bears on the charging methodology addressed at Q4.Q2: Do you agree with RECCo’s assessment that no amendments to the REC Main Body are required to deliver the CCS MMP?
We are not persuaded this is correct, for one specific reason: the accountability asymmetry described in the introduction and at critical issue 3 above is, in our view, a Main Body-level concern rather than something that can be addressed solely within the CCS Arrangements Schedule. At present, a CCS User’s breach of its obligations is an Event of Default under Main Body Clause 16, while RECCo and its CCS Provider face no equivalent consequence anywhere in the REC for failing to meet the CCS’s own published service levels, and the CCS Provider has no direct obligation to CCS Users at all (every Provider obligation runs through RECCo via a private, unpublished service-provider contract). If this asymmetry is to be addressed at all, we believe it requires either a Main Body amendment establishing a reciprocal standard of accountability for RECCo and its service providers, or an explicit acknowledgement in the Main Body that no such reciprocal standard exists and why.Q3: Do you have any comments on the content of the CCS Arrangements Schedule?
Yes. Our comments are organised below by clause, covering both direct textual issues and consistency findings against the Business Process Diagrams (Annex D) and the machine-readable API specifications. §2.7, §2.8: data accuracy and data-use disclaimers. RECCo gives no warranty as to EDH data accuracy or as to ATPs’ appropriate use of data. This is understandable in isolation, given RECCo does not generate the underlying energy data in a hybrid architecture. Read together with §7.18 (below), however, it goes further than declining to warrant accuracy: RECCo’s own monitoring and reporting approach is stated not to measure EDH data accuracy at all, meaning no party in the governance structure is watching for a systemic accuracy problem, not merely declining to accept liability for individual errors. Our more significant concern, set out fully at critical issue 4, is separate from EDH data accuracy: it concerns the accuracy of CCS’s own identity, occupancy, and Registrable Measurement Point matching (using the Electricity and Gas Enquiry Services), which is critical to the legal validity of the Permission itself, with liability for any error in that matching falling on the ATP or EDH rather than RECCo. Process tables: “Not defined” appearing 20 times. Across the onboarding process (§3.6.3, 3.6.5, 3.6.10, 3.6.11), the Shared Signals Framework verification process (§3.9.7), and the Grant/Revoke/Renew/Query operational tables (§14.3.4–14.3.7, 14.3.13, 14.4.2, 14.4.7, 14.4.10–14.4.12, 14.8.4), the “Interface/Means” column, which is meant to state the actual technical mechanism for that step, is simply recorded as “Not defined.” This is a systemic gap, not an isolated drafting slip, and it matters because breach of the related paragraphs constitutes an Event of Default: an applicant can be found in default of a process step whose own governing document does not yet specify how that step is meant to be carried out. §3.7(d), §3.9.5-§3.9.7: Shared Signals Framework participation for EDHs. We note positively that this is a well-specified mechanism: SSF participation for an EDH is self-determined based on its own processing arrangements (whether it needs to confirm permission status at a point where no access token is presented), backed by a clear verification heartbeat (at least daily, no more than once per 60 seconds) and a defined consequence for a missed verification (treat the channel as unhealthy and suspend notifications). This resolves what would otherwise look, from the Business Process Diagrams alone, like an unaddressed gap in the revocation/query safety net for EDHs without SSF configured. The residual gap is that nothing in the drafting audits whether an EDH’s own determination that it does not need SSF was actually correct. §5.3, §5.4: revocation during ATP suspension. Suspension of a CCS User’s access does not revoke the permissions associated with it, and the ATP cannot in any case obtain new access tokens while suspended, so a delay in processing a revocation has no immediate practical effect. The concern is what happens once the suspension is lifted: where a consumer contacted a suspended ATP directly to revoke, the ATP can only notify CCS of that revocation “within 1 Working Day of its own CCS access being restored”, meaning that if this notification is missed or delayed, the ATP could resume accessing data under a permission the consumer had already, and clearly, asked to end. We ask RECCo to confirm what safeguard exists to ensure a revocation raised during suspension is actually processed before, or immediately upon, the ATP’s access being restored, rather than relying solely on the ATP’s own subsequent notification. §5.8: CCS Provider’s certificate-revocation discretion. The CCS Provider may revoke a CCS User’s certificate “in its sole discretion, to mitigate the risk of a security breach,” reporting to RECCo only “within two Working Days” after the fact. No right of challenge or compensation for the affected CCS User is described. We ask RECCo to introduce a proportionate check on this power, given its potential to remove a CCS User’s market access unilaterally and without recourse. §7.14, §7.15: retry strategy and error resolution. The 12-hour retry ceiling for CCS Market Messages is materially longer than the equivalent 2-hour ceiling the CCS Service Definition sets for CCS-originated Shared Signals event delivery (§7.3), with no explanation for the asymmetry in either direction. Separately, §7.15 refers CCS Users to the “CCS Error Resolution Paths document” once the retry strategy is exhausted; this document is not published in this consultation bundle. §7.16-§7.19: monitoring explicitly excludes data accuracy. We address this primarily under Q7, given it concerns the monitoring and reporting approach directly, but note here that §7.18’s confirmation that “monitoring is limited to compliance with the CCS Arrangements and does not measure the accuracy of the Energy Data shared by EDHs” reinforces the §2.7/§2.8 disclaimers above: this is a deliberate design choice, not merely an unavoidable consequence of the disclaimer. As with §2.7/§2.8 above, this provision is framed around EDH energy-data accuracy; it does not address the separate and more significant question, at critical issue 4, of who is accountable for the accuracy of CCS’s own identity and matching outputs. §9.5 vs. API Technical Specification §3.43: data scope duty. The Arrangements Schedule’s data scope duty on EDHs (“consistent with the scope of the Permission defined in the Access Token”) is broader than the API Technical Specification’s narrower field-level redaction wording. The two are not contradictory, but neither cross-references the other, and we ask that they be aligned or explicitly reconciled. §9.6 vs. §9.7: EDH permission-record obligation. These two paragraphs are directly contradictory. §9.6 requires an EDH handling scheduled or future-triggered Permissions to “record the Grant Id and Permission Expiry Date.” §9.7 states “An EDH shall not hold its own record of the Permission.” Unless the intended distinction is between a minimal identifier/expiry cache and a fuller record, which is never stated, an implementer reading §9.7 in isolation would reasonably conclude §9.6 does not apply to them. We ask RECCo to reconcile this directly. §10.3(h): new Data Product governance. We welcome that the Data Product Proforma review criteria explicitly ask “whether a single organisation is providing a bespoke data set or multiple organisations are providing access to a standardised set of data.” This is the correct governance question for a scenario we identify at Q12 below (an ATP obtaining the same data from two independently qualified EDHs under one consent), but note that no corresponding technical safeguard exists in the API design to enforce whatever this governance review concludes. §11 vs. the (unpublished) Revocation Reason Catalog. The Permission Purpose Catalogue is given a fully governed, versioned, and published change process. The Revocation Reason Catalog, a comparable controlled value list that an ATP must comply with on every revocation call, is given no equivalent governance anywhere in this document set. We ask that it be brought under the same standard of governance and publication. §13.1: the two-identity-model split. We note this as the clearest statement in the pack of the deliberate distinction between occupier-led verification (Metered Data) and account-holder-led verification (Account Specific Tariff Information). See Q12 for the consequence of this split not being reconciled in the multi-dataset permission design. §13.4: mandatory three-year re-verification. We ask RECCo to confirm what happens to an existing, enduring permission if a consumer’s mandatory three-year occupancy re-verification cycle fails, given the no-fallback gap identified as critical issue 5 above, this converts a one-time onboarding risk into a recurring risk across the entire verified user base. §13.5: gas referenced in the core matching process, apparently a drafting hangover rather than a live scope decision. RMP matching is stated to use data from “the Gas Enquiry Service and/or Electricity Enquiry Service,” notwithstanding that gas consumption data and MPRN matching are stated elsewhere (including in the Product Roadmap) to be a “Later,” post-MMP capability, and notwithstanding that no Gas Data Access Matrix appears to have been produced for this Change Proposal (see Q14), which would be expected if gas were genuinely in scope. Our working assumption is that gas is not in fact in scope for this Change Proposal, and that this reference, along with the schema references at Q12, is a holdover from earlier design work rather than a live design decision. If that is correct, we ask RECCo to remove or clearly caveat these references so the document does not read as though gas matching is currently supported. If gas is in fact intended to be in scope, we ask RECCo to confirm this and to produce the corresponding Gas Data Access Matrix. §14.7.7, §14.7.8: cross-ATP cascade on move-out. Where an ATP revokes a permission because it believes the consumer is no longer the occupant, a belief that may be based solely on the ATP’s own internal records with no independent check required, CCS pushes a “Permission Verification Required” notification to every other ATP holding an active permission for that same occupancy. We welcome that receiving ATPs are required to independently re-confirm with the consumer rather than auto-revoke, but note that the triggering condition itself carries no quality bar, meaning a single ATP’s mistaken internal record can generate unnecessary re-confirmation friction for a consumer across every unrelated service they use. CCS Provider (Raidiam): no direct obligation to CCS Users. Every CCS Provider obligation in this Schedule is expressed as an arrangement RECCo has made, not as something a CCS User can enforce directly against the Provider. The actual contract governing what the CCS Provider owes for a platform failure sits in a private service-provider agreement outside this Code and outside CCS Users’ visibility or enforcement rights. We ask RECCo to consider whether CCS Users should have some form of direct recourse against the CCS Provider, proportionate to how central this infrastructure is to their ability to operate. Appendix 1: coercive-control mitigation. We welcome the strong general provisions in Appendix 1 (the prohibition on manipulative or coercive design, and the bar on making Permission a condition of an unrelated service). However, the one substantive mitigation for the multi-occupancy coercive-control risk identified as critical issue 6 above, a requirement that the person granting Permission be told other occupants may object, asks the potential source of coercion to disclose to the person who may need protection from them, and does not appear anywhere in the Consumer Experience Guidelines that are meant to guide how ATPs actually design this journey (see Q10). Multi-occupancy dispute mechanism. We ask RECCo to address, as a matter of policy rather than only technical process: (i) what happens where one occupant grants a permission and a second occupant repeatedly queries or withdraws it, is there any limit on this cycle, and is the granting occupant notified; (ii) whether a verified occupier logging into the Consumer Portal sees all consents associated with the property or only a subset; and (iii) how a dispute is intended to resolve where the ATP has installed physical equipment under a live, separate contract (for example, a “rent-a-roof” solar arrangement) and remains contractually obligated to maintain data access notwithstanding CCS’s immediate termination of the underlying permission. We also ask RECCo to confirm whether the immediate, no-notice termination mechanism could itself expose an ATP to a breach-of-contract claim from a consumer it was validly serving, given the ATP is not a party to the dispute that triggers termination. Occupancy scope: short-term lets and vacant premises. We ask RECCo to clarify how “occupancy” is defined for short-term letting arrangements (for example, Airbnb-style lets): whether only the current short-term occupant may grant permission, whether a non-resident landlord may do so instead, and if so what cut-off period applies, and what the position is where the premises are vacant between lets. Domestic/non-domestic misclassification. We ask RECCo to confirm what appeals or correction process, if any, applies where a premises is misclassified as domestic Metered Data when it is not (or vice versa). GDPR liability. See critical issue 4. We ask RECCo to state clearly who bears liability where a CCS-asserted fact (identity outcome, occupancy confirmation, RMP match) is subsequently found to be wrong, and an ATP or EDH has relied on it in good faith. At present, CCS creates a prescriptive, mandated route to obtaining and evidencing consent, while liability for anything that goes wrong within that route remains entirely with the ATP or EDH. “Grant” / “Grant Id” and “Class A/B Receiver” undefined. Both terms are used constantly and centrally throughout this Schedule, the API Technical Specification, and the OpenAPI schemas, but neither is formally defined anywhere in this consultation pack, including in the Schedule’s own table of new definitions proposed for transfer to Schedule 1. We ask that both be added. Guest journey removal and move-out cascading. We ask RECCo to confirm whether an ATP’s notification that a consumer has moved out cascades to withdraw every permission that consumer holds with every ATP, or only the reporting ATP’s own, and whether a suspension-style model (rather than immediate termination) might be more appropriate here than the immediate-termination approach chosen for the multi-occupancy dispute scenario above.Q4: Do you have any comments on the redlined changes to REC Schedule 10 ‘Charging Methodology’?
Yes. First, the funding rationale set out for the initial charging period rests explicitly on CCS participation remaining voluntary, in order to avoid placing disproportionate costs on early adopters. As set out at Q1 and critical issue 10, this premise is already in tension with the fact that CCS use is mandatory today for Tariff Interoperability suppliers, and is expected to become mandatory more broadly through Data (Use and Access) Act secondary legislation outside RECCo’s control. We ask RECCo to set out what happens to the charging methodology once that voluntary-participation premise no longer holds, rather than leaving the position to be revisited only when it arises. Second, we note that no defined trigger or date exists for reviewing the CCS charging model even on its own terms: RECCo’s position is to “keep the CCS charging arrangements under review as adoption of the service develops,” with any future shift to user-pays or transactional charging implementable via a Charging Statement update rather than a full REC Change. We ask for a specific, time-bound review commitment. Third, CCS’s own charging section (paragraph 10) is markedly thinner than the equivalent provisions for other REC Services. It amounts to two short paragraphs stating that costs will be recovered from Energy Suppliers and that a schedule of charges will be provided, with no apportionment methodology between individual suppliers. By contrast, the Electricity Enquiry Service charging methodology (paragraph 3) sets out a full apportionment formula banded by network size. We ask RECCo to specify, in equivalent detail, how the CCS supplier charge will be divided between individual suppliers. Fourth, we note as a competitive-fairness point that CCS costs recovered through supplier cost-mutualisation, which RECCo itself acknowledges “may ultimately flow through to consumer bills”, mean that a Supplier ATP pays both its own direct accreditation costs and a mutualised contribution to CCS’s central costs, while a non-supplier ATP (a fintech, aggregator, or comparison service) pays only its own direct costs. In effect, suppliers subsidise market access for organisations that compete with their own services. We ask RECCo to address whether this is the intended effect of the charging methodology.Q5: Do you have any comments on the redlined changes to REC Schedule 9 ‘Qualification and Maintenance’?
Our principal comment on Schedule 9 concerns the same point raised at Q6 below: the risk-based cost bands for accreditation are tied to a risk-tier classification whose assignment methodology has not yet been published. We ask that Schedule 9 and the ISDP Assessment Approach be read and finalised together, so that an applicant reading Schedule 9 alone is not left unable to estimate its own likely qualification cost.Q6: Do you agree that the ISDP approach, including the draft questions and the considerations used to assess individual risk levels, provides an appropriate level of assurance to mitigate the risk of data protection and/or information security breaches?
In part. We welcome that a genuine, detailed per-question evidence rubric exists, covering company information, data handling, security controls, governance, incident management, regulatory compliance, and third-party controls, each with distinct evidence expectations at High, Medium, and Low risk. We also welcome the outcome-based framing (an applicant may demonstrate equivalent controls rather than a specific prescribed technology), the full exemption for Registered Tariff Interoperability Users, and the sensible deduplication of assessment effort for organisations already holding ISO 27001 certification or existing supplier/network-operator/enquiry-service qualification. However, we do not consider the approach yet provides an appropriate or predictable level of assurance, for the following reasons. The mechanism for assigning an applicant to a risk tier is not defined. The document lists seven factors relevant to risk (role, data sensitivity and purpose, security maturity, downstream sharing, volume, third-party reliance, and incident history) but states that RECCo “continues to consider how these factors should be weighted,” with the final approach to be informed by this very consultation. Because the accreditation cost bands are directly keyed to risk tier, an applicant cannot know in advance what it will need to pay or how much evidence it will need to produce. We ask RECCo to publish the weighting methodology at the same level of detail as the per-question evidence tiers before this element of the design is finalised. Even the lowest risk tier represents a substantial documentary burden, though not all of it is attributable to CCS itself. The Low-Risk evidence expectations include a Data Protection Impact Assessment and a documented process for handling data subject rights requests, both of which reflect existing UK GDPR obligations (Articles 35 and 15 to 22 respectively) rather than requirements CCS has newly created; we do not object to evidencing these. The remainder of the Low-Risk list, a documented incident response policy, a written description of the applicant’s data governance approach, a documented risk register, a documented staff training policy, and a description of physical security measures, has no equivalent statutory basis and is demanded from every applicant from scratch, regardless of an applicant’s eventual risk classification. The High-Risk tier is calibrated for a large, formally governed organisation, not the smaller organisations this programme states it wants to serve. The High-Risk evidence for data governance includes “a formal Data Governance Committee, recent meeting minutes from relevant committee… a Responsible, Accountable, Consulted and Informed (RACI) matrix.” This is realistic for an energy supplier or a large aggregator. It is a serious stretch for the archetypes the Consumer Experience Guidelines themselves identify as important CCS users, “an insulation scheme, local authority, or energy charity”, and no visible mechanism lets such an organisation assess in advance whether ordinary business arrangements (for example, downstream data-sharing with an installation partner) would tip it into that tier. Existing suppliers benefit from both deduplication and a lighter compliance bar, while new entrants receive neither. We support proportionate deduplication of assurance work already completed elsewhere. We note, however, that this sits alongside the supplier cost-mutualisation funding model addressed at Q4: already-qualified suppliers benefit from both a lighter ISDP assessment and RECCo’s central costs (funded via suppliers), while a genuinely new entrant faces the full, unscoped assessment with no equivalent credit. We ask RECCo to address the tier-assignment methodology gap as a priority, since it currently prevents any applicant from meaningfully assessing the cost of participation, the single largest barrier to entry identified across this response.Q7: Do you agree with the monitoring and reporting approach and that this should be reflected in a future change to the Performance Assurance Reporting Catalogue?
Not without amendment. The CCS Arrangements Schedule states plainly that “monitoring is limited to compliance with the CCS Arrangements and does not measure the accuracy of the Energy Data shared by EDHs.” Combined with RECCo’s disclaimer of any warranty as to EDH data accuracy, this means no party within the CCS governance structure is monitoring for a systemic data-accuracy problem, even in aggregate and even without RECCo accepting liability for individual instances. We also note that no REC-governed data item exists anywhere in the Energy Market Data Specification for the actual energy values shared under a permission (only for the surrounding consent and permission-management messages), meaning the current data-specification framework could not, in its present form, support an accuracy-monitoring capability even if RECCo wished to introduce one. We ask that the future change to the Performance Assurance Reporting Catalogue include, at minimum, aggregate monitoring of EDH data-accuracy complaints or corrections (without RECCo thereby warranting individual accuracy), so that a systemic problem would be visible to RECCo and the REC Performance Assurance Board even where individual liability remains with the EDH. We also ask that it extend to monitoring the accuracy of CCS’s own identity, occupancy, and RMP-matching outputs (see critical issue 4), since these are outputs of CCS itself rather than of any individual EDH, and no other part of this consultation identifies who would monitor them.Q8: Do you have any comments on the redlined changes to the EES Service Definitions?
We have not identified specific issues with this document in the course of this review and have no comments to add beyond those already raised regarding the Electricity and Gas Enquiry Services’ role in RMP matching (see Q3, §13.5, regarding the apparent inclusion of gas matching ahead of gas being confirmed as in scope for MMP).Q9: Permission purposes currently used or expected to be used within your organisation
[This question requests organisation-specific information about our own data-access purposes rather than comment on the drafting, and is addressed separately from this document.]Q10: Do you have any comments on the draft Consumer Experience Guidelines?
Yes, and our concerns here are more significant than the main consultation document’s own narrative on this document suggests. Household cross-visibility is confirmed as a designed feature, with no safeguarding framing at all. The Guidelines state plainly that a consumer can, via the Consumer Portal, see permissions linked to their address that may have been granted by someone else, and can raise a query or complaint against one they did not grant. This is presented as ordinary transparency. As set out at critical issue 6, the one mitigation for the coercive-control risk this creates, a requirement that the person granting permission tell other occupants they may object, exists only in the Arrangements Schedule’s Appendix 1 and does not appear anywhere in these Guidelines, meaning the document that is meant to shape how ATPs actually design this consumer journey never surfaces the one safeguard that exists. No content anywhere addresses a consumer being declined by the system. We searched this document specifically for content addressing identity or occupancy verification failure. The only relevant content concerns a consumer choosing to decline permission; nothing addresses what a consumer sees, is told, or can do when the system is unable to verify them: the population we estimate, from published ONS and credit-reference data, at over a million people at any given time (see critical issue 5). Given this consultation’s own user-experience research identifies onboarding and verification as the area most likely to drive consumer drop-off, we consider this a significant gap. The illustrative screens are not available for consultees to assess. Section 5 of the document is marked “Placeholder - to be included post consultation.” Consultees are accordingly being asked to endorse the layered-information and consumer-journey approach described in the main consultation document without being able to see any actual example of it. The contents page references content that does not exist in this version, though we understand why. Section 6, “ATP Energy Data Subject Experience Requirements,” is listed in the contents page but does not appear in the document body. Appendix 1 of the CCS Arrangements Schedule, which is included in this consultation bundle and which we have reviewed directly, contains this content in full; the contents page should simply be corrected to remove the stale reference. Other findings. We ask RECCo to clarify: whether there is any route for a consumer to challenge or correct a mismatch between the address they provide and the Registrable Measurement Points CCS identifies, particularly given known, longstanding data-quality issues in industry address-matching records; what the “unverified” account status referred to in the Business Process Diagrams means and how a consumer returns to verified status from it; and why the Business Process Diagrams show the consumer, rather than the ATP, as typically initiating the renewal conversation, which is inconsistent with these Guidelines’ own description of ATP-initiated renewal notification as the standard mechanism. We also repeat, in this context, the data-minimisation question raised at critical issue 12 and at Q12: given that what is operationally required is confirmation of occupancy (or account-holder status for tariff data), we ask RECCo to justify why full verified identity, a name, is required at all, rather than only the narrower fact that is actually acted upon. We welcome, and wish to record positively, the strong general provisions against manipulative or coercive design and against making Permission a condition of an unrelated service, and the requirement that an ATP disclose which EDH a consumer’s data is sourced from.Q11: Do you believe consumer-facing screens should use the term ‘permission’ to align with the REC drafting or use the term ‘consent’?
We do not have a strong position on this specific terminology question and would defer to RECCo’s own consumer research, save to note that whichever term is chosen should be applied with full consistency across the CCS Arrangements Schedule, the Consumer Experience Guidelines, and the API Technical Specification, in a way that the “Grant”/“Grant Id” and “Class A/B Receiver” definitional gaps identified elsewhere in this response (Q3, Q12) suggest has not always been the case for other core terminology.Q12: Do you have any comments on the content of the CCS API Technical Specification?
Yes. We reviewed both the published prose specification and the machine-readable OpenAPI companion files published via the RECCo Developer Portal, and comment on both together. The specification’s own supporting normative documents are not available. The OpenAPI files state repeatedly that they are illustrative only and “impose no requirements”: the actual binding obligations sit in a Security Profile and an SSF Profile (one supporting file even references a Supplier ID&V Security Profile by relative file path), none of which are included in this consultation. Several of the points below may be resolved in those documents; we ask that they be published so this can be properly assessed. An Energy Data Holder identifier is supplied by the ATP before verification has taken place, and is never reconciled against the verified result. The permission schema requires the ATP to specify, at the point it pushes its initial authorisation request, which Energy Data Holder holds the relevant data, before the CCS has performed identity verification, occupancy verification, or Registrable Measurement Point matching for that consumer. The CCS validates only that the identifier named is a real, Qualified Energy Data Holder for that Data Product type; it does not cross-check the ATP’s choice against the Energy Data Holder that the CCS’s own later verification and matching process establishes as actually responsible for that consumer’s data. This creates no risk today, because only one Energy Data Holder exists for domestic half-hourly electricity data. It becomes a genuine correctness problem, not merely a duplication risk, the moment a second Energy Data Holder is accredited for the same Data Product: an ATP would need to correctly identify the right Energy Data Holder before the CCS has even confirmed who the consumer is, with no safeguard to catch an incorrect choice. We ask RECCo to specify how this will be resolved before a competitive market for any Data Product develops. A required revocation-reason value list is not published, and the field’s own status is inconsistent between documents. Every revocation call in the API Technical Specification requires a reason drawn from a catalogue that the specification states is “maintained by RECCo separately from this schema” and is “not enumerated here.” Separately, the Business Process Diagrams show the consumer providing a revocation reason as optional (“Optional: consumer provides revocation reason”), while the API schema treats the reason field as required on the call itself. We ask RECCo to publish the catalogue, bring it under equivalent governance to the Permission Purpose Catalogue, and clarify how an ATP is expected to populate a required field when the consumer providing the underlying reason is, by design, optional. Gas appears in the schema, most likely as a drafting hangover rather than a live design decision. The permission schema’s fuel-type field includes gas as a valid value, and the schema’s enrichment fields include a fully-specified gas metering-point identifier alongside the electricity equivalent, despite gas data being described elsewhere as a “Later,” post-MMP capability, and despite no Gas Data Access Matrix having been produced alongside the Standards Definition Document redline for this Change Proposal (see Q14). Taken together, this points to these references being carried over from earlier design work rather than reflecting a decision to bring gas into scope. We ask RECCo to confirm this and, if so, to remove the gas-related fields from the schema until gas is genuinely brought into scope through its own Change Proposal, rather than leaving them live and unused. The 30-minute maximum access-token lifetime is not clearly bound for the first token issued under a new grant. The validation rule stating the 30-minute maximum is attached to the schema for tokens issued via a refresh, in both places it appears, but its wording commits only to bounding tokens “issued through the refresh token grant”, not the very first token issued immediately after the consumer’s initial grant, which relies only on a non-binding illustrative example value. We ask this to be corrected so the rule applies explicitly and normatively to the first token as well. Therequest_uri lifetime given in the OpenAPI companion (60 seconds, by illustrative example) is not stated as a binding requirement anywhere. If 60 seconds reflects the intended policy, we ask RECCo to confirm this normatively and to consider whether it is workable in practice, given the redirect journey it must accommodate; if it does not reflect intended policy, we ask that the illustrative example be corrected so it does not mislead implementers.
The CCS-to-identity-verification-provider interface, and the Registrable Measurement Point matching interface, are not specified anywhere in this document set, despite identity and occupancy verification being the single most contested element of the design to date.
Two separately-issued identity tokens are not reconciled. The CCS’s own identity flow and the Energy Supplier’s Account Holder Verification flow both issue identity assertions for the same consumer, using different identifiers, with no stated mechanism for resolving a conflict (for example, an Energy Supplier’s identifier already linked to a different CCS account) and no corresponding error code defined for this case. Relatedly, the enrichment fields carrying verified meter-point identifiers carry no flag indicating whether they were established via the occupier-led or account-holder-led verification route, meaning a single permission combining both a Metered Data and a Tariff Interoperability entry provides no way to confirm the same verified person satisfied both roles; see Q3, §13.1.
One error code is used for at least six distinct failure causes (an expired authorisation code, a reused code, a code issued to the wrong client, a PKCE mismatch, a revoked refresh token, and an expired underlying permission), with only optional descriptive text to distinguish them, in contrast to the mandated, distinguishable description strings provided for the equivalent access_denied error. We ask for equivalent precision to be applied here.
The interface through which an Energy Data Holder actually provides Energy Data to an Authorised Third Party is not defined anywhere in this document set. We understand this is intended to sit within the Energy Market Data Specification; see Q13.
We would also repeat critical issue 11 here directly: the security architecture (FAPI 2.0, mutual TLS, 30-minute tokens, resource-scoped per-holder tokens) is justified on proportionality grounds, yet the sole Energy Data Holder in scope for MMP updates its data once per day. We ask RECCo to clarify what data-freshness requirement this model is actually sized to protect.
We note positively that consumer identity “hints” supplied by an ATP to assist matching (name, email, mobile number) are explicitly discarded before reaching the Energy Data Holder, with the CCS’s own verified identity always taking precedence, a genuinely good data-minimisation design choice on the Energy Data Holder-facing side of the transaction. This does not resolve the broader data-minimisation question we raise at critical issue 12 and at Q10: why full identity needs to be established by CCS at all, given the party ultimately relying on the Permission never receives it.