Synopsis	This document describes the user requirements for the Balancing Mechanism Reporting Agent (BMRA) system.
Version	Version 24.0
Effective date	02 November 2023

Intellectual Property Rights, Copyright and Disclaimer

The copyright and other intellectual property rights in this document are vested in Elexon or appear with the consent of the copyright owner. These materials are made available for you for the purposes of your participation in the electricity industry. If you have an interest in the electricity industry, you may view, download, copy, distribute, modify, transmit, publish, sell or create derivative works (in whatever format) from this document or in other cases use for personal academic or other non-commercial purposes. All copyright and other proprietary notices contained in the document must be retained on any copy you make.

All other rights of the copyright owner not expressly dealt with above are reserved.

No representation, warranty or guarantee is made that the information in this document is accurate or complete. While care is taken in the collection and provision of this information, Elexon Limited shall not be liable for any errors, omissions, misstatements or mistakes in any information or damages resulting from the use of this information or action taken in reliance on it.

Amendment History

Date	Version	Description of Change	Mods/ Panel/ Committee Refs
24/06/2010	16.0	Document rebadged and amended for November 2010 Release (P243, CP1333)	Change Implementation
29/11/2012	17.0	P278 for the November 2012 Release	ISG138/10
16/12/2014	18.0	P295, P291for the December 2014 Release	ISG162/01
05/11/2015	19.0	P305 for the November 2015 Release	ISG172/04
29/06/2017	20.0	P321 Self-Governance– 29 June 2017 Release	P245/05
		P329 Alternative – 29 June 2017 Release	ISG194/02
29/03/19	21.0	29 March 2019 Standalone Release – P369	P285/12
11/12/2019	22.0	11 December 2019 Standalone Release – CP1517	ISG220/01 ISG222/03
18/03/2021	23.0	18 March 2021 Standalone Release – P408 Self-Governance	ISG234/02
02/11/2023	24.0	02 November 2023 Standard Release	ISG270/02

1 Introduction

This document is the User Requirements Specification (URS) for the Balancing Mechanism Reporting Agent (BMRA) role within the Balancing and Settlement Code Services. It is one of a set of documents forming the baseline for requirements of the seven BSC central services. This document set comprises:

BMRA URS;
CRA URS;
SAA URS;
ECVAA URS;
CDCA URS;
FAA URS
SVAA URS
Interface Specifications.

The objective of this document is to provide a complete specification of the requirements that the BMRA service must meet, from the users’ point of view. For this purpose, the “users” include Ofgem, the National Electricity Transmission System Operator (NETSO) as the balancing mechanism operator, BSCCo Ltd (as the client), other Service Providers, BSC Parties, and the BMRA Service Provider’s own operators.

This User Requirements Specification forms the input to the System Specification for the BMRA Service. The System Specification constitutes the definition of the computer system requirements to be built in support of the BMRA Services.

The BMRA functional requirements include calculations of derived market data that are much in common with those implemented by the SAA. In order to maintain consistency between both systems, and minimise maintenance costs, common source code shall be applied where appropriate in the SAA and BMRA.

1.1 Purpose

The purpose of this document is to provide a complete specification of the set of business requirements that the BMRA Service must satisfy for all of its various User types. Similar documents define the requirements for the other Services.

A convention has therefore been used for uniquely identifying the requirements in each document. This ensures that the fulfilment of each requirement can be unambiguously traced through the subsequent functional specification, design and implementation.

The requirements that have been identified have been divided into four categories:

Functional (F), a specific business requirement of the service.
Non-functional (N), which includes auditing, security, resilience etc. The majority of these will probably be associated with the General (GEN) service.
Service (S), which includes all time-related service delivery requirements, including performance and volumetrics.
Interface (I), a requirement for data exchange between services or to / from external parties.

These requirements are catalogued in sections 5 to 8 respectively.

1.2 References

The code listed in the final column is used as a cross reference in the detailed requirement specifications listed in section 5.

It should be noted that these references do not form part of the BMRA User Requirements Specification (except for the non-functional requirements that are common to BSC central systems, defined in CRA URS).

Source	Author	Reference
Service Description for Balancing Mechanism Reporting	BSCCo	BMRA SD
Balancing Mechanism Reporting Business Process Models	BSCCo	BMRA BPM
Settlement Administration Business Process Models	BSCCo	SAA BPM
Interface Definition and Design - Parts 1 and 2	BSCCo	INTERFACE
Central Registration Agent User Requirements Specification	BSCCo	CRA URS
BMRA & SAA Interface Specification	NETSO	NGC IS
ETSO Balancing Process Results Management Document Implementation Guide Version1.0 Release 0	ETSOVista	ETSO BPRM

2 Management Summary

The Balancing Mechanism Reporting Agent (BMRA) is one of the suite of seven services to be provided to support the operation of the Balancing and Settlement Code (BSC).

The BMRA role is critical to the successful operation of the BSC, as it facilitates the opening of the wholesale electricity trading market in Great Britain under the NETA arrangements. Its role is to provide near to real-time reporting of all market information disseminated by the NETSO and submitted to the Balancing Mechanism (BM) from market participants. The principal business processes involved may be summarised as:

The capture of data from the NETSO, relating to the operation of the BM in each half hour;
For each Settlement Period, calculation of preliminary estimates of derived marked data, i.e. system sell and buy prices;
Distribution of market data to BSC Parties, including near real-time BM and NETSO data and derived market data for each Settlement Period;
Displaying real-time market data on dynamically updateable screens.

The purpose of this document is to provide a complete specification of the set of business requirements which the BMRA service must satisfy for all of its various user types. These range from the BSC Parties to BSCCo Ltd and its various agents, including the operators of the BMRA central system and the other BSC services. Similar documents will be produced to define the requirements for the other services. A convention has therefore been used for uniquely identifying the requirements in each document, so as to ensure that the fulfilment of each requirement can be unambiguously traced through the subsequent functional specification, design and implementation. The requirements which have been identified have been divided into four categories:

