Search Flexibility Market Rules

v2.0Current version

Published04/02/2026Effective date01/04/2026Release date04/02/2026

End-to-End process for flexibility services

Document Summary

What? The rule sets out a common language to describe the end-to-end journey for a Flexibility Service Provider to provide flexibility. How? The rule sets out common building blocks that define the key stages, and places an obligation on System Operators to describe which blocks are used, and how they are sequenced for each Sub-MarketWho? This rule impact all System Operators. The clearer definitions should benefit all Flexibility Service Providers.When? This rule comes into force on 01/04/2026. This gives the System Operators time to collate the relevant data for each Sub-Market.Why? This rule aims to aid understanding of how individual Sub-Markets work, as well as how aligned/different they are.

Propose change

End-to-End process for flexibility services - Flexibility Market Rules - Elexon

An entity (organisation or system) with a defined role and responsibility in executing market activities within a Sub-Market

A structured unit of information that flows between Actors in the Sub-Market for a given Market Activity. Inputs are information needed to start the Market Activity; Outputs are information created from the Market Activity.

A discrete, operational step carried out by a participant or operator that contributes to a broader market process. Market Activity can occur in parallel or sequentially to one another.

A logical grouping of Market Activities that share a common objective and temporal alignment in the end-to-end process

The state of a participant, asset, or unit being formally recognised as eligible and compliant to participate in a Sub-Market, having satisfied all applicable pre-qualification criteria and subsequently demonstrated compliance through verified performance.Qualification is therefore achieved and maintained through both ex-ante pre-qualification and ex-post verification activities.

A process conducted ex-ante to determine whether a participant, asset, or unit meets the minimum technical, operational, commercial, and data-exchange requirements necessary to participate in a flexibility Sub-Market.Pre-qualification confirms eligibility and readiness but does not constitute confirmation of service delivery. It typically involves the assessment of declared capabilities, supporting evidence, and, where relevant, grid-connection feasibility

0

0.0

Sections 1, 2, 3 and 4 form the legally binding Flexibility Market Rule.

Defined terms capitalised in this document shall have the meaning given in Section 4.

GuidanceSummary of the End-to-End process Flexibility Market Rule

This section is provided as guidance to the Flexibility Market Rule. Therefore, it is not legally binding and falls outside of the formal change management process.

Context

This rule establishes a standardised framework for describing the end-to-end process of delivering flexibility services, using defined building blocks to improve understanding across Sub-Markets and drive further consistency. It requires System Operators to clearly outline how these blocks are applied, improving transparency and simplifying participation for Flexibility Service Providers.

End-to-End process Flexibility Market Rule Requirements

The rule focuses on collecting information about the End-to-End processes across System Operators in a consistent manner, for the Market Facilitator to publish in the Flexibility Market Catalogue. This requires each System Operator to:

Identify which building blocks are utilised in each Sub-Market under their responsibility;
Describe how those building blocks are sequenced within their Sub-Market process; and
To provide metadata for each building block, including:
Data object inputs and outputs;
- Responsible/driving Actors;
- Dependencies between building blocks;
- Applicable time dimensions; and
- Related artefacts where possible (e.g. procurement documents, data catalogues…).

We believe the impact of these requirements to be:

Impact on System Operators	Impact on FSPs
Must formalise and publish a transparent mapping of their Sub-Market activity using the building-block framework and maintain this as live metadata as per implementation monitoring requirements.	No direct impact on FSPs. However, this should provide additional information on how each Sub-Market works.

Implementation monitoring requirements

The key requirements are laid out below. A view across the rules is available in our deadline tracker.

Category

Requirement

Trigger for data submission

What we will do with it

Implementation tracking

As defined in Section 3

From 14/01/2026 (20 working days after the published date).

Within 10 days of change

Track whether implementation is on track via our Implementation tracker.

Flexibility Market Catalogue data

As defined in Section 3

From 01/04/2026.

Within 10 days of change

Provide an overview of the Sub-Market and the market as a whole via the Flexibility Market Catalogue.

1Applicability of this Flexibility Market Rule

1.0

This Flexibility Market Rule applies to all System Operator Sub-Markets within the Market Facilitator scope.

Innovation trials are not bound by this Flexibility Market Rule.

All System Operators shall provide the data set out in section 3 no later than the timings also set out in section 3.

Variations to this rule are only permitted with an approved Derogation from the Market Facilitator.

The core dates for this Flexibility Market Rule are laid out below.

Table 1: Flexibility Market Rule dates

Published Date	04/02/2026
Implementation Date	01/04/2026
End Date	-

2Common End to End process

2.1Common Level 1 processes: Market Phases

