Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer. 

Thank you for considering our submission.

Call for Evidence response:

Theme 1 – Accessing and using data

Question 1: What are the challenges you face, or can foresee emerging, when accessing and using personal and non-personal data when developing or using AI and data‑intensive technologies? 

Icebreaker One (IB1) is an independent, nonprofit organisation working to make data sharing trusted, interoperable and scalable across sectors and markets. We support the development of  data governance, trust frameworks, and policy mechanisms that enable AI and make it possible to deploy other data-intensive technologies responsibly. 

IB1 convenes organisations across energy, finance, water, transport and agriculture to co-design and implement governance, trust frameworks and technical infrastructure required for secure, operable data flow. Our approach is grounded in practical implementation: defining data purposes and rights, establishing roles and responsibilities, creating common standards, assuring participants and data, and making data flows auditable. We do not access or use large amounts of data ourselves, but we help design and operate ecosystems that enable economy-scale data sharing.

The IB1 NOVA principles – Networked, Open, Verifiable Architecture – guide our approach to data sharing governance and associated responsibilities. This approach recognises that trusted data sharing requires more than technical infrastructure: it requires coordinated governance, clear rights and responsibilities, interoperable systems, and transparent, adaptive rules. In many use cases, relevant data is distributed across multiple organisations and across sector boundaries. Unlocking value and investment depends on trusted interactions between many market participants with different characteristics. NOVA guides us to consider architecture supporting trusted, permissioned and auditable data flows in a manner that reduces friction, supports open participation, and encourages scalable reuse of data and data-sharing infrastructure. It provides the foundation for aligning technical, legal, policy and commercial requirements needed to turn fragmented energy data into a trusted, usable and investable resource within a thriving wider digital ecosystem.

IB1 sees data governance as an enabling layer for AI. Our work has demonstrated that clear, machine-readable rules, trusted identities, provenance, permissions and assurance can reduce friction while strengthening protections. This is exemplified by Project Perseus: the UK’s first cross-sector Smart Data Scheme that enables assured smart meter data to flow from energy providers through carbon accounting platforms to financial services, supporting SMEs to access green finance. Perseus embodies the importance of permissions, identity, provenance, licensing and data rights needed to operate data flows across organisational boundaries. 

Chapter 3 on Responsible AI from Stanford HAI’s 2026 AI Index Report makes clear that AI and data governance is lagging behind AI capabilities, and the gap is widening. AI, and agentic AI in particular, requires tighter definition on elements of data protection than are typically used by organisations in their policies, and the policies must be capable of being exercised reliably by machines in real-time to govern AI workflows. The majority of UK organisations lack the legal, governance and technical expertise to design, implement and monitor such policies, with Trustmarque reporting in 2025 that 93% of UK organisations use AI, but only 7% have fully embedded governance. Standards in this area are at best emerging, and typically based on security, rather than data protection, concerns. 

Organisational immaturity with data governance is compounded when data is shared and combined across data ecosystems. Data users need clear signals to establish which data they can access, whether the data is trusted, what rights they have to use the data and how those permissions and responsibilities evolve once data flows across data ecosystems. Poorly defined rights can both stifle legitimate use of data and open the door to data misuse.

Question 2: Regarding data protection, how do you assess and justify the lawful use of personal data in these contexts?

Lawful use of personal data in AI and other data-intensive technologies is not fundamentally different from lawful data use elsewhere. IB1’s approach treats data governance, communications and stakeholder engagement as interconnected parts of responsible data use. We establish clear purposes, make them accessible to data subjects, and maintain trust as data is reused, shared, and applied in various environments. This is why communication is an inherent part of data governance that is always incorporated in our work: members and external stakeholders define how the Scheme is communicated to participants, regulators, and the public. This manages the ongoing narrative that sustains engagement and maintains trust over time as data use, technology and stakeholder expectations evolve.

IB1 supports the integrated framing of AI governance and data governance. It is important to note that personal data is not the only type of data subject to data protection regulation. For example, business smart data enabled by the Data Use and Access Act, and intellectual property protection frameworks, must also be taken into account. 

Question 3: How appropriate are the data protection framework’s definitions/obligations outlined above and are they likely to remain fit for purpose as data-intensive technologies continue to evolve?

No response 

Theme 2 – Data quality, accuracy, and downstream impacts 

Question 1: What approaches do you take in practice to assess and ensure the quality and accuracy of data, including personal data, and what challenges do you encounter?

No response

Question 2: How do you assess and manage fairness and impacts on individuals when using AI or other data‑intensive technologies?

No response

Question 3: How appropriate are the data protection framework’s principles of fairness and accuracy when applied to data-intensive technologies, and are they likely to remain fit for purpose as these technologies continue to evolve?

No response

Theme 3 – Governing data use across organisations 

Question 1: How do you collect and then govern data across supply chains or between organisations in practice, including allocating responsibility and enabling data sharing or access?

IB1 distinguishes between data collection/processing and data governance. In trusted data sharing ecosystems, the organisation(s) that  govern how data is accessed, shared, reused or managed are often not the ones that collect, hold or process the data itself. Effective data governance depends on clear, agreed and enforceable rules for how data can be used and shared in compliance with existing regulatory frameworks.

Our work defining and operating schemes and trust frameworks provides a practical example of this approach. A scheme defines what can be shared, why, by whom, how, and what protections exist. This gives organisations confidence that they can process and share data within the trust framework that underpins the scheme. While this can be achieved through bilateral data sharing agreements between participants, a more scalable and interoperable approach is to enact multilateral scheme-wide agreements that anchor the scheme rules and governance processes for all participants. IB1 has developed formal machine-readable definitions of scheme rules that are used by scheme participants to develop and maintain compliant, assured data services within the scheme.

A mutual understanding of the purpose for data sharing is key to governing data sharing. It underpins assurance, participant credentials, access control (including for agentic use), licensing and liability, and ensures clear scheme boundaries. Human users, and their AI agents, need a clear understanding of whether they can access the data, are allowed to use it for their intended purposes, and can rely on it for those purposes. Without clarity of purposes, these determinations are hard or impossible to make. Work is ongoing at IB1 to develop decision-making approaches and supporting information such that machines can determine reliably whether their intended purpose and processing aligns with the rights the organisations that operate the machines hold to the data.

The NOVA principles outlined in our response to Theme 1 Question 1 provide a structure for considering whether the architecture and governance of an ecosystem support networked, open and verifiable data exchange. Schemes and Trust Frameworks provide a mechanism for achieving this at scale while approaches like NOVA principles help assess whether the resulting ecosystem is capable of supporting trustworthy, interoperable and sustainable data sharing. 

Question 2: How do you approach automated decision-making, and will this approach remain fit-for-purpose as technology advances?

Automated decision making requires three layers of governance: 

1. Definition & design: establishing clarity of the purpose for the decision, the data requirements for it, and the methodology to reach the decision.
2. Operation: applying the implementation of the design to a specific decision, ensuring the data on-hand is adequate, enacting guardrails, flagging or escalating anomalies, logging reasoning and decisions. 
3. Monitoring: ensuring that operation is delivering the design, enabling audit, supporting investigation and resolution of disputes, informing improvements, building trust.

The Perseus smart meter data scheme enacts these governance layers to enable SME energy consumption data to be used to inform eligibility for green finance. IB1 supports scheme governance through a well-defined process for convening, specifying and designing the scheme (we term this Icebreaking), and then using trust services to implement and publish the rules in formats that machines and humans can understand. Scheme monitoring is supported by auditability, traceability and provable permission. While this approach may require different tooling as technology advances, the three layers of consideration are likely to remain relevant.

In operation, automated decision-making is only as sound as the data underpinning it. Assurance that the data meets a defined quality bar, clarity about what the data actually represents and how it may be used, and provenance that traces the data back to its origin are all needed for effective decisions. Within provenance, particular weight should be placed on understanding how the data was gathered in the first place, including, critically, whether the data itself was generated or transformed through AI processing, since AI-derived data carries its own risk and quality profile that needs to be surfaced. This includes factors such as the model, the quality of the data used to train it, and the potential for biases to have been incorporated in the training data that would have a material effect on reasoning and decision making.

Particular attention should be paid when smart data is used in automated decision-making, because it must be constrained to the purpose agreed at the point the data was originally shared. The consent or permission under which it was collected has to travel with the data into whatever automated process later uses it. AI’s potential to unlock data-driven innovation has to be balanced against privacy, security, and ethical considerations. This is why IB1 advocated in its response to Ofgem’s AI Assurance in the Energy Sector consultation for AI models that respect consumer consent and data sovereignty using decentralised identity frameworks, that support open standards to ensure interoperability between AI-driven systems, and that embed transparency and explainability to mitigate AI biases and prevent regulatory fragmentation.

Question 3: How effective and appropriate are the data protection framework’s definitions in assigning responsibilities (e.g. controller/processor), and are they likely to remain fit-for-purpose over time as technology advances?

IB1 doesn’t perceive a current need to change the controller/processor responsibilities, but as set out in our response to DSIT’s consultation – Empowering people through data intermediaries, we agree that clarification of delegation has the potential to be beneficial to data subjects. However, any amendment to UK GDPR must be made carefully, in consultation with EU and other international data protection counterparts alongside operators of UK governance schemes that incorporate GDPR – such as Open Banking and the Smart Energy Code. In particular, the change must not put EU adequacy determinations at risk, as the economic and social impacts of a weakened or lost adequacy status are likely to be disproportionate to the benefit.

If UK GDPR is amended, the purpose of, and limits to operation of, data intermediaries need to be made clear in the drafting in order to build trust. The drafting should include requirements for them to be: 

1. Neutral – the purpose for the data processing cannot be set by the intermediary.
2. Fiduciary – acting strictly in the data subject’s interest, not in their own or a third party’s.
3. Permissioned – possessing reliable evidence for permission to act as delegate for a scoped purpose.

Theme 4 – Transparency and rights in complex environments

Question 1: What approaches have you found effective for providing transparency and for enabling individuals to exercise their data protection rights in complex data processing environments?

In complex data environments, transparency is more effective when the rules governing data use are openly published, structured and understandable. Open standards allow participants, regulators and individuals to understand how a data-sharing ecosystem operates, what purposes data can be used for, who has responsibilities and how rights can be exercised. They also reduce the need for organisations to develop their own approach to explaining complex data flows, decrease friction between organisations, support interoperability and make governance more scalable (Shaharudin et al., 2024). 

There is strong precedent for this approach in the UK’s Open Standards Principles: Open standards allow organisations of various sizes to compete fairly, enable citizens to audit data and decisions based on it, meet user needs, support sustainable costs and avoid vendor lock-in. 

This is reflected in IB1’s NOVA approach. At NOVA level 5, the trusted, open market is interoperable across the economy (a desirable default state for UK data infrastructure). 

In order for individuals to trust the systems of processing, transparency of operation is needed alongside transparency of design. Clarity about the identity and credentials of the organisations processing the data and their role in data processing for the given purposes is required. Signals indicating anomalous or adverse events must be surfaced and communicated to those affected, along with information on how they were corrected. As stated in our response to Theme 3 Question 2, data flows and processing must carry and retain enough information to enable audit and support the investigation and resolution of disputes.

Question 2: How effective are the data protection framework’s transparency requirements and data subject rights in the context of data-intensive technologies and will these remain fit for purpose over time as technology advances?

The boundaries of the data protection framework are being tested but not necessarily exceeded. IB1 highlights three areas where work is needed by those developing or deploying complex data processing technologies in order to bring their processing into line with the framework.

1. Explainable AI

When a data process is a “black box” making complex decisions without being able to provide reliable information about the data and processes that led to the decisions, data subjects cannot be given the transparency required by the framework.

2. Personal data in models and memory

When personal data is included in model training, many Rights of the data subject, including rights to access, deletion and correction, are not possible with current Large Language Model (LLM) implementations. If personal data becomes embedded when a model is training, the model cannot unlearn it on-demand. Ideally models should only be trained on text which was explicitly produced for public use (Brown et al., 2022). There is a growing practice of de-identification and private association editing but these are still not entirely effective (Venditti et al., 2026; Patil, Hase, and Bansal, 2024).

In addition to model training data, many LLMs carry contextual memory to aid processing for an interaction or sequence of interactions. This memory may contain personal data from the data subject, and controls must be provided for data subjects to access, correct or delete that data.

3. Agentic systems and delegation

Agentic developments and delegation require further exploration as a potential area of growing challenge to transparency. Effective governance should make the scope and purpose of delegated authority clear, including who is authorised to act, on whose behalf, for what defined purpose and within what limitations. Accountability for the actions of software or equipment always sits with those deploying and operating it, even when it is autonomous. It is these individuals or organisations that must be identified clearly. Open and interoperable governance approaches can make complex data ecosystems more transparent, accountable and scalable. 

Theme 5 – Effectiveness of data frameworks in regulating AI

Question 1: Overall, what is working well, where have you observed disproportionate or unintended barriers in practice, and where have risks to data protection arisen?

No response

Question 2: Are the existing data frameworks sufficiently adaptable to future developments in AI, and where might rapid technological advances give rise to future difficulties? Or are there any alternative approaches that may be more effective, both now and in the future?

As highlighted in our response to Theme 1 Question 1, AI and data governance is lagging behind AI capabilities, and the gap is widening. The challenge for current data frameworks is not that their requirements are inappropriate, but that governability isn’t being designed into the models, agentic systems and data sharing ecosystems that are being deployed, often at huge scale. Where advances in technology fail to demonstrate governability, they must be limited in application until appropriate controls can be provided.

Our responses throughout this consultation set out ways in which data sharing and processing can be made more trustworthy, transparent and compliant with existing regulations. Regulation must reinforce key principles in responsible AI such as clarity of purpose, machine executable rules enforced at the point of data processing, open and transparent processes, methods to prove correct operation, and clear routes to redress when systems fail.

As IB1’s work, including Perseus, demonstrates, there is significant scope to improve data protection, particularly where AI is involved, by supporting the rapid rollout of voluntary data sharing schemes based on common open standards, to provide clear rules, well-communicated purposes and meaningful assurance and accountability.  This would unlock data value while maintaining trust and transparency and reducing the risk that regulation becomes obsolete as technology evolves.

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer. 

Thank you for considering our submission.

Consultation response:

The Icebreaker One (IB1) NOVA principles – Networked, Open, Verifiable Architecture – guide our approach to data governance and associated responsibilities within the energy data landscape. This approach recognises that trusted data sharing requires more than technical infrastructure: it requires coordinated governance, clear rights and responsibilities, interoperable systems, and transparent, adaptive rules. This is particularly relevant to energy, where data is distributed across many organisations and across sector/vector boundaries, and where unlocking flexibility and investment depends on trusted interactions between many market participants with different characteristics. NOVA guides us to consider architecture supporting trusted, permissioned and auditable data flows in a manner that reduces friction, supports open participation, and encourages scalable reuse of data and data-sharing infrastructure. It provides the foundation for aligning technical, legal, policy and commercial requirements needed to turn fragmented energy data into a trusted, usable and investable resource within a thriving wider digital ecosystem.

Question 1: Do the data types in scope for each domain provide a complete representation of each domain?

The proposed approach and associated groupings have internal consistency. We agree that data requirements will evolve as the energy system and new use cases develop. The framework should ensure it retains sufficient flexibility to amend and expand domain scopes over time. A Digitalisation Coordinator could identify and address potential blind spots and cross-domain dependencies that may not appear when domains are defined primarily by data origination. 

We note that the current approach to data domains does not always consider data journeys, dependencies and how data is used in practice, including beyond the boundaries of the traditional energy system. This creates blind spots to energy-relevant data that exert critical influences on the practical running of the sector, particularly: 1) economic and market data, 2) demographic and behavioural data, 3) weather, climate and environmental data, 4) carbon reduction and net zero data, and 5) security data. It is difficult to provide a comprehensive set of suggestions as to how data under these categories are incorporated, as they likely extend beyond current domain categories as well as influencing the four existing domains. Categories such as carbon, weather and security data, for example, implicate all domains. 

Gaps in specific domains are addressed under Q3.

Question 2: Which domain is best placed to coordinate meter asset data, considering the use cases the data supports, governance arrangements and cross-domain interoperability? Please explain your reasoning.

We align with the position that there is significant potential for crossover between consumer and metering domains around meter asset data and note that this is reflected clearly when use cases or data journeys are considered. Whichever Domain Coordinators are assigned to lead, communication and alignment between associated domains will be essential. We suggest that this may be a role that the Digitalisation Coordinator is positioned to oversee as, in addition to this particular issue, it is likely that all domains will evolve over time and other remit boundaries are likely to come into question. The Digitalisation Coordinator could apply a consistent approach to identifying and managing where this occurs. One significant consideration when assigning the lead coordinator is the question of rights over the data. 

As domains and ecosystems evolve and become increasingly complex (e.g. due to AI application), the use cases and data journeys, rights and lawful bases for data access, and requirements for cross-domain interoperability should be considered. Identifying long-term data rights is critical to operational resilience. We suggest that the Digitalisation Coordinator may play a role in exploring this space, connecting with actors outside the sector who may use the data, and understanding data journeys / use cases which cross domain boundaries. This position does not mean that we advocate for a coordinator to overstep or take back power from the domains; rather, it is a practical note that such a body provides a useful vehicle for approaching inter-domain concerns such as those illustrated in this consultation.

Question 3: Are there any additional data types that should be included, or data types that could sit in alternative domains than their categorisation in Table 1?

We note several gaps and areas requiring clarity. Reflecting our position in Q1, five categories of data appear to be largely absent from the current model: 1) economic and market data, 2) demographic and behavioural data, 3) weather, climate and environmental data, 4) carbon reduction and net zero data, and 5) security data. We acknowledge that the four domains are framed as a starting point, therefore omissions are anticipated. However, given the importance of categories outlined above to energy system function and policy goals, we would welcome clarity from Ofgem as to the intended approach to integrating these areas in future – either within the existing four domains or in forming supplementary domains, and the associated time span for decisions.

Additional gaps within the current domain structure are outlined below:

Core energy system data: 

• We suggest the core system domain currently lacks acknowledgement of market/economic data pertinent to system operation and decision-making that informs this. While some of this is incorporated in balancing and settlement, the current phrasing risks interpretation as a primarily technical matter. Decisions pertaining to whole-of-market factors such as grid mix, generation patterns, fuel prices, interconnection and international markets are also important and do not yet have a clear home. 

Customer data domain: 

• The differentiations between data pertaining to domestic and non-domestic consumers are not always clear. While definitions may be intentionally inclusive at the current stage, there are differences which will require future clarification.
• Secondly, geographic, behavioural and demographic information – informing asset and energy use patterns, customer interactions, product and service development – is currently missing. While this data may be seen as supplementary to purely energy system functions, it is a key part of the economic landscape of the sector and has practical implications in regulation, for example reflected in Ofgem’s consultation regarding potential innovation exemptions to the Universal Service Obligation. 

Behind-the-meter asset domain: 

• Granular data concerning customer and asset behaviour and forecasting is missing from the behind-the-meter domain, which should be acknowledged under the operational data bullet. We note that providers of this data may sit outside the current regulated sector, however they are implicated in the SSES programme and critical to the achievement of policy goals for digitally-enabled system flexibility, DSO transition (e.g. localised balancing) and grid decarbonisation.

Question 4: Is the purpose of Domain Coordinators clear and sufficiently explained to guide delivery and accountability? If not, where is additional detail required? 

There is sufficient explanation to guide the purpose of the Domain Coordinators at a general level. Areas of technical, engagement,  governance and operational responsibility are clearly identified. We support the suggestion that outputs for each Domain Coordinator – data domain definition, stakeholder map and engagement strategy, and delivery plan – are published openly where possible. We also note that the current content does not explicitly include legal and licensing within technical delivery and accountability, and suggest that this must be specifically named; legal interoperability is a key driver for data liquidity which is often overlooked.

Question 5: Which areas of responsibility should transfer from Domain Coordinators to the future digitalisation coordination function? How could the transition be managed to avoid any duplication or gaps?

As flagged in Q1, we note a number of cross-domain data which currently do not have a clear home. We encourage Ofgem to consider the relationship of these horizontal data ecosystems to the four data domains as well as their relationship to the Digitalisation Coordinator.

Beyond this, we agree with the areas proposed in 3.13 for consideration of transfer to the Digitalisation Coordinator. We note that other potential areas of handover could include:

• Oversight of cross-domain engagement programmes and approaches to inclusion
• Identification and coordination of cross-domain use case development
• Identification and upward reporting of the emergence of new data domains and/or changes to existing domains (this is potentially part of the suggested horizon scan function)
• Coordinate cross-domain approaches/standards for licensing (as part of technical coordination) and integration thereof with the DSI
• Coordinate the application and interpretation of data rights across domains
• Coordinate Trust Framework interoperability within a federated landscape.

Question 6: Do you have views on the most appropriate regulatory mechanism for overseeing and enforcing the Domain Coordinators role?

Coordinators have significant influence over how data is defined, accessed, exchanged and governed, including through the development and maintenance of standards. All coordinators also lead development of infrastructure, platforms or work programmes supporting data exchange (DSI and CCS primarily, with Elexon’s DIP and future FMAR work of additional note). This creates a concentration of influence integrated across the data ecosystem in each domain. Given the breadth of influence that a Domain Coordinators have, appropriate regulatory oversight and safeguards will be important to ensure that this role is exercised transparently, proportionately and in the interests of the wider energy system – including decarbonisation goals and consumer outcomes. While we understand that Domain Coordinator embeddedness may create efficiencies, we suggest that it strengthens the argument for the Digitalisation Coordinator to hold a higher level of legal and organisational neutrality, as well as the behavioural neutrality expected from Domain Coordinators. We anticipate this will offer the advantage of an additional check/balance supporting regulatory controls.

We recognise – and support – that the data itself will remain decentralised with existing data holders. We suggest that this principle is formally written into oversight programmes for the coordinators, including the Digitalisation Coordinator.

We also recommend that safeguards outlined in the consultation must be complemented by explicit requirements around conflict of interest management, transparency, accountability, and separation of functions. This would help mitigate the risk of a coordinator inadvertently becoming a gatekeeper to data, standards or infrastructure. We suggest that Ofgem draws a clear distinction between where organisations are performing pre-existing market functions and where they are performing Domain Coordination functions – particularly if NESO is to be governed under existing Ofgem Expectations. This could be complemented by KPIs which are designed to evidence collaborative, domain-level improvement in addition to specific organisational deliverables. 

For governance of all Coordinators, we raise for consideration the potential for creation of a new, bounded licence type to support direct regulatory control. There is precedent for the establishment of defined, purpose-specific licences through the creation of the Smart Meter Communication Licence. As sector digitalisation evolves, considering a new purpose-limited type of licence for data and digital functions may hold advantages. However, this is not an area which has been subject to much exploration within existing policy, industry, or academic literature, suggesting that it may take time and resources to explore or establish. 

Question 7: Do you agree with the proposed funding approach for the Domain Coordinators role? If not, what alternative approach should be considered?

We support the proposed approach and nuance between different organisation types taking on Domain Coordinators roles. If investment in particular domains requires additional focus, funding models may need to evolve. Likewise, oversight from Ofgem will be required to ensure that Coordinators provide comparable value for money, even if responsibilities are non-identical. In considering value for money, we encourage Ofgem to measure contributions towards decarbonisation and consumer value in addition to financial metrics.