Functional requirements - those requirements relating to a specific business activity, usually requiring some degree of automated support;
Interface requirements - the requirements for the exchange of data between the BMRA, the other BSC services shown above, and the external participants; (and covered in more detail in the Interface Definition and Design (IDD) documents;
Non-functional requirements - those requirements relating to such activities as security (both physical and user access related), audit, and system housekeeping (systems backups and archiving etc.). It is anticipated that the majority of these will be common to all of the services to be provided;
Service requirements - the underlying requirements for implementing and operating the overall BMRA service, including issues such as performance, service availability, etc.

3 Scope of Specification

This document provides a specification of the requirements for the Balancing Mechanism Reporting Agent (BMRA) Service within the NETA programme. The requirements are described from the point of view of the BMRA Service users.

The document is divided into the following chapters.

Chapter 4, Business and System Overview - describes the business context of the BMRA Service. It includes a definition of the BMRA Service user population.
Chapter 5, Functional Requirements - describes the functional requirements of the Service from the point of view of the Service users.
Chapter 6, External Interfaces - lists the interfaces with the external users of the Service.
Chapter 7, Non-Functional Requirements - describes the non-functional requirements of the Service.
Chapter 8, Service Requirements - describes the service delivery requirements of the Service, such as performance and volumetrics;
Chapter 9, User Roles and Activities - describes the roles supporting day to day operation of the Service and external users of the Service, such as other Service Providers and BSCCo Ltd;
Chapter 10, Future Enhancements - describes potential functional enhancements;
Appendix A, Glossary - includes a glossary of terms and acronyms;
Appendix B, Requirements Compliance Matrix - shows the mapping of requirements defined by this document to requirements set out in the BMRA Service Description;
Appendix C, BMRA external data flow timings - lists the source and timings of all data items published by the BMRA;
Appendix D, BMRA forecast data time line - shows the time relationship of published forecast data items;
Appendix E, BMRA settlement period time line - shows the time relationship of published data items relative to a settlement period;
Appendix F, Logical Data Model;

4 Business and System Overview

This section provides an overview of the Balancing Mechanism Reporting Agent (BMRA) business requirements and is for indicative purposes only. The definitive statement of requirements are given in the following chapters.

4.1 Summary of Business Requirements

The Balancing Mechanism Reporting Agent (BMRA) is responsible for collecting, displaying and providing Balancing Mechanism and other market information near to real-time to market participants and other interested parties, such as energy customers. The information needs to provide the necessary visibility of electricity market and balancing mechanism trading conditions to encourage liquidity in bid-offer submission pre-gate closure, and so has to be published in an intuitive graphical form where appropriate, but within time-scales that allow traders to take action on the basis of what is published.

The BMRA shall provide a continuous service. As information is received from the NETSO it shall be stored and published. If for some reason the data that has been received cannot be processed and stored, then the BMRA will inform either the NETSO or the CRA of the difficulties encountered. Thus a small degree of automatic validation is included in the service.

To avoid raising unnecessary barriers to market information there will be two levels of service provision:

1. a high grade 24x7 real-time service, providing defined delivery times for high performance market data that is “pushed” onto BMR service user screens. This service shall be provided at cost to the BMR service user, and will require a high performance private WAN and software licences for event driven client software;

2. a low grade service via the public Internet, with consequently no guarantees on access times. This service shall be available to the general public, and require no additional software other than a Java enabled Web browser;

Entire BMRA data will be available to both grades of service users. In order to provide market signals on a timely basis, the BMRA is also required to calculate certain market information in advance of its calculation, some days later, by the Settlement Administration Agent. These calculations are not official and only represent indicative estimates to the market. The information that the BMRA will derive and publish includes the following:

Period bid and offer acceptance volumes;
Period BM Unit total accepted bid-and offer volumes;
Period balancing mechanism bid and offer cashflows;
System sell price and system buy price;
Total Bid/Offer Volumes and Total Accepted Bid/Offer Volumes.

The Balancing Mechanism Reporting Agent is required to be available 24 hours a day, 7 days a week with no interruptions for resilience activities such as backup and archiving. The requirement for a continuous IT operation will be met by running two hardware and operating system platforms, each of which runs a duplicate copy of the application and database. These two copies will be mirrored so that no problems of database synchronisation are introduced, and the live application can switch between copies, allowing uninterrupted access to the same data.

4.2 Service Context

The following diagram illustrates the context of the BMRA service within the wider market of the Balancing and Settlement Code. This is a simplified view for clarity; section 6 describes the interfaces from the BMRA service to other parties in detail.

Item	Description
Bank	A bank which receives debit and credit instructions from the Funds Administration Agent.
BMRA	Balancing Mechanism Reporting Agent.
BSC Party	Any user of Balancing and Settlement Code services.
BSCCo Ltd	The Balancing and Settlement Code Company.
CDCA	Central Data Collection Agent.
CRA	Central Registration Agent
Credit Agency	A credit agency which provides credit cover data on Traders.
ECVAA	Energy Contract Volume Aggregation Agent.
ECVNA	Energy Contract Volume Notification Agent.
FAA	Funds Administration Agent.
IA	Interconnector Administrator.
IEA	Interconnector Error Administrator
Meter	A physical meter registered within the Balancing and Settlement Code arrangements.
MOA	Meter Operation Agent.
MVRNA	Meter Volume Reallocation Notification Agent
NETSO	National Electricity Transmission System Operator
Public	A member of the general public.
SAA	Settlement Administration Agent.
SVAA	Supplier Volume Aggregation Agent, equivalent to the current Initial Settlement and Reconciliation Agent (ISRA).
TAA	Technical Assurance Agent.

4.3 Numbering Scheme for Requirement Definitions

A User Requirements Specification shall be prepared for each of the seven BSC Services of the central BSC systems.

The common services (such as help desk) and common non functional requirements (e.g. general requirements for security, audit trail etc.) shall be defined in the CRA URS.

The present solution for the seven BSC Services is supported across four computer systems, plus a set of manual processes. Each requirement across the set of services is therefore uniquely identified. This allows each individual requirement to be traced from URS to System Specification (i.e. functional specification) and then to Design Specification (technical specification). There will be a separate System Specification (SS) for the BMRA system, which will include functions supporting the requirements derived from this URS.

In keeping with industry good practice, the URS adopts a requirements numbering system that works as follows:

1. Each requirement is associated with either an individual service, or as common to all services supported by the central systems. If a requirement applies to more than one service, but not all (e.g. two out of six), then the requirement is restated for each, i.e. there will be two separately numbered requirements (which happen to be the same).

Each requirement is therefore prefaced by one of the following codes, as a clear indicator as to which service generates the business need:

CRA (Central Registration Agent);
SAA (Settlement Administration Agent);
CDCA (Central Data Collection Agent);
ECVAA (Energy Contract Volume Aggregation Agent);
BMRA (Balancing Mechanism Reporting Agent);
FAA (Funds Administration Agent);
GEN (General).

2. Requirements shall be categorised into the following headings:

Functional (F), a specific business requirement of the service.
Non-functional (N), which includes auditing, security, resilience etc. The majority of these will probably be associated with the General (GEN) service.
Service (S), which includes all time-related service delivery requirements, including performance and volumetrics.
Interface (I), a requirement for data exchange between services or to external parties.

3. Within a service, each requirement shall have a unique number in the range 001 to 999. Numbers are not unique across services. Leading zeroes are always included.

Combining 1, 2 and 3 thus gives the following format for numbering each requirement (including a separator character):

[Service]-[Category][Number]

For example:

• CRA-F001

• BMRA-S022

• GEN-N112

• SAA-I033

4.4 Attributes of Individual Requirements

For each identified requirement, the following items of information are represented in a tabular format:

Requirement ID: a unique identifier for the requirement, as described above.

Status: while the majority of BMRA requirements are be mandatory for the Go Live date, others may not necessarily be. This field indicates whether the requirement is Mandatory (M) or Optional (O) in this context.

Title: a short descriptive title for the requirement.

BSC reference: a cross reference to the BSC documentation which is the original source of the business need. In most cases this will include a reference to the relevant Service Description and where appropriate, any Change Proposals or Modifications that have affected a particular requirement. Note that there may be detailed requirements identified in the User Requirements Specification which are not individually described in the BSC; in this case this field is used to reference the alternative source of the requirement, for instance a specific workshop with the customer’s user community.

Man/auto: this field provides an indication as to whether a given requirement is likely to be satisfied by a manual, as opposed to automated, mechanism. This is not however intended to be prescriptive, and the approach to supporting any individual requirement will be made definitively during the design phase.

Frequency: an indication of how often a business event will take place. Minimum, maximum and average frequencies, and any timing or scheduling requirements, are also identified here, as appropriate.

Volumes: data volumes associated with the requirement are identified here; this may include an estimate of the initial volume, and subsequent growth rates.

The requirement is then described in detail, with any associated specific non-functional and interface requirements separately identified.

We also identify any outstanding issues relating to the requirement definition, as a way of documenting these for resolution in subsequent versions of the User Requirements Specification.

5 Functional Requirements

This section describes the detailed set of business requirements for the Balancing Mechanism Reporting Agent. To ensure traceability through to other deliverable documents such as the System Specification and Design Specification, each requirement is assigned uniquely numbered, based on the convention described in section 4.

5.1 BMRA-F001: Calculate Balancing Mechanism and Replacement Reserve Volumes

Requirement ID:

BMRA-F001

Status:

Mandatory

Title:

Calculate Balancing Mechanism and Replacement Reserve Volumes

BSC reference:

BMRA SD 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9, BMRA BPM 3.3, CR009, P305, P344.

Man/auto:

Automatic

Frequency:

Once, for each settlement period.

Volumes:

Between 1000 - 5000 BM units. At least 1 FPN data per BM unit. For those BM units that receive bids and offers (estimated 1000), at most 10 Bid-Offer Pairs and 30 Bid-Offer Acceptances per BM unit, per settlement period.

Functional Requirements:

A large number of intermediate calculations are required to produce the balancing mechanism volumes and RR Acceptance volumes. Note that balancing mechanism volumes and RR Acceptance volumes share processes till qAO^kn_ij(t) and qAB^kn_ij(t) are calculated and then subsequently diverge. All calculation steps in this requirement are included here.

1: The value of Final Physical Notification, FPNi_j(t) shall be defined for spot times, t, falling within Settlement Period j by linear interpolation from the values of Point FPN (fFPNit), submitted for that Settlement Period j, for BM Unit i.

2: For any value of Bid-Offer Number, n, the Bid-Offer Volume (qBOⁿ_ij(t)) at any spot time t shall be defined by linear interpolation from the values of Point Bid-Offer Volume (^fqBOⁿ_it) submitted for spot times t in Settlement Period j for BM Unit i.

3: The Bid-Offer Upper Range BOURⁿ_ij(t) at any spot time t shall be defined for Bid-Offer Pairs with positive Bid-Offer Pair Numbers, as follows:

BOURⁿ_ij(t) = FPN_ij(t) + Σⁿ⁺qBOⁿ_ij(t); and

BOUR⁰_ij(t) = FPN_ij(t)

Where Σⁿ⁺ represents a sum over all positive Bid-Offer Pairs, 1 to n.

The Bid-Offer Lower Range BOLRⁿ_ij(t) at any spot time t shall be defined for Bid-Offer Pairs with negative Bid-Offer Pair Numbers, as follows:

BOLRⁿ_ij(t) = FPN_ij(t) + Σ^n-qBOⁿ_ij(t); and

BOLR⁰_ij(t) = FPN_ij(t)

Where Σ^n- represents a sum over the range of Bid-Offer Pair Numbers -1 to n.

4: The Acceptance Volume (qA^k_ij(t)) attributable to each Bid-Offer Acceptance, including RR Schedule flagged Acceptances, shall be defined through processing the Point Acceptance Volumes that define the MW output levels that the NETSO requested the BM Unit to operate for certain times within the Balancing Mechanism Window Period.

Linear interpolation shall be used to define the profile of power output in MW expected to be delivered in each Settlement Period within the Balancing Mechanism Window Period as a result of Bid-Offer Acceptance, k.

For spot times within the Balancing Mechanism Window Period prior to the first value Point Acceptance Volume for Bid-Offer Acceptance k, the value of the Acceptance Volume is set to the last calculated value of Acceptance Volume for those spot times. If no such previously calculated value of Acceptance Volume exists, then the Acceptance Volume will be set to the value of Final Physical Notification (FPN_ij(t)) for those times.

Acceptance Volumes are then ordered by reference to increasing values of k.

The diagram below shows a Bid-Offer Acceptance in relation to Point Acceptance Volumes and the Bid-Offer Upper and Lower Ranges.

complex image of process

5: The Accepted Bid-Offer Volumes (qABO^kn_ij (t)) shall be defined in MW of a Bid or Offer from Bid-Offer Pair n accepted as a result of Bid-Offer Acceptance k that is not flagged as relating to an RR Instruction in Settlement Period j from BM Unit i. This is determined as follows:

For n>0,

qABO^kn_ij (t) = Max{Min(qA^k_ij(t), BOURⁿ_ij (t)), BOUR^n-1_ij(t)} - Max{Min(qA^k-1_ij(t), BOURⁿ_ij(t)), BOUR^n-1_ij(t)}

For n<0,

qABO^kn_ij (t) = Min{Max(qA^k_ij(t), BOLRⁿ_ij(t)), BOLRⁿ⁺¹_ij(t)} - Min{Max(qA^k-1_ij(t), BOLRⁿ_ij(t)), BOLRⁿ⁺¹_ij(t)}

Where, from all Bid-Offer Acceptances for which an Acceptance Volume has been determined for Settlement Period j, k- represents that Bid-Offer Acceptance with the Bid-Offer Acceptance Time (T^k-_it) most recently preceding that of Bid-Offer Acceptance k.

If, there is no Bid-Offer Acceptance, for which an Acceptance Volume has been determined in Settlement Period j which has a Bid-Offer Acceptance Time that precedes that of Bid-Offer Acceptance k, the value of qA^k-_ij(t) = FPN_ij(t) for each Acceptance k that is not flagged as relating to an RR Instruction..

6: The Accepted Offer Volume (qAO^kn_ij(t)) and Accepted Bid Volume qAB^kn_ij (t) shall be defined in MW by splitting the positive and negative parts of the Bid-Offer Acceptance Volume.

The Accepted Offer Volume (qAOknij(t)) represents the volume (in MW) of Offer n accepted as a result of Bid-Offer Acceptance k from BM Unit i at spot times t within Settlement Period j. It is the positive part of the Bid-Offer Acceptance Volume, calculated by:

qAO knij(t) = Max {qABOknij(t), 0}

Similarly, the Accepted Bid Volume (qABknij(t)) represents the volume of Bid n accepted as a result of Bid-Offer Acceptance k from BM Unit i at spot times t within Settlement Period j. It is the negative part of the Bid-Offer Acceptance Volume, calculated by:

qABknij (t) = Min {qABO knij(t), 0}

The diagram below represents the volumes of Bids and Offers bought or sold as a result of a Bid-Offer Acceptance.

complex image of process

7: The Period Accepted Offer Volume (QAO^kn_ij) and Period Accepted Bid Volume (QAB^kn_ij) shall be calculated by integrating the Accepted Offer Volume and Accepted Bid Volume over all spot times in the Settlement Period, for each Acceptance k that is not flagged as relating to an RR Schedule.

The Period Accepted Offer Volume (QAO^kn_ij) is determined by integrating the Accepted Offer Volume over all spot times t in Settlement Period j, for each Acceptance k that is not flagged as relating to an RR Schedule. It represents the half-hourly integrated volume of Offer n, in MWh, accepted as a result of Bid-Offer Acceptance k.

The Period Accepted Bid Volume (QABknij) is determined by integrating the Accepted Bid Volume over all spot times, t, in Settlement Period, j, for each Acceptance k that is not flagged as relating to an RR Schedule. It represents the half-hourly integrated volume of Bid n, in MWh, accepted as a result of Bid-Offer Acceptance k.

The Indicative Period RR Accepted Offer Volume (IRRAO^knij) is established by integrating the Accepted Offer Volume over all spot times in the Settlement Period, for each Acceptance k that is flagged as relating to an RR Schedule.

The Indicative Period RR Accepted Bid Volume (IRRAB^kn_ij) is established by integrating the Accepted Bid Volume over all spot times in the Settlement Period, for each Acceptance k that is flagged as relating to an RR Schedule.

For more information on the method used for performing linear interpolation and integration please refer to the BMRA System Specification.

8: The Reserve Scarcity Price (RSVP_j) shall be calculated as:

RSVP_j = LoLP_j * VoLL

where LoLP_j is the Final Loss of Load Probability for the Settlement Period and VoLL is the Value of Lost Load system parameter.

Until 1 November 2018, if the NETSO does not report a Final Loss of Load Probability for the Settlement Period, then:

RSVP_j = 0.

From 1 November 2018, if the NETSO does not report a Final Loss of Load Probability for the Settlement Period, then the BMRA will use the most recent Indicative LoLP as though it were the Final LoLP, else if no Indicative LoLP is available then:

RSVP_j = 0.

If the BMRA uses an Indicative LoLP in the absence of a Final LoLP provided to it by the NETSO, then the BMRA will set the Default LoLP Flag to ‘True’.

9: The STOR Instructed Volume (QSIV^t_j) shall be calculated as follows:

In respect of each Settlement Period that is in a STOR Availability Window, for each accepted Offer or BSAA that is a STOR Action, the STOR Instructed Volume (QSIVtj) shall be equal to the Period Accepted Offer Volume derived from an accepted Offer that is STOR Flagged.

10: The STOR Action Price (STAP^t_j) shall be calculated as follows:

In respect of each Settlement Period that is in a STOR Availability Window, for each accepted Offer that is a STOR action:

STAP^t_j = max(POⁿ_ij, RSVP_j).

In respect of each Settlement Period, for each Balancing Services Adjustment Action that is a STOR action:

STAP^t_j = max(BSAP^m_j, RSVP_j ).

11: The Demand Control Volumes shall be calculated as follows:

The Start Point Demand Control level and End Point Demand Control Level shall be the Demand Control Event Estimates determined at the relevant times and dates notified by the NETSO.

In respect of each Settlement Period, the Demand Control Volume for each Demand Control Event Stage shall be established by linear interpolation from the values of the Start Point Demand Control Level and End Point Demand Control Level.

The System Demand Control Volume (QSDC_j) shall be determined as the sum of the Demand Control Volumes where the Demand Control Volume Notice has the SMAF Flag set to ‘Yes’.

The Balancing Demand Control Volume (QBDC_j) shall be determined as the sum of the Demand Control Volumes where the Demand Control Volume Notice has the SMAF Flag set to ‘No’.

12: Special Cases

Acceptances are processed in the order in which they are issued, with the exception of Acceptances that are flagged as relating to an RR Schedule, which shall be treated as issued at the Gate Closure time of the Replacement Reserve Auction Period to which they relate.

No Acceptance Volume (qA^k_ij(t)) shall be calculated for any spot times, t. where the following criteria are met:

- qA^k_ij(t) is not flagged as relating to a RR Schedule or a RR Instruction; and

- there exists a qA^k*_ij(t) flagged as relating to a RR Schedule; and

- BEGCT < qA^k_ij(t) Bid-Offer Acceptance Time < qA^k*_ij(t) associated Replacement Reserve Activation Time; and

- either:

qA^k-_ij(t) (MW) < qA^k_ij(t) (MW) < qA^k*_ij(t) (MW)

qA^k*_ij(t) (MW) < qA^k_ij(t) (MW) < qA^k-_ij(t) (MW)

where qA^k-_ij(t) represents the latest Acceptance Volume relating to the latest Acceptance issued prior to Gate Closure of the relevant Replacement Reserve Auction Period (BEGCT). If no such previously calculated value of Acceptance Volume qA^k-_ij(t) exists, then the Acceptance Volume shall be set to the value of FPN_ij(t) for those spot times; and where qA^k_ij(t) (MW), qA^k-_ij(t) (MW) and qA^k*_ij(t) (MW) represent the associated spot time MW values.

In the example below, a BOA, qA^k-_ij, is requested after BEGCT by the TSO. The BOA falls between an existing BOA, qA^k_ij’ which is equal to the FPN as it was sent prior to BEGCT, and an RR Activation qAk^*_ij.

complex image of process

Non Functional Requirement:

If there is insufficient data to calculate Period Bid and Offer Acceptance Volumes, an exception report shall be sent to the NETSO and BSCCo Ltd.

Interfaces:

BMRA-I001, BMRA-I002, BMRA-I006, BMRA – I036.

Issues:

5.2 BMRA-F002: Calculate Indicative Period BM and RR Unit Total Accepted Bid and Offer Volume

Requirement ID: BMRA-F002	Status: Mandatory	Title: Calculate Period BM and RR Unit Total Accepted Bid and Offer Volume.	BSC reference: BMRA SD 9.8, BMRA BPM 3.3, P344
Man/auto: Automatic	Frequency: Once, for each settlement period.	Volumes: Between 1000 - 5000 BM units. At least 1 FPN data per BM unit. For those BM units that receive bids and offers (estimated 1000), at most 10 Bid-Offer Pairs and 30 Bid-Offer Acceptances per BM unit, per settlement period.
Functional Requirement:
1: The Period BM Unit Total Accepted Offer Volume shall be calculated as follows for Acceptances that are not flagged as relating to an RR Schedule: QAOⁿ_ij = Σ^kQAO^kn_ij The Period BM Unit Total Accepted Bid Volume shall be calculated as follows for Acceptances that are not flagged as relating to an RR Schedule: QABⁿ_ij = Σ^kQAB^kn_ij This is the total MWh volume of Offer or Bid n accepted from all Bid-Offer Acceptances k that are not flagged as an RR Schedule.
2: The Indicative Period RR Total Accepted Offer Volume, for all Acceptances that are flagged as relating to an Indicative RR Schedule, and shall be established as follows: IRRAOⁿ_ij = Σ^k IRRAO^kn_ij The Indicative Period Indicative RR Total Accepted Bid Volume, for all Acceptances that are flagged as relating to an Indicative RR Schedule shall be established as follows: IRRABⁿ_ij = Σ^k IRRAB^kn_ij Where Σ^k represents the sum over all Acceptances within the Settlement Period for IRRABⁿ_ijand IRRAOⁿ_ij. The Indicative RR Activation Volume for a Quarter hour J shall be established as follows: IRRAV_i^J = Indicative Quarter Hour RR Activated Quantity * 0.25 Where J is the Quarter Hour and i is the BM unit.
Non Functional Requirement:
If there is insufficient data to calculate Period BM Unit Total Accepted Bid and Offer Volume, an exception report shall be sent to the NETSO and BSCCo Ltd.
Interfaces:
BMRA-I001, BMRA-I002, BMRA-I006, BMRA-I036.
Issues:

Requirement ID:

BMRA-F002

Status:

Mandatory

Title:

Calculate Period BM and RR Unit Total Accepted Bid and Offer Volume.

BSC reference:

BMRA SD 9.8, BMRA BPM 3.3, P344

Man/auto:

Automatic

Frequency:

Once, for each settlement period.

Volumes:

Functional Requirement:

The Period BM Unit Total Accepted Offer Volume shall be calculated as follows for Acceptances that are not flagged as relating to an RR Schedule:

QAOⁿ_ij = Σ^kQAO^kn_ij

The Period BM Unit Total Accepted Bid Volume shall be calculated as follows for Acceptances that are not flagged as relating to an RR Schedule:

QABⁿ_ij = Σ^kQAB^kn_ij

This is the total MWh volume of Offer or Bid n accepted from all Bid-Offer Acceptances k that are not flagged as an RR Schedule.

The Indicative Period RR Total Accepted Offer Volume, for all Acceptances that are flagged as relating to an Indicative RR Schedule, and shall be established as follows:

IRRAOⁿ_ij = Σ^k IRRAO^kn_ij

The Indicative Period Indicative RR Total Accepted Bid Volume, for all Acceptances that are flagged as relating to an Indicative RR Schedule shall be established as follows:

IRRABⁿ_ij = Σ^k IRRAB^kn_ij

Where Σ^k represents the sum over all Acceptances within the Settlement Period for IRRABⁿ_ijand IRRAOⁿ_ij.

The Indicative RR Activation Volume for a Quarter hour J shall be established as follows:

IRRAV_i^J = Indicative Quarter Hour RR Activated Quantity * 0.25

Where J is the Quarter Hour and i is the BM unit.

Non Functional Requirement:

If there is insufficient data to calculate Period BM Unit Total Accepted Bid and Offer Volume, an exception report shall be sent to the NETSO and BSCCo Ltd.

Interfaces:

BMRA-I001, BMRA-I002, BMRA-I006, BMRA-I036.

Issues:

5.3 BMRA-F003: Calculate Estimated Period Balancing Mechanism and Replacement Reserve Bid and Offer Cashflows

Requirement ID:

BMRA-F003

Status:

Mandatory

Title:

Calculate Estimated Period Balancing Mechanism and Replacement Reserve Bid and Offer Cashflows.

BSC reference:

BMRA SD 9.8, BMRA BPM 3.3, P344

Man/auto:

Automatic

Frequency:

Once, for each settlement period.

Volumes:

Functional Requirement:

A number of intermediate calculations are required to produce the Estimated Period Balancing Mechanism and RR Bid and Offer Cashflows. All calculation steps in this requirement are included here.

1: The estimated BM Unit Transmission Loss Multiplier ETLM_ij shall be calculated for each non-Interconnector BM Unit as:

ETLM_ij = 1 + TLF_ij + ETLMO⁺ for all BM Units that are in Trading Units that are attributable to production accounts,

ETLM_ij = 1 + TLF_ij + ETLMO^- for all BM Units that are in Trading Units that are attributable to consumption accounts.

ETLMO⁺and ETLMO^- are estimated values for TLMO_j⁺and TLMO_j^- respectively. They shall be user definable parameters, initially set to zero.

For each Interconnector BM Unit, the estimated BM Unit Transmission Loss Multiplier ETLM_ij shall be set as:

ETLM_ij = 1

irrespective of whether the Interconnector BM Unit is attributable to a production or consumption account.

For each BM unit:

TLF_ij is the Transmission Loss Factor assigned to each BM Unit, and shall apply to all settlement periods until a change is received from the Central Registration Agent (CRA);
the BM unit type (production or consumption) shall be received from the Central Registration Agent (CRA) and shall indicate whether the BM unit is attributable to a production or consumption account. (This data will be received from the CRA on a daily basis with the TLF_ij values.)

ETLM_ij is calculated for each BM unit and applies for all settlement periods, until a change to either TLF_ij , ETLMO⁺ or ETLMO^- prompts re-calculation.

Note that, by default, a BM Unit not comprising a Trading Unit with other BM Units shall be considered to be a ‘Sole Trading Unit’ for the purposes of these calculations. The production and consumption status of such a Trading Unit shall therefore be determined using the metered volume of the single BM Unit comprising that Trading Unit.

In respect of each Settlement Period, for each Secondary BM Unit, the Estimated Transmission Loss Multiplier shall be calculated as follows:

ETLM_ij = ETLM_ij(Base)

where ETLM_ij(Base)means the value of ETLM_ij calculated in the Settlement Period for BM Units belonging to the Base Trading Unit in the same GSP Group as the Secondary BM Unit.

2: The Period Acceptance Offer Cashflow CAO^kn_ij shall be calculated as:

CAO^kn_ij = QAO^kn_ij * POⁿ_ij * ETLM_ij.

The Period Acceptance Bid Cashflow CAB^kn_ij shall be calculated as:

CAB^kn_ij = QAB^kn_ij * PBⁿ_ij * ETLM_ij

Where QAB^kn_ijis the Period Accepted Bid Volume; QAO^kn_ijis the Period Accepted Offer Volume; PBⁿ_ijis the Bid Price for the corresponding Bid; POⁿ_ijis the Offer Price for the corresponding Offer; and ETLM_ijis the Estimated Transmission Loss Multiplier for BM Unit i.

The Period Acceptance Bid Cashflow (CAB^kn_ij) and Period Acceptance Offer Cashflow (CAO^kn_ij) represent the Estimated Transmission Loss adjusted Cashflow relating to BM Unit I for Balancing Mechanism action in Settlement Period j, allocated to Offer or Bid n, as a result of Bid-Offer Acceptance k. Under normal circumstances, the Period Acceptance Bid Cashflow will be negative as QAB^kn_ij is negative and PBⁿ_ij is normally positive.

The Period Acceptance Bid Cashflow and the Period Acceptance Offer Cashflow need to be stored if required for reporting purposes.

3: The Period BM Unit Offer Cashflow (COⁿ_ij ) shall be calculated as:

COⁿ_ij = QAOⁿ_ij * POⁿ_ij * ETLM_ij (=Σ^kCAO^kn_ij)

The Period BM Unit Bid Cashflow (CBⁿ_ij) shall be calculated as:

CBⁿ_ij = QABⁿ_ij * PBⁿ_ij * ETLM_ij (=Σ^kCAB^kn_ij)

These represent the Estimated Transmission Loss adjusted cashflows relating to BM Unit i for Balancing Mechanism action in Settlement Period j, allocated to Offer or Bid n. Under normal circumstances the Period BM Unit Bid Cashflow will be negative.

4: The Indicative Quarter-Hour RR Cashflow for a BM Unit (ICCR_iJ) is defined as:

ICCR_iJ = IRRAV_iJ * IRRAP_J

where IRRAP_J represents the Quarter Hour Indicative RR Activation Price and IRRAV_iJis the Indicative RR Activation Volume

IRRAV_iJ = Indicative Quarter Hour RR Activated Quantity * 0.25

5: The Indicative Period RR BM Unit Cashflow (ICRR_ij) for a BM unit is calculated as:

ICRR_ij = Σ_JICCR_iJ

where Σ_J is the sum over all Quarter Hours J within Settlement Period j.

Non Functional Requirement:

If there is insufficient data to calculate Estimated Period Balancing Mechanism Bid and Offer Cashflows, an exception report shall be sent to the NETSO and BSCCo Ltd.

Interfaces:

BMRA-I001, BMRA-I002, BMRA-I006, BMRA-I036.

Issues:

The method used in section 1 for calculating the estimated transmission loss multiplier for each BM unit (ETLM_ij) is as agreed at the BMRA URS workshop of the 28^th January 2000.

5.4 Not Used

5.4.1 Not Used

5.4.2 BMRA-F004b: Calculate Estimated System Buy and Sell Prices using the P217 methodology

Requirement ID:

BMRA-F004

Status:

Title:

Calculate Estimated System Buy and Sell Prices

BSC reference:

P217, P305, P344

Man/auto:

Automatic

Frequency:

Once, for each Settlement Period.

Volumes:

Functional Requirements:

1: Identify Short-Duration Acceptances.

The rules for identifying Short-Duration Acceptances are:

a. Acceptances for each BM Unit are grouped into sets of overlapping acceptances (for the avoidance of doubt, if two acceptances are contiguous, i.e. the last spot time of one acceptance matches the first of another, then the two are considered to overlap).

b. The overall duration of the group is computed (earliest spot time of any acceptance in a group to latest spot time of any acceptance in a group).

c. In relation to any Demand Control Volume, the Continuous Acceptance Duration shall be the duration of the period commencing at the Demand Control Event Start Point and ending at the Demand Control Event End Point.

d. If the overall duration is less than the Continuous Acceptance Duration Limit, CADL_dthen the Short Duration Acceptance flag for each acceptance in the group is set to show that it is a Short-Duration Acceptance. If CADL_d= 0 then no acceptances are “Short-Duration Acceptances”. CADL_d will be an integer number of minutes from 0 to 30.

Short-Duration Acceptances will be considered to be “CADL Flagged” for the purposes of the System Price Calculation process.

2: Compute Total Volumes:

a. Total Volume of Offers

TQAO_j = Σ_iΣⁿQAOⁿ_ij

where: Σ_i represents the sum over all BM Units;

Σⁿ represents the sum over all accepted Offers

b. Total Volume of Bids

TQAB_j = Σ_iΣⁿQABⁿ_ij

where: Σ_i represents the sum over all BM Units;

Σⁿ represents the sum over all accepted Bids

c. Total Period Applicable Balancing Services Volume

TQAS_j = Σ_iQAS_ij

where: Σ_i represents the sum over all BM Units;

d. Total Balancing Services Adjustment Buy Volume

TBVA_j = Σ^mQBSAB^m_j

where: Σ^m represents the sum over all Balancing Services Adjustment Buy Actions.

e. Total Balancing Services Adjustment Sell Volume

TSVA_j = Σ^mQBSAS^m_j

where: Σ^m represents the sum over all Balancing Services Adjustment Sell Actions.

f. TQSIV_j = Σ^tQSIV^t_j

where: Σ^t represents the sum over all STOR Actions.

g. TQSDC_j = ΣQSDC_j

where: Σ represents the sum over all System Demand Control Volumes.

h. TQBDC_j = ΣQBDC_j

where: Σ represents the sum over all Balancing Demand Control Volumes.

3: Identify “De Minimis Acceptance Volumes”.

Acceptances (including those that are STOR Flagged) with a Total Accepted Volume less than the De Minimis Acceptance Threshold (i.e. where values of |QAOⁿ_ij| < DMAT_d or |QABⁿ_ij| < DMAT_d) are identified as “De Minimis Acceptance Volumes” and are therefore considered to be De Minimis Tagged.

Balancing Services Adjustment Actions (including those that are STOR Flagged) with a Volume less than the De Minimis Acceptance Threshold (i.e. where values of |QBSAB^m_j| < DMAT_d or |QBSAS^m_j| < DMAT_d) are identified as “De Minimis Acceptance Volumes” and are therefore considered to be De Minimis Tagged.

Demand Control Volumes with a volume less than the De Minimis Acceptance Threshold (i.e. where values of |QSDC_j| < DMAT_d or |QBDC_j| < DMAT_d) are identified as “De Minimis Acceptance Volumes” and are therefore considered to be De Minimis Tagged.

De Minimis Tagged System Actions are excluded from the price calculations as they may distort the results.

If DMAT_d is set to 0, then no volumes will be tagged in this way. DMAT_d will always be a positive number or 0.

4: Build Buy and Sell Stacks.

Buy System Actions (QSB^w_j) are considered to be:

i. All those Accepted Offers (QAO^kn_ij) which are not “De Minimis Acceptance Volumes” and not STOR Actions;

ii. All Balancing Services Adjustment Buy Actions (QBSAB^m_j) which are not “De Minimis Acceptance Volumes” and not STOR Actions;

iii. All STOR Instructed Volumes (QSIV^t_j) which are not “De Minimis Acceptance Volumes”;

iv. All System Demand Control Volumes (QSDC_j) which are not “De Minimis Acceptance Volumes”; and

v. All Balancing Demand Control Volumes (QBDC_j) which are not “De Minimis Acceptance Volumes”.

vi. In relation to Replacement Reserve Auction Results, the positive values of Quarter Hour Volume GB Need Met (VGB^J_j) in MWh for each Quarter Hour falling within Settlement Period j determined as below:

VGB^J = GB^J * 0.25

where GB^J represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour GB Need Met for Quarter Hour ‘J’

in relation to Replacement Reserve Auction Results, Replacement Reserve Aggregated Unpriced System Buy Actions (IRRAUSB_j) determined for each Settlement Period as below:

IRRAUSB_j = max {(∑ⁿ_i IRRAOⁿ_ij + ∑ⁿ_i IRRABⁿ_ij ), 0}

+ max (∑^J VIⁿ_j , 0) – max (∑^JVGB^J_j, 0)

where VI^J represents the Quarter Hour Volume Interconnector Schedule to be determined from the Quarter Hour Interconnector Schedule (I^J) as below;

VI^J = I^J * 0.25

where I^J represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour Interconnector Schedule for Quarter Hour ‘J’

Sell System Actions (QSS^w_j) are considered to be:

i. All those Accepted Bids (QAB^kn_ij) which are not “De Minimis Acceptance Volumes”; and

ii. All Balancing Services Adjustment Sell Actions (QBSAS^m_j) which are not “De Minimis Acceptance Volumes”.

iii. in relation to Replacement Reserve Auction Results, the negative values of Quarter Hour Volume GB Need Met (VGB^J_j) in MWh for each Quarter Hour falling within Settlement Period j determined by the SAA as below:

VGB^J = GB^J * 0.25

where GB^J represents the Quarter Hour RR Activated Quantity associated to the Quarter Hour GB Need Met for Quarter Hour ‘J’

iv. in relation to Replacement Reserve Auction Results, Indicative Replacement Reserve Aggregated Unpriced System Sell Actions (IRRAUSS_j) determined by the SAA for each Settlement Period as below:

IRRAUSSj = min {(∑ⁿ_i IRRAOⁿ_ij + ∑ⁿ_i IRRABⁿ_ij ), 0}

+ min (∑^J VIⁿ_j , 0) – min (∑^JVGB^J_j, 0)

The price of a System Action is considered to be (SAP^w_j):

i. In the case of an accepted Offer, the Offer Price POⁿ_ij;

ii. In the case of an accepted Bid, the Bid Price PBⁿ_ij;

iii. In the case of Balancing Services Adjustment Actions, Balancing Services Adjustment Price BSAP^m_j(derived from Cost/Volume, i.e. a £/MWh price);

iv. In the case of a STOR Action, the STOR Action Price (STAP^t_j); or

v. In the case of a System Demand Control Volume or a Balancing Demand Control Volume, the VoLL.

vi. In the case of Quarter Hour Volume GB Need Met, the associated Indicative Quarter Hour Replacement Reserve Activation Price (QHRRAP^J); and

vii. In the case of Replacement Reserve Aggregated Unpriced System Actions, the price shall be equal to zero.

For each Settlement Period, all System Actions are listed in descending order of price, within the relevant Stack. Unpriced Balancing Services Adjustment Actions are placed at the top of the Buy Stack (as if most expensive) or the bottom of the Sell Stack (as if least expensive), as appropriate. For example:

Buy Stack		Sell Stack
Vol(QSB^w_j)	Price(SAP^w_j)	Vol(QSS^w_j)	Price(SAP^w_j)
12	-	7	25
24	45	15	8
15	40	5	7
50	10	5	4
20	10	10	-

5: Apply Arbitrage Tagging.

Starting from the most expensive Sell Action and least expensive Buy Action, each System Action is inspected for arbitrage, i.e. where the Sell Action’s price exceeds or is equal to the Buy Action’s price. Where arbitrage exists then equivalent amounts of volume are tagged out from both stacks until arbitrage no longer exists.

Actions with the same price which are on the same stack are combined into a single item for the purpose of Arbitrage inspection. If, for a particular price, only a subset of the combined Buy (or Sell) Actions can be matched, then every Buy (or Sell) Action at that price is tagged to the same degree (a fraction equal to amount matched, for that price, over the total volume available, for that price), rather than tagging some of the individual Actions entirely, and others not at all.

Extending the example from above:

Buy Stack		Sell Stack
Vol(QSB^w_j)	Price(SAP^w_j)	Vol(QSS^w_j)	Price(SAP^w_j)
12	-	7	25
24	45	15	8
15	40	5	7
50 45	10	5	4
20 18	10	10	-

In this example there are two Buy Actions (total volume = 70 MWh, price = £10) matched to a single Sell Action (volume = 7 MWh, price = £25). The two Buy Actions therefore have an amount tagged equal to 7/70 times their volume ( 5 and 2 MWh respectively, for a total of 7 MWh tagged volume)

Unpriced Balancing Services Adjustment Actions are ignored for the purposes of Arbitrage – i.e. once all Priced Actions on a Stack have been Arbitrage tagged then no further Arbitrage tagging can occur.

The process of Arbitrage Tagging will only be carried out for Settlement Dates where the Arbitrage Flag (a dated system parameter) is set.

6: Determine Action Classification

For each Settlement Period, the Buy and Sell Stacks are then updated by applying the following algorithm:

All the First-Stage Flagged and Unflagged System Actions are identified on each Stack. A First-Stage Flagged System Action is one which is either:

a) A Short-Duration (CADL Flagged) Acceptance;