The common level 1 processes, which describe the high-level phases of the markets are listed in the table below.

Table 2: Common Level 1 processes

Market Phase	Description
Exploration	The preliminary first Market Phase, containing activities to understand market opportunities, assess potential participation, and form an initial strategy for flexibility provision.
Qualification	Steps required for a participant and their assets and units to become eligible to offer services in a grid-safe manner, in a Sub-Market.
Competition	Market-facing activities where buy/sell requirements are communicated, prices are formed and transactions are cleared, either continuously or via auctions.
Scheduling and Dispatch	Processes to maintain operational readiness, provide visibility, and deliver contracted services in real time.
Verification	Collection, processing, and communication of performance data to confirm service delivery.
Settlement	Financial processes to generate invoices and execute payments based on verified service delivery.

2.2Common Level 2 building blocks: Market Activities

Each of the Market Phases listed above are made up of lower-level building blocks: Market Activities. The common building blocks set out in this rule are listed in the table below. Note the Market Activities as described are not necessarily executed in linear fashion as listed below. Market Activities may occur in parallel. Market Activities may even occur in different Market Phases, depending on the Sub-Market (e.g., Q.4 Sign Service Contract occurs in parallel to C.3 Clear Market in national Sub-Markets).

Table 3: Common market activities

I.D	Market Activity	Definition	Related Market Phase
E.1	Define Sub-Market	Identify and describe the scope, operator, and objectives of the Sub-Market.	Exploration
E.2	Understand Flexibility Markets	Gather and analyse market design, rules, and price signals.
E.3	Build Investment Case	Assess costs, revenues, and risks to justify participation.
E.4	Develop Operational Strategy	Identify operational needs, formulate internal processes and readiness plans.
Q.1	Register Counterparty	Submit commercial information to become a recognised participant for a Product within a Sub-Market.	Qualification
Q.2	Qualify Counterparty	Confirm FSP commercial criteria such as credit, corporate compliance, and insurance details are in line with obligations
Q.3	Register Product	Publish product requirements such as technical and procurement terms.
Q.4	Sign Service Contract	Execute service term agreements with the system operator.
Q.5	Register Assets	Provide technical information about physical assets required for participation in the Sub-Market
Q.6	Pre-Qualify Assets	Verify asset technical requirements.
Q.7	Register Units	Define market units for bidding.
Q.8	Pre-Qualify Units	Verify unit meets preliminary operational requirements.
Q.9	Pre-Qualify Grid	Verify relevant network segment can handle a unit providing the product (system readiness).
Q.10	Test Units	Conduct operational trials such as a communication test to confirm readiness. Can be ex-ante or ex-post actual service delivery.
Q.11	Register Baseline	Submit reference consumption/generation profile for performance assessment.
C.1	Communicate Buy Requirements	Publish product buy order reflecting operational need for flexibility services.	Competition
C.2	Communicate Sell Requirements	Submit offers or availability declarations.
C.3	Clear Market	Match buy and sell orders, determine clearing prices.
D.1	Maintain Unit Availability	Ensure units remain operationally ready.	Scheduling and Dispatch
D.2	Provide Operational Visibility	Share availability and/or metering data with SOs.
D.3	Dispatch Units	Issue instructions to market units.
D.4	Dispatch Assets	Send operational commands to physical assets.
D.5	Cease Units	Terminate scheduled operation of units.
D.6	Cease Assets	Stop service delivery from physical assets.
V.1	Collate Verification Data	Gather metering and operational data.	Verification
V.2	Process Verification Data	Analyse data to assess compliance with obligations.
V.3	Communicate Performance	Report performance outcomes to market participants.
V.4	Communicate Consequences of Non-Performance	Report consequences of non-performance such as penalty outcomes to market participants.
V.5	Manage Disputes	Resolve disagreements over verification outcomes.
V.6	Report on Service Delivery	Produce regulatory or contractual reports for settlement.
S.1	Generate Invoices	Prepare invoices based on verified delivery.	Settlement
S.2	Process Payments	Transfer funds to service providers.	Settlement

2.3Data Objects

Each Market Activity is associated with incoming and outgoing Data Objects that describe the information required to initiate the activity and the information produced as a result of it.

System Operators shall, where reasonably practical, provide Data Object references as text fields or URLs pointing to existing materials such as web-hosted PDFs, API endpoints, web pages, or documentation. These references should help describe:

Inputs - information required to perform the Market Activity; and
Outputs - information or artefacts generated by the activity.

The table accompanying below provides indicative examples of possible Inputs and Outputs. These examples are non-exhaustive, and System Operators may include additional Data Objects where appropriate.

