Network Code on Demand Response Issue III - Responsibility for the Operation of the CU Module

October 21, 2025

Throughout the recent months we have analysed carefully the ACER-reviewed version of the European Network Code on Demand Response ( [here] ). The document is a step forward, yet it contains a series of issues that should be resolved with the finally released code. We will commence with the assignment of default responsibilities for modules in the Flexibility Information System.

Modules of a Flexibility Information System

In order to understand the problem, we first should commemorate definitions:

• 'flexibility information system' means a system to record at least the qualification of service providers, the product prequalification, product verification and grid prequalification of SPUs and SPGs and the switch of controllable units for the provision of balancing and local services and to exchange data for such processes;
• 'CU module' means a data space of a 'flexibility information system' that contains, manages and makes available data about controllable units;
• 'SP module' means a data space of a 'flexibility information system' that conains, manages, and makes available data about service providers, service providing groups, service providing units and system users.

In addition to that, each FIS shall have a 'common front-door', a machine-usable API for service provider to interact with the FIS modules in a standardised manner. It should furthermore be highlighted that these definitions have been put in place to support realities in many Member States. Some MS have centralised flexibility information systems in place, some have been developing these platforms alongside existing distributions of responsibility and in a de-centralised manner. In some MSs there will be a single and combined CU Module/ SP Module, some will have multiple CU Modules and a single SP Module and some will have multiple CU Modules and multiple SP Modules.

Option 1: Centralised Flexibility Information System operating a single CU module and a single SP module combined

Option 2: ACER Version Option - each Procuring SO running both a CU module and an SP module

Option 3: Better approach - each Connecting SO running a CU module for all assets connected to its grid, one centralised SP module

Now, in the ACER version published March 2025, puts a responsibility to each procuring system operator to operate a CU module and an SP module: Article 25(4) - Each procuring system operator shall be responsible for operating and maintaining one or more SP modules and one or more CU modules. This is problematic, as it will lead to inefficient and diffuse structures.

The Issue

Recommendation

Concluding from the abovementioned considerations, it is much better and follows more stringently the natural distribution of responsibilities, if the default responsibility for operating a CU module lies with the connecting system operator. For the market-sided SP module, it is ok to leave it under the responsibility of procuring system operators.

Hence, Article 25(4) should be reformulated: Each connecting system operator shall be responsible for operating and maintaining a CU module. Each procuring system operator shall be responsible for operating and maintaining an SP module.

Please note, that delegation is still possible as of Article 8 of the ACER NC proposal.