b) A SO-Flagged Acceptance;

c) A SO-Flagged Balancing Services Adjustment Action; or

d) A System Demand Control Volume

A First-Stage Unflagged System Action is one which is not a First-Stage Flagged System Action.

Then, for the Buy Stack, all First-Stage Flagged System Actions with a price which is higher than the most expensive First-Stage Unflagged System Action are classified as Second-Stage Flagged System Actions. And, for the Sell Stack, all First-Stage Flagged System Actions with a price which is lower than the least expensive First-Stage Unflagged System Action are classified as Second-Stage Flagged System Actions.

All Second-Stage Flagged System Actions are considered to be unpriced.

For example:

Buy Stack

complex image of process

Sell Stack

complex image of process

Note that unpriced Balancing Services Adjustment Actions are always classified as Second-Stage Flagged System Actions and therefore always remain unpriced.

7: Apply NIV Tagging

Starting from the least expensive Sell Action and most expensive Buy Action, Actions from the two stacks are matched and tagged until the smaller (in total volume) of the two stacks is completely tagged. Unpriced Actions are included in NIV Tagging. Unpriced Sell Actions are considered to be the least expensive Sell Actions and Unpriced Buy Actions are considered to be the most expensive Buy Action – i.e. where present they are the first Actions to be considered during the NIV Tagging process.