It is recognised that Flexibility Service Providers will maintain their own internal processes and artefacts to participate in markets. Data Objects relating to Market Activities led by FSPs do not need to be reported by System Operators; rather, the purpose of the reporting is to indicate what information is included in, or exchanged through, the Market Activity.

GuidanceGuidance: Data Objects

This section is provided as guidance to the Flexibility Market Rule. Therefore, it is not legally binding and falls outside of the formal change management process.

At this stage of implementation, Data Objects are intended to be lightweight and high-level signposts, expressed as nouns defined by the reporting System Operator. They are not new datasets but pointers to existing artefacts or information sources that support the activity.

When setting out Data Objects, System Operators should balance the objective of increasing market transparency with the need to avoid unnecessary administrative burden. Minor editorial or procedural updates to supporting documents should not trigger a Data Object update unless they materially affect market participation or interpretation.

An example of a useful Data Object submission would be as it relates to participation available to Flexibility Service Providers offering detail on (e.g. “API”, “manual submission”, or “both”). Such information helps prospective participants understand the complexity or level of upfront integration required to engage in different Sub-Market activities.

We expect to develop a more structured and comprehensive method for collecting this information in future versions of the rule (e.g., standard taxonomy of Data Objects aligned with Ontology). This will build on the information collected in this version. Future versions will also signpost Flexibility Market Rules applicable to Market Activities.

Table 4: Indicative Data Objects

I.D	Market Activity	Indicative Data Object Inputs	Indicative Data Object Outputs
E.1	Define Sub-Market	e.g., Market operator mandate, geographical constraints, regulatory framework	e.g., Sub-Market definition record
E.2	Understand Flexibility Markets	e.g., BSC rules, Market rules, procurement schedules, historical prices	e.g., Market analysis report object
E.3	Build Investment Case	e.g., Cost data, forecast price signals, asset capability data	e.g., Business case object
E.4	Develop Operational Strategy	e.g., Business case, operational capability plan	e.g., Operational strategy document
Q.1	Register Counterparty	e.g., Counterparty details	e.g., Counterparty registration confirmation
Q.2	Qualify Counterparty (Commercially)	e.g., Credit rating, proof of insurance, financial statements	e.g., Counterparty qualification confirmation
Q.3	Register Product	e.g., Product requirements document(s)	e.g., Product specification
Q.4	Sign Service Contract	e.g., Contract terms, signature authority	e.g., Executed service contract
Q.5	Register Assets	e.g., Asset technical details, connection agreement	e.g., Asset registration record
Q.6	Pre-Qualify Assets	e., Asset data validation results	e.g., Asset pre-qualification record
Q.7	Register Units	e.g., Asset-to-unit mapping capacity data	e.g., Unit registration record
Q.8	Pre-Qualify Units	e.g., Unit-to-product mapping, Unit data validation results	e.g., Unit pre-qualification record
Q.9	Pre-Qualify Grid	e.g., Product-to-grid mapping, grid technical data	e.g., Grid pre-qualification record
Q.10	Test Units	e.g., Dispatch test instructions, telemetry	e.g., Unit test report
Q.11	Register Baseline	e.g., Baseline methodology statement	e.g., Approved baseline reference
C.1	Communicate Buy Requirements	e.g., System need forecast, procurement terms	e.g., Buy requirement publication
C.2	Communicate Sell Requirements	e.g., Availability declarations, bid prices	e.g., Offer submission record
C.3	Clear Market	e.g., All valid bids/offers, buy requirements	e.g., Market clearing report
D.1	Maintain Unit Availability	e.g., Maintenance schedules, operational status reports	e.g., Updated availability status
D.2	Provide Operational Visibility	e.g., Unit telemetry, constraint data	e.g., Operational visibility report
D.3	Dispatch Units	e.g., Market clearing results, unit availability	e.g., Dispatch instruction object
D.4	Dispatch Assets	e.g., Unit dispatch instruction, asset mapping	e.g., Asset-level operational command(s)
D.5	Cease Units	e.g., Dispatch termination signal	e.g., Unit stop confirmation
D.6	Cease Assets	e.g., Asset stop command(s)	e.g., Asset stop confirmation
V.1	Collate Verification Data	e.g., Metering data, dispatch logs	e.g., Verification dataset
V.2	Process Verification Data	e.g., Verification dataset, baseline reference	e.g., Performance assessment record
V.3	Communicate Performance	e.g., Performance assessment record	e.g., Performance report
V.4	Communicate Consequences of Non-Performance	e.g., Penalty assessment record	e.g., Penalty notice
V.5	Manage Disputes	e.g., Dispute submission, evidence documents	e.g., Dispute resolution record
V.6	Report on Service Delivery	e.g., Performance report, regulatory templates	e.g., Service delivery report
S.1	Generate Invoices	e.g., Verified performance data, contract price terms	e.g., Invoice object
S.2	Process Payments	e.g., Approved invoice, payment details	e.g., Payment confirmation