Question 8: What specific KPIs or success measures for digitalisation progress could be included to measure success of the Domain Coordinators role within each domain?

We broadly agree with the type of KPIs outlined in section 3.19 . However, these are only a baseline approach and we envisage them developing with more clarity as the coordinators take up work in this space. As outlined above, it is critical for KPIs to be tied to measurable progress at the domain level, within reason and relevant to the appropriate context, rather than relying solely on outputs delivered by the coordinating organisation. 

Areas in which KPIs could benefit from more specificity include:

• Ensuring there is an accessible feedback process for logging changes to the domain; for example, notifying the coordinator of new data assets or asset types.
• Publishing the criteria by which data quality is determined and assessed.
• Assessing balance within the engagement sphere to ensure an even spread of perspectives is included; ‘strong and active engagement’ does not necessarily require this to be open or representative.
• A commitment to regular review/challenge of governance arrangements to empower the Coordinators to act with agility.
• KPIs assessing the impact of Coordinator activity on decarbonisation and delivering customer value would be useful for tracking how digital progress interacts with wider sector objectives.

Question 9: Do you agree with the proposed governance decision-making, reporting and oversight arrangements for Domain Coordinators? Are these clear and proportionate? If not, what should be changed?

On decision-making:

• Evidencing engagement is an important part of these requirements. Reflecting our comments in Q12-14, there are certain gaps in the engagement model which require attention prior to relying on engagement as a source of validation.
• We support the proposed position to work with existing code, license or governance arrangements where possible. We query how the Domain Coordinators will interact with these mechanisms where remits exceed the definition of the data domain – for example, where using existing avenues may engage stakeholders or surface use cases that extend beyond one individual domain. Defining the approach to these instances will also be relevant for defining the role and remit of the future Digitalisation Coordinator.
• We encourage openly published meeting minutes and decisions wherever possible, alongside quarterly reporting to named stakeholders. The quarterly reporting may be in more depth or surface higher sensitivity information. 
• Decisions referred to the Digitalisation Board under 4.5 may implicate the Digitalisation Coordinator in future.

On quarterly reporting:

• We encourage open publication of reports wherever possible, with clear rules as to where information is redacted or edited for public consumption if it is sensitive. Consistent application of these rules is helpful for supporting a coherent approach to transparency and disclosure in a multi-actor system.

Upward reporting and decision-making:

• We agree that the role of the Digitisation Delivery Group (DDG) and relationship to Domain Coordinators is clear and appropriate. 
• References to the future role of the Digitalisation Coordinator providing a preparatory and advisory function match our expectations of the role and its utility in providing a space and resource for balanced consideration of materials for advisory purposes.

Question 10: Do you agree with the proposed technical requirements of Domain Coordinators, including data standards, data quality, domain definition and access to data? If not, which responsibilities should be amended and how?

We agree with the proposed technical requirements of the Domain Coordinators. However, we believe that a distinction should be made between the function of setting requirements and supporting outcomes, and that of detailed management arrangements within individual organisations, with the latter remaining out of scope for the Domain Coordinators. An outcomes-based approach would allow organisations to set requirements without prescribing the detailed arrangements that implement requirements. This would provide organisations with the flexibility to determine the most appropriate arrangements for their individual circumstances, while maintaining clear focus on achieving intended outcomes. 

Data Access

We support the proposed responsibility for Domain Coordinators to establish standardised access processes, with the additional expectation that the DSI should provide the mechanisms of access control when possible. We recommend that the guidance makes clear that Domain Coordinators are responsible for the identity verification, credentialing and licensing policies that are necessary to enact data access controls within their domain, with coordination across domains to ensure interoperability and streamline processes for data users.

Data Standards

The development and maintenance of a data standards catalogue should be represented through the DSI. We also encourage the use of open standards within the data standards catalogue rather than limiting the approach to standards that already exist. This should be accompanied by the overarching coordination function to promote interoperability between standards across the wider ecosystem. Without this cross-domain perspective, there is risk that Domain Coordinators develop standards that only work effectively within individual domains and not across domains.

Data Quality

We support the principle that the Domain Coordinators should establish expectations around data quality, but metrics and requirements should be informed by actual use cases. These quality metrics are context dependent and datasets that are fit for one purpose may not be adequate for another. We also note that many use cases are cross-domain, providing value for the overarching coordination function to examine quality across domains.

Digital Infrastructure Requirements

Requirements for digital infrastructure should similarly be developed through engagement and informed by use cases, supporting cross-domain interoperability. Additionally, while we understand the transfer of 5.24 and 5.25 responsibilities to the Digitalisation Coordinator function once established, domain-specific issues will likely need input from Domain Coordinators. 

Identification and Development of Use Cases

We agree that identifying use cases should be a critical component of the Domain Coordinator role. This responsibility should be transparent, including the logging and publication of identified use cases where appropriate. This provides visibility of the evidence base informing priorities and technical requirements. The methodology for developing and prioritising use cases should be based on genuine use cases and user needs rather than just dataset availability. This distinction avoids designing a system around only existing data rather than the outcomes that data is intended to enable. The Digitalisation Coordinator will likely have an important role in identifying and supporting use cases that extend across domain boundaries, supporting a more interoperable data ecosystem. 

Question 11: Are any key technical requirements missing, unclear, not proportionate or not deliverable in practice?

Currently, the consultation does not address standardisation of licenses as part of the technical components of delivery. This is a critical element of interoperability as, ultimately, a technically interoperable data landscape can still be limited by legal interoperability challenges that slow or stop dataset combination for the delivery of real use cases. We strongly recommend that license identification and standardisation is included in the technical remit for Domain Coordinators, supported by interaction with the Digitalisation Coordinator to enable license interoperability across domains and translation to license representations within relevant Digital Infrastructure. Where multi-party preemptive licenses are developed, we suggest that the Digitalisation Coordinator takes an oversight role to support consistency of approach throughout the sector and promote cross-sector interoperability.

We separately note that this consultation implies Domain Coordinators will take on an active role in shaping domain agreements – e.g. on standards adoption – that will then be codified into the DSI to accelerate data exchange. Formal technical and governance relationships between data Domain Coordinators and the DSI are yet to be fully established. We suggest that both data Domain Coordinators and the Digitalisation Coordinator establish and transparently document their relationships to digital infrastructure projects. This is particularly important where functions are held by the same body.

Question 12: Do you agree with the proposed engagement requirements of Domain Coordinators, including strategic engagement, technical engagement, and engagement of consumer groups and smaller organisations? If not, which requirements should be amended and how?

We support positioning engagement as a key responsibility for the Domain Coordinators. We also support consideration of engagement including technical, consumer, small organisation, and participant groups. However, certain aspects of the engagement requirements would benefit from additional robustness and prioritisation of context-specific methods to avoid over-reach or fatigue in a landscape with high existing engagement demands.

We note that meaningful engagement must be balanced with the potential for engagement fatigue, which has already been raised within the sector around digital developments. It is particularly significant for small or non-profit organisations with fewer available resources and time; engagement structures must be designed sensitively to avoid unintentional exclusion of these actors. We suggest that a clear plan for inclusion is necessary and that there is benefit to this being openly published. In future, this may be something requiring oversight from the Digitalisation Coordinator to support consistency and promote efficiencies that can reduce risk of engagement fatigue and/or flexible response to periods of high engagement demand. In parallel, we note that good stakeholder engagement practice – e.g. evidenced through IB1’s DAFNI-DINI programme – requires circularity; programmes in which participants understand the value and outcomes of their engagement are perceived more favourably than those which are considered to be more one-sided or extractive.

We also note that engagement approaches outlined do not explicitly name end users as stakeholders that should be included in engagement processes, beyond consumer groups. We suggest using a use case lens for stakeholder mapping and engagement can be constructive for ensuring representation from the full data value chain.

Finally, we suggest that Domain Coordinators may find achieving a balance between existing and supplementary routes an area requiring sensitive handling, particularly to ensure that there are not discrepancies or preferences unintentionally applied to various settings. We encourage Domain Coordinators to consider questions such as:

• Where supplementary engagement groups are constructed, how will these interact with existing forums? Are discussions in either group privileged in any way (e.g. information asymmetry, powerful voices in the room, visibility of what the other group has discussed or decided)?
• How will participants be given appropriate voices and opportunities? 
• How will disagreements be handled and/or reported between groups?
• Are there different weightings given to decisions made within or between groups? How might this interact with existing groups that have set governance and voting structures? 
• How will competing interests and priorities be balanced if discussions are separate?

This response is not to suggest that the above challenges are insurmountable, however they do flag the risk of creating unintentional asymmetries or imbalances that have potential to undermine trust and legitimacy of engagement processes without adequate consideration.

Question 13: Which strategic, technical, consumer group or smaller organisation stakeholders or stakeholder groups should be engaged for each domain?

As noted in Q12, we advocate a use case lens to approach engagement across the data value chain. This can also help reduce engagement fatigue by targeting engagement strategies to the most relevant participants informed by context. Without further context it is difficult to provide a comprehensive response. IB1 is happy to discuss our approach to stakeholder mapping and engagement separately if useful to support this consultation.

Question 14: Are any key engagement requirements missing, unclear, not proportionate or not deliverable in practice?

Reflecting Q12, we would welcome further detail and/or guidance provided to Domain Coordinators about how to set up, govern, and communicate between engagement tracks happening separately to pre-established routes.

Question 15: Do you agree with the proposed governance requirements of Domain Coordinators including requirements to participate in governance forums and operational reporting? If not, which responsibilities should be amended?

We support the proposed approach which appears proportional, deliverable and appropriate to the short-medium term. We acknowledge that approaches may require adaptation over time. We suggest that consumer outcomes and decarbonisation are explicitly included in reporting as topics for monitoring and reporting regarding the strategic direction and impact of Domain Coordinator activity. We also recommend that these outcomes are formally included under the heading ‘Track digitalisation progress’ (7.17-7.20). 

Question 16: Are any key governance requirements missing, unclear, not proportionate or not deliverable in practice?

See Q15.

The tl;dr is it’s looking at a slimmer strategic report: most of the current non-financial disclosure requirements would go, replaced by a shorter set of baseline narrative disclosures, and topics such as environmental impact would only need to be reported where they are financially material.

This matters to anyone who relies on comparable sustainability data: investors, lenders, insurers, supply-chain teams and the SMEs that sit at the end of supply chains. It matters to Perseus as its purpose is to make the data behind emissions reporting easy to share and easy to trust. So, is this good or bad for Perseus? On balance we think this could have a positive impact on Perseus.

What the government is proposing

The consultation covers a lot of ground, but most relevant to sustainability data includes:

• Removing explicit strategic report requirements on environmental matters, employees and diversity, social responsibility, community engagement, human rights, and anti-bribery. Companies would still report on these where they are financially material (ed: one could reasonably suggest that many matters carry financial materiality across the entire economy).
• Testing a single new ‘very large’ company threshold to simplify which companies carry non-financial reporting obligations.
• Asking whether private companies should carry any non-financial reporting obligations at all.
• Letting companies choose where sustainability information sits within the strategic report.
• Considering how the new UK Sustainability Reporting Standards (UK SRS) should be reflected in the Companies Act 2006.

One thing is not changing: existing climate-related financial disclosure requirements stay in place. The government is reviewing them separately, with a conclusion expected by Spring 2027. In parallel, the Financial Conduct Authority (FCA) is consulting on mandatory UK SRS reporting for listed companies.

SME realities are not addressed

The report has a large-company focus and most SMEs sit below its thresholds. However, this does not mean that SMEs are untouched by reporting rules: they feel them second-hand.

ACCA and UK Finance’s recent white paper, Measure what matters, sets out how SMEs respond reactively to sustainability data requests that trickle down supply chains from regulation designed for large organisations and financial services. Requests arrive from multiple customers and lenders in different formats (this directly echoes Perseus’ research).

Half of ACCA’s roundtable participants named lack of standardisation as the biggest obstacle to digital data collection by SMEs, and half named unclear business benefit (a quarter said they do not collect data digitally at all). This further echoes Federation of Small Businesses research that 74% of SMEs simply do not understand the terms Scope 1, 2 and 3.

So, the consultation’s proposals will change what large companies disclose in their annual reports, but they will not change the demand for SME data that flows through supply chains and lending books, and they do nothing to fix the fragmentation that ACCA and FSB highlight. If anything, moving from explicit topic requirements to a ‘materiality judgements’ gives large companies more latitude to ask its suppliers for what it thinks it needs: without shared standards, this could mean more variation, not less.

What does this mean for sustainability data?

We see three potential shifts:

1. a narrowing of ESG transparency. Fewer companies will be required to report on fewer topics and anyone who depends on comparable disclosures, from lenders to supply-chain due diligence teams will see gaps.
2. a decisive shift toward financial materiality. This aligns the UK with the IFRS and ISSB approach and moves it away from the double-materiality model in the EU’s Corporate Sustainability Reporting Directive (CSRD). This could reduce domestic burden but it may also create friction for UK groups operating in EU markets.
3. a risk of a two-tier information landscape. Where mandatory disclosure recedes, voluntary and investor-driven disclosure will fill the gap, but it will do so unevenly and SMEs are likely to carry the cost of that unevenness.

Taken together, these shifts strengthen the case for standards-based, machine-readable reporting rails. If ‘financially material’ is the test, then the data that passes it needs to be discoverable, comparable and assured. If not it will fragment across bespoke company formats, and differing interpretations of reporting frameworks. The ACCA’s recommendations point in the same direction: standardised frameworks and collection methods, open standards developed bottom-up with technology providers, and data collection that accounts for business size and structure, rather than just sector alone.

What does this mean for Perseus?

On balance, we see this as broadly neutral to positive, with some second-order risks to be considered.

The core demand driver for Perseus is unchanged. Banks and financial service providers still need assurable Scope 2 data from their SME customers to produce their own Scope 3 Category 15 (financed emissions) reporting: the consultation leaves climate-related financial disclosure requirements untouched. UK SRS is moving ahead through the FCA, and Perseus is already aligned with the ISSB approach through PCAF and the GHG Protocol. The ACCA paper reinforces this from the lending side with the Prudential Regulation Authority’s SS5/25 expecting banks to identify, measure and monitor climate-related financial risk across their lending, and sustainability data is increasingly part of whether an SME qualifies for green loans, sustainability linked loans or preferential terms.

The shift to financial materiality reinforces the need for Perseus: decision-useful, financially material climate data is exactly what a standards-based data infrastructure delivers and government’s intent to reflect UK SRS in the Companies Act can support, and be supported by, the plumbing Perseus has already built.

ACCA’s findings also map closely onto what Perseus is designed to do:

• Standardisation and open standards. Perseus gives banks, SMEs, energy providers and application vendors one common implementation for consumption, tariff and carbon-intensity data, built on PCAF and the GHG Protocol and developed with members rather than imposed on them.
• Feedback loops. ACCA argues that value lies in closing the loop, so SMEs get insight and finance in return for data. Perseus automates the data flow from meter to application to bank so that personalised recommendations and green finance decisions can follow.
• Digital collection. A quarter of ACCA’s respondents do not collect data digitally: Perseus enables SMEs to automate the data flow by sourcing assured energy data direct from the meter/energy data providers.
• Trusted advisers. ACCA recommends reaching SMEs through accountants and membership bodies. Carbon accounting providers who are rolling out Perseus-enabled products can enable reach hundreds of thousands of UK SMEs.

The risks are indirect:

• Removing explicit environmental, community and human-rights reporting weakens the wider ESG-reporting efforts that support voluntary SME adoption and buy-side engagement.
• A new ‘very large’ threshold could shrink the number of reporters and push more of the SME data conversation into more voluntary and commercial territory.
• Perceptions of ‘dilution’ could undermine overall progress.

What will we do next?

The FSP demand that anchors the business case for Perseus remains, and the direction of travel towards more ISSB-style materiality and UK SRS strengthens the case for Perseus as the delivery mechanism. We need to pay attention to any softer signalling around SME and private-company disclosure.

We plan to respond to the consultation with a focus on making the case that reducing reporting burden and improving data quality are the same job, and that trusted, permissioned data sharing is how you achieve both. The ACCA white paper supports that case with a fresh evidence base, and its recommendations on standardisation, open standards and feedback loops are ones we will amplify.

If you work with SME sustainability data and want to contribute to our response, please get in touch at perseus@ib1.org.

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer. 

Thank you for considering our submission.

Consultation response:

Amending UK GDPR

Question 1: To what extent do you agree or disagree with this statement: Providing legislative clarity alone in UK GDPR would be sufficient to address barriers faced by intermediaries?

No response

Question 2: If UK GDPR were amended to clarify the role of intermediaries, do you think any further details should be included alongside explicit delegation of data subject rights, for example, guidance, code of practice, specific data formats, frequency, or how portability should operate in practice?

While we agree that clarification of delegation would be beneficial to data subjects, any amendment to UK GDPR must be made carefully, in consultation with EU and other international data protection counterparts alongside operators of UK governance schemes that incorporate GDPR such as Open Banking and the Smart Energy Code. In particular, the change must not put EU adequacy determinations at risk, as the economic and social impacts of a weakened or lost adequacy status are likely to be disproportionate to the benefit.

If UK GDPR is amended, the purpose of, and limits to operation of, data intermediaries need to be made clear in the drafting in order to build trust. The drafting should include requirements for them to be: Neutral – the purpose for the data processing cannot be set by the intermediary; Fiduciary – acting strictly in the data subject’s interest, not in their own or a third party’s; Permissioned – possessing reliable evidence for permission to act as delegate for a scoped purpose.

To aid adoption and oversight, these requirements could be provided as model contract or privacy policy terms for intermediaries to execute as part of their usage agreements with the data subjects on whose behalf they act.

Regulation

Question 3: What obligations on data controllers, if any, would be effective in supporting requests made via authorised data intermediaries?

No response

Question 4: How burdensome would an authorisation or registration requirement on intermediaries be for your organisation?

No response

Question 5: What would be the advantages and/or disadvantages of the UK implementing a regime similar to that of the EU’s regime?

No response

Question 6: To what extent could it help to build trust between intermediaries, controllers and individuals?

No response

Question 7: How important do you view regulatory alignment with the EU for your operations, given potential changes arising from the Digital Omnibus proposal?

No response

Question 8: To what extent would a voluntary registration process for intermediaries likely be sufficient, to ensure services comply with rules?

No response

Question 9: For data controllers: would an EU-style model make you more likely to accept delegated requests from intermediaries on an official register?

No response

Question 10: If a certification scheme were adopted for data intermediaries in the UK, who would be best suited to carry out the certification process? For example: self-certification, regulator certification, government certification or third-party certification.

No response

Question 11: To what extent do you agree or disagree with the following statement: an authorisation scheme (whether notification-based, registration, or licensing-based) would meaningfully reduce the uncertainty or friction you/your organisation currently face?

No response

Question 12: For data controllers: How important is formal recognition of intermediaries (e.g., being listed, registered, or licensed) in giving you confidence as a data controller to accept delegated rights requests?

No response

Question 13: Which of the following approaches would best strike the right balance between assurance and proportionality for your sector?

No response

Question 14: To what extent would requiring the use of Portability APIs affect the level of friction your organisation experiences when responding to or submitting delegated data access requests?

No response

Question 15: How would requiring mandatory APIs affect your organisation’s compliance costs, especially relative to existing data portability obligations?

No response

Question 16: Which of the following would need further standardisation to make mandatory APIs more workable?

No response

Non-Legislative Options

Question 17: For data controllers: To what extent would a non-statutory authorisation scheme, potentially run by industry, increase your willingness in using or accepting requests from data intermediaries?

No response

Question 18: What standards or criteria would be most important for an industry-run authorisation scheme to be effective?

No response

Question 19: What oversight or accountability arrangements would be necessary to ensure an industry-run scheme remains trusted?

An industry-run scheme must have strong, visible governance to maintain trust and ensure the scheme operates in an accountable and legitimate way. This includes establishing principles and processes, defining roles and responsibilities, and a significant investment in public communication. Delivery oversight with operational monitoring and clear routes to redress are also required.

Governance must be based on principles of transparency, accountability, engagement and responsiveness, with enough flexibility to adapt to specific socio-technical contexts and goals. Adopting an iterative, collaborative approach with stakeholder engagement and regular review ensures that an industry-led scheme remains effective, credible and trusted. 

Question 20: What measures, if any, would be needed to ensure such a scheme does not disadvantage new or smaller entrants?

Schemes should provide a clear, tested pathway to operation, with transparent requirements, onboarding and compliance expectations. Providing a tested pathway to operation gives greater certainty and reduces the cost and complexity of entering the market. The pathway may include variable entry requirements dependent on considerations such as data sensitivity, tiers of purposes, and number of data subjects using the intermediary. 

IB1’s Project Perseus, the UK’s first cross-sector Smart Data scheme, provides a practical example. Its 6-month pilot phase tested the technical, legal and user experience aspects of a trust framework, highlighting the need to reduce friction and enhance the way Perseus works for SMEs, energy data providers, carbon accounting providers and financial service providers. A sandbox environment enables all participants to develop their implementations safely using synthetic data, and to continuously improve SME user experience. The scheme also provides onboarding support and guidance, open source example implementations, case studies from participants and supporting discussion channels. 

Question 21: For data controllers: Could a statutory code of practice increase your confidence in using or accepting requests from intermediaries?

No response

Question 22: Would an industry-led code provide meaningful reassurance about the credibility of intermediaries?

Yes, a well-governed industry-led code should provide meaningful reassurance about the credibility of intermediaries, provided that it meets the requirements for transparency, accountability, engagement and responsiveness mentioned in Q19. Particular attention must be paid to messaging and communication intended to inform and reassure data subjects so they are not unduly burdened in their decision to use an intermediary as a delegate, and are clear about routes to redress if there are issues with the intermediary or the data transfer and onward use.

Question 23: Do you believe voluntary, industry led approaches can meaningfully reduce data controller friction that was reported in our call for evidence last year?

No response

Question 24: Would updated ICO guidance meaningfully change how your organisation handles delegated rights requests?

No response

Question 25: What specific elements of guidance would be most useful to you?

No response

Question 26: Would guidance alone be enough, or would you expect additional regulatory or legislative measures to address barriers facing the intermediaries market?

No response

Data Portability Through Smart Data Schemes 

Question 27: To what extent could a Smart Data scheme provide sufficient trust for intermediaries operating in your sector?

Smart Data schemes are a proven, scalable approach to secure, private data sharing and should be built as a priority. Building interoperable schemes that are based on harmonised legal, procedural and technical definitions will provide the basis for trusted data sharing and for intermediaries to operate effectively. 

Our experience with Perseus demonstrates that trust is strengthened when Schemes have a clear purpose, with well-defined roles and responsibilities, transparent governance, assured data flows, proportionate technical requirements and onboarding support. Its pilot and sandbox also showed the value of testing these elements with participants and iterating the framework in response to stakeholder feedback. 

By defining priority user needs and use cases, schemes can be designed and adapted to real-world requirements, identify and mitigate uncertainties early and reduce friction for participants. This approach provides clarity and assurance needed for intermediaries while allowing schemes to evolve as the market develops. 

Question 28: What measures would be needed to ensure Smart Data schemes adequately support intermediaries, or vice versa?