Actions with the same price which are on the same stack are combined into a single item for the purpose of matching. If, for a particular price, only a subset of the combined Buy (or Sell) Actions can be matched, then every Buy (or Sell) Action at that price is tagged to the same degree (a fraction equal to amount matched, for that price, over the total volume available, for that price), rather than tagging some of the individual Actions entirely, and others not at all. Unpriced items are considered to be at the same price for the purpose of NIV Tagging.

In the example from above the Buy Stack is the smaller (having only 70 MWh of total volume, as opposed to 100 MWh on the Sell Stack). The result of this process is that there will be, across the two stacks, a mixture of NIV Tagged and NIV Untagged stack items. Continuing the example from before:

Buy Stack			Sell Stack
Tagged Status	Price	Vol	Tagged Status	Price	Vol
Tagged	-	10	Untagged	15	15
Tagged	-	0	Untagged	10	15
Tagged	25	5	Tagged	10	29
Tagged	20	20	Tagged	5	5
Tagged	15	5	Tagged	-10	7
Tagged	10	30	Tagged	-	25
			Tagged	-	4

Note that for the £10 price range only 29 out of the 44 available MWh of Sell Actions at that price can be tagged. Therefore each Sell Action in that price range would be tagged by an amount equal to 29/44 of their entire volumes. Expanding the example, and assuming that there are three Sell Actions that make up the 44 MWh:

Sell Action	Volume	Tagged Volume	Untagged Volume
1	20	20 x 29/44 = 13.182	20 x 15/44 = 6.818
2	10	10 x 29/44 = 6.591	10 x 15/44 = 3.409
3	14	14 x 29/44 = 9.227	14 x 15/44 = 4.773

8: Calculate and Apply Replacement Price

The Replacement Price is calculated from a selection of those untagged items remaining after the NIV Tagging process which are priced System Actions (i.e. Unflagged Second-Stage System Actions). This selection is determined by the Replacement Price Average Reference (RPAR) Volume, and is defined as that volume of the most expensive priced System Action items remaining after NIV Tagging which is equivalent to the RPAR Volume (where necessary only part of an item’s volume will be considered selected in order that the total selected volume is equal to the RPAR Volume). Where the total remaining volume of untagged, priced System Action items is less than the RPAR Volume then all untagged, priced System Action items are selected.

The Replacement Price is calculated as the volume weighed average price of the selected items.

If NIV is positive then:

RP_j = ∑^w' (QSB^w'_j * SAP^w'_j) / ∑^w' QSB^w'_j

and if NIV is negative then:

RP_j = ∑^w' (QSS^w'_j * SAP^w'_j) / ∑^w' QSS^w'_j

Where ∑^w'is the sum over all RPAR Volume selected untagged, priced System Actions.

Where no priced System Action items remain after NIV Tagging then the Replacement Price is the Market Price. If the Market Price is undefined then the Replacement Price is zero.

The actual volume of Actions used to calculate the Replacement Price is defined as the Replacement Price Calculation Volume. If the Replacement Price is derived from the Market Price then Replacement Price Calculation Volume will be considered to be zero.

Once calculated the Replacement Price is assigned to those remaining untagged stack items which are classified as Second-Stage Flagged System Actions, All such affected System Actions are considered to be “Repriced” System Actions.

9: Apply PAR Tagging

Referencing the remaining Buy or Sell Stack (depending on whichever stack has untagged items remaining after NIV tagging), and starting from the most expensive Sell Stack item or least expensive Buy Stack item, Buy or Sell Stack items are tagged until the total remaining priced volume in the stack is not more than the Price Average Reference Volume (PAR_d).

Actions with the same price which are on the same stack are combined into a single item for the purpose of matching. If, for a particular price, only a subset of the entire set of combined Sell Actions (or Buy Actions) can be matched, then every Sell Action (or Buy Action) at that price is tagged to the same degree (a fraction equal to amount matched, for that price, over the total volume available, for that price), rather than tagging some of the individual Sell Actions (or Buy Actions) entirely, and others not at all. For an example which demonstrates the principle of this mechanism see the section describing NIV tagging above.

Continuing the example from above: All items in the Buy Stack are NIV Tagged, and only two items remain untagged in the Sell Stack, leaving a total of 30 MWh untagged volume. For example, if PAR_d was defined to have a value of 20 MWh, this would mean that 10 of the remaining 30 MWh should be PAR Tagged (to leave us with the required 20 MWh), leaving the stacks as follows:

Buy Stack			Sell Stack
Tagged Status	Price	Vol	Tagged Status	Price	Vol
NIV Tagged	-	10	PAR Tagged	15	10
NIV Tagged	-	0	Untagged	15	5
NIV Tagged	25	5	Untagged	10	15
NIV Tagged	20	20	NIV Tagged	10	29
NIV Tagged	15	5	NIV Tagged	5	5
NIV Tagged	10	30	NIV Tagged	-10	7
			NIV Tagged	-	25
			NIV Tagged	-	4

Note that where, after NIV Tagging, the remaining volume is less than or equal to the PAR_d then no items will be PAR Tagged.

10: Calculate Reported Period BM Unit Volumes

It is now possible to calculate the following reported derived values:

a. Period BM Unit Tagged Volume of Offers (QTAOⁿ_ij) and Bids (QTABⁿ_ij) are the amounts of QAOⁿ_ij and QABⁿ_ij respectively which were excluded from the System Price Stacks by De Minimis Tagging, Arbitrage Tagging, NIV Tagging and/or PAR Tagging.

b. Period BM Unit Repriced Accepted Volume of Offers (QRAOⁿ_ij) and Bids (QRABⁿ_ij) are the amounts of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) but which were Classified as Second-Stage Flagged and therefore subject to the Replacement Price.

c. Period BM Unit Originally-priced Accepted Volume of Offers (QOAOⁿ_ij) and Bids (QOABⁿ_ij) are the amounts of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) and were not Classified as Second-Stage Flagged and therefore not subject to the Replacement Price.

11: Calculate Reported Acceptance Volumes

It is now possible to calculate the following reported derived values:

a. The System Total Priced Accepted Volume of Offers (TQPAO_j) and Bids (TQPAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were not Classified as Second-Stage Flagged.

b. System Total Tagged Accepted Volume of Offers (TQTAO_j) and Bids (TQTAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were excluded from the System Price Stacks by De Minimis Tagging, Arbitrage Tagging, NIV Tagging and/or PAR Tagging.

c. System Total Repriced Accepted Volume of Offers (TQRAO_j) and Bids (TQRAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) but which were Classified as Second-Stage Flagged and therefore subject to the Replacement Price.

d. System Total Originally-priced Accepted Volume of Offers (TQOAO_j) and Bids (TQOAB_j) are the sum of QAOⁿ_ij and QABⁿ_ij respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) and were not Classified as Second-Stage Flagged and therefore not subject to the Replacement Price.

12: Calculate Reported Adjustment Volumes

It is now possible to calculate the following reported derived values:

a. Total System Adjustment Volume of Buy Items (TSVA_j) and Sell Items (TBVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively.

b. Total System Tagged Adjustment Volume of Buy Items (TSTVA_j) and Sell Items (TBSVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively which were excluded from the System Price Stacks by De Minimis Tagging, Arbitrage Tagging, NIV Tagging and/or PAR Tagging.

c. Total System Repriced Adjustment Volume of Buy Items (TSRVA_j) and Sell Items (TBRVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) but which were Classified as Second-Stage Flagged and therefore subject to the Replacement Price.

d. Total System Originally-priced Adjustment Volume of Buy Items (TSOVA_j) and Sell Items (TBOVA_j) are the sum of QBSAB^m_j and QBSAS^m_i respectively which were not NIV tagged (i.e. remain on the System Price Stacks after NIV Tagging) and were not Classified as Second-Stage Flagged and therefore not subject to the Replacement Price.

13: The actual Indicative Net Imbalance Volume (NIV) for each Settlement Period can then be calculated as follows:

NIV_j = ∑_w QSB^w_j – ∑_w (-QSS^w_j)

where

Σ_w represents the sum over all System Actions that are not De Minimis System Actions, and not Arbitrage Tagged System Actions.

14: The remaining offers and bid volumes shall be used in the calculation of the Indicative System Buy Price (SBP_j) as follows:

In respect of each Settlement Period, if the Net Imbalance Volume is not equal to zero and is a positive number, and {Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^m {QBSAB^m_j + Σ^tQSIV^t + QSDC_j + QBDC_j+ Σ^J {VGB_j^J} + {IRRAUSB_j}} is not equal to zero, then the System Buy Price will be determined as follows:

SBP_j = {BPA_j} +

{Σ_iΣⁿΣ^k {QAO^kn_ij * POⁿ_ij* TLM_ij} + Σ^m {QBSAB^m_j * BSAP^m_j} + Σ^t {QSIV^t_j * STAP^t_j} + {QSDC_j + QBDC_j} * VoLL} } + Σ^J {VGB^J * QHRRAP^J} + {0 * RRAUSB_j } ________________________________________________________________________________________________________________________________________

{Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^m QBSAB^m_j + Σ^t QSIV^t_j + QSDC_j + QBDC_j } + Σ^J {VGB_j^J} + {IRRAUSB_j}

where

Σ_i represents the sum over all BM Units;

Σ^k represents the sum over all Acceptances;

Σⁿ represents the sum over those Accepted Offers that are not De Minimis Tagged and not Arbitrage Tagged Offers and not NIV Tagged Offers and not PAR Tagged Offers;

Σ^t represents the sum over all STOR actions

POⁿ_ij is the Price for the Offer acceptance n, for BM Unit i and Settlement Period j (which may be the Replacement Price);

Σ^m represents the sum over those Balancing Services Adjustment Buy Actions that are not De Minimis Tagged and not Arbitrage Tagged Actions and not NIV Tagged Actions and not PAR Tagged Actions;

Σ^J represents the sum over all Quarter Hour Volume GB Need Met in the Final Ranked Set of System Buy Actions; and

BSAP^m_j is the Price for the Balancing Services Adjustment Buy Action m for Settlement Period j (which may be the Replacement Price); and

BPA_j is the Buy-Price Price Adjustment; and

The System Sell Price SSP_j = SBP_j.

15: The remaining offers and bid volumes shall be used in the calculation of the Indicative System Sell Price (SSP_j) as follows:

In respect of each Settlement Period, if the Net Imbalance Volume is not equal to zero and is a negative number, and {Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^m {QBSAS^m_j} + Σ^J {VGB_j^J} + {RRAUSB_j} is not equal to zero, then the Indicative System Sell Price will be determined as follows:

SSP_j = {SPA_j} +

{Σ_iΣⁿΣ^k {QAB^kn_ij * PBⁿ_ij* TLM_ij} + Σ^m {QBSAS^m_j * BSAP^m_j}} + Σ^J {VGB^J * QHRRAP^J} + {RRAUSB_j * 0} ________ ______________________________________________________________________________

{Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^m QBSAS^m_j} + Σ^J {VGB_j^J} + {RRAUSB_j}

where

Σ_i represents the sum over all BM Units;

Σ^k represents the sum over all Acceptances;

Σⁿ represents the sum over those Accepted Bids that are not De Minimis Tagged and not Arbitrage Tagged Bids and not NIV Tagged Bids and not PAR Tagged Bids;

PBⁿ_ijis the Price for the Bid acceptance n, for BM Unit i and Settlement Period j (which may be the Replacement Price):

Σ^m represents the sum over those Balancing Services Adjustment Sell Actions that are not De Minimis Tagged and not Arbitrage Tagged Actions and not NIV Tagged Actions and not PAR Tagged Actions;

Σ^J represents the sum overall Quarter Hour Volume GB Need Met in the Final Ranked Set of System Buy Actions;

BSAP^m_j is the Price for the Balancing Services Adjustment Buy Action m for Settlement Period j (which may be the Replacement Price); and

SPA_j is the Sell-Price Price Adjustment; and

The System Buy Price SBP_j = SSP_j.

15a: If, for any Settlement Period,

if the Net Imbalance Volume is equal to zero or is a positive number,

if {Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^mQBSAB^m_j + Σ^tQSIV^t + QSDC_j + QBDC_j} + Σ^J {VGB_j^J} + {RRAUSB_j} is equal to zero,

then SBP_j = SSP_j = Market Price (MP_j)

If, for any Settlement Period,

if the Net Imbalance Volume is equal to zero or is a negative number,

if {Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^mQBSAB^m_j} + Σ^J {VGB_j^J} + {RRAUSS_j} is equal to zero,

then SBP_j = SSP_j = Market Price (MP_j)

15b: If, for any Settlement Period,

Σ_sQXP_sj = 0,

where

Σ_s represents the sum over all Index Providers;

QXP_sj is the Market Index Volume for Index Providers and Settlement Period j

Then

if the Net Imbalance Volume is not equal to zero or is a positive number,

if {Σ_iΣⁿΣ^k {QAO^kn_ij * TLM_ij} + Σ^mQBSAB^m_j + Σ^tQSIV^t + QSDC_j + QBDC_j} is equal to zero,

then SBP_j = SSP_j = 0

if the Net Imbalance Volume is not equal to zero and is a negative number,

if {Σ_iΣⁿΣ^k {QAB^kn_ij * TLM_ij} + Σ^mQBSAS^m_j} is equal to zero,

then SBP_j = SSP_j = 0

16: The price adjustment parameters shall be set through the automatic interface BMRA-I014, as directed by the NETSO. Note that if no adjustment data has been provided for Settlement Period j then a value of zero will be used for SPA and BPA.

The system parameters like RPAR_d, PAR_d, Arbitrage Flag, DMAT_d, CADL_d and VoLL are received from BSCCo Ltd through the manual flow BMRA-I012.

Market Index Data is received from Market Index Data Providers through the automatic flow BMRA-I015.

Where no Market Index Data has been provided by a Market Index Data Provider, at the point where the Indicative Calculation is carried out, for a given Settlement Period, then the BMRA will generate a warning message (see BMRA-F007).

The BMRA shall, for the purposes of performance reporting, record details of those cases where:

1. A value of zero was used for Market Index Price and Volume for a Settlement Period, for the purposes of the Indicative Calculation

2. A Market Index Provider has failed to supply Market Index Data for any given Settlement Period, such that a default price and volume of zero are used for that Settlement Period, for the purposes of the Indicative Calculation.

The BMRA shall for the purposes of reporting, record a Price Derivation Code (PDC_j) for each Settlement Period. This code will describe how the Indicative SBP and SSP were calculated. The possible values for the code, and their associated meaning, are defined in Appendix G.

Non-Functional Requirement:

Interfaces:

BMRA-I001, BMRA-I002, BMRA-I006, BMRA-I012, BMRA-I014, BMRA-I015, BMRA-I031, BMRA-I036.

5.5 BMRA-F005: Postponement of Calculations

Requirement ID: BMRA-F005	Status: Mandatory	Title: Postponement of calculations	BSC reference: CP560
Man/auto: Manual	Frequency: Ad hoc	Volumes: N/a
Functional Requirements:
1. When the BMRA is advised of an Outage by the NETSO it shall carry out the following procedures in order to avoid publishing erroneous Settlement data: a) If an Outage is planned, the BMRA shall receive a prior warning from the NETSO detailing the expected date and time of the Outage. For those unplanned Outages, the BMRA will be informed of the date and time as soon as possible after the Outage has commenced. b) The BMRA shall inform BSCCo that Settlement calculations shall be suspended during the planned Outage. c) From the time at which the Outage commenced (if it was planned), or as soon as possible after it commenced (if the Outage was unplanned) the BMRA shall disable its automatic calculation processes. In the case of an unplanned Outage the BMRA shall also send confirmation to BSCCo that calculations have been suspended. d) During the Outage, the BMRA shall load and report any Bid-Offer and Physical Notification data received from the NETSO as normal. e) When the Outage has ceased, the BMRA shall receive and load the backlog of Bid-Offer Data issued by the NETSO. Once the backlog has been received and loaded, the automatic calculation processes shall be re-enabled to operate on the first Settlement Period affected by the Outage. f) The BMRA will then inform BSCCo that calculations have resumed, and confirm the Settlement Periods that have been affected.
2. During an Outage the BMRA reporting service shall continue to operate as normal.
3. In cases where an unplanned Outage has led to the calculation processes being disabled after the first Settlement Period of the Outage (and therefore incorrect data has been published), the BMRA is not required to re-calculate and correct the data on the BMRS once the Outage has ceased. For the avoidance of doubt, note that the BMRA may, at its discretion, re-calculate and correct the data.
4. In the event that the date and time of an Outage changes from that already notified by the NETSO, a further warning shall be issued to the BMRA containing the revised date and time.
Non-Functional Requirements:

Interfaces:
No interfaces are defined for the interactions with the NETSO and BSCCo. These will take the form of email or telephone calls.
Issues:

Requirement ID:

BMRA-F005

Status:

Mandatory

Title:

Postponement of calculations

BSC reference:

CP560

Man/auto:

Manual

Frequency:

Ad hoc

Volumes:

N/a

Functional Requirements:

1. When the BMRA is advised of an Outage by the NETSO it shall carry out the following procedures in order to avoid publishing erroneous Settlement data:

a) If an Outage is planned, the BMRA shall receive a prior warning from the NETSO detailing the expected date and time of the Outage. For those unplanned Outages, the BMRA will be informed of the date and time as soon as possible after the Outage has commenced.

b) The BMRA shall inform BSCCo that Settlement calculations shall be suspended during the planned Outage.

c) From the time at which the Outage commenced (if it was planned), or as soon as possible after it commenced (if the Outage was unplanned) the BMRA shall disable its automatic calculation processes. In the case of an unplanned Outage the BMRA shall also send confirmation to BSCCo that calculations have been suspended.

d) During the Outage, the BMRA shall load and report any Bid-Offer and Physical Notification data received from the NETSO as normal.

e) When the Outage has ceased, the BMRA shall receive and load the backlog of Bid-Offer Data issued by the NETSO. Once the backlog has been received and loaded, the automatic calculation processes shall be re-enabled to operate on the first Settlement Period affected by the Outage.

f) The BMRA will then inform BSCCo that calculations have resumed, and confirm the Settlement Periods that have been affected.

2. During an Outage the BMRA reporting service shall continue to operate as normal.

3. In cases where an unplanned Outage has led to the calculation processes being disabled after the first Settlement Period of the Outage (and therefore incorrect data has been published), the BMRA is not required to re-calculate and correct the data on the BMRS once the Outage has ceased. For the avoidance of doubt, note that the BMRA may, at its discretion, re-calculate and correct the data.

4. In the event that the date and time of an Outage changes from that already notified by the NETSO, a further warning shall be issued to the BMRA containing the revised date and time.

Non-Functional Requirements:

Interfaces:

No interfaces are defined for the interactions with the NETSO and BSCCo. These will take the form of email or telephone calls.

Issues:

5.6 BMRA-F006: Validate Market Index Data

Requirement ID: BMRA-F006	Status: Mandatory	Title: Validate Market Index Data	BSC reference: P78
Man/auto: Automatic	Frequency: On demand.	Volumes:
Functional Requirements:
The BMRA shall validate Market Index Data, on receipt, to ensure that the Market Index Volume equals, or exceeds the Liquidity Threshold for the relevant Market Index Data Provider, Settlement Day, and Settlement Period. If the Market Index Volume is non-zero and below the defined threshold, then the BMRA will default the invalid Market Index Volume, and its associated Market Index Price, to zero for that Settlement Period. The occurrence of below threshold, non-zero Market Index Data is recorded by the BMRA for the purposes of performance reporting. Unless a specific clock change day Liquidity Threshold has been submitted, then, where a Liquidity Threshold is defined for a range of days that spans a ‘long’ or ‘short’ day, the following rules will be applied: For a ‘short’ day, having 46 Settlement Periods (i.e. the spring clock change when 1am GMT changes to 2am BST): Settlement Periods 1 to 2 (00:00 to 01:00 GMT) of the ‘short’ day take the values of Settlement Periods 1 to 2 (00:00 to 01:00 local time) of the ‘normal’ day data; Settlement Periods 3 to 46 (02:00 to 24:00 BST) of the ‘short’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day data; Settlement Periods 3 and 4 of the ‘normal’ day data are not used on a short day. For a ‘long’ day, having 50 Settlement Periods (i.e. the autumn clock change when 2am BST changes to 1am GMT): Settlement Periods 1 to 4 (00:00 to 02:00 BST) of the ‘long’ day take the values of Settlement Periods 1 to 4 (00:00 to 02:00 local time) of the ‘normal’ day data; Settlement Periods 5 to 6 (01:00 to 02:00 GMT) of the ‘long’ day take the values of Settlement Periods 3 to 4 (01:00 to 02:00 local time) of the ‘normal’ day data; Settlement Periods 7 to 50 (02:00 to 24:00 GMT) of the ‘long’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day data.
Non-Functional Requirements:

Interfaces:
BMRA-I011, BMRA-I015

Requirement ID:

BMRA-F006

Status:

Mandatory

Title:

Validate Market Index Data

BSC reference:

P78

Man/auto:

Automatic

Frequency:

On demand.

Volumes:

Functional Requirements:

The BMRA shall validate Market Index Data, on receipt, to ensure that the Market Index Volume equals, or exceeds the Liquidity Threshold for the relevant Market Index Data Provider, Settlement Day, and Settlement Period. If the Market Index Volume is non-zero and below the defined threshold, then the BMRA will default the invalid Market Index Volume, and its associated Market Index Price, to zero for that Settlement Period.

The occurrence of below threshold, non-zero Market Index Data is recorded by the BMRA for the purposes of performance reporting.

Unless a specific clock change day Liquidity Threshold has been submitted, then, where a Liquidity Threshold is defined for a range of days that spans a ‘long’ or ‘short’ day, the following rules will be applied:

For a ‘short’ day, having 46 Settlement Periods (i.e. the spring clock change when 1am GMT changes to 2am BST):

Settlement Periods 1 to 2 (00:00 to 01:00 GMT) of the ‘short’ day take the values of Settlement Periods 1 to 2 (00:00 to 01:00 local time) of the ‘normal’ day data;
Settlement Periods 3 to 46 (02:00 to 24:00 BST) of the ‘short’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day data;
Settlement Periods 3 and 4 of the ‘normal’ day data are not used on a short day.

For a ‘long’ day, having 50 Settlement Periods (i.e. the autumn clock change when 2am BST changes to 1am GMT):

Settlement Periods 1 to 4 (00:00 to 02:00 BST) of the ‘long’ day take the values of Settlement Periods 1 to 4 (00:00 to 02:00 local time) of the ‘normal’ day data;
Settlement Periods 5 to 6 (01:00 to 02:00 GMT) of the ‘long’ day take the values of Settlement Periods 3 to 4 (01:00 to 02:00 local time) of the ‘normal’ day data;
Settlement Periods 7 to 50 (02:00 to 24:00 GMT) of the ‘long’ day take the values of Settlement Periods 5 to 48 (02:00 to 24:00 local time) of the ‘normal’ day data.

Non-Functional Requirements:

Interfaces:

BMRA-I011, BMRA-I015

5.7 BMRA-F007: Generate Missing Market Index Data Messages

Requirement ID:

BMRA-F007

Status:

Mandatory

Title:

Generate Missing Market Index Data Messages

BSC reference:

P78

Man/auto:

Automatic

Frequency:

Once, for each settlement period.

Volumes:

Functional Requirements:

The BMRA shall, for each Settlement Period, identify those Market Index Data Providers which are active for that Settlement Period, but have not submitted Market Index Data by the time that BMRA commences calculating the Indicative System Buy and Sell Prices – i.e. those cases where the calculation will use default values.

A warning message will be generated for each Market Index Data Provider so identified.

The Warning message will include:

Settlement Day

Settlement Period

Market Index Data Provider Identifier

Market Index Data Provider Name

Message detailing that the MIDP has not submitted Market Index Data in time for the Indicative Calculation, and therefore the Market Index Price and Market Index Volume have been defaulted to zero for that MIDP and Settlement Period

Non-Functional Requirements:

Interfaces:

BMRA-I005

5.8 BMRA-F008: Process Market Index Data Provider Liquidity Thresholds

Requirement ID:

BMRA-F008

Status:

Title:

Process Market Index Data Provider Liquidity Thresholds

BSC reference:

P78

Man/auto:

Manual/Automatic

Frequency:

On demand.

Volumes:

Functional Requirements:

The BMRA shall carry out the following validation on MIDP Liquidity Thresholds:

(a) That there is no impact on retrospective dates;

(b) Where the Action is ‘Insert’, then the effective date range of the Liquidity Threshold record must not overlap with any existing record for that MIDP;

(c) Where the Action is ‘Update’, then the ‘Effective From Settlement Date’ must match the Effective From Settlement Date of an existing Liquidity Threshold record for that MIDP;

(d) Where the Action is ‘Delete’, then the ‘Effective From Settlement Date’ must match the Effective From Settlement Date of an existing Liquidity Threshold record for that MIDP.

Where a Liquidity Threshold record fails validation then it is rejected, and the details of the rejection are reported back to BSCCo.

After applying an update, or set of updates, for a given MIDP, the Liquidity Threshold data for current and future dates is reported back to BSCCo, using the BMRA-I017 flow.

Amendments to Liquidity Thresholds will not be applied to existing Market Index Data.

Non-Functional Requirement:

Interfaces:

BMRA-I016, BMRA-I017

5.9 BMRA-F009: Validate Adjustment Data

Requirement ID:

BMRA-F009

Status:

Title:

Validate Adjustment Data

BSC reference:

P78, P217

Man/auto:

Automatic

Frequency:

On demand.

Volumes:

Functional Requirements:

For Settlement Dates prior to the P217 effective date the BMRA shall validate Adjustment Data, on receipt, to ensure that:

1. One of Energy SVA and Energy BVA must be zero;

2. One of System SVA and System BVA must be zero.

Where this is not the case, then the BMRA will generate an exception to the NETSO (via the BMRA-I010) detailing the reason for the exception, and will not load data for the offending Settlement Period.

For Settlement Dates on or after the P217 effective date the BMRA shall validate the following Adjustment Data items:

Net Energy Buy Price Cost Adjustment (EBCA) (£)

Net Energy Buy Price Volume Adjustment (EBVA) (MWh)

Net System Buy Price Volume Adjustment (SBVA) (MWh)

Net Energy Sell Price Cost Adjustment (ESCA) (£)

Net Energy Sell Price Volume Adjustment (ESVA) (MWh)

Net System Sell Price Volume Adjustment (SSVA) (MWh)

Where they are found to be non-zero, the BMRA will set the values to zero and pass the details of the validation failure to BSCCo.

Non-Functional Requirement:

Interfaces:

BMRA-I014, BMRA-I010

5.10 BMRA-F011: Process SO-SO Trades

Requirement ID:

BMRA-F011

Status:

Title:

Process SO-SO Trades

BSC reference:

CP1333

Man/auto:

Automatic

Frequency:

Continuously

Volumes:

Up to 20 prices per Interconnector per hour (received as one file per Interconnector per hour) plus occasional resends and corrections of data (up to an extra 10% volume)

Functional Requirements:

The BMRA shall carry out the following activities to process and prepare for publication information relating to SO-SO Trades:

1. The BMRA shall use the Resource Provider, Acquiring Area, Connecting Area and Resolution Codes to identify the SO-SO Trade Type to which the SO-SO price in each interval element of BMRA-I025 relates.

2. The effective date and time of each SO-SO price shall be determined from the Time Interval element of BMRA-I025, this time being the start time of the block to which the price relates. For example, a price that relates to 04:00 – 05:00 on 26 June 2011 would be notified with a time of 2001-06-24 04:00:00.

3. Individual Bids and Offers shall be identified using the Contract Identification and Direction elements, with a stack of multiple prices being built up for each block.

4. The currency in which each price is provided shall be determined from the currency element in BMRA-I025, validated against the expected of currencies for that price received in BMRA-I026.

5. The energy price value and quantity associated with each SO-SO trade shall be determined from the Energy Price and Qty elements in BMRA-I025. The quantity shall represent a MWh level while energy price shall represent a price value in the currency relevant for that SO-SO Trade Type (i.e. £/MWh or €/MWh).

6. The previous steps shall result in a set of Bids and Offers each comprising the following data items:

SO-SO Trade Type
Effective date and time
Direction
Contract Identification
Quantity
Energy Price

7. Following successful processing the information shall be published on the BMRS in accordance with BMRA-I005.

Non-Functional Requirement:

Interfaces:

BMRA-I025, BMRA-I026, BMRA-I005

5.11 BMRA-F012: Process Settlement Exchange Rate

Requirement ID:

BMRA-F012

Status:

Title:

Process Settlement Exchange Rate

BSC reference:

P344

Man/auto:

Manual

Frequency:

Daily

Volumes:

Functional Requirements:

The BMRA shall carry out the following activities to process and prepare for publication information relating to the Settlement Exchange Rate:

1. By 16.00 each day, the BMRA shall retrieve the latest average GBP-EUR Exchange Rate from the Exchange Rate provider.

2. The BMRA shall record the latest average exchange rate as the Settlement Exchange Rate for use on the following Settlement Day.

3. Following successful processing, the information shall be published on the BMRS in accordance with BMRA-I037 and shall include:

Settlement Exchange Rate
Settlement Day
Date and time retrieved

3. BMRS Users shall be able to retrieve this information through the API.

4. Where data is not available at the time of initial upload; the BMRA shall repeat the retrieval process a number of times until 16.00 on the given day. Where no data is available by 16:00; the published Settlement Exchange Rate shall default to the value for the previous Settlement Day.

Non-Functional Requirement:

Interfaces:

Operator Interface; SAA-I053

6 External interfaces

Details of the contents of interfaces relevant to the BMRA are contained in the Interface Definition and Design (IDD). Part 1 of the IDD is limited to the definition and design of interfaces between the BSC central systems and the BSC Parties and their Agents, while Part 2 details the interfaces between the BSC central systems and other BSC service providers.

The interface document is based from and references to the NETSO BMRA & SAA Interface Specification:

6.1 Overview

The BMRA Service shall provide an interface to the following external parties.

Other Service Providers:

Central Registration Agent (CRA)
Settlement Administration Agent (SAA)

Other external parties:

The National Electricity Transmission System Operator (NETSO)
BMRS User

The BMRS shall provide inbound and outbound interfaces as summarised in the following table. Each interface requirement is listed below.

Reqt. No.	Interface Requirement	I/O	Interface User	Mechanism
BMRA-I001	Receive Registration Data	I	CRA	Automatic
BMRA-I002	Receive Balancing Mechanism Data	I	NETSO	Automatic
BMRA-I003	Receive System Related Data	I	NETSO	Automatic
BMRA-I004	Publish Balancing Mechanism Data	O	BMR Service User	Automatic
BMRA-I005	Publish System Related Data	O	BMR Service User	Automatic
BMRA-I006	Publish Derived Data	O	BMR Service User	Automatic
BMRA-I007	SAA/ECVAA Balancing Mechanism Data	O	SAA, ECVAA	Automatic
BMRA-I010	Data Exception Reports	O	NETSO, CRA, BSCCo Ltd, MIDP	Automatic
BMRA-I011	Performance Reports	O	BSCCo Ltd	Manual
BMRA-I012	Receive System Parameters	I	BSCCo Ltd	Manual
BMRA-I013	BMRA BSC Section D Charging Data	O	BSCCo Ltd	Manual
BMRA-I014	Receive Adjustment Data	I	NETSO	Automatic
BMRA-I015	Receive Market Index Data	I	MIDP	Automatic
BMRA-I016	Receive Market Index Data Provider Thresholds	I	BSCCo Ltd	Manual
BMRA-I017	Report Market Index Data Provider Thresholds	O	BSCCo Ltd	Manual
BMRA-I018	Receive Credit Default Notices	I	ECVAA	Automatic
BMRA-I019	Publish Credit Default Notices	O	BMR Service User	Automatic
BMRA-I020	Receive BM Unit Fuel Type List	I	NETSO	Manual
BMRA-I021	Receive Temperature Reference Data	I	NETSO	Manual
BMRA-I022	Receive Daily Energy Volume Reference Data	I	NETSO	Manual
BMRA-I023	Receive Wind Generation Registered Capacities	I	NETSO	Manual
BMRA-I024	Large Combustion Plant Directive Spreadsheet	I	BSCCo Ltd	Manual
BMRA-I025	SO-SO Prices	I	NETSO	Automatic
BMRA-I026	SO-SO Standing Data	I	NETSO	Manual
BMRA-I027	Settlement Report	I	SAA	Automatic
BMRA-I028	REMIT Data	I	BMR Service User NETSO	Automatic
BMRA-I029	Transparency Regulation Data	I	NETSO	Automatic
BMRA-I030	Publish REMIT Data	O	BMR Service User	Automatic
BMRA-I031	Publish Transparency Regulation Data	O	BMR Service User ENTSO-E	Automatic
BMRA-I034	Trading Unit Data	I	SAA	Automatic
BMRA-I035	Publish Trading Unit Data	O	BMR Service User	Automatic
BMRA-I036	Receive Replacement Reserve Data	I	NETSO	Automatic
BMRA-I037	Publish Replacement Reserve Data	O	BMR Service User	Automatic

BMRA-I004, I005, I006, I030 and I031 are outbound interfaces that comprise of the following formats:

screen based (on both high and low grade services);
programmatic (on high grade service);
file download (on both high and low grade services).

6.2 Inbound Interface Requirements

6.3 Outbound Interface Requirements

7 Non-Functional Requirements

Please refer to the document CRA URS for a complete specification of the non-functional requirements which are generic to all NETA central systems.

The generic non-functional requirements include:

GEN-N001: Audit Requirements;
GEN-N002: Security Requirements;
GEN-N003: Operational Control;
GEN-N004: Euro Compliance;
GEN-N005: Help Desk Queries;
GEN N006: Help Desk SLA Reporting.

7.1 BMRA-N001: Security for BMRA Service

Requirement ID: BMRA-N001	Status: Mandatory	Title: Security for BMRA Service	BSC reference: GEN SCH 3.B.4
Man/auto: As required	Frequency: As required.	Volumes: As required
Non Functional Requirement:
1: A secure site shall be provided for the systems required to support the Internet web based access of the BMRA Service. The systems and data shall be protected against unauthorised access and corruption of data. Note: Refer to GEN-N002 for common security requirements
Interfaces:

Issues:

Requirement ID:

BMRA-N001

Status:

Mandatory

Title:

Security for BMRA Service

BSC reference:

GEN SCH 3.B.4

Man/auto:

As required

Frequency:

As required.

Volumes:

As required

Non Functional Requirement:

1: A secure site shall be provided for the systems required to support the Internet web based access of the BMRA Service. The systems and data shall be protected against unauthorised access and corruption of data.

Note: Refer to GEN-N002 for common security requirements

Interfaces:

Issues:

8 Service Requirements

Please refer to the document CRA URS for a complete specification of the service requirements which are generic to all NETA central systems.

The generic service requirements include:

GEN-S001: Volumetric Requirements;
GEN-S003: Backup and Recovery Requirements;
GEN-S004: Archiving Requirements;
GEN-S005: Synchronise System Time;
GEN-S006: Query Resolution

(GEN-S002: Resilience Requirements is superseded by BMRA-S008: Resilience Requirements.)

8.1 BMRA-S001: High Grade BMRA Service Availability

Requirement ID:

BMRA-S001

Status:

Mandatory

Title:

High Grade BMRA Service Availability

BSC reference:

BMRA SD 1.4, 1.5, 1.6, 3.1, 4.2, B5, B6, B7. BMRA SCH 4 Part B section 2.2.3., CP703, P291, P295

Man/auto:

Automatic

Frequency:

See below.

Volumes:

See below.

Non Functional Requirement:

1: The BMRA central system shall receive, store and publish data on the high grade service continually as it is submitted by the NETSO, ECVAA or BMR service users.

2: Published data shall be “pushed” in near to real-time to interested BMR service users over high performance private lines in accordance to service level delivery times.

3: Published data shall be made available to all interested BMR service users at the same time.

4: Published data shall be presented to BMR Service Users as continuous real-time parameterised BM reports/screens, screen trading reports and BM data reports. Published data shall be received by interested BMR service users as a real-time feed and automatically update the relevant screen(s) displaying the data (if it is open). The visual representation of the data (i.e. graph, text) will automatically update to reflect the newly received data values.

5: Published data shall be identifiable at a component level (i.e. bid-offer data) so that BMR service users can select which data component to subscribe and display.

6: Published data shall be available to BMR Service Users:

Forecast data: forecasts relating to future dates and periods will be available
System Warnings: warnings will be available for 7 days from receipt
Credit Default Notices: Level 1 and Level 2 Default Notices will be available as long as the default is in force, or until the associated BSC Party is withdrawn from the BSC. Cleared Notices will be available for 30 days (parameterised) from receipt
REMIT data messaged will be available for a period of 3 years after the calendar day to which it relates
Transparency data data will be available for a period of 5 years after its initial receipt
All other data: data will be available for one year after the Settlement Date to which it relates

7: Drill-down facilities and intuitive on-screen cues shall be used to ensure that all information in the rolling seven day/1 year period can be readily accessed.

8: Published data shall be published on a near real-time message (or programmatic) interface, which may be used for integration with BMR service user proprietary systems.

9: The BMR Service User main screen shall load within 10 seconds (subject to client PC hardware and LAN satisfying minimum specification).

10: If the BMR Service User requests to view a different screen, the requested screen shall display within 1 second of request (subject to client PC hardware satisfying minimum specification).

11: If the BMR Service User requests to subscribe to different data, the requested data shall begin to download within 1 minute of request

12: High grade users will retrieve historical data through the web interface, they shall also have the ability to download BMRA data.

13: Credit Default Notices will be removed from the BMRA Screens when instructed by ELEXON (e.g. when a party is removed from the BSC or when a dispute is upheld). When Credit Default Notices are removed in this way, no explicit message will be sent to BMR Service Users to indicate removal of the notice.

Interfaces:

Issues:

The requirement for pictorial data has been discussed, but a specific requirement has not been agreed. Section 1.4 of the BMRA SD states that short term forecasts may be presented in a graphical or pictorial format. In the absence of an agreed format for pictorial data, short term forecasts shall be presented graphically.

8.2 BMRA-S002: Low Grade BMRA Service Availability

Requirement ID: BMRA-S002	Status: Mandatory	Title: Low Grade BMRA Service Availability	BSC reference: BMRA SD 1.5, 1.6, 3.1, 5.1, CP703, P291, P295
Man/auto: Automatic/ Manual	Frequency: See below.	Volumes: See below.
Non Functional Requirement:
1: Published data shall be made available on a publicly available Internet web site. The availability and performance of this service shall be commensurate with standard Internet web sites.
2 Published data shall be refreshed on the source web page. The BMR Service User shall refresh the screen by manually re-loading the web page.
3: Published data shall be available: Forecast data: forecasts relating to future dates and periods will be available System Warnings: warnings will be available for 7 days from receipt Credit Default Notices: Level 1 and Level 2 Default Notices will be available as long as the default is in force, or until the associated BSC Party is withdrawn from the BSC. Cleared Notices will be available for 30 days (parameterised) from receipt. REMIT data data will be available for a period of 3 years after the calendar day t which it relates Transparency data data will be available for a period of 5 years after its initial receipt All other data: data will be available for one year after the Settlement Date to which it relates All received and derived data shall be downloadable in a standard format (e.g. comma delimited ASCII file)
4: Low grade users will have the ability to download data and retrieve historical data through the web interface.
5: Credit Default Notices will be removed from the BMRA Screens when instructed by ELEXON (e.g. when a party is removed from the BSC or when a dispute is upheld). When Credit Default Notices are removed in this way, no explicit message will be sent to BMR Service Users to indicate removal of the notice.
Interfaces:

Issues:

Requirement ID:

BMRA-S002

Status:

Mandatory

Title:

Low Grade BMRA Service Availability

BSC reference:

BMRA SD 1.5, 1.6, 3.1, 5.1, CP703, P291, P295

Man/auto:

Automatic/ Manual

Frequency:

See below.

Volumes:

See below.

Non Functional Requirement:

1: Published data shall be made available on a publicly available Internet web site. The availability and performance of this service shall be commensurate with standard Internet web sites.

2 Published data shall be refreshed on the source web page. The BMR Service User shall refresh the screen by manually re-loading the web page.

3: Published data shall be available:

Forecast data: forecasts relating to future dates and periods will be available
System Warnings: warnings will be available for 7 days from receipt
Credit Default Notices: Level 1 and Level 2 Default Notices will be available as long as the default is in force, or until the associated BSC Party is withdrawn from the BSC. Cleared Notices will be available for 30 days (parameterised) from receipt.
REMIT data data will be available for a period of 3 years after the calendar day t which it relates
Transparency data data will be available for a period of 5 years after its initial receipt
All other data: data will be available for one year after the Settlement Date to which it relates

All received and derived data shall be downloadable in a standard format (e.g. comma delimited ASCII file)

4: Low grade users will have the ability to download data and retrieve historical data through the web interface.

5: Credit Default Notices will be removed from the BMRA Screens when instructed by ELEXON (e.g. when a party is removed from the BSC or when a dispute is upheld). When Credit Default Notices are removed in this way, no explicit message will be sent to BMR Service Users to indicate removal of the notice.

Interfaces:

Issues:

8.3 BMRA-S003: Data Storage

Requirement ID: BMRA-S003	Status: Mandatory	Title: Data Storage	BSC reference: BMRA SD 4.1, 4.2, 5.1, CP703 P291, P295
Man/auto: Automatic	Frequency: As required.	Volumes: See below.
Non Functional Requirement:
Both the High Grade BMRA Service and the Low Grade BMRA Service shall store all received and derived data on a rolling basis: Forecast data: all forecasts relating to future dates and periods will be stored System Warnings: warnings will be stored for 7 days from receipt Credit Default Notices: Level 1 and Level 2 Default Notices will be stored as long as the default is in force, or until the associated BSC Party is withdrawn from the BSC. Cleared Notices will be stored for 30 days (parameterised) from receipt. REMIT data data will be stored for at least 3 years after the calendar day to which it relates Transparency data data will be stored for at least 5 years after its initial receipt All other data: data will be stored for one year after the Settlement Date to which it relates

Interfaces:

Issues:

Requirement ID:

BMRA-S003

Status:

Mandatory

Title:

Data Storage

BSC reference:

BMRA SD 4.1, 4.2, 5.1, CP703

P291, P295

Man/auto:

Automatic

Frequency:

As required.

Volumes:

See below.

Non Functional Requirement:

Both the High Grade BMRA Service and the Low Grade BMRA Service shall store all received and derived data on a rolling basis:

Forecast data: all forecasts relating to future dates and periods will be stored
System Warnings: warnings will be stored for 7 days from receipt
Credit Default Notices: Level 1 and Level 2 Default Notices will be stored as long as the default is in force, or until the associated BSC Party is withdrawn from the BSC. Cleared Notices will be stored for 30 days (parameterised) from receipt.
REMIT data data will be stored for at least 3 years after the calendar day to which it relates
Transparency data data will be stored for at least 5 years after its initial receipt
All other data: data will be stored for one year after the Settlement Date to which it relates

Interfaces:

Issues:

8.4 BMRA-S005: Data Access and Display

Requirement ID: BMRA-S005	Status: Mandatory	Title: Data Access and Display	BSC reference: BMRA SD 5.2, CP589 part 2 P295
Man/auto: Automatic	Frequency: As required.	Volumes: As required
Non Functional Requirement:
1: BMR service software shall be used to provide selective data reports, through on-line screens, to enable BMR Service Users to select, display and download a range of Balancing Mechanism information. Historic access to BM Unit related data shall allow BMR Service Users to retrieve Settlement Period related data relating to multiple BM Units in a single query. A single Settlement Period’s data shall be provided for up to 50 BM Units or up to a whole Settlement Day’s data may be provided for a single BM Unit.
2: The BMRA shall provide an authenticated access facility to allow BMR Service Users to submit REMIT data, ensuring that only users with appropriate permissions are able to do so.
3: BMR Service software shall make use of the most appropriate format, i.e. text, graphical or pictorial, for display of data. (See appendix C for more information.)
Interfaces:

Issues:

Requirement ID:

BMRA-S005

Status:

Mandatory

Title:

Data Access and Display

BSC reference:

BMRA SD 5.2, CP589 part 2