2.4Timings

Understanding the relative timings of each Market Activity is important to understanding how they operate, and the time sensitive operations.

Given the complexity of these timings (some are relative, others are absolute, some are one off, others repeat), and the many different ways in which they are expressed, these will be collected as text fields.

When responding System Operators should consider the relevant information of value to Flexibility Service Providers such as:

When the activities open and close, deadlines
How long they are valid for
How often they repeat
Where timings are applied on an ad-hoc basis

2.5Actors

Each Market Activity has an associated Actor who is responsible for completing the activity. The current list of Actors is set out in the table below.

Table 5: Actors

Actor Category	Actor Category description	Actor Instance
Market Facilitator	The central, independent body responsible for administering the rules and commercial arrangements of the flexibility market; undertakes settlement and calculate imbalance positions.	Elexon
Buyer	An organisation, typically the system operator, who buys flexibility services to meet local or system-wide needs. Includes intermediary organisation partners who operate software and infrastructure across end-to-end process.	National Energy System Operator
		Distribution Network Operator
		Independent Market Platform
Counterparty	An organisation who is the counterparty selling flexibility services and is responsible for managing an imbalance position and dispatching assets.	Flexibility Service Provider – AMVLP
		Flexibility Service Provider – VLP
		Flexibility Service Provider – Trading Party – Generator or Supplier

3Market Information

3.1Implementation tracking

The System Operators must provide the Market Facilitator with the data set out in Table 6 for each Sub-Market in scope of this Flexibility Market Rule. The data provided should accurately reflect their implementation of the rule within each Sub-Market.

The expected values required for compliance are also set out in Table 6.

Initial data shall be sent no later than 20 working days after the Published Date of this Flexibility Market Rule.

Updates shall be sent as soon as reasonably practical, and no later than 10 working days after any changes to the values.

Elexon reserves the right to publish this data within its Implementation Tracker.

Table 6: Implementation tracking requirements

FMR-E2E	Parameter	Required value (per Sub-Market)
Implementation Status	Dependent on date: Before Implementation Date: Not yet started, Implementing, Paused, Implemented Between Implementation Date and End Date: Implemented After End Date: Superseded
Target Implementation Date	No later than Implementation Date

FMR-E2E

Parameter

Required value (per Sub-Market)

Implementation Status

Dependent on date:

Before Implementation Date: Not yet started, Implementing, Paused, Implemented
Between Implementation Date and End Date: Implemented
After End Date: Superseded

Target Implementation Date

No later than Implementation Date

3.2Flexibility Market Catalogue data

The System Operators must update the Market Facilitator with the data set out in Table 7 below for each Sub-Market in scope of this Flexibility Market Rule. This should accurately reflect their implementation of each Sub-Market.

The expected values required for compliance are also set out in Table 7.

Initial data shall be sent no later than the Implementation Date of this Flexibility Market Rule.

Updates shall be sent as soon as reasonably practical, and no later than 10 working days after any changes to the values.

Please refer to Section 2 for further guidance.

System Operators shall also publish this information themselves.

Elexon reserves the right to publish this data within its Flexibility Market Catalogue.

Table 7: Flexibility Market Catalogue data

	Parameter	Description	Required Values
For each Market Activity (as set out in Table 4) except Exploration phase	Used?	Is the Market Activity used in this Sub-Market?	-
	Incoming Dependency	What are the incoming Market Activities which must be completed first?	-
	Outgoing Dependency	What are the outgoing Market Activities which follow?	-
	Data Object Inputs	What are the incoming Data Objects?	-
	Data Object Outputs	What are the outgoing Data Objects?	-
	Time Constraints	What are the associated time constraints?	-
	Time Constraints comment	Associated Commentary	-
	Actor Instance	Who is responsible for the activity?	-

Note: The submission of Flexibility Market Catalogue data for the Exploration Market Phase isn't required because it's a preliminary stage focused on FSP strategy, not formal market interactions. Cataloguing this data isn't necessary for alignment or signposting purposes.

GuidanceExample of Sub-Market data

This section is provided as guidance to the Flexibility Market Rule. Therefore, it is not legally binding and falls outside of the formal change management process.

Table 8: Example Flexibility Market Catalogue data – Sub-Market: NESO Slow Reserve

	Parameter	Description	Field