A Smart Data scheme involving intermediaries simply needs to include them in the governance framework: defining their roles and responsibilities, accountability and liability the same as for other scheme participants. This provides certainty for all participants, reduces friction and supports trusted data sharing.

Smart data schemes should provide communication guidelines or requirements that assist intermediaries in their approach to building user journeys, disclosures and permissions.

Smart data schemes should be designed for continuous improvement and adaptation so that they remain relevant and effective as technology, markets and user needs evolve. Care must be taken to ensure that ongoing changes do not become onerous for participants, or introduce risk or confusion for end users.

Question 29: How do you see a Smart Data scheme in digital markets interacting with data intermediaries?

No response

Question 30: What would each of their respective roles be in supporting effective data portability?

No response

Final Questions

Question 31: Are you aware of good international examples where action has been taken to improve the operation of data intermediaries?

No response

Question 32: Do you think one option or a combination of the options discussed in this consultation would work best to improve the operation of data intermediaries in the UK?

No response

Question 33: What other options should be considered in your opinion?

No response

Question 34: What additional infrastructure, if any, do you think is essential to enable data intermediaries to operate effectively especially in high-priority sectors (for example, finance, energy, health or transport)?

Trust frameworks operate at sector level to collaboratively establish and maintain a light layer of identity management, governance, common definitions, principles and open standards for data sharing. They provide the foundations of a trusted data-sharing ecosystem that sector- or use case-specific schemes can build on. 

Trust frameworks and Smart Data schemes should be complementary. Trust frameworks provide the common foundation for identity, governance and interoperability across a sector or sectors while individual schemes can build upon these foundations to target specific market-wide applications. This approach enables targeted and efficient data sharing and identity verification without requiring every scheme to recreate underlying trust infrastructure.

Question 35: What interoperability challenges currently limit the effectiveness of data intermediaries?

No response

Question 36: What types of infrastructure would help address these challenges? (For example, technical standards, governance arrangements, or supporting services).

Infrastructure that enables and supports trust frameworks for data sharing should be prioritised. This includes clear governance, open standards and identity and assurance mechanisms that support participants to interact with confidence. 

Good governance also addresses challenges of adoption by providing participants with clarity and confidence needed for technical infrastructure. Governance should be designed into the framework from the outset rather than through a technical-first approach. Infrastructure should be designed as an enabling layer for the trust framework, with technical standards and supporting services developed to implement and reinforce agreed governance principles. 

As more schemes are rolled out, work is needed to characterise and harmonise the ID & verification, accreditation, legal, licensing and procedural aspects of data sharing in order to ensure schemes are interoperable and remove friction for participants and end-users. It is likely that these considerations, not technical interoperability, will cause the majority of bottlenecks to realising the full value of data portability enabled by data intermediaries.

Please note that throughout this consultation, Icebreaker One (IB1) uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer. 

Thank you for considering our submission.

Call for input response:

As stated in IB1’s response to Ofgem’s AI in the Energy Sector Guidance Consultation, AI presents immense opportunities for delivering customer benefits, driving economic growth, accelerating the transition to net zero, and enhancing financial and regulatory frameworks. However, AI must be deployed responsibly – ensuring trust, transparency, and interoperability across sectors.

The questions in this consultation lean towards gathering information on what individual organisations are doing to assure themselves about their own use of AI. This is a necessary first step, but covers only a part of today’s interconnected energy sector services. To have real impact, assurance must be extended to cover AI-mediated data that is shared and used across organisations, sectors and use cases. It is in that context of data sharing governance that IB1 is responding to the consultation. 

IB1 highlights two key points about data assurance:

1. Assurance is evaluated in the context of the entity using the data, not the entity providing it. What is adequate for one usage situation may not be enough for another. Consequently, data sharing assurance can only be established by convening data users and publishers and developing their assurance needs and options around clearly defined use cases
2. Assurance is a journey, not a destination. As available data, data users and use cases proliferate, so do their assurance needs. A sector approach to assurance must establish an agile process for determining assurance needs, and encoding and enforcing them so that machines (AI or otherwise) can rely on them at scale.

These requirements for data sharing assurance existed before recent AI advances. AI hasn’t changed them, but the opacity of inference and the non-deterministic nature of outputs that are features of Generative Pretrained Transformer (GPT) models bring new challenges compared to deterministic and probabilistic approaches. A distinction between “Narrow AI” (AI designed for a specific task such as weather forecasting) and “General AI” (AI with human-like performance at different task types) may prove useful in assurance. Despite the rapid uptake of both types of AI, governance is still nascent within organisations, and even more so between them. These factors amplify the need and shorten the timelines for determining what “fit for purpose” means. 

Over the past six years, IB1 has developed and openly published co-design processes (Icebreaking) and Trust Framework-based approaches to enable rapid decision-making and implementation of governance of data sharing. These apply equally when AI is in the mix. Trusted use of AI demands well-understood, open governance with agile co-design by market participants delivered at ecosystem scale. The importance of these factors multiply as AI capacity and independence grows, with oversight often taking time to catch up.

IB1 recommends that, at the end of this information-gathering phase of its AI work, Ofgem ensures that the proposed Digitalisation Coordination Function is tasked with convening data stakeholders and working at pace to uncover, elucidate and specify assurance standards within a governance framework.

Question 1: Current AI assurance practices

1. How do organisations evidence that AI systems are operating as intended and delivering safe, fair and effective outcomes?

No response

2. What AI assurance approaches are currently used or under development, including in-house and third-party?

No response

3. What tools and technical capabilities are available to support AI assurance in practice, how mature and effective are they, and where are there gaps or opportunities for shared or sector-wide approaches?

A range of tools are available to support AI assurance, including model testing, performance monitoring, explainability techniques, audit logging and cybersecurity controls. While these approaches are becoming increasingly mature for assuring AI within individual organisations, there is much less maturity in assessing AI operating across organisational boundaries and shared data ecosystems. A lack of trusted data flows into AI systems could lead to poor, potentially unaccountable, decisions made or informed by machines and human-machine systems.

Effective AI assurance depends on trusted data flows. Capabilities such as provenance and lineage metadata, verifiable signatures, machine-readable licenses and organisational identity provide confidence in where data originated, how it has been processed and who is accountable. 

However, the characterisation and verification of AI models and their applications within data-sharing remains immature. More work is needed to identify and develop use cases that surface assurance requirements. Developing assurance around real-world use cases will help establish reusable assurance ontologies, with lessons drawn from more mature sectors such as autonomous vehicles or medical diagnostics. 

4. How are AI governance frameworks translated into operational practice?

No response

5. Which assurance or governance practices are most effective in supporting reliable outcomes?

The most effective assurance and governance practices are those that provide clear, proportionate evidence that data and AI systems are fit for their intended purpose. Assurance should be assessed in the context of how AI-mediated data will be used, recognising that while assurance signals originate from the data publisher, the decision to trust and use that data ultimately sits with the data user. 

IB1’s work on data assurance is a good starting point to adapt for AI-mediated data. Organisational and dataset assurance can be extended to provide consistent, machine-readable signals relating to provenance, quality, governance, licensing and accountability. As AI becomes more prevalent, these assurance signals become increasingly important for establishing credibility, compliance, quality and usability across organisational boundaries.

AI governance in the energy sector must also be codified to require a demonstrable contribution to net zero targets and consumer outcomes. This should be supported by appropriate explainability standards that are needed for AI-driven decisions, such as pricing and grid management, alongside regulatory monitoring to prevent AI-driven market monopolisation.

6. What skills, expertise and resources are required for effective AI assurance, and where are the main capability gaps?

Effective AI assurance requires a combination of technical expertise, governance, and stakeholder engagement. While AI introduces new technical considerations, many of the core capabilities are the same as those required for trusted data sharing. 

Core capabilities include: 

• Stakeholder engagement to understand ecosystem needs and develop proportionate, useful assurance to meet those needs
• Appropriate model and process selection
• Risk characterisation and management
• Data annotation (metadata) using appropriate standards
• Quality control and verification

AI’s potential to unlock data-driven innovation must be balanced with privacy, security, and ethical considerations. Therefore, IB1 advocates for AI models that:

• Respect consumer consent and data sovereignty, using decentralised identity frameworks
• Support open standards to ensure interoperability between AI-driven systems
• Embed transparency and explainability to mitigate AI biases and prevent regulatory fragmentation

Organisations using AI must possess relevant expertise that encompasses the above bullet points to ensure their solutions provide, secure, fair and sustainable AI.

Question 2: Risks and challenges

1. What are the main barriers to implementing effective AI assurance?

The fundamental barriers to effective assurance of AI-mediated data are structural and cultural. Organisations tend to work in siloes, which limits the sharing of both data and assurance practice. There is no accepted standard for AI explainability or verification, making it hard to establish a common baseline for what “good” assurance looks like. This is compounded by the pace of change in the underlying technology – rapidly evolving models and increasingly agentic processes make static assurance frameworks quickly outdated.

Stemming from this, the data which AI requires is also fragmented, held in inconsistent formats across organisations, and subject to different consent regimes to access. System-wide data that would support assurance work, such as LV feeder loads, flexibility capacity, and network constraints, often exists but remains inaccessible or non-interoperable between organisations. 

Privacy-preserving technology and synthetic data are effective methods to enable innovation without creating data protection issues. While good work is being done to provide this for smart meters, such as via the Faraday project, there is a need for similar efforts on other datasets, such as flexibility assets and behind-the-meter energy use. 

Finally, there is a lack of structured methods to evaluate and communicate assurance for data processing, including using AI, across organisational boundaries, so even where individual organisations assure their own systems, that assurance doesn’t travel or compound across the sector. This is worsened by a general lack of consideration by data publishers about appropriate AI use by the downstream applications of data users. For instance, no mechanism exists to signal which models are appropriate for which specific applications, leaving adopters to make that judgement without guidance.

2. What are the key risks associated with AI use in the energy system (including system reliability, market functioning and consumer outcomes)?

The key risks associated with AI in the energy system extend beyond performance of individual AI models to the governance of the data ecosystems on which they depend. Focusing solely on AI assurance for organisations’ use of their own AI systems risks overlooking compounding risks for data sharing scenarios across organisations, use cases and sectors.

Without clear, actionable assurance signals describing the provenance, quality, licensing and appropriate use of AI-mediated data, downstream users may be unable to assess whether the data is fit for purpose. Similarly, without the use of open and shared access frameworks, AI capabilities will consolidate in the hands of large incumbents who already hold proprietary datasets, creating market concentration risks that undermine innovation, consumer, and environmental benefits. 

We anticipate that cost, usage and IP conditions will hamper otherwise technically possible uses of the data. We recommend early surfacing of this information to mitigate five risks: 

1. Regulatory and compliance complexity: Data licensing must align with compliance rules around grid data, market data, and critical infrastructure. It is important to ensure data inputs to AI systems, and the outputs of the AI, remain compliant.

2. Third-party data dependencies AI models in energy often rely on weather feeds, satellite imagery, market pricing, and sensor data from multiple vendors. Each source carries its own licensing terms around permitted use, commercial exploitation, and AI training rights. Identifying these dependencies early prevents data supply chain disruptions during development, or worse, after deployment.

3. Intellectual property and model ownership: Who owns the AI model trained on licensed data? Many data providers now include clauses that restrict or claim rights over derivative works, including trained models.

4. Onward data publishing and monetisation: Energy sector companies typically want to share or sell AI-derived insights. Licensing terms set upstream can block valuable downstream opportunities. 

5. Long-term data access and continuity risk: Many foreseeable AI systems in the energy sector (e.g. predictive maintenance, load forecasting) need consistent, long-term data access. Identifying long-term data rights is critical to operational resilience.

3. Which risks are most difficult to assess, evidence, or link to real-world outcomes?

Risk assessment must be based on concrete use cases. These allow the counter-assessment of the risks of not using AI or not sharing the data created. The hardest risks to assess are those where there is insufficient information for a data user to make an informed judgement.

4. Where are current AI assurance approaches most limited in practice?

Data assurance, whether the data was generated by AI or otherwise, is unevenly applied in the UK energy sector. There is a lack of attention to the data foundations and their transparency and accountability. A coherent, well-governed trust framework with standards for assurance signals is required, along with processes to develop and monitor them.

As discussed in 1c, the characterisation and verification of AI models and their applications within data-sharing remains immature. More work is needed to identify and develop use cases that surface assurance requirements. Developing assurance around real-world use cases will help establish reusable assurance ontologies that can be implemented within trust frameworks. 

Question 3: Critical infrastructure considerations

1. How should AI assurance reflect the criticality of energy systems as national infrastructure?

No response

2. What level of rigour is appropriate for high-impact or safety-critical AI use cases?

An appropriate level of rigour can only be determined on a use case by use case basis.

Question 4: Consumer protection and fairness

1. How can AI assurance support fair treatment of consumers, including vulnerable groups?

AI assurance can support fair treatment of consumers by ensuring that AI-enabled decisions are transparent, accountable and designed around the needs of those affected, including vulnerable groups. This requires more than assessing technical performance; it requires governance arrangements that consider social impacts, consumer rights and the ability for individuals to understand and challenge decisions that affect them. 

IB1 advocates that data governance should establish clear principles, structures, roles and responsibilities, agreed by market participants, to enable accurate and timely data sharing at market-wide scale. These principles extend to AI assurance, ensuring that approaches are developed with cross-sector collaboration and learning rather than imposed through a purely top-down process.

2. What risks arise from AI-driven pricing, segmentation or prioritisation, e.g. fairness, transparency, consumer outcomes?

We strongly advocate for the adoption of a broader concept of social sustainability in defining fairness. This must conceptualise people in a manner beyond their economic roles and should also be capable of viewing people in terms of groups. This approach is vital to assessing a more holistic range of AI impacts beyond the individualised economic sphere. 

As stated by Which? “consumers [must] have the right to challenge decisions that are made about them by computers alone. This right is particularly important because it forces transparency and accountability in systems, making sure companies can be held to account if things go wrong”. Transparency and accountability are precisely what assurance seeks to bring.

Question 5: Cyber security and resilience

1. How should AI assurance align with existing cyber and operational security frameworks, e.g. NIS Regulations?

Assurance must align entirely.

2. How can AI assurance support system resilience, including identifying and mitigating cyber, operational and AI-specific risks?

IB1’s 2025 Positioning Paper on AI set out five dimensions of resilience for consideration with AI, going beyond the purely technical. The benefits of assurance to each are below:

1. Economic Resilience
   • Assurance enhances the likelihood that AI-driven data-sharing infrastructure (e.g. smart data initiatives​) is interoperable and equitable, preventing market concentration and boosting innovation and SME growth
2. Sustainability and Environmental Resilience
   • Assurance can increase confidence in the use of AI to optimise energy efficiency, emissions tracking, and climate risk modelling, helping industries and governments meet net zero goals​.
   • Assurance can be used to evidence that AI contributes to the UK’s net zero targets, enabling the requirement to be open to monitoring and audit
3. Regulatory and Governance Resilience
   • Consistent, well-understood assurance signals enable AI-driven compliance automation, reducing administrative burden and maintaining public trust in AI-enabled services
4. Digital and Cyber Resilience
   • Open and interoperable digital identity frameworks alongside clear governance and accountability enable data users to be assured about the provenance of the information being relied upon to make operational decisions
   • Robust data governance policies, evidenced as part of assurance, ensure AI systems remain secure, transparent, and resistant to manipulation
5. Social and Community Resilience
   • Well-understood, structured assurance enables confident deployment of  data-driven AI interventions to novel scenarios, including emergency responses and disaster preparedness
   • AI assurance can demonstrate that inferences and decisions are free from bias and discrimination, ensuring fair access to economic opportunities, financial services, and public resources.

Question 6: Proportionality

1. What does proportionate AI assurance look like across different use cases and risk levels?

The use cases drive both the assurance and the proportionality. Potential aspects of the assurance include:

• The identity of the assuring party
• Information about the training data
• Information about the contextual data used for a specific inference
• Model choice and use
• Explainability
• Verification
• Data protection
• Liability and redress
• Prompts for appropriate use
• Reports from other users
• Monitoring reports and incident logging
• Reproducibility
• Reliability of data availability and comparability in the long term

2. How can assurance approaches be tailored while remaining effective and practical, including for smaller organisations?

Clarity on the data use case, by both data producer and data user, greatly assists in identifying appropriate, proportionate assurance. Over time, informed by modelling and in-use analysis, individual use cases may well cluster into categories, further simplifying decision-making. Case studies, automated compliance, and effective, transparent monitoring and verification all lead to building greater confidence amongst stakeholders.

Question 7: External assurance and standards

1. Are existing frameworks and standards sufficient, or is sector-specific AI assurance guidance needed?

Existing standards are not sufficient, especially in data sharing ecosystems involving LLMs and agents. Governance concepts, structures and implementations are nascent, both within organisations and and between them.

Ideally, the UK would have cross-sector guidance and standards for AI assurance to enable assured data flows throughout the economy. Ofgem would then build on this where further refinement is needed, for example regarding critical national infrastructure and energy supply considerations. 

In the absence of UK-wide guidance, approaches taken by Ofgem should be designed to be replicable elsewhere by adopting existing standards where available, and openly publishing governance processes, data standards, and ontologies.

2. What role should independent assurance (e.g. audits, certification) play?
   

The role of independent assurance is use case specific. It is likely to be required for scenarios involving personal/customer data and where decision-making affects customers. 

Audits may be applied to both parties sharing data: the AI-mediated data provider to ensure their assurance signals are correct, and the data user to ensure they are not using AI-mediated data for unintended purposes.

3. What are the benefits and risks of external assurance approaches?

No response

Question 8: Future guidance

1. What would be most useful in future AI assurance guidance for the energy sector?

Future AI assurance guidance for the energy sector should focus on supporting practical decision-making rather than prescribing a single approach. Guidance should help organisations identify their AI use cases, understand the level of assurance required for the intended purpose and apply proportionate governance measures based on risk and impact. 

A key priority should be the development and adoption of open standards for representing assurance information, enabling organisations to communicate. Similar to the role of standards like Dublin Core in describing metadata, common assurance standards would support interoperability, transparency, and more efficient trust decisions across AI-enabled data ecosystems.

Guidance should also support cross-sector collaboration, engagement and knowledge sharing through forums where organisations can exchange approaches. IB1’s own experience with collaborative governance models and Trust Frameworks demonstrates the value of bringing participants together to establish shared principles, standards and assurance approaches.

2. What types of evidence are most useful in demonstrating outcomes in practice?

Useful evidence should demonstrate that assurance requirements are being met and that they lead to reliable outcomes in practice. This could include:

• Membership of data sharing Schemes
• Volume and continuity of data transactions
• New products and services enabled by AI-intermediated data
• Evidence of exceptions, “Red Flags,” when assured data hasn’t proven to be as reliable as asserted
• Audit reports
  

3. What examples or case studies would be valuable?

Assured Open Data

With input from Open Energy members, IB1 developed the Assured Open Data (AOD) scheme in the Energy Sector Trust Framework in order to provide a standard externally credible mechanism for organisations to demonstrate their implementation of Data Best Practice Guidance (DBPG). 

In the scheme, progressive assurance levels operate at both organisational and dataset level. Organisational assurance verifies identity, governance, and accountability. Dataset assurance covers metadata quality, format, provenance, licensing, accessibility, and update cadence. Four cumulative levels run from minimum DBPG-aligned entry expectations through to comprehensive, machine-readable cross-market reuse. Assurance is signalled through metadata that maps to human-readable badges.

SSEN-D was the first organisation to adopt AOD and has assured many datasets on its portal (e.g. SSEN Substation Data). AOD is in the process of implementation by other UK regulated energy sector companies.

Perseus Assurability Framework

Perseus is a UK-led Smart Data Scheme for SMEs to embed sustainable finance with trusted, automated carbon emissions reporting. In it, SMEs give permission for their energy consumption data to be processed securely by carbon accounting platforms in order to provide emissions data to financial service providers to evidence carbon reductions.

In order for financial service providers to reach reasonable assurance in the data they receive under the scheme, an assurability framework was developed, implemented by signed provenance records provided at each data exchange. These capture the identity of the sending and receiving parties within the trust framework, specify the data’s origins, codify the processing that has taken place, and make clear the permission and licence that covered the processing and transfer. Provenance records are chained as data is shared onwards, providing a verifiable record of assurance claims by processing parties.

While the assurance information carried is use case specific, the building blocks of provenance records – identity, origin, licence, permission, processing, transfer, receipt – are broadly applicable. This enables assurance requirements, once defined, to be deployed within trust frameworks very rapidly.

Question 9: Communication

1.  How should organisations communicate AI assurance to different audiences?

By working in collaboration with the users of AI-mediated data to identify use cases and the assurance they require, organisations can design and communicate assurance in terms that are meaningful to those users. Open publication of the purpose and rationale for the assurance signals provided allows for a rapid adopt-and-adapt approach for new scenarios.  

To support this, well-defined frameworks and guidance should be established, facilitating open standards, clear ontologies and machine readable formats for interoperability among people and systems. 

2. What information is most useful for consumers, boards, senior management and affected groups?

The type and usefulness of information is use case specific, and should be developed alongside the assurance needs for each use case.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer.

Overall Position 

We welcome Ofgem’s focus on strengthening the governance of energy system data but believe this consultation should fundamentally be about improving decision-making rather than selecting a technical solution. Before investing in new infrastructure, there must be a clear, transparent, and consistent process for assessing what data should be open, shared, or closed. Processes must be applicable at the level of individual datasets, however the sector also requires a mechanism for considering publishing decisions at the aggregate level, for example when risks associated with publication multiply at scale. Without this, there is a risk of building technology that does not address the underlying governance challenge. 

We support the Educational Model as the preferred approach, subject to some adjustments, as it addresses the challenge of improving decision-making without introducing centralised infrastructure that has potential to compound security and resilience risks. We also recommend expanding the assessment criteria to explicitly consider liability, governance, resilience, and interoperability. Responsibility should remain clearly assigned to each data publisher while recognising that some risks require collective assessment. A Trust Framework provides the appropriate mechanism for a collective approach to decision-making, data triage and risk assessment without centralised data infrastructure.

Effective governance should define, articulate, mandate, and enforce a monitoring, reporting, and verification process to ensure published data meets agreed requirements while allowing technical implementation to remain decentralised. This approach avoids creating single points of failure, strengthens system resilience, and maintains interoperability through common standards and assurance mechanisms. The Digitalisation Coordinator should focus on establishing and maintaining governance processes rather than operating centralised technical services.

We strongly recommend the adoption of a transparent, evidence-based approach to risk assessment. The consultation proposes solutions before clearly describing the threats, vulnerabilities, or risk reduction expected from each option. A structured risk assessment with established methodologies, such as the NCSC Framework, should underpin any changes to Open Data policy. Security considerations must also be balanced against the UK’s net zero objectives, recognising that unnecessarily restricting data access may hinder consumer benefits, innovation, system coordination, and decarbonisation without reducing risk. Given that much infrastructure information is already publicly available, decisions should be made based on demonstrable risk reduction rather than assumptions about the benefits of data restriction. 

Consultation question responses:

Question 1: Please provide examples of where data made available under DBP Guidance has allowed your business model to develop either new products and services, or make efficiency savings?