P295

Man/auto:

Automatic

Frequency:

As required.

Volumes:

As required

Non Functional Requirement:

1: BMR service software shall be used to provide selective data reports, through on-line screens, to enable BMR Service Users to select, display and download a range of Balancing Mechanism information. Historic access to BM Unit related data shall allow BMR Service Users to retrieve Settlement Period related data relating to multiple BM Units in a single query. A single Settlement Period’s data shall be provided for up to 50 BM Units or up to a whole Settlement Day’s data may be provided for a single BM Unit.

2: The BMRA shall provide an authenticated access facility to allow BMR Service Users to submit REMIT data, ensuring that only users with appropriate permissions are able to do so.

3: BMR Service software shall make use of the most appropriate format, i.e. text, graphical or pictorial, for display of data. (See appendix C for more information.)

Interfaces:

Issues:

8.5 BMRA-S006: Volumetric Requirements

Requirement ID:

BMRA-S006

Status:

Mandatory

Title:

Volumetric Requirements

BSC reference:

RETA BSC A3

Man/auto:

Manual & Automatic

Frequency:

As required

Volumes:

As below.

Non Functional Requirement:

The BMRA shall be sized in accordance with the following volumetric requirements. Required traffic volumes are unknown at present; these will be agreed when the current performance modelling work is completed.

	Volumes
	Low	Average	High
BSC Service Users*	100	200	300
Other users*	50	100	150
Connections (1.5 x BSC Service Users)*	225	450	675

*Concurrent users/connections supported

Interfaces:

Issues:

8.6 BMRA-S007: Resilience Requirements

Requirement ID:

BMRA-S007

Status:

Mandatory

Title:

Resilience Requirements

BSC reference:

BMRA SD B1

Man/auto:

Automatic

Frequency:

As required

Volumes:

As below.

Non Functional Requirement:

1: The BMRA central system shall provide a continuous unmanned 24x7 service, to enable support of the high grade BMRA service’s near real-time reporting requirements. All software components of the high grade BMRA service shall run on a very high availability and resilient dual processor architecture which support an automatic fail over capability if either processor node was to fail.

The very high availability architecture shall support no single point of failure, with transparent fail-over of applications, storage and files.

2: The health of all application processes (in the high grade BMRA service) and system resources shall be continuously monitored. On detection of error, a pre-determined set of actions shall be performed. Examples of actions taken can include restarting a failed process and warning of critical resource shortages (disk, memory, CPU).

3: The continuous receipt of inbound data from the NETSO must not be lost or duplicated in the event of a failure.

Interfaces:

Issues:

9 User Roles and Activities

Please refer to the document CRA URS for description of the user roles which will support the day to day operation of the NETA central system services.

10 Future Enhancements

The BMRA shall be designed with a requirement to be flexible and accommodate change to specification with the minimum impact to program code re-work. Future enhancements may include:

significant changes to display charts and graphs, according to the requirements of BMR service users.

Appendix A Glossary

Please refer to the document CRA URS for a complete reference of the NETA glossary of acronyms.

Appendix B Requirement Summary Matrix

The following table shows the mapping of requirements defined in this URS document to the requirements set out in the Service Description for Balancing Mechanism Reporting [BMRA SD].

Service Description Requirement Number or CR number	URS Requirement Reference Number	Notes
1.1 - 1.3		Overview sections, therefore no mapping of requirements
1.4	BMRA-S001
1.5	BMRA-S001
1.6	BMRA-S001 BMRA-S002
1.7	GEN-S007
2		Overview section, therefore no mapping of requirements
3.1	BMRA-I002 BMRA-S001 BMRA-S002
4.1	BMRA-S003
4.2	BMRA-S001 BMRA-S003
5.1	BMRA-S002 BMRA-S003
5.2	BMRA-S005
6.1	BMRA-I001
6.2	BMRA-I010
7.1	BMRA-I003 BMRA-I005 BMRA-I010
7.2	BMRA-I014
7.3	BMRA-I012
7.4	BMRA-I004
7.5	BMRA-I002
7.6	BMRA-I002
8.1	BMRA-I012
8.2	BMRA-I012
8.3	BMRA-I012
8.4	BMRA-I012
9.1	BMRA-I006
9.2	BMRA-F001
9.3	BMRA-F001
9.4	BMRA-F001
9.5	BMRA-F001
9.6	BMRA-F001
9.7	BMRA-F001
9.8	BMRA-F001 BMRA-F002 BMRA-F003 BMRA-F004
9.9	BMRA-F004
9.10	BMRA-F001
9.11	BMRA-F001
9.12	BMRA-F001
9.13	BMRA-F004
9.14	BMRA-F001
9.15	BMRA-F001
9.16	BMRA-F001
9.17	BMRA-F002
9.18	BMRA-F004
9.19	BMRA-F004
9.20	BMRA-F004
9.21	BMRA-F004
10.1	GEN-S005
B1	BMRA-S007
B2	BMRA-I001
B3	BMRA-I003
B4	BMRA-I002
B5	BMRA-S001
B6	BMRA-S001
B7	BMRA-S001
B8-15	GEN-N005 GEN-N006
CR 65	BMRA-I013
P8	BMRA-I005
P18A	BMRA-I006
P71	BMRA-I002 BMRA-I004 BMRA-I007
P78	BMRA-F004 BMRA-F004a BMRA-F004b BMRA-F006 BMRA-F007 BMRA-F008 BMRA-F009 BMRA-I001 BMRA-I005 BMRA-I006 BMRA-I010 BMRA-I011 BMRA-I014 BMRA-I015 BMRA-I016 BMRA-I017
CP703	BMRA-I018 BMRA-I019 BMRA-S001 BMRA-S002 BMRA-S003
CP736	BMRA-I006 BMRA-I011
CP975	BMRA-I001
P219	BMRA-I003 BMRA-I005
P220	BMRA-I003 BMRA-I005
P226	BMRA-I024
P243	BMRA-I003 BMRA-I005
CP1333	BMRA-F011 BMRA-I025 BMRA-I026
P291	BMRA-I028 BMRA-I030 BMRA-S001 BMRA-S002 BMRA-S003
P295	BMRA-F010 BMRA-I029 BMRA-I031 BMRA-S001 BMRA-S002 BMRS-S003
P321	BMRA-I034 BMRA-I035	Trading Unit Data Publish Trading Unit Data
P344	BMRA-I036 BMRA-I037	Replacement Reserve Data Publish Replacement Reserve Data

Appendix C BMRA external data flow timings and formats

C.1 NETSO System Related Data (BMRA-I003 and BMRA-I005 (partial))

DATA ITEM	[NGC IS] Reference and Flow Acronym	BSC Section Q Ref	TIMING (when issued by NETSO)	COVERAGE	FORMAT
2-14 days ahead (TSDFD) Transmission System demand forecast	5.1.3 TSDFD	6.1.3	By 1500hrs each day	Data for D+2 to D+14	Tabular and graphic (½ hour average MW value for the peak of the day)
2-14 days ahead (NDFD) National demand forecast	5.1.2 NDFD	6.1.3	By 1500hrs each day	Data for D+2 to D+14	Tabular and graphic (½ hour average MW value for the peak of the day)
2-52 weeks ahead (TSDFW) Transmission System demand forecast	5.1.3 TSDFW	6.1.2(b)	By 1500hrs each Thursday	Data for Week+2 to Week+52	Tabular and graphic (½ hour average MW value for the peak of the week)
2-52 weeks ahead (NDFW) National demand forecast	5.1.2 NDFW	6.1.2(a)	By 1500hrs each Thursday	Data for Week+2 to Week+52	Tabular and graphic (½ hour average MW value for the peak of the week)
2-14 days ahead (SPLD) National surplus forecast	5.1.1 OCNMFD	6.1.4	By 1600hrs each day	Data for D+2 to D+14	Tabular and graphic (½ hour average MW value for the peak of the day)
2-52 weeks ahead (SPLW) National surplus forecast	5.1.1 OCNMFW	6.1.2A(c)	By 1600hrs each day	Data for Week+2 to Week+52	Tabular and graphic (½ hour average MW value for the peak of the week)
2-156 weeks ahead (SPLY) National surplus forecast	5.1.1 OCNMF3Y	6.1.4B(d)	By 1600hrs each day	Data for Week+2 to Week+156	Tabular (½ hour average MW value for the peak of the week)
2-14 days ahead National Generating Plant Demand Margin	16.2.1 OCNMFD2	6.1.4(e)	By 1600hrs each day	Data for D+2 to D+14	Tabular and graphic (½ hour average MW value for the peak of the day)
2-52 weeks ahead National Generating Plant Demand Margin	16.2.1 OCNMFW2	6.1.2A(e)	By 1600hrs each day	Data for Week+2 to Week+52	Tabular and graphic (½ hour average MW value for the peak of the week)
2-156 weeks ahead National Generating Plant Demand Margin	16.2.1 OCNMF3Y2	6.1.4B(e)	By 1600hrs each day	Data for Week+2 to Week+156	Tabular (½ hour average MW value for the peak of the week)
Output Usable Data	National 16.1.2 NOU2T14D 6.1.4(a) NOU2T52W 6.1.2 (a) NOU2T3YW 6.1.4B(a)		By 1600hrs each day Data for D+2 to D+14 By 1600hrs each day Data for Week+2 to Week+52 By 1600hrs each day Data for Week+2 to Week+156		Download (½ hour average MW value for the peak of the day)

	By Fuel Type 16.1.3 FOU2T14D 6.1.4A(b) FOU2T52W 6.1.2A(b) FOU2T3YW 6.1.4B(b)		By 1600hrs each day Data for D+2 to D+14 By 1600hrs each day Data for Week+2 to Week+52 By 1600hrs each day Data for Week+2 to Week+156		Graphic and download (½ hour average MW value for the peak of the day)
	By Fuel Type and BM Unit 16.1.4 UOU2T14D 6.1.4A(c) UOU2T52W 6.1.2A(c) UOU2T3YW 6.1.2A(c)		By 1600hrs each day Data for D+2 to D+14 By 1600hrs each day Data for Week+2 to Week+52 By 1600hrs each day Data for Week+2 to Week+156		Download (½ hour average MW value for the peak of the day)

Initial Day ahead National demand forecast (NDF)	5.2 NDF	6.1.5(a)	By 0900hrs each day	Data for the following Operational Day (D+1)	Tabular and graphic (½ hour average MW values).
Initial Day ahead transmission system demand forecast (TSDF)	5.2 TSDF	6.1.5(b)	By 0900hrs each day	Data for the following Operational Day (D+1)	Tabular and graphic (½ hour average MW values).

Initial Day ahead Zonal transmission system demand forecast (TSDF)	5.2 TSDF	6.1.5(c)	By 0900hrs each day	Data for the following Operational Day (D+1)	Tabular, graphic and pictorial (½ hour average MW values).
Initial National Day ahead Indicated Margin (MELNGC)	5.3 MELNGC	6.1.6(a)	By 1200hrs each day	Data for the following Operational Day (D+1)	Tabular or graphic (½ hour average MW values).
Initial National Day ahead Indicated Imbalance (IMBALNGC)	5.3 IMBALNGC	6.1.6(b)	By 1200hrs each day	Data for the following Operational Day (D+1)	Tabular or graphic (½ hour average MW values).
Initial National Day ahead Indicated Generation (INDGEN)	5.3 INDGEN	6.1.6(c)	By 1200hrs each day.	Data for the following Operational Day (D+1)	Tabular or graphic (½ hour average MW values).
Initial National Day ahead Indicated Demand (INDDEM)	5.3 INDDEM	6.1.6(d)	By 1200hrs each day.	Data for the following Operational Day (D+1)	Tabular or graphic (½ hour average MW values).
Updated Day ahead National demand forecast (NDF)	5.3.1 NDF	6.1.6(e)	By 1200hrs each day	Data for the following Operational Day (D+1)	Tabular or graphic (½ hour average MW values).
Updated NETSO Transmission System Demand Forecast (TSDF)	5.3.1 TSDF	6.1.6(f)	By 1200hrs each day	Data for the following Operational Day (D+1)	Tabular or graphic (½ hour average MW values).

Current Day and Day Ahead Updated Market Information (MELNGC, IMBALNGC, INDGEN, INDDEM, NDF and TSDF)	National 5.3.1 NDF 6.1.8(a) MELNGC 6.1.8(b) IMBALNGC 6.1.8(c) INDDEM 6.1.8(d) INDGEN 6.1.8(e) TSDF 6.1.8(k)		By 0200hrs Data for 0200D to 0500D+1 By 1000hrs Data for 1000D to 0500D+1 By 1600hrs Data for 0500D+1 to 0500D+2 By 1630hrs Data for 1630D to 0500D+1 By 2200hrs Data for 2200D to 0500D+2		Tabular, graphic and pictorial (½ hour average MW values).
Current Day and Day Ahead Updated Market Information (MELNGC, IMBALNGC, INDGEN, INDDEM and TSDF)	Zonal 5.3.2 TSDF 6.1.8(f) MELNGC 6.1.8(g) IMBALNGC 6.1.8(h) INDDEM 6.1.8(i) INDGEN 6.1.8(j)		By 0200hrs Data for 0200D to 0500D+1 By 1000hrs Data for 1000D to 0500D+1 By 1600hrs Data for 0500D+1 to 0500D+2 By 1630hrs Data for 1630D to 0500D+1 By 2200hrs Data for 2200D to 0500D+2		Tabular, graphic and pictorial (½ hour average MW values).
Initial National Demand Out-turn (INDO)	7.0 INDO	6.1.13	Within 15 minutes of the end of the settlement period	Data for previous Settlement Period	Tabular and graphic
Initial Transmission System Demand Out-turn (ITSDO)	7.0 ITSDO	6.1.13	Within 15 minutes of the end of the settlement period	Data for previous Settlement Period	Tabular and graphic
System warnings (SYS_WARN)	SYSWARN	n/a	Within 15 minutes of issue to MCUSA signatories	n/a	Textual
SO-SO Prices	SOSO	n/a	By 15 minutes before the start of each hour	Data for next hour	Tabular
Temperature (TEMP)	14.0 TEMP	6.1.15	By 1700hrs each day	Data for the previous Operational Day (D-1)	Tabular and graphic
Reference Temperature (REFTEMP)	N/A	6.1.16	By 1700hrs each day	Data for the previous Operational Day (D-1)	Tabular and graphic
Wind Generation Forecast (WINDFOR)	15 WINDFOR	6.1.17	By 1700hrs each day	Data for D to D+2	Tabular and graphic
Instantaneous Generation by Fuel Type (FUELINST)	12 FUELINST	6.1.18	Every 5 minutes	Data for previous 5 minutes	Tabular and graphic
Half Hourly Generation by Fuel Type (FUELHH)	12.FUELHH	6.1.19	Within 15 minutes of the end of the settlement period	Data for previous Settlement Period	Tabular and graphic
Non-BM STOR (NONBM)	16 NONBM	6.1.22	Within 15 minutes of the end of the settlement period	Data for previous Settlement Period	Tabular and graphic
System Frequency (FREQ)	13 FREQ	6.1.23	Every 2 minutes	Data for previous 2 minutes	Tabular and graphic
Initial National Demand Out-Turn Daily (INDOD)	7 INDOD	6.1.21	By 1700hrs each day	Data for the previous Operational Day (D-1)	Tabular and graphic
Reference Initial National Demand Out-Turn Daily (REFINDOD)	N/A	6.1.21	By 1700hrs each day	Data for the previous Operational Day (D-1)	Tabular and graphic