Q.5 Pre-Qualify Asset	Used?	Is the Market Activity used in this Sub-Market?	Y
	Incoming Dependency	What are the incoming Market Activities which must be completed first?	Q.2 Register Counterparty; Q.3 Register Asset
	Outgoing Dependency	What are the outgoing Market Activities which follow?	Q.6 Register Unit
	Data Object Inputs	What are the incoming Data Objects?	Asset PQ Data template- SMP XXX user screen Asset Data Validation results – XXX API
	Data Object Outputs	What are the outgoing Data Objects?	Asset PQ record – SMP XXX user screen
	Time Constraints	What are the associated time constraints?	Valid and complete data should be submitted GCT-7 Calendar Days
	Time Constraints comment	Associated Commentary	NESO will notify the Registered Auction Participant if allocation activity can be accommodated sooner
	Actor Instance	Who is responsible for the activity?	National Energy System Operator

3.3Effectiveness monitoring

There are no market facilitator metrics for this rule

4Glossary

4.0

The following definitions are specific to this Flexibility Market Rule. These are supplemented by the definitions in the Market Facilitator Glossary. If there is an inconsistency between definitions, the definition in this document shall prevail.

Glossary

Term	Aliases	Definition
Actor	-	An entity (organisation or system) with a defined role and responsibility in executing market activities within a Sub-Market
Data Object	-	A structured unit of information that flows between Actors in the Sub-Market for a given Market Activity. Inputs are information needed to start the Market Activity; Outputs are information created from the Market Activity.
Market Activity	-	A discrete, operational step carried out by a participant or operator that contributes to a broader market process. Market Activity can occur in parallel or sequentially to one another.
Market Phase	-	A logical grouping of Market Activities that share a common objective and temporal alignment in the end-to-end process
Qualification	-	The state of a participant, asset, or unit being formally recognised as eligible and compliant to participate in a Sub-Market, having satisfied all applicable pre-qualification criteria and subsequently demonstrated compliance through verified performance.Qualification is therefore achieved and maintained through both ex-ante pre-qualification and ex-post verification activities.
Pre-Qualification	-	A process conducted ex-ante to determine whether a participant, asset, or unit meets the minimum technical, operational, commercial, and data-exchange requirements necessary to participate in a flexibility Sub-Market.Pre-qualification confirms eligibility and readiness but does not constitute confirmation of service delivery. It typically involves the assessment of declared capabilities, supporting evidence, and, where relevant, grid-connection feasibility

FMR: End to End process - Amendment record

Guidance

This section is provided as guidance to the Flexibility Market Rule. Therefore, it is not legally binding and falls outside of the formal change management process.

Version	Published Date	Document Status	Description of Changes	Change Proposal Reference	Market Facilitator Decision Report Ref
1.0	12/12/2025	Final	Document Published	-	-
2.0	04/02/2026	Final	Housekeeping changes.	CP002	CP002

4.0.2

Annex 1: Associated meta-data

Guidance

This annex is provided as guidance to the Flexibility Market Rule. Therefore, it is not legally binding and falls outside of the formal change management process.

Identifier	FMR-E2E
Title	End-to-End process for flexibility services
Type	Flexibility Market Rule
Collection	Sub-Market Alignment
Audience	NESO, DNOs, Flexibility Service Providers
Expertise	Market Access, Market Design
Owner	Market Facilitator
Expected benefit	Deliver a common approach to defining how different submarkets work: - aid understanding of the individual Sub-Markets and the market as a whole, - aid comparison across Sub-Markets - target further alignment in future
Related end-to-end process reference	E.1 Define Sub-market
References
IsReferencedBy	All other Flexibility Market Rule meta-data
Published version number	2.0
Applicability	All DNO and NESO Sub-Markets
Published Date	04/02/2026
Implementation Date	01/04/2026
End Date	-
Terms of variations	Self-derogation
IsReplacedBy	N/A
Replaces	N/A
Status	Final
Change since last version	Housekeeping change – correction of Implementation date. Update to section 3.3 and sub-market guidance
Description	What? The rule sets out a common language to describe the end-to-end journey for a Flexibility Service Provider to provide flexibility. How? The rule sets out common building blocks that define the key stages, and places an obligation on System Operators to describe which blocks are used, and how they are sequenced for each Sub-Market Who? This rule impact all System Operators. The clearer definitions should benefit all Flexibility Service Providers. When? This rule comes into force on 01/04/2026. This gives the System Operators time to collate the relevant data for each Sub-Market. Why? This rule aims to aid understanding of how individual Sub-Markets work, as well as how aligned/different they are.