Icebreaker One and partners have used the data extensively in our work to assess and develop use cases enabling data to work harder to support energy system decarbonisation. Data made available under the DBP guidance has supported use cases in areas including, but not limited to:

• EV infrastructure development, including a targeted use case serving households without off-street parking 
• Heat decarbonisation and heat pump roll-out
• Local authority planning and LAEP development
• Cross sector data sharing between energy-water-telecoms for e.g. storm response
• Community energy build out supporting the Local Power Plan

Use cases are especially valuable in considering data security as these provide an opportunity to clearly define the purpose of data access, identify relevant stakeholders, and understand user needs. This approach helps minimise unintended consequences by ensuring that decisions about whether data should be open, shared, or closed are based on clear understanding of who needs the data, for what purposes, and under what conditions. 

Currently, we are using the data to form part of our development work to assess how a data sharing scheme could accelerate Industrial and Commercial (I&C) participation in electricity flexibility. Data included in the landscape assessment supporting the use case includes: network flexibility data (e.g. forecasts, zoning, trades), network constraints/headroom, and connections data (e.g. LCT connections, capacity registers). 

Question 2: Do you agree with the criteria underpinning the Options Analysis as described above? 

The proposed criteria provide a useful basis for the Options Analysis, but we believe they are currently incomplete and, in some cases, do not fully support an objective comparison of the proposed models. We make the following observations on the existing criteria.

Ownership and accountability: We are concerned that the current scoring does not appear to reflect that distributed responsibilities, when supported by common standards and governance, can provide clear and consistent accountability. There is a risk that the scoring methodology unintentionally favours centralised delivery models by assuming that the Digitalisation Coordination Function (DCF) is able to define and operate triage standards and processes internally that cannot be disseminated and carried out by data publishers. The scoring should assess how standardisation and governance can reduce risk irrespective of architecture. They should also flag where risks are present with regards to assigning responsibilities to the DCF as a body whose remit has not yet been defined.

The assessment should also consider how conflicts of ownership and decision-making would be managed in practice. For example, tensions may arise between network operators and a central coordination body where publication decisions differ, particularly if decisions contradict current publication requirements set out by sector governance regimes such as the Codes. Similar complexity exists for smart meter data, where governance may overlap between the Smart Energy Code (SEC), Central Switching Service (CCS/RECCo), UK GDPR, the Data (Use and Access) Act, Data Access and Privacy Framework, and Ofgem’s Data Best Practice Guidance. We therefore recommend that the assessment explicitly considers governance arrangements and conflict resolution mechanisms, in addition to whether any proposed central body (e.g. DCF) would assume the role and responsibilities of Data Controller under UK GDPR.

Data security:  We agree that data security should remain a core assessment criterion. However, security should be assessed across the entire data lifecycle, including how data is stored, governed, transferred, and accessed, rather than focusing solely on publication decisions. In particular, the analysis should recognise that centralising data storage or transferring data to a central body may increase systemic risk by creating attractive targets for attack and introducing potential single points of failure. These architectural trade-offs should be explicitly reflected in the assessment.

Data quality:  We welcome the inclusion of data quality into the assessment. To clarify scoring in this area, we suggest providing an authoritative definition of what is meant by “data quality”, distinguishing, for example, between schema compliance, completeness, accuracy, timeliness, and fitness for purpose. This distinction is particularly important when assessing the extent to which automated processes can improve quality. The assessment should also identify who is responsible for improving data quality under each option, together with the associated implementation and operational costs.

Cost:
We encourage further transparency on the assumptions underpinning the cost assessment. In particular, it is unclear how anticipated savings for individual licensees have been calculated and whether these represent genuine efficiency gains or simply the transfer of costs to a central coordination function. The analysis should also consider how any savings would be used in practice. For example, would reduced expenditure on local publishing platforms enable greater investment in data quality, governance, and workforce capability, or would these simply be treated as financial savings? In addition, we are concerned that indirect costs – including staff training, specialist expertise, organisational change, and ongoing governance – are underrepresented relative to technical implementation costs. In our experience, these organisational costs frequently exceed technology costs and should form part of any comparison of delivery models.

Question 3: Would you suggest any other criteria that you would consider critical for analysis?

We recommend the following additions to Ofgem’s analysis criteria:

Liabilities: while ownership/accountability is an analysis criteria, this does not fully enable the required assessment of who/which body would be held liable for publication decisions, nor assess processes required to handle situations in which data publishers and other relevant decision-makers disagree. In the Hybrid model, it is also notable that the use of automated processing may incur a specific discussion of liability where machine decision-making interacts with human decisions. Liabilities assigned to a potential DCF are also significant and not yet discussed, which requires further thought – particularly where liabilities are affected by other forms of legislation (e.g. Data Use and Access Act (DUAA)) or Codes (e.g. DCUSA data publishing specifications).

Governance: The governance of a system cannot be left as separate to the architecture of the system, but governance details would benefit from further depth in all options. In the Central and Hybrid functions in particular, this creates a large and undefined burden on a future body, whose own format and governance model remains subject to future consultation. As part of governance assessment, we suggest that Ofgem considers the clarity, transparency, and accountability of decision-making processes. For example, processes for assessing risks at the collective level, and determining action, would benefit from further detail. Such processes are important as they intersect with liability assessments. For example, if a licensed entity’s decision to publish Open data is challenged, this is left at conflict with the licensee’s internal process and/or potential obligations under industry codes.

Resilience: current analysis does not identify and assess risks emerging from the potential to create new single points of failure within the energy data landscape. This consideration goes beyond practices within monopoly bodies to also implicate single points of failure regarding aspects such as:

• An open data publishing portal (central/hybrid models)
• Decision-making (central model)
• Automation processes (central/hybrid models)

Interoperability: while the consultation presents arguments for open data publishing to be architecturally separate from other Trust Frameworks, this separation should not be extended to process and data assurance. IB1 suggests that the triage process – and the off-ramp for sharing data subject to restrictions (Shared data) – is not adequately discussed. Rather than presenting a vulnerability, consistency of process and data governance between the DSI, adjacent Trust Frameworks (e.g. CCS, Open Banking, IB1) and Open Data practices lend benefit to data security. Additionally, integration with Trust initiatives in the sector could offer the benefit of integrating Identity and Verification (ID&V) for data users and publishers, thereby streamlining onboarding, increasing confidence in the provenance of published Open Data and reducing the capacity for bad actors to misrepresent themselves across different platforms and processes. Failing to integrate could also unintentionally increase costs through duplication, as flagged via industry engagement groups in relation to Trust Frameworks being developed for the DSI and CCS.

We include analysis under these four categories as part of our response to Q4-6 below.

Question 4: Do you agree with our Option Assessment scoring and conclusion for the Centralised Model?

Our analysis suggests that a Centralised model presents the highest risks and lowest additional advantage as a pathway for improving the sector’s open data security, as well as uncertainty on costs. While the current Options Assessment captures some of these risks, we suggest that the full depth of risks to data security presented through centralised infrastructure have not been fully explored. There are also considerable legal and governance implications for permitting a central coordination body to view and triage all raw data. We suggest a number of points below that, if incorporated in the scoring, we believe would downgrade the Centralised model to the lowest scoring option.

Data security:

• 3.9: ‘The process flow diagram above shows how licensees would send ESD (untriaged) through their Data Preparation Node (DPN) across the Data Sharing Infrastructure (DSI), where it would be subject to Data Quality (DQ) review and then passed to a Triage Function within the Digitalisation Coordination Function.’:
  • Transference of large volumes of data to a central body creates a large threat risk, as acknowledged in the wider literature on information security and engineering. While section 3 describes this as ‘reducing the threat surface area’ this is not an accurate representation of risk; rather than reducing the threat, it concentrates it.
  • Currently, the Options Assessment does not specify how the proposed central structure would handle key governance decisions such as data deletion. If the body decides that data should not be published, it is unclear how the data is handled, where it sits within the central body vs licensees, and how decisions are documented and recorded. 
  • The boundaries of what raw data is transferred to the central function on this basis are unclear, as well as who makes the decision about what is or isn’t included for analysis. Scope creep presents a potential issue which could increase costs and act as a resource drain in the central body.
• 3.16 ‘the risk of accidental over-publication is lowered’ – analysis currently makes the assumption that trained individuals in the centralised process are less likely to create errors. It is unclear how this is different to equivalently-trained individuals in distributed licensees. Additionally, when they occur, a centralised body potentially increases the scale of consequences for errors.
• We suggest that tooling or methods applied to check triage compliance and consistency could be decentralised, defined and enforced via a Trust Framework. Centralisation of this function is not necessary to deliver the same outcomes.

Cost:

• We agree with the assessment on cost (score 1 – poor). Design, implementation and operation of the triage/data publishing service would duplicate functions already present in DNOs.
• The overall cost score appears to be contradicted by point 3.14: ‘The model should provide savings for the licensees, as the costs of triage and running an Open Data Platform would be reduced significantly’. This depends on how the DCF is funded and managed, which is not yet determined.

Data quality:

• We query why this metric is scored as 4. In particular, we raise concerns that assumptions have been made about the necessity and feasibility of the role that the central function is envisaged to perform in 3.16 ‘Additional data utility benefits can be accrued through a single centralised portal, increasing interoperability, and allowing for data quality and schema validation as part of data processing, increasing the consistency of data offerings across the sector.’:
  • Analysis assumes that the digital coordinator is successful in defining a schema all parties agree with, and 
  • Will ensure that data provided using the schema is conformant (this may be costly or face limits on compliance). 
• We suggest that schema agreement and conformance do not require centralisation; the same outcomes could also be achieved in a decentralised manner via mandating the use of a Trust Framework.

Liability:

• Structure not currently discussed, though the model implies a high degree of reliance on the process and decisions of the DCF. 
• Potential for liability conflict unless clarified.

Governance:

• Governance of key processes run by the DCF are as yet undefined.
• Governance of the process to decide whether metadata is published openly is unclear.

Resilience:

• This model creates single points of failure in relation to process/decision-making and technical architecture (portal). 
• Relationships/liabilities between data providers and the DCF require clarifying with regards to how licensees may be impacted by a failure or breach of centralised systems. 

Interoperability:

• If successfully imposed (this is a risk – see Q2-3), the application of Schema could result in a high degree of data interoperability with the DSI. However, a centralised approach is not the only way to ensure this.
• Legal interoperability must also be addressed; the consultation currently does not propose a function to address licence consistency.
• Interoperability with other Trust Frameworks has not been actively considered in the consultation document.

Question 5. Do you agree with our Option Assessment scoring and conclusion for the Hybrid Model?

Presentation of the Hybrid model offers advantages in terms of checks for consistent application of triage processes, while retaining primary decision-making as a decentralised function. However, the current Option Assessment for the Hybrid Model does not adequately address the governance of automated checks, how this functions with human decision-making, how collective decision-making will be conducted, or how data quality improvements are guaranteed. We believe that amendments to scoring based on points raised below would downgrade the Hybrid model’s overall score and encourage Ofgem to consider this when determining their minded-to position.

Data security:

• Issues related to data centralisation and deletion remain, as described in Q4.
• The automated component of the model may function for certain aspects of assessment – e.g. providing an additional compliance function to check triage steps have been followed – however further exploration of how this interacts with human decision-making would be beneficial.
• Governance of automated checks is not fully described at present. This potentially interacts with gaps in liability assessment identified in Q2-3. Example: dataset is approved by automated compliance function but later found to present risks that were not picked up: does the original data publisher, centralised body, or provider of the tool (if third party) hold liability?
• The model does not fully address how decisions beyond compliance will be made, particularly regarding data which:
  • requires an assessment of risk at the collective level, and
  • requires an assessment of risk related to landscape changes over time.
• We suggest that tooling or methods applied to checking triage compliance and consistency could be decentralised, using a Trust Framework to both define good and enforce it.

Data quality:

• Observations outlined in Q4 are also applicable to the Hybrid model; it is unclear how data quality improvements are guaranteed through this proposal in a manner that is different to improved coordination/accountability applied to decentralised data triage. 

Liability:

• The Hybrid model’s liability structure, and relationship to DCF liabilities, is not yet defined.
• Liabilities for automated processing decisions are not discussed.

Governance:

• Governance of key processes run by the DCF requires definition.
• Governance of automated processes is not currently discussed.
• Monitoring, Reporting, and Verification (MR&V) mechanisms are missing to ensure data published conforms to requirements.

Resilience:

• This model reduces certain single points of failure present in the Centralised model by keeping triage processing decentralised and adding an automated process check. 
• However, the data portal element remains centralised, as does data Schema assessment.

Interoperability:

• If successfully imposed (this is a risk – see Q2-3), the application of Schema could result in a high degree of data interoperability with the DSI. However, this can also be achieved in a more decentralised manner than the Hybrid model presents.
• Legal interoperability must also be addressed; the consultation currently does not propose a function to address license consistency.
• Interoperability with other Trust Frameworks has not been actively considered in the consultation document.

Question 6: Do you agree with our Option Assessment scoring and conclusion for the Educational Model?

We disagree with the current scoring of the Educational Model. In particular, the Options Assessment does not address how decentralisation automatically increases security threats despite high cybersecurity standards within licensees, why data quality cannot be assured with effective data governance, or any MR&V mechanisms for the proposed model. 

Ownership and accountability: 

• We suggest that this score is revisited; distributed ownership does not necessarily complicate accountability. All data publishers are regulated parties whose accountability to Ofgem, and other bodies, is guaranteed in relation to many other functions they deliver. We disagree with the current assessment score on this basis. 

Data security:

• We disagree with the low scoring for this category. Licensees are required to maintain high cybersecurity standards for many forms of operational data, including critical national infrastructure. Based on this, it is unclear why distributed responsibility equates to low cybersecurity scoring.
• We suggest that distributed data presents a lower security threat than centralised infrastructure for several reasons. This includes:
  • No single point of failure or leverage
  • Different internal security infrastructure at each licensee makes “full spectrum” breaches much harder
  • Untriaged data does not leave the organisation boundary
• On this basis we suggest that the data security score is reviewed and recategorised. 

Data quality:

• We disagree with the low scoring for this category. The assessment appears to define data quality through only a centralised scheme validation despite the ability for agreed standards, accountability, and assurance processes with effective data governance. 
• The same data quality investments considered for the Centralised and Hybrid model should be included for the educational model. 

Liability:

• Liability is clearly assigned to each data publisher.
• Collective liability would need to be addressed, e.g. in the case where data publishing needs to be assessed at the collective level. This could be addressed meaningfully through a Trust Framework approach with appropriate governance and associated decision-making.

Governance:

• Effective governance within a Trust Framework can define what is required and enforce it without centralisation.
• MR&V mechanisms would be required to ensure data published conforms to requirements.
• The Educational Model could be adapted to give publishing parties the triage check tooling from the Hybrid Model that otherwise sits centrally in the digitalisation coordinator. The DCF, or anyone else who has the specifications and technical ability, could provide the checking functionality, allowing the DCF to focus only on decision-making and collective assessments.

Resilience:

• See security section above: this option presents significant advantages by avoiding the creation of single points of failure and making a full spectrum breach less likely. 
• We do not believe that system resilience has been adequately accounted for in Ofgem’s current analysis – doing so could significantly change the minded to position.

Interoperability:

• A Trust Framework can support interoperability by establishing common requirements and assurance mechanisms across publishers.
• Identities and standards established in the DSI trust framework may be used to harmonise trust signals for Open data, such as provenance and assurance, with those for data shared securely within the DSI, with both operating the same peer-to-peer data sharing principle.

Question 7: Do you agree with our minded to position? If not, what is your view as to the best approach to this issue?

We support Ofgem’s focus on strengthening data governance but believe the key challenge is improving the decision-making framework and governance processes that determine whether data should be Open, Shared, or Closed, rather than developing new technical infrastructure. Our preferred approach is the Educational Model, strengthened through a Trust Framework, enabling collective decision-making and standard-setting for data triage and risk assessment. With the addition of governance, liability, resilience, and interoperability as core criteria, the Educational Model provides more robust assurance while avoiding unnecessary centralisation of technology or liability. Effective governance should establish clear standards with monitoring, reporting, and verification processes, allowing the DCF to focus on oversight and decision-making. Any changes to Open Data policy should be supported by evidence-based risk assessment that balances security considerations with consumer benefits, innovation, system coordination, and progress towards net zero. 

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer. 

Call for input response

Prioritisation of sectors and use cases

Through IB1 programmes and years of expertise, IB1 supports following a use case approach to data sharing initiatives. This approach centres user needs, makes a business case for the investment in data sharing, and allows for:

1. Market incentives: there must be an economic argument that policy can then amplify or mandate. If there is no financial incentive, there will be no movement.
2. Removal of transactional friction: There must be “something in it” for everyone, or at least a path to cost reduction or a new business model. Removing friction can help everyone go together: this is never solely a ‘technology problem’ (e.g. absence of a data ontology).
3. Documentation with the identified problem statement, actors and stakeholders, a clear goal, and the envisaged impact. 

Smart Data becomes effective when it is connected

In terms of prioritisation of sector, use cases requiring cross-sector interoperability and cohesion offer the greatest immediate ability to create impact, with a manageable degree of complexity involved in rollout. These use cases support private sector growth and require achievable government intervention, allowing green growth and environmental goals to be met.

User and customer needs should be identified through a robust governance process which can understand, process, and define use cases with relevant stakeholders. In IB1’s Scheme governance (standard operating procedures), IB1 emphasises the importance of having a user needs & impact advisory group which explores, prioritises, and works through use cases (including identifying users, their needs, and mapping data value chains). This process allows for the development of business, value, and impact cases and their impact on policy, businesses, and financial instruments. 

To maximise the benefits, use cases must:

• Address governance, user needs, business, social, legal, engagement and communications to ensure the solution is fit for purpose, and can be adopted by the market. IB1 observes that technical-led programmes tend to fail to gain traction or deliver against material user needs.
• Foster a community to ensure there is cross-sector collaboration. IB1 strongly recommends taking a joined up approach which is interoperable with initiatives across the economy. IB1 suggests defining relationships with adjacent bodies in the sector and beyond to enable cross sector interoperability.

For identified energy use cases, see IB1’s response to DESNZ energy smart data scheme call for evidence question 14. 

The interplay between industry and government progress in developing schemes or regulations, and how to encourage fast progress

It is important that progress toward sharing data is incentivised before waiting for one perfect data sharing solution to be built as there is demand for data immediately. 

For example, in the near-term it is unlikely that the energy data sharing infrastructure (DSI) will be suitable for all use cases, as it is currently unclear when and how non-regulated actors will be able to access data via the DSI, for what purposes, and under what assigned roles. These actors constitute major customers for connections data (e.g. heavy industry, retail, local authorities etc). While they may well be users of the DSI in future, opportunities to service these data customers in a secure, structured and well-governed manner must not be put on hold until the DSI is ready. 

As there is demand by non-regulated users for data now, there would be benefits to developing high-impact schemes in the short term that operate autonomously, but are legally and technically structured to facilitate integration with future common data sharing infrastructure. It is essential that as the government makes progress on developing schemes and regulations that they do not block valuable industry initiatives from being established quickly.

The coordination layer

To enable valuable government and industry schemes to progress quickly in parallel while remaining coherent and interoperable, IB1 strongly recommends intentional coordination of the cross-programme rules, standards, credentials and access controls that make data flow possible at scale. We recommend that responsibility for the coordination layer sits in an independent mission-locked entity that holds – or subcontracts – the sector’s Trust Framework and provides the sector’s neutral data coordination function. While different ownership options exist, industry co-ownership and co-Directorship of such a body provides a meaningful route for ensuring stakeholder buy-in and co-funding, akin to the model of Open Banking Ltd.

A neutral data coordination function must consider:

• How will schemes’ governing bodies coordinate with developments within and beyond their own scope? 
• How will this feed into goals, design choices, and definition of technical/architectural parameters? 
• How might this need to evolve over time? For example, sectoral coordination laddering up to cross-sector.
• How might Scheme development interact with overarching sector and national data/digitalisation strategies?
• How can Schemes encourage competition, markets and service creation within and across boundaries?

The coordination function requires a Secretariat to act as a neutral facilitator for participatory governance processes which can adapt flexibly to evolving coordination needs and ensure accountability. This requires:

• Strong governance processes – e.g. covering participant selection, means of input, minuting, reporting, and decision-making
  • Ability to offer tailored mechanisms where required – e.g. working groups to focus on specific sectors or data flows, or task-and-finish groups to support elements of data strategy delivery.
  • Flexible staffing, with ability to take on additional domain specialists/contractors as necessary
• Experienced administrators to execute governance processes and communicate expectations of timescales, plans, key decisions etc.
• Where required, the provision of independent chairing or facilitation services
• Dispute resolution processes, linked to existing sector mechanisms and to individual Scheme governance processes where relevant.
• Participant accountability mechanisms 
• Commitment to open publishing as a default approach (unless there is strong reason to do otherwise) 

It is vital for the coordination body to be fully independent; it cannot be nested in a body with pre-existing market functions without risking conflict of interest or transparency problems. 

Effective coordination should also be supported by monitoring in two key areas:

• Mapping of the domain(s) in which coordination is enacted in order to support effective participatory governance in an ongoing manner
• Monitoring and reporting on the outcomes of coordination activity to improve transparency and join-up with adjacent policy/regulatory goals
  • Where relevant, this may additionally include monitoring the delivery of a sector’s data strategy / roadmap.

We suggest that the above activities would require a small permanent staff to ensure continuity of process and expertise, with additional needs met via subcontracting and secondment on a time-limited basis for agile response to emergent needs (e.g. particular technical or domain expertise concerning a coordination challenge). This lightweight approach delivers the intended benefits at a reasonable cost to the bill or tax payer, supporting the general principle of minimisation outlined earlier in this response.

Finally, we propose that any enforcement powers for the coordinator can be most readily delivered via existing regulatory and legislative capabilities. This reduces cost and risk of establishing new statutory bodies.

Best practice in scheme design, including for vulnerable and other consumers, and to maximise how well the system works for services that use data from more than one sector

A core centralised capability must be the design principles. Critically, aligning on design principles for governance will lead to greater cohesion and interoperability of outcomes. 

Governance processes should collaboratively agree upon:

• The intent to work toward interoperability and working in widely understood formats. 
• Licence compatibility – creation of preemptive multilateral contracts/agreements, including appropriate permissioning where required
• Human- and machine-readable representations of scheme rules
• Adoption of common open web standards as the default (unless insufficient) to allow for widest possible number of technologists to understand
• Open publication of new specifications (legal, procedural and technical) that may be adopted by other schemes to aid interoperability
• The use of consistent tooling that is well understood by stakeholders
• Appropriate proven security standards
• The use of open source 
• Conceptual alignment on what metadata means (better yet  – technical compatibility), and aligning around standards

Within this governance function, there must be adequate consideration of the amount of communications and time needed to convene, design, implement and develop consumer messaging for schemes.

To enable interoperability, IB1 recommends considering how Schemes will interact. Key aspects of this are:

Identity. IB1 suggests this should not be a centralised identity, but a mechanism which can enable cross scheme identity verification. This is a key area of research with further needs around how a federated identity system may work. IB1 is exploring this within Perseus, to enable an identity interaction with Open Banking’s identity establishment. 