Notes: All forecast data is sourced from the NETSO.

In the event that a forecast update is not received from the NETSO, the BMRA shall display the most recent forecast value for that time.

If an initial forecast is not received from the NETSO, the BMRA shall display nothing.

All data is published within 5 minutes of receipt by BMRA

Where data is scheduled to be issued on a Friday and this is a non-working day, it will be published on the Thursday instead

C.2 BM Data (BMRA-I002, BMRA-I014, BMRA-I004 and BMRA-I005 (partial))

DATA ITEM	SOURCE	FORMAT	DEFAULT	COMMENTS
FPN per BM Unit (PN, QPN)	NETSO (Grid Code)	Tabular and graphic.	None
Bids and Offers per BM Unit (BOD)	NETSO (Grid Code)	Tabular.	None	Prices and volumes to be displayed
Total Bid Volume	BMRA	Tabular and graphic.	None	Calculated from BOD data.
Total Offer Volume	BMRA	Tabular and graphic.	None	Calculated from BOD data.
Dynamics per BM Unit (MEL, MIL, RURE, RURI, RDRE, RDRI, NDZ, NTO, NTB, MZT, MNZT, SEL, SIL, MDV, MDP)	NETSO (Grid Code)	Tabular.	Previously submitted dynamics
Acceptances per BM Unit (BOAL)	NETSO (Grid Code)	Tabular and graphic.	None	Replacement Reserve RR Instruction data and Balancing Mechanism.
Balancing Services Adjustment Data (BSAD): ESCA ESVA SSVA SPA EBCA EBVA SBVA BPA	NETSO	Tabular	None	Include BSAD as used in derivation of estimated SSP and SBP (published alongside derived estimated SSP/SBP) Also list of most recent version of BSAD data.
Disaggregated Balancing Services Adjustment Data (DBSAD)	NETSO	Tabular	None

Notes: All BM data is sourced from the NETSO.

All data is published within 5 minutes of receipt by BMRA and retained for 12 months.

Total Bid/Offer volumes are computed when Bid-Offer data is processed

C.3 BMRA Derived Data (BMRA-I005 (partial) and BMRA-I006)

DATA ITEM	SOURCE	FORMAT	DEFAULT	COMMENTS
Estimated System Buy Price (SBP_j)	BMRA	Tabular and graphic	None	Derived within BMRA for initial numbers.
Estimated System Sell Price (SSP_j)	BMRA	Tabular and graphic	None	Derived within BMRA for initial numbers.
Period BM Unit Total Accepted Bid and Offer Volumes (QABⁿ_ij and QAOⁿ_ij)	BMRA	Tabular	None	Derived within BMRA for initial numbers.
Total Accepted Bid Volume	BMRA	Tabular and graphic	None	Derived within BMRA for initial numbers.
Total Accepted Offer Volume	BMRA	Tabular and graphic	None	Derived within BMRA for initial numbers.
Estimated Period Balancing Mechanism Bid and Offer Cashflows (CBⁿ_ijand COⁿ_ij)	BMRA	Tabular	None	Derived within BMRA for initial numbers.
Total Unpriced Accepted Bid Volume	BMRA	Tabular and graphic	None	Derived within BMRA for initial numbers.
Total Unpriced Accepted Offer Volume	BMRA	Tabular and graphic	None	Derived within BMRA for initial numbers.
Total Priced Accepted Bid Volume	BMRA	Tabular and graphic	None	Derived within BMRA for initial numbers.
Total Priced Accepted Offer Volume	BMRA	Tabular and graphic	None	Derived within BMRA for initial numbers.
Indicative System Price Stacks	BMRA	Tabular and graphic	None	Derived within BMRA for initial numbers.
System messages	BMRA	Textual	None	Reports missing Market Index Data

Notes: All data is published within <CADL> + 15 (parameterised) minutes of the end of relevant ½ hour and retained for 12 months.

C.4 Market Index Data (BMRA-I005 (partial))

DATA ITEM	SOURCE	TIMING	FORMAT	DEFAULT	COMMENTS
Market Index Data	MIDP	Within 15 minutes of end of related Settlement Period, or within 15 minutes of receipt, whichever is later.	Tabular	None	Data arriving after the related calculation has begun will be rejected, and therefore not published.

C.5 Credit Default Notices (BMRA-I019)

DATA ITEM	SOURCE	TIMING	FORMAT	DEFAULT	COMMENTS
Credit Default Notices	ECVAA	Within 5 minutes of receipt, then 2 (parameterised) additional times at 20 minute (parameterised) intervals	Tabular	None	Level 1 and Level 2 notices displayed continuously while BSC Party is still effective. Cleared notices displayed for 30 (parameterised) days.

C.6 REMIT Data (BMRA-I028)

REMIT Data may be received from either the NETSO or from BMR Service Users via the ELEXON Portal.

DATA ITEM	TIMING	FORMAT	DEFAULT	COMMENTS
REMIT Data	Within 5 minutes of receipt,	Tabular	None

C.7 Transparency Regulation Data (BMRA-I029)

Transparency Regulation Data is sourced from the NETSO or generated by BMRA and is provided in a tabular format along with options to download the information. All data is published within 5 minutes of receipt or generation by BMRA. Where data related to outages is duplicated, it is published under REMIT Data (BMRA-I028) only.

DATA ITEM	ARTICLE REF	TIMING	COVERAGE
Actual Total Load per Bidding Zone	6.1.(a)	No later than one hour after the Settlement Period	Data per Settlement Period over the previous day
Day Ahead Total Load per Biding Zone	6.1.(b)	Two hours after gate closure	Data per Settlement Period over the day ahead
Week Ahead Total Load Forecast per Bidding Zone	6.1.(c)	Each Friday, two hours before gate closure	Data per day for the week ahead
Month Ahead Total Load Forecast per Bidding Zone	6.1.(d)	One week before the delivery month	Data per week for the month ahead
Year Ahead Total Load Forecast per Bidding Zone	6.1.(e)	15^th day of the month before year to which the data refers to	Data per month for the year ahead


Year Ahead Forecast Margin	8.1	15^th day of the month before year to which the data refers to	Data for the year ahead





Costs of Congestion Management	13 (c)	Before the last working day of the following month	Details of cost incurred in a given month
Installed Generation Capacity Aggregated (>1MW)	14.1.(a)	One week before the beginning of the forecast year	Data for the next year
Installed Generation Capacity per Unit (>100MW)	14.1.(b)	One week before the beginning of the first forecast year	Data for the next 3 years
Day-Ahead Aggregated Generation	14.1.(c)	By 18:00 hours (Brussels time, UTC+01:00), one day before actual delivery	Data per Settlement Period for the day ahead
Day-Ahead Generation Forecasts for Wind and Solar (MWh)	14.1.(d)	18:00 hours (Brussels time, UTC+01:00), one day before actual delivery	Data per Settlement Period for the day ahead




Actual Generation Output Per Generation Unit	16.1.(a)	Five days after the Settlement Period	Data per Settlement Period
Aggregated Generation per Type (units >100MW installed capacity)	16.1.(b)	No later than one hour after the Settlement Period	Data for the previous Settlement Period
Actual or Estimated Wind and Solar Power Generation	16.1.(c)	No later than one hour after the operational period	Data for the previous Settlement Period

Amount of Balancing Reserves under Contract	17.1.(b)	Two hours before the next procurement	Coverage dependent on by contract type (yearly monthly, etc.)
Prices of Procured Balancing Reserves	17.1.(c)	No later than one hour after the procurement process ends	Coverage dependent on by contract type (yearly monthly, etc.)





Financial Expenses And Income For Balancing	17.1.(i)	No later than three months after the operating month	Data for the previous month

C.8 Trading Unit Data (BMRA-I034)

Trading Unit Data will be received from SAA following the completion of each Settlement Run.

DATA ITEM

TIMING

FORMAT

DEFAULT

COMMENTS

Trading Unit Data

Within 5 minutes of receipt

Tabular

None

Sent by the SAA as the SAA-I049

Published on BMRS as the BMRA-I035

C.9 Replacement Reserve Data (BMRA-I036)

Replacement Reserve Data will be received from NETSO following the completion of each Settlement Run.

DATA ITEM	TIMING	FORMAT	DEFAULT	COMMENTS
RR Bids	Within 5 minutes of receipt	Tabular	None	This data is shared with SAA upon receipt
RR Auction results: RR Activations	Within 5 minutes of receipt	Tabular	None	This data is shared with SAA upon receipt
RR Auction results: Volume of GB Need Met	Within 5 minutes of receipt	Tabular	None	This data is shared with SAA upon receipt
RR Auction results: Interconnector Schedule Data	Within 5 minutes of receipt	Tabular	None	This data is shared with SAA upon receipt

C.10 Settlement Exchange Rate

Replacement Reserve Data will be manually uploaded

DATA ITEM	TIMING	FORMAT	DEFAULT	COMMENTS
Settlement Exchange Rate	Published by 16.00	Tabular	Exchange rate for previous Settlement day

Appendix D BMRA forecast data time-line

Appendix E BMRA settlement period time-line

Appendix F Logical Data Model

The following logical data model diagram is for indicative purposes only.

Appendix G Price Derivation Code Definitions

The possible values of the Price Derivation Code are defined in the table below. The description gives a brief summary of what the code represents, and the condition detail defines the relevant conditions that cause this related code to be true. Refer to the description of how the Indicative System Buy Price and Indicative System Sell Price are calculated for further understanding of what these conditions mean.

For Settlement Dates prior to the P217 effective date:

Code	Description	Condition Detail
A	SBP = Main price; SSP = Reverse Price	NIV is positive ΣQXP is non zero SBP = NIV; SSP = PXP; QAPO + UEBVA is not zero; SSP is not greater than SBP
B	SSP Capped to SBP	NIV is positive ΣQXP is non zero SBP = NIV; SSP = NIV; QAPO + UEBVA is not zero; SSP is greater than SBP
C	SSP Defaulted to SBP	NIV is positive ΣQXP is zero SBP = NIV; SSP = NIV; QAPO + UEBVA is not zero
D	SBP & SSP Defaulted to Market Price	NIV is positive ΣQXP is non zero SBP = PXP; SSP = PXP; QAPO + UEBVA is zero
E	SSP & SBP Defaulted to Zero	NIV is positive ΣQXP is zero SBP = 0; SSP = 0; QAPO + UEBVA is zero
F	SSP = Main Price; SBP = Reverse Price	NIV is negative ΣQXP is non zero SBP = PXP; SSP = NIV; QAPB + UESVA is not zero; SSP is not greater than SBP
G	SBP Capped to SSP	NIV is negative ΣQXP is non zero SBP = NIV; SSP = NIV; QAPB + UESVA is not zero; SSP is greater than SBP
H	SBP Defaulted to SSP	NIV is negative ΣQXP is zero SBP = NIV; SSP = NIV; QAPB + UESVA is not zero
I	SBP & SSP Defaulted to Market Price	NIV is negative ΣQXP is non zero SBP = PXP; SSP = PXP; QAPB + UESVA is zero
J	SSP & SBP Defaulted to Zero	NIV is negative ΣQXP is zero SBP = 0; SSP = 0; QAPB + UESVA is zero
K	SSP & SBP Defaulted to Market Price	NIV is zero ΣQXP is non zero SBP = PXP; SSP = PXP;
L	SSP & SBP Defaulted to Zero	NIV is zero ΣQXP is zero SBP = 0; SSP = 0;

For Settlement Dates on or after the P217 effective date (note: Price Derivation Codes D, E, I, and J are not applicable for P217 effective dates):

Code	Description	Condition Detail
A	SBP = Main price; SSP = Reverse Price	NIV is positive ΣQXP is non zero SBP = NIV; SSP = PXP; SSP is not greater than SBP
B	SSP Capped to SBP	NIV is positive ΣQXP is non zero SBP = NIV; SSP = NIV; SSP is greater than SBP
C	SSP Defaulted to SBP	NIV is positive ΣQXP is zero SBP = NIV; SSP = NIV;
F	SSP = Main Price; SBP = Reverse Price	NIV is negative ΣQXP is non zero SBP = PXP; SSP = NIV; SSP is not greater than SBP
G	SBP Capped to SSP	NIV is negative ΣQXP is non zero SBP = NIV; SSP = NIV; SSP is greater than SBP
H	SBP Defaulted to SSP	NIV is negative ΣQXP is zero SBP = NIV; SSP = NIV;
K	SSP & SBP Defaulted to Market Price	NIV is zero ΣQXP is non zero SBP = PXP; SSP = PXP;
L	SSP & SBP Defaulted to Zero	NIV is zero ΣQXP is zero SBP = 0; SSP = 0;

For Settlement Dates on or after the P305 effective date:

Code	Description	Condition Detail
K	SSP & SBP Defaulted to Market Price	NIV is zero ΣQXP is non zero SBP = PXP; SSP = PXP;
L	SSP & SBP Defaulted to Zero	NIV is zero ΣQXP is zero SBP = 0; SSP = 0;
N	SSP Defaulted to Main Price; SBP = SSP	NIV is negative
P	SBP Defaulted to Main Price; SSP = SBP	NIV is positive

CONTENTS

Balancing Mechanism Reporting Agent

1 Introduction

1.1 Purpose

1.2 References

2 Management Summary

3 Scope of Specification

4 Business and System Overview

4.1 Summary of Business Requirements

4.2 Service Context

4.3 Numbering Scheme for Requirement Definitions

4.4 Attributes of Individual Requirements

5 Functional Requirements

5.1 BMRA-F001: Calculate Balancing Mechanism and Replacement Reserve Volumes

5.2 BMRA-F002: Calculate Indicative Period BM and RR Unit Total Accepted Bid and Offer Volume

5.3 BMRA-F003: Calculate Estimated Period Balancing Mechanism and Replacement Reserve Bid and Offer Cashflows

5.4 Not Used

5.4.1 Not Used

5.4.2 BMRA-F004b: Calculate Estimated System Buy and Sell Prices using the P217 methodology

5.5 BMRA-F005: Postponement of Calculations

5.6 BMRA-F006: Validate Market Index Data

5.7 BMRA-F007: Generate Missing Market Index Data Messages

5.8 BMRA-F008: Process Market Index Data Provider Liquidity Thresholds

5.9 BMRA-F009: Validate Adjustment Data

5.10 BMRA-F011: Process SO-SO Trades

5.11 BMRA-F012: Process Settlement Exchange Rate

6 External interfaces

6.1 Overview

6.2 Inbound Interface Requirements

6.3 Outbound Interface Requirements

7 Non-Functional Requirements

7.1 BMRA-N001: Security for BMRA Service

8 Service Requirements

8.1 BMRA-S001: High Grade BMRA Service Availability

8.2 BMRA-S002: Low Grade BMRA Service Availability

8.3 BMRA-S003: Data Storage

8.4 BMRA-S005: Data Access and Display

8.5 BMRA-S006: Volumetric Requirements

8.6 BMRA-S007: Resilience Requirements

9 User Roles and Activities

10 Future Enhancements

Appendix A Glossary

Appendix B Requirement Summary Matrix

Appendix C BMRA external data flow timings and formats

Appendix D BMRA forecast data time-line

Appendix E BMRA settlement period time-line

Appendix F Logical Data Model

Appendix G Price Derivation Code Definitions