Access, licensing and permissions. There is a need to invest in research into this, as uncertainty in rights to access, use, combine, sell or share data is a drag on innovation and introduces unnecessary cost. Different regulatory environments can lead to additional confusion for cross-sector data use. There is potential to develop permissioning and purpose representations that can be understood readily by data users and their customers, but interpreted at scale by machines.

Assurance: Schemes need to address the assurance needs of data users in order to deliver value. Considerations include provenance, quality, processes, auditability, liability and redress. Protections for scheme participants (companies) and the customers they serve must be clear. A common language and machine-readable representation for these aspects of data sharing enables confident use of data and accelerates adoption.

Potential cross-sector innovation support, or data or regulatory sandbox services, and how they are designed 

IB1 recommends investment in common tooling to develop public digital infrastructure and open source support which can be re-used across schemes. 

There is a potential role for the National Data Library to curate common standards for scheme rules and their representations and convene the working groups that define them.

The places and methods through which competition should be enabled or promoted in the smart data system, and the pros and cons involved

Scheme development will be a part of the public digital infrastructure development, with appropriate governance oversight to avoid anticompetitive practices, and to guard against cartels to ensure it is a fair place to do business. IB1 thinks of this as “collaborate on the [data sharing] rules, compete on the [services] game.” It is part of the governance process to delineate what is considered pre-competitive and to have short term targeted projects (e.g. mapping stakeholders who must be consulted when developing a specific area of pre-competitive activity).

IB1 also recommends to include value-mapping guidance in the handbook (recommended approaches to do it for a scheme) and to identify and caution against perverse incentives.

Underlying trust services (for example identity, verification, compliance monitoring, permission management, version-controlled registries of scheme rules) must have open standards, ideally with Open Source reference implementations. Scheme operators should have a competitive market of trust service providers to choose from, whose services comply with these standards. The aim is to create a market that operates along the same lines as the HTTP web standard and web hosting providers. 

Methods and forums for engagement with those outside government and join-up between sector-level and cross-sector developments (such as the guidebook)

• Opportunity to capitalise on existing data sharing governance forums:
  • Perseus
  • Open Energy 
  • Stream
  • https://ib1.org/sops/governance-schemes/
• Any coordinating entity must be accountable to its stakeholders. We suggest this is supported by the following:
  • Openness policies enabling scrutiny (e.g. of methodologies, processes, minutes, reports)
  • Where required (for security purposes), clear rules defining how scrutiny will be undertaken among closed audiences
  • Defined process for dispute resolution integrated with existing sector mechanisms
  • Clear processes for change management
  • Defined avenues for external involvement in participatory processes
• Wider engagement than just the incumbents and/or regulated entities within a sector (e.g. in the energy sector this must include actors beyond the roles licensed by Ofgem)
• Cross sector convening needs to be around coherent use cases with a wide range of stakeholders representing the different roles and stakeholders within the data value chain

Join-up between smart data and other data policy, and with international partners

There are developing debates in sectors such as energy and property as to what is considered under the realm of smart data, versus what is considered ‘system data’  There is potential for some issues emerging there and in other sectors which need to be considered and worked through with the relevant stakeholders. Definitions established under the Data Use and Access Act must be respected where relevant.

It is worth noting that not all data is smart data but will need to interact with other data which could/should be shared for key use cases. We caution against excluding ‘non-smart’ data stakeholders when convening around smart data and other data policy. 

Our most prominent international partner – the EU – has invested heavily in technical infrastructure via its Gaia-X initiative. Outcomes have been mixed, due in part to an apparent assumption that “if we build it they will come”. Recent work by the Data Spaces Support Centre on design principles and governance has the promise to encourage more use cases to be brought forward and be implemented. The UK should have a goal of alignment with EU developments on data spaces, but to aim for eventual harmonisation (as with the advice on interoperability within the UK above) as opposed to full technical interoperability at an early stage. As with all data sharing work, the use case is key here. If a use case requires interoperability with EU dataspaces, or interoperability drives very high value, then it is worth the investment to align and connect. Many use cases will not require this, at least in their initial phases.

Links between smart data and AI adoption and innovation, either within the Industrial Strategy sectors or more widely across the economy. 

AI is moving rapidly from performing tasks for people (“summarise this document in under 300 words”, “tell me the top considerations when buying a new fridge”) to performing tasks on behalf of people (“deploy this software”, “find and book a reasonably-priced vegetarian restaurant in Soho for me and 3 others next Thursday evening”). To perform these tasks, agents will need to access the instigator’s personal data, and to exercise delegated authority to act on their behalf. Both of these may implicate multiple providers, using data and access that the instigator didn’t foresee.

AI and smart data intersect in governance and assurance, enabling trust in AI operation by answering questions such as: 

• Where is personal data stored and processed, and to whose benefit?
• Where did the data the model is using come from? (Both for training and for retrieval-augmented generation)
• What personal data did the model use?
• How much reliance can the user put on the inference?
• How are permissions delegated to AI, and how are consumers protected?
• How does the agent ensure that personal information is protected under GDPR when shared?

Relevant materials

Please see other relevant IB1 call for evidence responses:

• DSIT’s Smart Data call for evidence
• DSIT’s Data intermediaries call for evidence
• DESNZ energy smart data scheme call for evidence
• IB1’s response to Ofgem’s Energy digitalisation governance: architectural coordination letter

General principles

Additional comments:

• Reusability: the methodology for exploring and getting Schemes off the ground can have generic/reusable items. But the Schemes themselves must have capacity for tailoring.
• Minimisation: Schemes should do the minimum possible that enables the use case to be addressed.

Please note that throughout this response, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer. 

Call for evidence response:

1. What energy problem do you want to solve? 

There is a wide range of energy use cases identified and highlighted in IB1’s response to DESNZ’s Developing an energy smart data scheme: call for evidence (question 14). There are core principles IB1 recommends embedding. 

Smart Data becomes effective for use in AI and in decision making when it is connected

In terms of prioritisation of sector, use cases requiring cross-sector interoperability and cohesion offer the greatest immediate ability to create impact, with a manageable degree of complexity involved in rollout. 

Regardless of use case, codify a requirement to contribute to net zero

As mentioned in IB1 response to Ofgem’s AI in the energy sector guidance consultation, we acknowledge and appreciate Ofgem’s commitment to encouraging innovation while helping the UK to meet its net zero target and other associated targets. As mentioned in the IB1’s May 2024 AI consultation response, IB1 recommends that the developing AI governance landscape codifies a requirement for AI use in the energy sector to demonstrably contribute to the UK’s net zero targets and for this requirement to be open to monitoring and audit. Without codification of this principle there is a risk that AI systems are established to optimise non-environmental goals, while creating negative environmental impacts. 

IB1 acknowledges the risk of AI systems generating increases in energy and water demand. Both the impacts and the demand profile of AI use should be subject to scrutiny and appropriately governed to ensure they contribute meaningfully to the UK’s net zero targets.

2. What kind of data is needed? 

All identified IB1 use cases, detailing the value, kind, potential users, and scale of the required data, are outlined here: https://ib1.org/energy/reports/ 

3. What work is needed to create or enable a useable dataset, including making sure it can be easily combined with other datasets? 

IB1 observes that this list concentrates on technical barriers to data use, but fails to highlight legal, licensing and commercial considerations. It is very possible that cost, usage and IP conditions will hamper otherwise technically possible uses of the data. We recommend early surfacing of this information to mitigate five risks: 

1. Regulatory and compliance complexity: Data licensing must align with compliance rules around grid data, market data, and critical infrastructure. It is important to ensure data inputs to AI systems, and the outputs of the AI, remain compliant.
2. Third-party data dependencies AI models in energy often rely on weather feeds, satellite imagery, market pricing, and sensor data from multiple vendors. Each source carries its own licensing terms around permitted use, commercial exploitation, and AI training rights. Identifying these dependencies early prevents data supply chain disruptions during development, or worse, after deployment.
3. Intellectual property and model ownership: Who owns the AI model trained on licensed data? Many data providers now include clauses that restrict or claim rights over derivative works, including trained models.
4. Onward data publishing and monetisation: Energy sector companies typically want to share or sell AI-derived insights. Licensing terms set upstream can block valuable downstream opportunities. 
5. Long-term data access and continuity risk: Many foreseeable AI systems in the energy sector (e.g. predictive maintenance, load forecasting) need consistent, long-term data access. Identifying long-term data rights is critical to operational resilience.

Governance to enable usable datasets which can be combined with other datasets 

As mentioned in IB1 response to Ofgem’s AI in the energy sector guidance consultation IB1 encourages cross-sector collaboration and learning wherever possible. We recommend engaging with cross sector (i.e. water, transportation, local authorities, etc) and working with citizen advocacy groups to learn from best practices, ensure guidance is consistent for cross sector use cases (hydrogen, electric vehicles, electrifying public transport, etc), and understands the impact of AI guidance on different socio-economic stakeholder groups.

As described in IB1’s AI positioning statement, IB1 supports a hybrid governance model, combining robust oversight with decentralised data sharing, including smart contracts and digital identity solutions

AI must be designed to mitigate bias and discrimination, ensuring fair access to economic opportunities, financial services, and public resources. We support governance which is co-designed through processes which are adequately representative of different stakeholders or stakeholder groups, ensuring that the approach is collective rather than ‘done to’ from the top down.

To mitigate risks and enable data sharing at scale for AI use, the industry must consider more than just the dataset. For an identified use case, it needs to collectively determine:

• User needs & impact: commercial priorities, business cases, and prospective new products and services to be unlocked.
• Technical infrastructure: shared ontologies, APIs, schemas and standards to support data exchange. 
• Licensing & legal: data sharing agreements, modes of redress and liability frameworks.
• Engagement & communications: common language, stakeholder engagement and recruitment.
• Policy: alignment with corporate policy and industry regulations.

At IB1 we do this through a robust governance process and Icebreaking to drive groups of organisations to make the critical decisions required to exchange data with one another.

4. Who would the users of the dataset be? 

All identified IB1 use cases, detailing the value, kind, potential users, and scale of the required data, are outlined here: https://ib1.org/energy/reports/ 

5. What scale does the dataset need to be? 

All identified IB1 use cases, detailing the value, kind, potential users, and scale of the required data, are outlined here: https://ib1.org/energy/reports/ 

6. What would enabling AI use of this dataset unlock? 

All identified IB1 use cases, detailing the value, kind, potential users, and scale of the required data, are outlined here: https://ib1.org/energy/reports/ 

7. What would be the arrangements for ongoing maintenance, governance and curation of the dataset? 

As noted in IB1’s response to Ofgem’s AI in the energy sector guidance consultation: 

IB1 encourages cross-sector collaboration and learning wherever possible. IB1 recommends engaging with cross sector (i.e. water, transportation, local authorities, etc) and working with citizen advocacy groups to learn from best practices, ensure guidance is consistent for cross sector use cases (hydrogen, electric vehicles, electrifying public transport, etc), and understands the impact of AI guidance on different socio-economic stakeholder groups.

AI must be designed to mitigate bias and discrimination, ensuring fair access to economic opportunities, financial services, and public resources. IB1 advocates strongly for AI governance to integrate with developments in data governance, both within the energy sector and in the cross-economic space (e.g. Smart Data Roadmap, approaches to consent or permission). 

IB1 believes it is important for data governance to establish principles, structures, roles and responsibilities, agreed upon by market participants, that enable auditable, accurate and timely data sharing at a market-wide scale. As mentioned in the IB1’s May 2024 AI consultation response, IB1 recommends that the data ecosystem, and integration with the data governance landscape be acknowledged.

IB1 notes that in training a model it is highly likely that training datasets will contain sensitive data (it is also possible to use only anonymised data within a training dataset to retain privacy in the model itself), but it is possible to implement techniques where sensitive data is significantly better protected in the training of the model such as aggregation, pseudo-anonymising personal data. A good example of this that has been accepted by Ofgem as appropriate for maintaining privacy is the creation of datasets in energy that aggregate data down to a few households based on which properties are on different Low Voltage Feeders. If there are clear controls on the training data which datasets can and cannot be used to train AI models, then we can expect the produced AI model to be privacy preserving. If you implement data protections after an AI model has already been trained, it is harder to control. If a model has used training datasets with potentially identifiable data within them, the model may provide outputs using this data and can end up linking datasets together to make it personally identifiable

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer. 

Overall Position

We support the introduction of a new licence condition requiring improvement to connections data. However, the proposal would benefit from clearer definitions of sensitive data and a broader scope that includes both open data and shared (sensitive) data. It is important to note that capacity data is relational not static – interoperability between different data providers and datasets is essential.

A transparent user needs-led approach to data assurance would encourage data sharing, support higher data user confidence, and provide more flexibility than fixed requirements on accuracy, completeness and timeliness, for example regarding update schedules and interoperability. Data user needs must be explored and permitted to share improvement incentives to ensure design and use are aligned. It is important that shared data improvement is incentivised before the timeline for full DSI integration as there is demand for this data immediately. 

Consultation question responses:

Theme 1 – Improving visibility and accuracy of connections data 

Q1.1. Do you agree with Proposal 1.1. to introduce a new licence condition for accurate, complete and timely data? 

Yes, we agree with Proposal 1.1 to introduce a new licence condition, however, it should not be limited to open data publication (see question 1.2 below for sensitive data response). All data sharing would benefit from a clear assurance framework, which may draw from established assurance approaches such as Icebreaker One’s generic dataset assurance levels. Data that is not 100% accurate, complete or timely can still be valuable as long as the limitations are made clear. Assurance encourages publication rather than waiting for “perfect” data, which can mean that key datasets are not published due to data quality concerns. Assurance can include accuracy, completeness and timeliness but it enables more nuanced or context-specific signals about data quality, for example interoperability or provenance.

We encourage licensees to engage widely with stakeholders, particularly those outside the energy sector, to develop data assurance signals that meet specific user needs. Open Energy can facilitate this through a structured approach to design, implementation and governance of such standards within the Energy Sector Trust Framework.  

We support the requirement for data to be as close to real time as feasible, subject to security considerations (e.g. more granular data may be subject to additional access controls). Monthly updates should be considered a minimum baseline, not an indicator of best practice. More frequent (e.g. daily) data updates would be helpful to accelerate policy ambitions to speed up the connection queue. In all cases, update schedules should be published transparently as part of the assurance process.

It is vital that this condition has a consistent  approach across distribution and transmission networks to ensure data is as interoperable as possible. Increasing demand from new industrial plants and digital infrastructure reinforces the need for high-quality, frequently updated, relational connections data. Connections data requirements should apply consistently to both:

• Generation connections
• Demand connections (including large industrial loads and data centres)

Q1.2. Do you agree with Proposal 1.2. to split data into open and sensitive categories, and to use the Data Sharing Infrastructure to share sensitive data? 

No. Sensitive data is not a monolithic category, there are existing approaches (e.g. IB1 Data Sensitivity Classes) to sub-categorise which should be used in order to assess data sensitivities and place appropriate access controls/licensing. This will provide DNOs greater guidance from regulators on what should be considered sensitive data. 

DSI data sharing may not be (immediately) suitable for all use cases, it is currently unclear when and how non-regulated actors will be able to access data via the DSI and these actors constitute major customers for connections data (e.g. heavy industry, retail etc). While sensitive data may be exchanged via the DSI in future, improvements must not be put on hold until the solution is ready. Further, determining whether the DSI is used as the primary mechanism to share sensitive data should depend on the outcome of the MVP.  

Q1.3. Do you have any additional comments in relation to the decisions and proposals outlined in this theme? Do you have any additional comments related to any other aspects of this theme you think we should consider? 

Additional comments:

• Network headroom is not static at a single supply point (substation / GSP). Capacity availability is relational and influenced by:
  • Nearby supply points and how power is drawn/combined from different points
  • Connection queues and timelines
  • Reinforcement plans and timelines
  • Local and regional constraints (e.g. DNO/TNO or cross-DNO constraint interactions)
• The licence condition and associated data standards should better capture and communicate these relational dependencies.
• Greater transparency regarding capacity that has been committed but is not yet utilised (and anticipated timescale for use) may support better planning.

Lessons from relevant innovation projects (e.g. work examining relational network constraints) should inform the design of data publication and visualisation tools. In particular, lessons from the Strategic Innovation Fund REACT programme which aimed to  address current planning and future planning for generation siting may be valuable. REACT’s Alpha Phase Data accessibility and interoperability report recommendations:

• Reducing friction: To improve data assurance, reduce friction across data silos and provide forward compatibility with the Virtual Energy System, the REACT project must embrace a ‘Trust Framework’ methodology throughout its work.
• Improving data accessibility: To improve the discoverability of datasets and encourage process innovation, Transmission Owners should publish internal process diagrams that describe the workings of complicated internal processes – such as the Network Connection Request process.
• Improving prediction: To improve long-term planning for Transmission Owners and for other stakeholders, a statistical model of projects should be embraced that tracks a project’s estimated probability of success according to the best available data.
• Embracing innovation: To radically embrace innovation around processes, such as the Network Connection Request process, virtual ‘sandbox’ representations of these processes with representative data should be created. This will enable innovators to safely experiment with innovative solutions without affecting Business as Usual.

As mentioned in IB1’s Response to Ofgem Modifications to RIIO-3 consultation, with the progress of the Data Sharing Infrastructure (DSI) programme, IB1 anticipates ‘Shared Data’ sharing will evolve and will inform the evolution of data best practice (DBP) guidance. In particular, as data sharing scales, the need to standardise and harmonise legal and technical approaches will become more pressing in order not to slow innovation and add unnecessary cost. IB1 recommends that DBP should include guidance around Shared Data within the triage processes and licensing decisions, highlighting the role of Shared Data Schemes to provide definitions that aid interoperability and maximise impact.

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer. 

Consultation response:

1. Do you agree with the Workgroup’s initial view that P494 does better facilitate the Applicable BSC Objectives than the current baseline?* Please provide your rationale and, if ‘No’, please provide full details of your Alternative Modification(s) and your rationale as to why it / they better facilitate the Applicable BSC Objectives. 

• Yes
• No 
• Neutral / No Comment 
• Other 

Rationale: Elexon is unable to fulfil the potential benefit of making the data available with its current position as Data Processor.

2. Do you agree with the Workgroup that the draft legal text in Attachment B delivers the intention of P494?

• Yes
• No 
• Neutral / No Comment 
• Other 

Rationale: 

• Data Controller is limited to “Relevant BSC Personal Data” which only applies to data about natural persons. This will exclude data protections for company data envisaged in the DUAA. It leaves a lot of heavy lifting to the SDR Rules for non-personal but commercially-sensitive company data.
• SDR Rules not sufficiently developed at this time to assess whether, in combination with the code change, they are sufficient to ensure adequate data protection under the DUAA:
  • Identifying legitimate agents
  • Identifying meter owners not covered by CCS
  • Licensing and access arrangements for commercially-sensitive but non-personal data
• The consultation notes that “The means of determining whether a data set is commercially sensitive or personal data are being explored and are outside of P494”. This leaves a lot of work for the SDR Operations Manual to cover. The SDR is described on p27 of the consultation as containing “list of all APIs and reports published as well as technical details for how SDR users can interact with the SDR”. It will need to have much more detailed governance information. There is a risk that these considerations will “fall between the stools” of the BSC modification and the SDR Operations Manual.

3. Do you agree with the Workgroup’s recommended Implementation Date?

• Yes
• No 
• Neutral / No Comment 
• Other 

4. Do you agree with the Workgroup that there are no other potential Alternative Modifications within the scope of P494 which would better facilitate the Applicable BSC Objectives?

• Yes
• No 
• Neutral / No Comment 
• Other 

5. Do you agree with the Workgroup’s assessment of the impact on the BSC Settlement Risks?

• Yes
• No 
• Neutral / No Comment 
• Other 

6. Will P494 impact your organisation?

* If it will impact, please provide a description of the impact(s) and any activities which you will need to undertake between approval and implementation (including any necessary changes to your systems, documents and processes) and any on-going operational impacts. Where applicable, please state any difference in impacts between the Workgroup’s proposed solutions. 

• High 
• Medium 
• Low
• None 
• Other 

Rationale: There is potential for P494 to affect the Perseus smart meter scheme positively, opening up a wider array of the kind of meter points used by SMEs. 

7. How much will it cost your organisation to implement P494?

* If any, please provide details of these costs, how they arise. Please also state whether it makes any difference to these costs whether implemented as part of or outside of a normal BSC Systems Release. Where applicable, please state any difference in costs between the Workgroup’s proposed solutions and if applicable, between the different roles. 

• High 
• Medium 
• Low
• None 
• Other 

Rationale: P494 does not drive any direct costs

8. What will the ongoing cost of P494 be to your organisation?

* If any, please provide details of these costs, how they arise. Please also state whether it makes any difference to these costs whether P494 is implemented as part of or outside of a normal BSC Systems Release. Where applicable, please state any difference in costs between the Workgroup’s proposed solutions and if applicable, between the different roles. 

• High 
• Medium 
• Low 
• None
• Other 

9. How long (from the point of approval) would you need to implement P494?

* Please provide an explanation of your required lead time, and which activities are the key drivers behind the timescale. Please also state whether it makes any difference to this lead time whether implemented as part of or outside of a normal BSC Systems Release. Where applicable, please state any difference in lead times between the Workgroup’s proposed solutions. 

• 0-6 months 
• 6-12 months 
• >12 months 
• Other

Rationale: P494 does not require any action from us

10. Do you agree with the Workgroup’s assessment of the consumer benefits?

• Yes 
• No 
• Neutral/No comment
• Other

11. Do you agree with the Workgroup’s assessment that P494 does impact the European Electricity Balancing Guideline (EBGL) Article 18 terms and conditions held within the BSC?

• Yes 
• No 
• Neutral/No comment
• Other

12. Do you have any comments on the impact of P494 on the EBGL objectives?

No

13. Which of the following funding options do you prefer for the recovery of SDR costs?

• Costs recovered from Suppliers based on the number of MPANs supplied (option one)
• Costs recovered from Suppliers based on their share of delivered energy volumes (option two)
• Costs recovered from Suppliers using a hybrid approach combining MPAN-based and volume-based charging (option three) 
• Costs recovered through existing BSC arrangements and borne by all BSC Trading Parties (option four) 

Rationale: No comment

14. Do you have any views on when the full review of the cost to SDR Users should occur?

• Yes 
• No 
• Neutral/No comment
• Other

15. Do you agree with the legal basis to establish and operate the SDR?

• Yes 
• No 
• Neutral/No comment
• Other

Rationale: The underlying mechanism of creating the SDR Manager and giving it Processor rights seems sound, but it is lacking detail for non-domestic users as noted in our response to Question 2

16. Do you have any views on what the de minimis aggregation level should be?

• Yes 
• No 
• Neutral/No comment
• Other

Rationale: The proposed choice of 10 MPANs is not presented with a clear evidence based rationale. If there is a more detailed rationale this should be put forward transparently. There is an opportunity to build a more nuanced context-specific decision on the appropriate level of aggregation based on factors such as geographic dispersal and existence of generation and storage capabilities that may provide a “signature” in the data. Also consider differentiating “highly aggregated” data (say 50+ MPANs) that may be widely licensed, and “minimally aggregated” data (5-10 MPANs) that may have more restrictive access and licensing to prevent abuse.

17. Do you have any further comments on P494? 

There is a considerable amount of work to be done in the SDR Operations Manual in order to achieve the goals of the SDR Trust Framework. The following are some key elements left to be defined:

1. ID & Verification for non-CCS access is not defined (and even for CCS requires that to have been established). CCS should eventually cover business meters , and hopefully this will extend to smart and AMR meters. But that may not be until 2028. Businesses are key potential beneficiaries of SDR, for both cost reduction and net-zero impact. A number of the expected SDR Users focus on services intended for business. How will SDR support businesses in the interim? How will the SDR Users be verified, their data usage controlled, and how will they provide evidence for meter data access from businesses?
2. The data sensitivity classes need more definition and clear policies for application
3. The eligibility requirements and decision-making process for executing an Access Agreement and allowing access must be defined, as well as policies/processes for ensuring SDR Users remain eligible
4. Data licensing requirements are not mentioned in the consultation. How will purposes be categorised and policed? What is permitted/not permitted for the various levels of non-open data?
5. Liability and redress are not mentioned in the consultation. What policies and processes will enable data subjects harmed by the SDR to seek redress?

Since SCR covers a wider range of legal bases and potential data users than CCS, we recommend early consideration of how governance elements such as those above may be harmonised with other data sharing initiatives. This may be achieved through identifying opportunities for common definitions around ID&V, data sensitivity, purposes (or classes of purpose), and licences. Icebreaker One and Open Energy have research and experience, drawn from wide stakeholder engagement, that can inform this work.

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org.

Consultation response:

Q1. Do you agree with our case for change and that policy intervention is needed for DNO asset registration? 

Icebreaker One (IB1) is a non-profit working on data sharing and sustainability, convening organisations and governments to design market-scale solutions to make data work harder to deliver Net Zero. IB1 creates and runs programmes to reduce barriers and costs to finding, accessing, using, and sharing data, which will ultimately reduce costs for consumers.

IB1 supports better data on assets, and data sharing between DNOs, suppliers, and other organisations who need to understand headroom capacity and demand. We note there is a need to distinguish clearly between asset type(s) and capacity at the initial phase. In future, better data on asset performance and behaviours would be helpful to ensure this initiative can be most useful – e.g. capacity is not static with flexibility assets in play.

Q2. Do you agree with our priority use cases, and are there any other use cases we should consider? 

We agree with Ofgem’s identified use cases, however, we note that the data end user within the priority (regulated entities) and further use cases may have very different needs and data sharing instruments available. As mentioned in IB1’s response to Ofgem’s Energy digitalisation governance: architectural coordination letter, we propose that an industry-independent coordination body helps coordinate a flexible energy system. Data sharing at scale requires the separation of ‘the data’ from its governance and the technology used to host and transfer it.

We encourage the inclusion of potential ‘further users’ as a part of a governance process from the outset to ensure a solution suits their needs and does not exclude the solution from expanding past the priority use cases. We advocate for starting with a use case with external (non-regulated / less digitally mature) players, then a B2B DNO focussed use case to make subsequent use cases easier and less likely to inadvertently produce blockers. Leaving local authority use cases for “later” risks local planning and investment being disconnected from the physical reality of supply. A key use case to consider is data centre energy demand, which reinforces the need to urgently prioritise local authority use cases. 

IB1 has worked on a few other relevant collaborative use cases in this area, including:

• Getting small scale assets / flex services online (Open Energy Future of heating –  Residential Property Developer use case).
• How data sharing can be used to better understand how to maintain the assets already in place. IB1, SSEN-Transmission, IBM, and Palantir on a Strategic Innovation Fund programme, NIMBUS, which focussed on granular weather data and network innovation to build for sustainability. See the Discovery Phase report and the Alpha Phase report.
• IB1 partnered with SSEN-Transmission, Olsights, Mapstand, SGN, and National Grid on a Strategic Innovation Fund programme REACT to address current planning and future planning for generation siting. See the Discovery Phase report, and the Alpha Phase report. This use case reinforces the need to know other assets on grid to aid grid capacity understanding and future planning.

Q3. Are there any other policy or industry initiatives that we should seek to align with? 

IB1 encourages seeking alignment with:

• Open Energy – run by IB1, has expertise articulating use cases, and designing and quickly implementing shared data schemes with appropriate governance – includes legal agreements, assurance and technical specifications – in collaboration with stakeholders.
• Connections end-to-end review: updated proposals and next steps​ consultation. To what extent are external entities interested in assets as opposed to capabilities?
• Consumer Consent Solution, currently being developed, designed and delivered by RECCo Ltd, as small scale asset data is in scope (unless this programme is using another lawful basis for processing, this would need to be articulated clearly).

Q4. Do you agree with the scope proposed for assets, data, entities, and data stages, should anything else be considered?

As mentioned above, there needs to be a defined governance process for considering and agreeing upon the proposed scope for assets, data, entities, and data stages. 

IB1 would highlight there is a need to identify current data uses, and to be flexible enough to incorporate new ones as they emerge, to establish both the scope and the data quality and completeness requirements for asset information. For example, there is likely to be a difference between the DNOs’ data quality requirements at the lowest end of the asset capacity scale and the data quality requirements for users like councils, planners, microgrid/heat network assessors etc. Additionally if this asset data feeds into the flex market, missing or incorrect installations could lead to financial consequences for asset owners. 

While not in scope for the initial phase of development, our suggestion for future development would be the ability to transfer data on asset profiles/behaviours. This would be incredibly useful to better understand how flexible assets actually behave and their real-life impact, for example on network capacity.

Q5. Do you agree with our enablers and dependencies, and are there any others we should consider? 

IB1 would add on the lawful basis for processing – if not using consent then clarify on what lawful basis the register operates under. It would also help to understand how any data protection risks potentially associated with the register will be managed and governed. It is not currently clear how the lawful basis distinguishes between household and business (including microbusiness/SME) assets. This will interact with the Data (Use and Access) Act for businesses and requires clarification.

Q6. Do you have any suggestions for collecting legacy data, or for integration of other datasets into DNO registers? 

No comment. 

Q7. Do you agree with the advantages and disadvantages for the proposed options, are there others or any wider aspects we should consider? 

Wider aspects to consider on Option 2:

• May require upskilling/investment by DNOs, with an opportunity to subcontract if they are lacking skills in-house. This is a low risk if data standards are agreed through a governance process.
• As mentioned in Question 2, this initiative must be mindful of restricting use cases to regulated entities first which may make it harder for other users in the future. 
• As there is demand by non-regulated users for asset data now, there may be a benefit to spinning up a scheme in the short frame which is ready to integrate with DSI but has governance to engage a wider range of end users at the start. 
• This option has the highest potential to scale as it does not bottleneck in a single database/register, and provide utility for a wide range of use cases. 

Wider aspects to consider on Option 3:

• New databases and portals struggle to scale for a wide array of use cases as infrastructure systems are being digitalised in a decentralised and distributed way
• This option gives liability to a central entity versus distributed liability to DNOs
• May conflict with current DNO autonomy in deciding what data to publish and how to publish it, guided by DBPG. In particular may lead to a lowest-common-denominator approach that disincentivises DNOs from publishing otherwise-useful data that isn’t needed by the central register

Wider aspects to consider on Option 4:

• Operating a flexible market is a significantly different use case from the ones articulated above – expanding existing initiatives may result in a loss of focus on the original challenge it was solving
• Suggest a focus on harmonisation rather than making FMAR even more complex.

Q8. Are there any changes you would make to any of the proposed options to enhance them? 

IB1 would emphasise the need for a determination on what body would govern the standards for Option 2, and how stakeholder engagement beyond the regulated entities will be managed. There is a need to convene stakeholders within and outside the industry to ensure it is fair and accessible as well as implementable by the data holders. 

Q9. Have we missed or discounted any options that you think are suitable? In particular, for option 4 is there a preferable alternative to FMAR for expansion, and why? 

No Comment. 

Q10. Which option is your preferred option, and why?

IB1 would encourage Option 2, as it is the fastest to market and lowest cost, and can be decoupled from other initiatives, so can run in parallel and at pace. We would suggest this happens through a trial ‘scheme’ developed as and will be DSI integration ready for when DSI is ready to support asset data sharing. 

This option also has the opportunity to have the simplest governance (only DNO liabilities) – although this needs defining – as referenced in Question 8.

This is Icebreaker One’s response to Ofgem’s Energy Digitalisation Governance – Architectural Coordination letter.

Please note that throughout this consultation, Icebreaker One (IB1) uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org.

Executive summary

This response advocates for a focus on coordination of the energy sector’s data architecture and energy data governance as a fruitful starting point for architectural coordination of digitalisation governance. It emphasises that coordination is an ongoing process with human and technical components. It further works to the principle of minimisation, specifying that coordination activity must work in the leanest feasible manner, delegating to existing sector processes where possible and only acting where there are clear requirements for further intervention. We propose that the coordination challenge should be met via the appointment of an industry–independent coordination body composed of Secretariat, Research, and Monitoring functions. 

We do not propose that the coordinator should have enforcement powers, as these are most readily delivered under the existing regulatory and legislative capabilities of Ofgem and DESNZ. However, both Ofgem and DESNZ must be required to consider options from the coordination body in their determinations. 

The Secretariat should act as an independent facilitator for participatory governance processes which can adapt flexibly to evolving coordination needs and ensure accountability. 

The Research and Monitoring function should have two responsibilities:

1. mapping the domain(s) in which coordination is enacted in order to support effective participatory governance
2. monitoring and reporting on the outcomes of coordination activity to improve transparency and join-up with adjacent policy/regulatory goals (energy and cross-sector). 

We suggest that this function includes coordinating and monitoring the delivery of the sector’s digitalisation roadmap. We suggest that the body would require a small permanent staff to ensure continuity of process, with additional staffing contracted or seconded in on a short term basis for agile response to emergent needs (e.g. particular technical or domain expertise concerning a particular coordination challenge). This lightweight approach will deliver the intended benefits at a reasonable cost to the bill- or taxpayer. 

Response

Where should we focus?

Prior to addressing specific prompt questions, it is important to discuss the boundaries of the digital space and its component parts. Digitalisation is an umbrella term which can be used to refer to a wide range of different processes, technologies, activities, actors, and frameworks. Accordingly, the term is prone to some mystification as well as the drawing of false equivalences between digitalisation and technology. While we agree with Ofgem’s statement that there is an emergent need for coordination in energy sector digitalisation, we emphasise the importance of defining the boundaries of what exactly, within the wider digital space, is the target for this activity.

As discussed in IB1’s response to DBT’s Invest 2035: industrial strategy consultation, and in alignment with the National Data Strategy, the bedrock of digitalisation lies in data. In parallel, a significant proportion of industry digital activities to date involve laying the foundations for how data is governed, shared, and used within the energy sector. Accordingly, we strongly suggest that Ofgem’s architectural considerations at the present time focus on the coordination of the sector’s data architecture and associated energy data governance rather than other elements of the digital transition. Coordination in other digital arenas may well be required in future and we support future consultation accordingly. However, we do not believe that it represents value for money, nor effective prioritisation against net zero, to focus on these areas at the current time.

It is also important to draw a clear line between the valuable work currently progressing in large but focused sector-wide initiatives, such as the Data Sharing Infrastructure (DSI) or Consumer Consent Solution programmes, with the overall task of coordinating sectoral data governance. At its heart, data is not a technology, an ontology, or a standard. Rather, data is highly contextual — defined by a framework of rights-based governance, shaping how it can be gathered, shared and used, by whom, and for what purpose(s). 

Many ongoing data sharing initiatives in the sector (currently in their definition, prototype, or pilot phases) are advancing technology-led projects. These technical developments augment the sector’s capacity to collect, transport, and process data which is valuable. However, we have raised concerns in several forums that these projects risk developing in a manner which results in disjointed data governance. Coordination in the data governance arena would ensure that technology buildout will be clearly linked to user needs, meet appropriate levels of security, and promote legal interoperability supporting clear and confident data use. Without coordinating energy data governance, we risk building an environment where data exchange is improved on a technical level, but the real world use of the data remains subject to the same limitations that have been established by the research literature. 

How would coordination be achieved?

Coordination is an ongoing process between people and organisations, which will contend with ‘live’ and sensitive factors such as vested interests as well as wider factors such as the economic climate. We would anticipate a common digital architecture coordination function extending beyond a document, to capture the scale and nature of the coordination problem. The “function” of architectural coordination delivers the value – a document could describe it, but would not enact it. We believe that an independent entity is required to operationalise effective coordination. We also advocate that this should be achieved through as thin a layer of activity as possible, in order to present the best value for money and time. 

Additionally, we emphasise that our engagement with industry via the Open Energy Advisory and Working Groups has highlighted a need to think of coordination not as all organisations within the sector doing things in the same way. Rather, coordination should  focus on harmonisation and interoperability within company contexts of operation and as a common framework which aligns activities and reduces duplication. 

Open Energy

We believe that Open Energy is the only initiative currently operating within the energy sector that holds the independence, governance approach (designed in collaboration with the Institute of Directors), cross-sector experience, technical knowledge and flexible capacity to address architectural coordination of energy data governance. 

Open Energy, the competition-winning programme developed under the UKRI Modernising Energy Data Access initiative, identified and articulated the need to make it straightforward to find, access and share energy data. Open Energy was funded by £1.3m public money through three phases and is currently funded by commercial members. 

Open Energy is coordinated by the public-benefit nonprofit body, IB1, and has been specifically developed for this purpose using a combination of radically transparent methods of open working, extensive consultation with stakeholders, and the input of specific domain expertise from energy industry, academic, cybersecurity and Smart Data specialists.

Successful governance initiatives, including Open Banking, have taken the model of having an independent, non-sectoral incumbent body take on an architectural coordination role. Additionally a key recommendation from the 2021 Energy Digitalisation Taskforce Report summarises:

It is recommended that an independent, commercially disinterested body is established by Government to develop and/or incubate Public Interest Digital Assets on behalf of the sector. The Body should be given a mandate and funding to develop and deploy assets (either directly or via partners), directed by a stakeholder panel interested in the current and future needs of the energy sector. The benefit of this is that it would report to government but operate to the side of it.

As part of discussions following this letter, we appeal to Ofgem and DESNZ to enter into dialogue with Open Energy and its membership to discuss how Open Energy might be appropriately strengthened (e.g. participation or enforcement mandates) or configured (e.g. as a special purpose vehicle) to enable it to meet the required coordination function.

Our focus on governance is driven by the view that making data work harder for net zero isn’t a technology challenge. Rather than a deficit of data or technologies to manage it, it’s a deficit of effective processes for groups of organisations to come together, cooperate on and set the terms of data sharing that’s really holding us back.

In our work, governance is an ongoing process. The execution of this process produces decisions that enable data sharing to take place. In practice, this involves establishing principles, defining clear roles and responsibilities, and agreeing priorities and tasks. It also involves collaborating to create artefacts to express and enforce these decisions, such as legal agreements and technical standards.

We have a particular approach to organising data governance at IB1. We use a tiered system of Steering, Advisory and Working Groups to bring organisations together. These groups work together to agree and adopt:

• User needs & impact: commercial priorities, business cases, and prospective new products and services.
• Technical infrastructure: shared ontologies, APIs, schemas and standards to support data exchange. 
• Licensing & legal: data sharing agreements, modes of redress and liability frameworks.
• Engagement & communications: common language, stakeholder engagement and recruitment.
• Policy: alignment with corporate policy and industry regulations.

Participation in this process can be either voluntary (initiated by the market), or mandatory (demanded by regulators).

Using this collaborative process within the Open Energy programme, IB1 has designed, implemented and operates the Open Energy data search engine, the Energy Sector Trust Framework (ESTF), and within it, the Assured Open Data scheme. The ESTF is supported by IB1-developed open source Trust Services, including common technical specifications, a registry providing human- and machine-readable data sharing rules, a public directory of members and a secure portal for members to manage their information and issue digital identity certificates. These atomic, reusable services also power the cross-sector Perseus scheme that automates emissions reporting based on smart meter consumption data for UK SMEs. 

Our approach is inspired and practically informed by the UK’s Open Banking ecosystem, which enables data to be shared in new ways across banks and other financial services. It now has 15 million users and is projected to sustain a $12bn market of data-driven products and services. This change has been achieved not by building a big, centralised database of customer banking data, but by governing who should access it and how it should flow. 

Key questions:

1. Where is there a need for architectural coordination across the sector to unlock the full value of energy system digitalisation? 

As outlined above, we advocate that data governance, including the governance of data sharing, represents the clearest priority for coordination activity in the current moment. Needs are likely to change over time, so this must be regularly re-assessed in light of the wider sectoral environment (e.g. digital maturity, progress towards net zero, contextual policy challenges, economic environment etc). Additionally, we urge Ofgem to approach coordination through the lens of cross-sector interoperability and harmonisation, rather than a “one size fits all” standardisation. 

There is a need for coordination of data governance in the following arenas:

Secretariat:

• Participatory processes: An independent facilitator is needed to support the involvement of a range of participants (directly or via a representative structure) which can adapt flexibly according to coordination needs. This requires:
  • Strong governance processes – e.g. covering participant selection, means of input, minuting, reporting, and decision-making
    • Ability to offer tailored mechanisms where required – e.g. working groups to focus on specific parts of the sector, or task and finish style groups to support elements of digitalisation strategy delivery.
  • Independent Secretariat function with experienced administrators to execute governance processes and communicate expectations of timescales, plans, key decisions etc.
  • Where required, the provision of independent chairing or facilitation services
  • Dispute resolution process, linked to existing sector mechanisms and to participatory governance processes.
  • Participant accountability mechanisms (linked to enforcement – see below).
• Enforcement: we suggest that enforcement activity occurs under the umbrella of either Ofgem or DESNZ. This may include:
  • Ability to compel involvement in participatory processes (at least at some defined level) of regulated entities to ensure fair and balanced process
  • Ability to invite external stakeholders as and when required, in a transparent manner (e.g. pinned to a published methodology for a certain use case / decision / piece of research).
  • Ability to action change
• Accountability: any coordinating entity must be accountable to its stakeholders. We suggest this is supported by the following:
  • Openness policies enabling scrutiny (e.g. of methodologies, processes, minutes, reports)
  • Where required (for security purposes), clear rules defining how scrutiny will be undertaken among closed audiences
  • Defined process for dispute resolution integrated with existing sector mechanisms
  • Clear processes for change management
  • Defined avenues for external involvement in participatory processes
• Other:
  • We strongly suggest that the Secretariat is empowered to communicate across sectors in order to best learn and harmonise with digital and data sharing initiatives that cross sector boundaries.

Research and monitoring:

• Mapping: light touch, but regularly re-visited, research and documentation to understand current and emergent actors, activities, points of interaction/crossover/competition, and gap analysis – this will also help draw the boundaries around the remit of current coordination priorities and future considerations. This must:
  • Include cross-sector activities
  • Include cross-scalar activities (e.g. map devolved authorities, local etc as well as national initiatives)
  • Include identification of priority use cases / sets of use cases, particularly which require addressing via pre-competitive activity.
  • Highlighting areas where government or regulatory input may be required to meet policy goals.
  • De-mystify parts of the digital transition into clear component elements (both socio-economic and technical) with defined terminology
• Monitoring: 
  • Devising, implementing and openly publishing Monitoring, Evaluation and Learning (MEL) methodologies and reports in accordance with a transparent schedule – including ways to ensure digitalisation supports other policy goals (e.g. Net Zero, Warm Homes Plan, Flexibility development etc) and increases transparency in an area of rapid sector growth.
  • Coordinating the delivery of the sector’s digitalisation roadmap to ensure that effort is not duplicated and complexity is minimised. While we welcome NESO’s work to address sector-wide digitalisation planning, we suggest that this function should be devolved to an independent body in order to appropriately hold all actors to account. 

2. What are the constituent elements of architectural coordination of digitalisation in the energy sector?

We have interpreted this question to refer to how architectural coordination could be operationalised through a coordinating body. We suggest that the body is composed of an experienced Secretariat, which is vital to good governance processes. It must also have a small research and MEL team as outlined below. Additional elements should be flexible and responsive to the developing ecosystem. Accordingly, it may be beneficial for the body to be able to second in expert staff on a temporary basis. Across the board it is vital for the coordination body to be independent.

Secretariat component

A Secretariat coordinates and supports group meetings to ensure the programme is making effective and timely decisions and is aligned with strategic objectives. Secretariat  administrative support includes: meeting arrangements, pre-read and agenda dissemination, note-taking and drafting of formal minutes. Maintenance of an effective, experienced Secretariat requires an appropriate budget for ongoing roles.

As outlined in question 1, the Secretariat component would support participatory processes, enforcement, and accountability functions. It is vital that the Secretariat retains independence from other sector bodies in order to navigate conflicts of interest and build trust among participants.

Research and monitoring component

An effective research and monitoring function requires the maintenance of a small team with expertise in research methods, knowledge transfer, and reporting. We suggest that primary research should be participatory, bringing in experts to minimise cost and duplication. The research element of this component may require a small flexible fund to support short term targeted projects (e.g. mapping stakeholders who must be consulted when developing a specific area of pre-competitive activity). The monitoring element requires access to participation from sector authorities to define the target and frequency of monitoring activity and dialogue with the wider sector, and appropriate experts, to identify or devise appropriate methodologies. It is essential for this component to have the ability to freely publish monitoring results, with sensitivity to factors such as security when defining the appropriate level of openness. This component should provide a forum for feedback from scrutiny as and when required.

We again emphasise the importance of independence in this arena as there may be cases where the component sheds light on poor performance or emergent issues. This requires an independent entity to perform; it cannot be nested in an existing body without risking conflict of interest.

3. What value could a common digital architecture document for the energy sector provide?

Coordination is an ongoing process between people and organisations, which will contend with ‘live’ and sensitive factors such as vested interests as well as wider factors such as the economic climate. We would anticipate a common digital architecture coordination function extending beyond a document, to capture the scale and nature of the coordination problem. The “function” of architectural coordination delivers the value – a document could describe it, but would not enact it. We believe that an independent entity is required to operationalise effective coordination

Potential benefits of architectural coordination include:

• Avoiding duplication — e.g. multiple Trust Framework providers that potentially aren’t interoperable
• Learning from other sectors — lacking clear deadlines and costs. The Pensions Dashboard Programme has an estimated cost of £289m, with no released date of when the dashboard will be made available to the public
• Saving money and reducing time-to-value by providing market participants with repeatable processes and building on well-understood standards 
• Prioritisation of key use cases
• Avoid the time and financial costs of a lack of coordination, especially on urgent causes such as net zero

4. What function may be needed to deliver architectural coordination and how would it interact with functions/organisations that are delivering digital public infrastructure (DSI/NESO, Consumer Consent Solution/RECCo, Smart Metering Network/DCC, FMAR and SDR/Elexon) 

• Ability to liaise and harmonise across sectors — e.g. Smart Data schemes, DSIT, Smart Data Council
• Cross-sector thinking is required to achieve the size of impact that the Industrial Strategy and The Clean Power Plan have outlined
• Must be a non-profit dedicated to the public good to avoid distorting the market and discouraging commercial members
• A function should be judged against the criteria of:
  • How light-touch and small it can be in order to deliver the needed effect
  • How much value is gained by stakeholders from their participation

5. Is coordination an ongoing task (including monitoring), or a temporary task to deliver the elements needed (from q2)? 

We strongly encourage that coordination must be an ongoing task, including monitoring, and acknowledge that it will adapt and change as energy digitalisation evolves. Governance must be designed to assess and adapt to changes. 

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer.

Consultation response:

18. Please provide any feedback on the proposal to refine the definition of scope 2, to emphasize its role within an attributional value chain GHG inventory and clarify that scope 2 must only include emissions from electricity generation processes that are physically connected to the reporter’s value chain, excluding any emissions from unrelated sources?

This response is on behalf of the Perseus programme’s member organisations. Perseus aims to unlock access to finance that reduces emissions, by automating sustainability reporting for every SME business in the UK. Perseus operationalises one granular use case focusing on the sharing of 30-minute electricity consumption data, which is combined with corresponding 30-minute local grid carbon intensity readings to calculate assurable monthly GHG emissions (See Perseus’ emissions calculations: https://registry.core.sandbox.trust.ib1.org/scheme/perseus/process/emissions-calculations/2025-10-23). The consumption data is sourced from SMEs with either a) a single business premise and a single, unshared smart meter, or b) an account with Perseus member Energy Data Provider that can provide half-hourly electricity consumption data. 

We welcome the GHG Protocol’s efforts to update the Scope 2 guidance. As the grid decarbonises, the current annual, market-wide accounting framework is increasingly insufficient for capturing the reality and complexity of electricity consumption. Perseus is currently UK focused and requires 30-minute electricity consumption and local grid carbon intensity granularity, however, we encourage the protocol to globally require reporting organisations to use the best possible available data. 

The proposal to restrict sourcing to the same “deliverable market boundary” rightly addresses the disconnect where companies claim emission reductions from grids they do not physically use. However, boundaries must be pragmatically defined.

Perseus member companies note that restricting procurement to narrow pricing zones could strangle market liquidity and prevent companies from supporting high-impact projects in adjacent, interconnected grids where decarbonisation is necessary. The final standard should explicitly allow for procurement across recognised interconnected power pools (e.g., EU-wide) rather than strictly enforcing narrow pricing zones.

19. Please provide any feedback on the proposal to clarify the LBM definition to reflect scope 2 emissions from generation physically delivered at the times and locations of consumption, with imports included in LBM emission factor calculations where applicable? 

As Perseus uses location-based method emissions calculations, we will only comment on LBM changes. 

The proposal to refine the Location-Based Method by prioritising a hierarchy of “Local” and “Hourly” data over national annual averages is scientifically sound. It correctly identifies that grid carbon intensity varies significantly by time and place. The administrative burden of the proposals may affect different business structures in quite different ways, potentially introducing new costs to distributed business with sites that are geographically dispersed. We suggest that the potential for an element of aggregation is considered. For example, this could mirror the ESOS model where a relevant proportion of the portfolio is surveyed and information is then extrapolated to the rest of the portfolio.

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org.

Consultation response:

Regarding paragraph 3.36 in the Statutory Consultation on the RIIO-3 Licence Drafting modifications – reasons and effects document:

Generally IB1 supports a common Digitalisation Re-opener to encourage digitalisation by allowing network companies to seek funding for data and digital related projects with a broader scope than just IT hardware or software upgrades and to align with RIIO-ED2.

IB1 supports digitalisation as key for energy sector decarbonisation, and required for the investment in flex services and the coordination between sectors who rely on energy to meet their decarbonisation targets (water, transportation, built environment, industry).

IB1 supports sector-wide convening and governance to ensure digitalisation happens in a coordinated manner and can enable ‘whole system solutions,’ as promoted in RIIO-ED2 and realise the subsequent cost savings. IB1 supports Ofgem to continue to promote and finance whole system digitalisation coordination in RIIO-ED3.

As there are many ongoing data sharing and data governance initiatives e.g. consumer consent solution, flexibility services, Data Sharing Infrastructure (DSI), which are currently in progress at different stages of development (definition, prototype, or pilot). Ofgem should not expect these programmes and underlying challenges the projects aim to solve to be resolved by the end of RIIO-ED3 (2031). Data sharing and data governance needs and subsequent solutions will evolve over time as we continue to electrify and connect the UK’s grid. As mentioned above, Ofgem needs to ensure ongoing governance and sector collaboration on data and digitalisation – reinforcement of this would be welcomed in addition to specific plans to expand/evolve data governance initiatives.

With the progress of the Data Sharing Infrastructure (DSI) programme, IB1 anticipates ‘Shared Data’ sharing will evolve and will inform the evolution of data best practice (DBP) guidance. In particular, as data sharing scales, the need to standardise and harmonise legal and technical approaches will become more pressing in order not to slow innovation and add unnecessary cost. IB1 recommends that DBP should include guidance around Shared Data within the triage processes and licensing decisions, highlighting the role of Shared Data Schemes to provide definitions that aid interoperability and maximise impact.

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer.

Consultation response:

Do you agree with the proposed implementation approach? Yes.

Rationale: We appreciate that there is a governance in place to discuss and approve the proposed implementation. We would welcome further transparency on the outcomes of applications to access data via this method and suggest that a summary of cases are made openly available after a 6-12 month trial period. Ongoing avenues for scrutiny remain important.

Please provide any further comments you may have.

As we are looking holistically at the smart meter data landscape, we will continue to work with the SEC and engage as it develops on a case by case basis and impacts wider use cases.

A draft of this position paper was circulated ahead of a licensee working group meeting held on November 26, 2025. Following input from the workshop, this updated draft is being circulated for further feedback from wider energy data stakeholders. 

Open Energy members hope that all RIIO-2 licensees, and the users of their data, will benefit from a clearly-articulated position on Open Data classification and access control. They would particularly welcome feedback from licensees who use third-party data platforms.

The Google version of the position paper is open to comments. Alternatively, interested parties may download a Word version. 

Please send comments or feedback to openenergy@ib1.org before February 2, 2026.

Key points from the position paper

RIIO-2 licensees that are members of Open Energy will:

• Adopt and enact an updated Assured Open Data definition that includes purposes for registration:

• D1.5.3 Anonymous downloads of open data is strongly preferred, but where the dataset requires compulsory registration before download:
  • D1.5.3.1 Registration is only conditional on completion of a lightweight challenge necessary for technical measures to minimise spam and bot abuse, such as verifying receipt of an email
  • D1.5.3.2 Acceptance of registration is automatic and immediate
  • D1.5.3.3 Registration may only be denied or withdrawn for misuse
  • D1.5.3.4 The registration process does not introduce any barriers to automated downloads or API access. Access to data is identical in all respects to a simple HTTP download of a published URL or API, except for the addition of a static credential or token that does not need renewing
  • D1.5.3.5 Require additional opt-in consent to use registration data for any further purpose. Data access must not be made conditional on obtaining any additional consents (e.g. use of registration data for analytics)
  • D1.5.3.6 If registration is only available via a third party platform (Data Controller), the third party must also comply with conditions D1.5.3.1 – D 1.5.3.5
  • D1.5.3.7 Third parties must transparently provide privacy policies and terms and conditions to the user if/where these differ from those of the Data Publisher.

• Apply the definition to metadata and data, meaning either or both may require registration
• Classify data requiring this form of registration as Open
• Licence data requiring this form of registration with either CC-BY-4.0 or OGLv3
• Implement information on registration forms/access gating screens making clear the purpose of this form of registration to end users and work with other licensees to align this language
• As required for compliance with UK GDPR, ensure privacy policies correctly reflect the use and protection of registration data, the length of time the data will be held, the situations where it would be disclosed
• Ensure terms of service for data portals do not contradict the Open Data licence being asserted for datasets on the portals
• Provide information in the registration process and/or the dataset listings that clearly separates Open Data “lightweight” registration from Shared Data registration requirements where registration may be used for other purposes, including limitations on access or use of the data
• Use registration as an opportunity, on a strictly opt-in basis, to provide additional benefits to users such as subscription to dataset update notifications or notifications of training opportunities

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer.

About Icebreaker One

Icebreaker One (IB1) makes data work harder to deliver net zero. We do this by orchestrating the development of focused, decentralised Schemes that unlock data from across organisations at market scale.
Perseus, for example, enables businesses to access over $100B of green finance, by automating high-quality sustainability reporting for every SME in the UK. The Schemes we orchestrate are inspired by the architecture of the UK’s successful Open Banking ecosystem and the interventions that brought it about.

1. What issues do customers face in accessing their data held by digital markets firms and sharing that data with third parties?   

‘Digital markets’ are hard to define, given the pervasiveness of the web and related technologies. Almost all companies will use web technologies to exchange goods, services or information. 

The following are examples of consumer markets that we think are particularly reliant on network effects, data-driven operations and multi-sided interactions: 

• Social media (such as Facebook, Twitter, TikTok, Instagram, Threads and Bluesky).
• Messaging (such as Whatsapp, Messenger, Telegram and Discord).
• Online marketplaces and retailers (such as Amazon, Temu, Shein, eBay, Gumtree, Etsy and Depop).
• Payment and transaction (such as Shopify, Klarna, Visa, PayPal and Stripe).
• Operating systems (such as Microsoft Windows, MacOS, Linux, Android and iOS).
• Web browsers (such as Chrome and Firefox). Email (such as Gmail and Outlook).
• Search (such as Google Search and Bing).
• App stores (such as Apple App Store and Google Play Store).
• Virtual assistants (such as Siri and Alexa).
• Large language models and interfaces to them (such as GPT-4, Chat-GPT, Copilot, Gemini, Claude and Perplexity).
• Cloud services (such as Google Photos, DropBox and OneDrive).
• Online courses and learning (such as Coursera and Udemy).
• Jobs (such as LinkedIn, Indeed and Adzuna).
• Loyalty schemes (such as Nectar, Clubcard and Avios).
• Gaming (such as Steam, PlayStation Network and Xbox Live).
• Gambling and betting (such as Bet365, 888 and SkyBet).
• Music streaming (such as Apple Music, and Spotify).
• Podcast streaming (such as Spotify, BBC Sounds sounds and Apple Podcasts).
• Books and audiobooks (such as Audible and Kindle).
• Video streaming (such as BBC iPlayer, Sky, Netflix, Amazon Prime and Disney+).
• News (such as Sky News, BBC News and Apple News).
• Content distribution (such as YouTube, OnlyFans and Substack).
• Travel (such as Airbnb, booking.com, Expedia and Skyscanner).
• Ticketing (such as Viagogo, StubHub and EventBrite).
• Navigation (such as Google Maps, Apple Maps and CityMapper).
• Ride hailing and food delivery (such as Uber, Bolt, Deliveroo, UberEats and JustEat).
• Gig economy (such as Upwork and TaskRabbit).
• Smart devices (such as Philips Hue and Apple Homepod).
• Health applications and wearables (such as ClassPass, Fitbit, Oura, Whoop, and Flow).

IB1 is generally involved in data sharing schemes where businesses initiate data sharing, rather than individual customers directly. However, we understand that both individual consumers and businesses can face a variety of issues in accessing their data from the services they use and sharing that data with third parties, including:

• A lack of transparency in obtaining consent, including overly legalistic wording, items hidden in small print, and a lack of clarity around the full range of partners’ data will be shared with and/or for what purpose(s).
• Lack of trust – this is key for obtaining consent. 
• Individual/household dilemma – consent for data sharing pertaining to a whole household of people is obtained from a single individual (there may also be a gender bias here if the account holders tend to be male) who may or may not actually live at that address (eg shared subscription service) – there is no mechanism to ensure household members are consulted.
• Revoking or changing consent – it is often easy to give consent (e.g. automatic pop-up) but much harder to change or revoke consent (e.g. requires a log in, hidden in a long settings menu, not available by non-digital means) – this requires much more transparency and an easy process.
• Linked services – Lack of understanding about the impacts of giving, changing, or revoking consent for services that may be linked (e.g. reliant on data flows) but potentially operated by different companies. For example, consumers may not understand the impact of rejecting access to a type of consumption data on access to smart products and services.

2. The government would like to identify where businesses are being held back by poor data access and where these data access issues could be helped through a Smart Data scheme. What use cases do you believe could be supported through a Smart Data scheme to address those issues, including types of products and services that ATPs might be able to offer, and what outcomes could this result in? 

Defining digital markets where businesses are particularly held back by poor data access is again hard to define.

In the context of this consultation – and to delineate this work from the UK Government’s existing work on Smart Data in more clearly defined, regulated markets such as energy and finance – the following can be seen as examples of business-to-business digital markets:

• Operating systems (such as Microsoft Windows, MacOS, Linux, Android and iOS).
• Cloud and compute (such as Amazon Web Services, Microsoft Azure, and Google Cloud).
• Virtual workspaces (such as Microsoft 365 and Google Workspace).
• Project management and productivity (such as Asana, monday.com and Notion).
• Instant messaging and video conferencing (such as Zoom and Slack).
• Large language models and interfaces to them (such as GPT-4, Chat-GPT, Copilot, Gemini, Claude and Perplexity).
• Financial management and accounting (such as QuickBooks, Sage and Xero).
• Customer relationship management (such as Salesforce, Hubspot and Mailchimp).
• Data science and reporting (such as Databricks and Microsoft BI).
• Content production and editing (such as Adobe, Canva and Figma).
• Social media (such as Facebook, Twitter, TikTok, Instagram, Threads and Bluesky).
• Recruitment (such as LinkedIn, Indeed and Adzuna).
• Online marketplaces and retailers (such as Amazon, Temu, Shein, eBay, Gumtree, Etsy and Depop).
• Logistics and distribution (such as SAP, Oracle and EasyShip).
• Online advertising (such as Meta Ads and Google Adsense).
• Payment and transaction (such as Shopify, Klarna, Visa, PayPal and Stripe).
• Web publishing and content management (such as WordPress, Wix and Squarespace).
• Content distribution (such as YouTube and Substack).
• Ticketing (such as Viagogo, StubHub and EventBrite).

This list is far from exhaustive; there are many further domain-specific digital markets.

At IB1, our focus is to drive the development of schemes around tightly-focused challenges or use cases related to net zero. Our flagship programme, Perseus, enables small-and-medium sized businesses to share granular emissions data from their smart meter systems with banks and other lenders. By providing lenders with the accurate and assurable data they need, the Perseus enables participating businesses to access loans and other finance to help reduce their emissions.

We urge DSIT to explore opportunities for Smart Data schemes to drive the sharing of similar energy consumption and emissions data related to these digital markets. The cloud and compute services market, for example, is responsible for a significant and increasing share of global greenhouse gas emissions. The data centers it uses consume close to 3% of the world’s electricity and global greenhouse gas emissions comparable to the airline industry. This could be achieved efficiently by developing or adapting Perseus.

3. What types of data and data holders would need to be in scope of a scheme in order to support any business models and address data access issues and use cases you have identified above? 

Data and data holders to target will depend entirely on the purpose of any Smart Data scheme. 

We believe it will be more difficult for the UK Government to establish a ‘contained’ scope for a Smart Data scheme here than in more clearly defined, regulated markets such as energy and finance. With digital markets, services are often entwined – for example, Facebook is both a social media platform and a marketplace for goods.

Open Banking was delivered through clear identification of a problem in the consumer banking market, supported by evidence. Any smart data scheme for digital markets will need a similarly thorough analysis of the market dynamics that require improved data access and intervention. 

In determining what data holders should be within scope of a Smart Data scheme for digital markets, DSIT could adopt a similar approach to the UK’s Online Safety Act and the EU’s Digital Market Act. Although imperfect – see discussion around Wikipedia’s classification under the OSA – these interventions target organisations with the power to act as gatekeepers to particular markets, primarily based on their user numbers and market position.

In determining the scope of any Smart Data scheme for digital markets, we urge DSIT to:

• Identify a very clear use case. Without this, data sharing doesn’t work. A clearly defined use case ensures there is no ambiguity around the purpose of the scheme and what it must achieve.
• Arrive at use cases and data sharing rules collaboratively. Our approach, Icebreaking, involves scheme co-creation with regulators, consumer organisations and civil society as well as industry.

4. What are your views on the feasibility to deliver a digital Smart Data scheme? Please consider any current or planned industry developments or changes that might affect delivery and highlight any key challenges.

Delivering a Smart Data scheme for digital markets is eminently feasible, even accounting for the difficulties described above. Perseus is proof of this, with banks starting to use the data to inform real loan-making.

5. Do you have an initial or provisional view on the likely impacts (positive and negative) on:

• Existing and future customers
• Data holders
• Small and micro businesses

We encourage the identification and definition of clear use cases with defined users (as mentioned in question 3) to be able to comment on likely impacts.

6. Do you have an initial or provisional view on the likely impacts (positive and negative) on:

• Innovation in the supply or provision of goods, services and digital content whether directly affected by a scheme or otherwise
• Competition in markets for goods, services and digital content affected by the regulations or other markets
• Business investment in the UK
• Economic growth

We encourage the identification and definition of clear use cases with defined users (as mentioned in question 3) to be able to comment on likely impacts.

7. What challenges and risks should we consider when developing a digital markets smart data scheme and how can we mitigate these? This might include (but is not limited to): competition; customer exclusion; data quality or data misuse; ethical, operational or technical readiness.

We see the following risks to successful delivery: 

• Developing a centralised solution. 
  • Mitigation: embrace a decentralised model, which aligns with the approach taken by Open Banking, and the architectural principles of the Data Sharing Infrastructure for ease of access and protection (ensures alignment with national strategy, Open Banking has been endorsed by the Competition and Markets Authority (CMA) and the Financial Conduct Authority (FCA)).
• Not codifying the relationship and responsibilities of the smart data scheme to be in support of the UK’s net zero and climate targets. This is essential to meeting the UK’s net zero and industrial strategy goals.
  • Mitigation: Codify the relationship between a digital market smart data scheme and existing net zero goals.
• Not following a use case driven approach. The risk is trying to do too much at one time, and the programme becomes overwhelmed without a core focus point.
  • Mitigation: follow a use case driven approach 
• A chosen use case does not have a clear business impact case. If there is no financial incentive, there will be no movement.
  • Mitigation: an advisory group articulates their business case for the chosen use case. 
• Failure to implement governance from the start, and governance failure to address broader user needs, technical implementation, legal, communication / engagement and policy impacts.
  • Mitigation: robust governance from the outset. 
• Lack of cross sector collaboration. Risk of non-interoperability and not taking the learnings from other sectors.
  • Mitigation: actively engage with stakeholders from the start.
• Too much emphasis on a technical solution  – must equally address governance, user needs, business, social, legal, engagement and communications to be successfully implemented and ensure a scheme is fit for purpose
  • Mitigation: understand the holistic approach required – user needs, legal, policy, and communications. https://ib1.org/sops/governance-schemes/ 
• Cultural change and industry readiness 
  • Mitigation: interact with the current data sharing culture within the energy companies, and consumers must be engaged to understand their value proposition. 
• Stakeholder engagement for collective agreement across the sector
  • Mitigation: engage early, often, and formally through governance.
• A scheme is seen as a technical solution rather than a holistic solution.
  • Mitigation: a trust framework incorporates technical, communications, engagement, legal and ongoing governance arrangements.
• Unequal access to smart services if we do not address the challenges known to exist in digital markets or known barriers to access, and any other infrastructure collecting the data which will be used in the scheme. This unequal access will be baked into any smart services offered and may unintentionally miss out key beneficiaries.
  •  Mitigation: robust governance experience to reduce unintended impacts.
• Creating unintended monopolies, negative incentives, corporate capture, and data misuse
  • Mitigation: robust governance, embracing and building upon open source solutions. 

8. What are the potential implementation costs to industry of introducing a digital markets Smart Data scheme? What aspects of a scheme might be most expensive to implement?

Open Banking is a case study for engagement for Smart Data. It has over 15 million users and over 29 million transactions per month. This provides strong evidence that there is both appetite and capability for British consumers to engage with Smart Data utilising a Trust Framework approach. 

Since 2013, it has cost Open Banking £millions to achieve this success. Building on the foundations of Open Banking, the Smart Data schemes Open Energy and Perseus have been able to be in pilot phases for £3.5m. With these foundations laid, costs for smart data schemes should be reduced over time as we build on the existing investments and lessons learned through implementation.  

As a key learning from the success of Open Banking is to follow a use case driven approach, it is vital to note that identifying the user(s), their needs and developing use cases requires time, effort and resources. This can be a challenging aspect of a scheme to define but it is a core element as everything is built around the user needs. 

Another key learning from Open Banking, Open Energy, and Perseus is the importance of incorporating robust governance from the outset. Implementation costs will include secretariat functions for a governance body, relevant company time for stakeholder engagement and scoping requirements, and technical implementation. This will include team members from across an organisation, which may include innovation, technical, data, research, legal, communications/PR, and policy compliance teams. 

9. How can we build and maintain customer trust in a digital markets Smart Data scheme? For example, what responsibilities need to be considered for data owners and ATPs?

Obtaining consumer consent and customer trust is key for a digital market smart data scheme. It is important to note that the current methods for obtaining consent from a consumer may be ineffective or inefficient as laid out in our response to question 2. 

As mentioned in IB1’s Developing an energy smart data scheme: call for evidence response, please find our recommendations to build and maintain trust with core principles below:

• Governance mechanism is built to function flexibly: As digitalisation of the wider economy accelerates it is essential that governance adapts with a shifting technical landscape. There will be a continual balance between addressing user needs and potential threats, necessitating robust governance to be participatory and responsive to a full spectrum of social and environmental considerations shaping the operational landscape, for example including capacity to respond to forthcoming Net Zero 2030 milestones. 
• Simple and Low Friction: IB1 recommends a simple and low friction option which builds on previous implementation in other industries, for example Open Banking which has been endorsed by the Competition and Markets Authority (CMA) and the Financial Conduct Authority (FCA), to ensure an energy smart data scheme is aligned with national strategy.
• Interoperable IB1 strongly recommends taking a joined up approach which is interoperable with initiatives across the economy. IB1 suggests the solution defines relationships with cross-sector bodies to enable cross-sector interoperability.
• Agile, Flexible, and Scalable: IB1 suggests introducing a clear process for change management in this principle. As governance needs will likely change with time. This may include indication of how the list of permitted data use purposes will be maintained with additions and removals
• Transparent and Informative: IB1 strongly recommends that documentation is published openly, along with any accompanying processes, methodologies, financial, legal, operations and governance processes, as also suggested in our DSI consultation response. 
  • Clear and consistent use of definitions and communications surrounding data. IB1 uses the data spectrum to communicate the definitions and differences between Open, Shared, and Closed data. 
• Inclusive by Design: IB1 urges the defined user journeys, messaging, terms, and customer support to be easy to use, transparent, and explained in a way that someone with a low technical reading comprehension can engage with. IB1 recommends building on open source, if not incorporated, there is a risk of inadvertently creating a monopoly.

• Secure by Design: IB1 encourages working with the National Protective Security Authority (NPSA) and National Cyber Security Centre (NCSC). IB1 would also recommend an adversarial analysis to be performed to see where security gaps may occur, and may affect the proposed architecture. A Smart Data scheme must avoid creating large targets for hackers where a compromise affects many consumers. Data required for investment must undergo a thorough assessment of risks, benefits, security measures, and potential international standards as there may be implications for data transfer and use across the UK and international borders. 
• IB1 recommends a focus on data rights: the same data will be used for many purposes. This means there will be multiple rights, based on purpose, carrying different legal, liability and related conditions. 

10. What common principles are needed to support the development of a digital markets smart data scheme and why?

We have recently introduced NOVA. A ‘NOVA-compliant’ solution embodies a coordinated structure of interoperable rules, governance, and infrastructure that connects actors across sectors while ensuring data flows are lawful, rights-based, and fit-for-purpose. NOVA stands for:

Networked

Data infrastructure must support modular, federated and interoperable participation across organisations, sectors, and jurisdictions.

• Modular: embody what is needed in a repeatable, cohesive and scalable manner
• Federated: support the coexistence of multiple platforms, protocols, and providers
• Interoperable: systems (not just technical, but also legal and operational) must be able to interact with low cost and friction, with harmonised approaches

Open

Data infrastructure must be grounded in open standards, API-enabled access, and transparent governance.

• Open standards: standards which are openly accessible and usable by anyone
• Open APIs: a web-addressable interface that enables machine-enabled data exchange
• Transparent governance: clear, accurate, and timely disclosure of policies, decisions, performance and impact

Verifiable

Data infrastructure and data access, usage, and governance must be assurable, rights-based and permissioned.

• Assurable: that the process of joining as a member, and of enabling data transfer and use can be audited, tracked and held to account
• Rights-based: data sharing is based on legal and related rights, codified in a contract, and enabled between assured members
• Permissioned: where relevant, or required by law, that permission or consent is given from the business or consumer, or that pre-authorised permission is determined by contract

Architecture

Data infrastructure must optimise for market access while enabling adaptive governance, whether market participants are data providers or data users, to ensure an open market.

• Market access: enable any Verifiable actor to enter the market
• Adaptive governance: define, iterate at market-relevant pace, enable, and facilitate scalable enforcement of, the rules
• Open market: ensure private sector, public-benefit, and national interests are addressed

11. Are there any tensions, overlaps, gaps or other features of the regulatory landscape in digital markets that the government should take into consideration?

As noted in IB1’s response to the Department for Science, Innovation, and Technology’s Technology Adoption Review, IB1 notes a key barrier to digital market and technology adoption, investment, and participation is a lack of a consistency in vision and policy which is vital for the decision makers in the organisations and companies to de-risk technical and innovation investments. Having a cohesive, consistent vision with clear actions allows for stakeholders to incorporate data sharing and data access at the core of their decisions.

As the data sharing economy develops in a manner which is increasingly fluid and cross-sector there is an ongoing need for policy and regulatory development which horizon-scans, assesses, and defines responsibility for addressing different aspects of the regulatory landscape. Providing this form of policy and regulatory join-up presents essential support to the incentivising and de-risking of investment in strategic sectors. 

Additionally, it is essential to have consistency within sectors and to consider cross-sector interactions of digital market Smart Data schemes, especially across the pinchpoints where sectors meet and/or markets are increasingly ‘coupled’ (i.e. energy and transport; energy and water; energy and manufacturing). It is essential that a smart data scheme promotes interoperability and consistency across sectors, promoting a whole-system approach to digitalisation and net zero.

12. What data sharing initiatives already exist in digital markets that the government should be aware of when evaluating a Smart Data scheme in digital markets?

Open Banking

The Open Banking Standard, which is now implemented in over 95 jurisdictions and a £20B open market, placing the UK at the forefront of data sharing innovation. It uses financial-grade APIs within a strong, neutral governance framework to address data policy, licensing, privacy, liability and technical standards. 

Perseus

Icebreaker One’s Perseus Scheme (the ‘rule book’ defining how data is governed) is aiming to facilitate trusted, standardised, permissioned and secure data sharing across sectors. It addresses key challenges in data interoperability and trust by linking data systems through a cohesive Trust Framework, streamlining the process of collecting and reporting emissions data. By enabling interoperability between members, it enables SMEs to minimise their manual effort in measuring and reporting their GHG footprint, and matching their profile to green finance. 

It is being developed by a group including commercial businesses (incumbents and challengers), non-profits, public bodies and trade associations, with support from the UK Government.

Open Energy

Icebreaker One’s (IB1) UKRI Modernising Energy Data Access competition-winning programme Open Energy has identified and articulated the need to make it straightforward to find, access and share energy data. IB1 established an energy sector data sharing programme through sector engagement (convening 100s of organisations and 500+ public webinar attendees) and governance processes (80+ Steering and Advisory Groups members) to develop operational services for search and access control. These are are now live and market-facing through the Energy Sector Trust Framework and Schemes, IB1 created, designed and developed Open Energy https://ib1.org/energy/ to provide three services:

1. Community: an expert network of professionals – the IB1 Constellation
2. Governance: co-design of data sharing Schemes using our Icebreaking process
3. Trust Services: An Energy Sector Trust Framework for Scheme implementation, covering Open Data, commercial Shared Data with pre-authorised access controls, and commercial Shared Data where access requires end-user permission/consent. In addition, Trust Services deliver search and assurability services. 

Our approach helps drive the design, implementation and adoption of open standards to create assurable data flows between organisations. This enables assurable Open Data and pre-authorised Shared Data and ultimately builds confidence across the ecosystem.

As noted in IB1’s Developing an energy smart data scheme: call for evidence response,international examples of data sharing initiatives include (not all smart data schemes):

• India: https://indiastack.org/
• Government scale (not energy system) Taiwan – https://digi.taiwan.gov.tw/ MyData – https://www.ndc.gov.tw/en/nc_8455_34364 
• COVID tracking – data governance: https://academic.oup.com/policyandsociety/article/41/1/129/6513795
• See for examples of data ecosystems and learnings: https://cris.vtt.fi/en/publications/guidebook-data-ecosystems-for-smart-sustainable-cities 

13. What lessons should we bear in mind from Open Banking that would be helpful to consider when developing a digital markets Smart Data scheme?

It is essential that Open Banking is viewed holistically – an entity incorporating technical, communications, engagement, legal and ongoing governance arrangements – rather than a technical solution.

IB1’s foundational work on Open Energy, Open Net Zero and approach to data sharing is based on the foundations of Open Banking. IB1 practises this through:

• Decentralised architecture implementation
• Advocating for common secure web standards (i.e. FAPI)
• Openly published rules and clear governance structure 
• Openly list service providers are available
• Providing member services 

As mentioned above, a key learning from the success of Open Banking is to follow a use case driven approach.

General lessons from national and international data sharing initiatives: 

• Incorporate governance at the outset. It is difficult to retroactively implement robust governance.
• Ensure governance is robust, participatory and responsive. It will be required to adapt to a full spectrum of social and environmental considerations shaping the operational landscape. A governance model must reflect the socio-technical nature of the energy sector, not just the technical side.
• Avoid putting too much emphasis on a technical solution  – An energy smart data scheme must equally address governance, user needs, business, social, legal, engagement and communications to be successfully implemented and ensure the solution is fit for purpose.
• Complexity and collective agreement across the industry – an initiative must recognise the complexity and changing nature of the energy industry.
• Cultural change and industry readiness – must understand and interact with the current data sharing culture within the energy companies, and consumers must be engaged to understand their value proposition. 
• Appropriately defining and governing the roles and responsibilities.
• Appropriate legal support and resourcing – a mechanism must develop the applicable data licences, and needs to be appropriately resourced to be able to do so. 

14. What lessons should the government bear in mind from the EU DMA and other Smart Data schemes in other jurisdictions including the establishment of Open Banking schemes around the world?

Icebreaker One Founder & CEO, Gavin Starks, co-chaired the development of the Open Banking Standard, co-chaired the UK Smart Data Council, and was founding CEO of the Open Data Institute. Since then Gavin has advised New Zealand and Canada on their implementation of Open Banking in their jurisdictions. 

In New Zealand in particular, the initial implementation of Open Banking was sector-led by Payments NZ. In 2017 and 2019, former Ministers of Commerce and Consumer Affairs wrote to New Zealand’s banks to encourage them to advance sector-led initiatives for open banking. From 29 August to 10 October 2024, the Ministry of Business, Innovation, and Employment consulted on policy settings for banking regulations under the Customer and Product Data Act, the regulations for which were then drafted in 2025. This shows the importance of both industry collaboration and regulatory mandate to drive sector-wide adoption.

15. Do you have any additional comments on any aspect of developing a digital markets Smart Data scheme that has not been covered elsewhere in this call for evidence?

None.

Please note that throughout this consultation, Icebreaker One uses the terms Open, Shared and Closed data as defined here.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer.

Consultation response:

Icebreaker One (IB1) is a public-benefit non-profit working on data sharing and sustainability, convening organisations and governments to design market-scale solutions to make data work harder to deliver Net Zero. It creates and runs programmes to reduce barriers and costs to finding, accessing, using, and sharing data, which will ultimately reduce costs for consumers. Through the UKRI Modernising Energy Data Access competition, in collaboration with over 400 industry stakeholders, IB1 developed Open Energy which identified and articulated the need to make it straightforward to find, access and share energy data. Given IB1’s focus, we have responded to a number of the questions in the consultation. 

IB1 supports RIIO-ED3’s goals of moving away from gas infrastructure, toward renewables, and a more resilient grid. It is essential to have a joined-up approach and cross-sector thinking to achieve the size of impact outlined in the Industrial Strategy and The Clean Power 2030 Action Plan and unlock the widest range of potential benefits.

OVQ36. Do you agree with our position of not changing the Digitalisation licence condition?

IB1 supports digitalisation as key for energy sector decarbonisation, and required for the investment in flex services and the coordination between sectors who rely on energy to meet their decarbonisation targets (water, transportation, built environment, industry).

IB1 supports sector-wide convening and governance to ensure digitalisation happens in a coordinated manner and can enable ‘whole system solutions,’ as promoted in RIIO-ED2 and realise the subsequent cost savings. IB1 supports Ofgem to continue to promote and finance whole system digitalisation coordination in RIIO-ED3.

As there are many ongoing data sharing and data governance initiatives e.g. consumer consent solution, flexibility services, Data Sharing Infrastructure (DSI), which are currently in progress at different stages of development (definition, prototype, or pilot). Ofgem should not expect these programmes and underlying challenges the projects aim to solve to be resolved by the end of RIIO-ED3 (2031). Data sharing and data governance needs and subsequent solutions will evolve over time as we continue to electrify and connect the UK’s grid. As mentioned above, Ofgem needs to ensure ongoing governance and sector collaboration on data and digitalisation – reinforcement of this would be welcomed in addition to specific plans to expand/evolve data governance initiatives.

With the progress of the Data Sharing Infrastructure (DSI) programme, IB1 anticipates ‘Shared Data’ sharing will evolve and will inform the evolution of data best practice (DBP) guidance. In particular, as data sharing scales, the need to standardise and harmonise legal and technical approaches will become more pressing in order not to slow innovation and add unnecessary cost. IB1 recommends that DBP should include guidance around Shared Data within the triage processes and licensing decisions, highlighting the role of Shared Data Schemes (see OVQ37) to provide definitions that aid interoperability and maximise impact.  

OVQ37. Do you agree with our proposed approach to the DSI licence condition?

IB1 welcomes the energy industry collaborating and agreeing on data sharing. Through IB1’s Open Energy programme, we have co-designed the Energy Sector Trust Framework with sector stakeholders, including DNOs. Members are currently in the process of assuring their open data publication using the Assured Open Data Scheme governed by Open Energy. IB1 will continue to bring Open Energy learnings into the DSI development process. 

We encourage more clarity on what DSI ‘participation’ entails, including anticipated associated costs and funding. As mentioned in IB1’s response to DESNZ energy smart data scheme call for evidence, it is essential that a Trust Framework is viewed holistically – an entity incorporating technical, communications, engagement, legal and ongoing governance arrangements – rather than a technical solution. IB1 would recommend ‘participation’ in DSI is defined as being broader than operating data sharing nodes, including:

• In collaboration with stakeholders within and outside the energy sector:
  • Identifying and developing use cases
  • Designing technically- and legally- interoperable schemes
  • Agreeing, implementing and governing operational policies
  • Keeping in step with emerging trusted data approaches in other sectors of the economy, at home and abroad
• Articulating the amount of technical and non-technical work required for a Trust Framework 
• Articulating the role of consent and permissioning aligned with the 2025 Data (Use and Access) Act.
• Setting out the expected amount of resourcing including external and internal communications, executive support, legal resource, and skilled involvement in data governance and technical implementation

Our experience is based on establishing an energy sector data sharing programme through sector engagement (convening 100s of organisations and 500+ public webinar attendees) and governance processes (80+ Steering and Advisory Groups members) to develop operational services for search and access control. These are are now live and market-facing through the Energy Sector Trust Framework and Schemes, IB1 created, designed and developed Open Energy https://ib1.org/energy/ to provide three services:

1. Community: an expert network of professionals – the IB1 Constellation

2. Governance: co-design of data sharing Schemes using our Icebreaking process

3. Trust Services: An Energy Sector Trust Framework for Scheme implementation, covering Open Data, commercial Shared Data with pre-authorised access controls, and commercial Shared Data where access requires end-user permission/consent. In addition, Trust Services deliver search and assurability services. 

We recommend drawing upon this experience to both clearly and tightly define expectations for the DSI licence condition, and the roles of actors in the ecosystem (e.g. what is within the remit of regulators and code bodies, what could/should be precompetitive and what is open to commercial market competition).

• The scheme agreement [pdf, Google Doc for comment]
• The assurance levels:
  • Organisation assurance [specification]
  • Dataset assurance [specification]
  • Both specifications are also available in a Google Doc for comment

Please comment directly on the Google Docs if you are able, or email feedback to openenergy@ib1.org. Comments received before June 2 2025 will be considered for inclusion in the initial scheme implementation.

Background

Open Energy is proposing to add an Assured Open Data scheme to the Energy Sector Trust Framework (ESTF). The scheme has these main aims:

• Provide assurance to consumers of Open Data published by Members
• Enhance the quality, consistency, and reliability of published data
• Ensure Members comply with relevant data protection, privacy, and security regulations (e.g. members don’t publish any data subject to data protection regulations such as GDPR as Open Data under the scheme)
• Promote transparency and accountability within the data-sharing ecosystem.

The scheme incorporates updated organisational and dataset assurance levels based on feedback on the original levels that Icebreaker One announced in September 2023. These levels are already being used, for example by Open Energy members SSEN-D on their data portal.

Joining the scheme will be free to ESTF members. In order to assert the assurance levels members must execute the scheme agreement that sets out their commitments, and liabilities should they fail to meet them.

If you have any questions about our submission or require clarifications please do not hesitate to contact us via policy@ib1.org. We have omitted questions which we did not answer.

Call for evidence response:

Section B: Data intermediaries

Q4. Does the taxonomy above fully reflect the range of models of data intermediaries in the UK or elsewhere?

Based on the call for evidence definition, “data intermediaries” refers to a range of organisations that facilitate access to and exchange of data. The EU Data Space Support Centre’s Data Space Intermediary definition, also refers to “service providers for enabling services and functions: These providers do not intermediate the Exchange of Data Products. Instead, they intermediate the exchange of trust-related information or data product metadata”. IB1 proposes considering another interpretation of a data intermediary matching the EU definition above, termed “Trust Services”. This table should include an entry for Trust Services as follows:

Trust Services:

Trust Services enable members to adhere to the agreed rules for sharing data at scale within a Trust Framework (IB1 definition – https://ib1.org/trust-frameworks/). These services do not intermediate the exchange of data products. Instead, they intermediate the exchange of trust-related information or data product metadata.

The “Orchestration Service Providers” described in the UK Digital Identity and Attributes Trust Framework are examples of Trust Services:

• Identity and attribute broker service providers
• Identity and attribute hub service providers
• Identity access management service providers
• Distributed ledger service providers

This list isn’t exhaustive though. Other functions may be needed for other use cases.

Trust Frameworks: Defining and applying the rules

Trust Frameworks create the transparent rules and processes for sharing data at scale – across an entire sector, market, or geography. They set openly-published rules around: 

• How organisations prove who they say they are
• Who is publishing data
• For Shared Data, who is accessing data and for what purpose
• Legal and operational responsibilities

Trust Frameworks are not intermediaries, but use humans and machine governance as market enablers. Schemes are the rulebooks of how organisations can share data. They define what can be shared, why, by whom, how, and what protections exist. Trust Frameworks and related Trust Services help apply the rules in a way that both humans and machines can understand. A critical design feature of a Trust Framework is that it does as little as possible. It doesn’t define the rules, nor does it touch the underlying data, or know who the end users are. It just verifies that rules have been agreed and can enable their enforcement.

Trust Framework design and operation: The role of Implementation Entity

Based on our work over the past 5 years on data governance for sectors such as energy, water and supply chains, Icebreaker One has developed a structured approach that we call Icebreaking. As a neutral, non-partisan non-profit we help stakeholders deliver impact by unlocking trusted data sharing at market scale. This open market architecture for data sharing includes both commercial and non-commercial data.

The Icebreaking process convenes stakeholders around purpose and priority use cases – building on our experience to save time and money. With strong governance and oversight, stakeholders and experts collaborate to co-design Schemes that address legal, technical, policy and communications needs. Trust Services can (optionally) be used to implement Schemes at market scale.

Ensuring that digital infrastructure balances the value to all stakeholders against security, cost and complexity considerations requires a neutral co-ordinating body. Icebreaker One is an implementation entity that can deliver governance and Trust Frameworks as a service. Open Banking Ltd fulfils a similar role, specifically for the Open Banking Trust Framework.

Section C: Barriers to data intermediary sector

Q6. What are the main barriers to performing data intermediation services in the UK, and how do they differ across sectors and models?

In IB1’s response to the Department for Science, Innovation, and Technology’s Technology Adoption Review, and IB1’s response to the Department of Energy Security & Net Zero Developing an energy smart data scheme call for evidence, IB1 noted a key barrier to technology adoption, investment, and participation is a lack of a consistency in vision and policy which is vital for the decision makers in the organisations and companies to de-risk technical and innovation investments. Having a cohesive, consistent vision with clear actions allows for stakeholders to incorporate data sharing and data access at the core of their decisions. 

IB1 also notes that successful data intermediation requires specificity to be effective, in the form of a use case. Focusing on a use case avoids the pitfall of being designed too broadly and generically, rather than being designed to meet a narrow set of purposes and outcomes and then expand to other use cases. 

IB1 supports following a use case approach to data sharing initiatives. This approach centres user needs, makes a business case for the effort of data sharing, and allows for:

1. Market incentives: there must be an economic argument that policy can then amplify or mandate. If there is no financial incentive, there will be no movement.
2. Removal of transactional friction: There must be “something in it” for everyone, or at least a path to cost reduction or a new business model. Removing friction can help everyone go together: this is never a ‘technology problem’ (e.g. absence of a data ontology).
3. Documentation with the identified problem statement, actors and stakeholders, a clear goal, and the envisaged impact. 

To maximise the benefits, use cases must:

• Address governance, user needs, business, social, legal, engagement and communications to ensure the solution is fit for purpose, and can be adopted by the market. IB1 observes that technical-led programmes tend to fail to gain traction or deliver against material user needs.
• Foster a community to ensure there is cross-sector collaboration. IB1 strongly recommends taking a joined up approach which is interoperable with initiatives across the economy. 

Q7. What role should the government have in addressing these barriers? Are there examples of effective or ineffective government interventions in other countries or markets?

As mentioned in IB1’s response to the Department for Science, Innovation, and Technology’s Technology Adoption Review, and IB1’s response to the Department of Energy Security & Net Zero Developing an energy smart data scheme call for evidence,

To meet the combined needs of economic growth, environmental sustainability and social equity, the UK must fund institutions that can help convene and aid multi-stakeholder collaborations. Such support is essential to deliver open and accessible markets (available to the whole UK economy) and equally to protect our economy from monopoly behaviours. This applies to data intermediaries as much as it applies to the data publishers and data consumers they service.

Our previous experience has been that projects to co-design market-wide solutions without external or public neutral funding suffer from a collective action problem in which prospective partners are unwilling to contribute to the costs as the benefits of the developed outcome will accrue to them whether they contribute or not. Failure to fund risks a lack of cohesion, duplication, or a very limited trial with limited reusability.

Public signalling and funding enables IB1 as an implementation entity and facilitator of industry co-design to support an effective methodology and increase buy-in from partners and testers, resulting in better outputs and adoption.

More generally, IB1 supports developing, supporting, and promoting a principles-based approach to implement its national data infrastructure so different sectors can move at pace on their own, develop their own customer-facing values and business propositions, get them out into the market, but all anchored on principles of data rights, of machine interoperability and of fair value exchange: reciprocity is at the heart of all of this work.

Key principles for designing data sharing as infrastructure:

• Decentralised solution: guiding principles while allowing different sectors or other operational environments to tailor to user needs/circumstances, minimising barriers to scaling-up
• As digitalisation of the wider economy accelerates it is essential that any governance mechanism is built to function flexibly within a shifting technical landscape. There will be a continual balance between addressing user needs and potential threats, necessitating robust governance to be participatory and responsive to a full spectrum of social and environmental considerations shaping the operational landscape, for example including capacity to respond to forthcoming Net Zero 2030 milestones, negative incentives, corporate capture, unintended monopoly positions, and data misuse.
• Security: Data required for investment must undergo a thorough assessment of risks, benefits, security measures, and potential international standards as there may be implications for data transfer and use across the UK and international borders. 
• Clear and consistent use of definitions and communications surrounding data. IB1 uses the data spectrum to communicate the definitions and differences between Open, Shared, and Closed data. 
• Build upon prior art: IB1 recommends simple and low friction options which builds on previous implementation in other industries, for example Open Banking which has been endorsed by the Competition and Markets Authority (CMA) and the Financial Conduct Authority (FCA)
• Joined up approach to be interoperable with initiatives across the economy.

Q8. Can you provide examples of successful data intermediaries and the technological and non-technological factors that contributed to their success?

As noted in IB1’s response to the Department of Energy Security & Net Zero Developing an energy smart data scheme call for evidence, Open Banking is a case study for engagement for Smart Data within a Trust Framework. It has over 10 million users and over 22.1 million transactions per month. This provides strong evidence that there is both appetite and capability for British consumers to engage with Smart Data utilising a Trust Framework approach. 

It is essential that Open Banking is viewed holistically as a Trust Framework – an entity incorporating technical, communications, engagement, legal and ongoing governance arrangements – rather than a technical solution.

Through providing clear roles and purposes for data intermediaries alongside openly-published compliance, legal and technical requirements, Open Banking has enabled a range of data intermediaries providing trust, integration and permission management services. Notable companies providing these services include Klarna, Plaid, Tink, TrueLayer, and Yapily, with combined valuations of billions of dollars.

IB1’s foundational work on Open Energy, Open Net Zero and approach to data sharing is based on the foundations of Open Banking. IB1 practises this through:

• Decentralised architecture implementation
• Advocating for common secure web standards (i.e. FAPI)
• Openly published rules and clear governance structure 
• Openly listing service providers that are available
• Providing member services 

A key learning from the success of Open Banking is to follow a use case driven approach.

See more information on the development of UK Open Banking here: https://dgen.net/0/2018/04/04/report-development-of-uk-open-banking/