Balancing and Settlement Code
Code Subsidiary Documents Architectural Principles
Code Subsidiary Documents Architectural Principles
1. Reference is made to the Balancing and Settlement Code as given contractual force by the BSC Framework Agreement dated Code Effective Date and as modified from time to time (the Code). In particular reference is made to the definitions in Section X, Annex X-1.
2. This is the Code Subsidiary Documents Architectural Principles Document, Version 8.0 relating to the architecture of the Code Subsidiary Document set.
3. This document is effective from01 October 2024.
4. This document has been approved by the BSC Panel.
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. |
Version | Date | Description of Change | Panel Reference |
1.0 | 23/8/05 | | |
2.0 | 28/11/05 | For Consultation | |
2.2 | 08/06/06 | For Panel Approval | 115/08 |
3.0 | 02/11/06 | For Publication as part of the BSC Baseline | |
4.0 | 23/08/07 | P197 Release | 115/04 |
5.0 | 18/03/10 | CP1322 | 166/12 |
6.0 | 29/03/19 29/03/19 | 29 March 2019 Standalone Release – P369 29 March 2019 Standalone Release – CP1511 | Panel 285/12 Panel 285/10 |
7.0 | 01/09/21 | 1 September 2021 Non-Standard Release – P420 | Panel 316/05 |
8.0 | 01/10/24 | 01 October 2024 Non-Standard Release | Directed by Secretary of State |
1.1.1 This document sets out the principles that underpin the architecture of the Code Subsidiary Document (CSD) set. It sets out general principles concerning the contents of the CSDs along with more detailed guidance on the contents of each type of document. It also captures the principles governing the change to existing and the creation of new CSDs.
1.1.2 All future changes to the CSD suite should be undertaken in a manner consistent with this Architectural Principles Document.
1.2 Changes to this Document
1.2.1 This document is defined as a Category 2 BSC Configurable Item in BSCP40 (see section 2.2 of this document) which is owned and managed by the BSC Panel. Whilst individual Parties or Panel Committees may recommend a change to this document through a Change Proposal, changes to this document may only be made with the Panel’s approval.
1.3 Coverage of Code Subsidiary Documents
1.3.1 The constituent CSDs are defined in Section H1 of the Balancing and Settlement Code (BSC). They comprise:
(c) BSC Service Descriptions;
(d) The Party Service Line;
(f) The Communication Requirements Document;
(g) The Reporting Catalogue; and
(h) The Load Flow Model (LFM) Specification.
1.3.2 An up-to-date list of the CSDs, indicating the version number of the then in force version together with the date when it became effective is maintained by BSCCo. This is published as part of the BSC Baseline Statement.
1.4 Modification and Creation of Code Subsidiary Documents
1.4.1 Existing CSDs may be modified and new CSDs created in accordance with Section F3 of the BSC.
1.4.2 Such changes may only be made if and to the extent that the modified or new CSD:
(a) Is consistent with, and does not impair, or frustrate or invalidate, the provisions of the BSC; and
(b) does not impose new obligations or restrictions of a material nature on Parties or Party Agents (or classes thereof) which are not authorised or envisaged by, or subsidiary to, the rights and obligations of Parties under, the BSC.
Where a Panel Committee considers that an obligation should be included within a CSD that is not reflective of an obligation within the BSC then the express approval of the BSC Panel shall be sought (which may necessitate raising a supporting Modification Proposal to the BSC).
1.4.3 When considering a proposed change to the CSD suite, the Panel or relevant Panel Committee shall additionally ensure that the BSC and CSDs together continue to facilitate the achievement of the Applicable BSC Objective(s) as defined in the ESO Licence.
1.4.4 In particular where additional prescription is added to a CSD then the net effect of the revised suite of CSDs and BSC must be to better facilitate the Applicable BSC Objectives. Where this test is not achieved then the change should not be progressed.
1.4.5 Section F3 of the BSC requires that, prior to agreeing a change the following activities shall be undertaken:
(a) consultation shall take place with Parties and interested third parties in a manner appropriate to the complexity, importance and urgency of the proposed change;
(b) regard shall be given to any representations made during such consultation;
(c) the proposed draft changes shall be copied to each Party and otherwise published in such a manner as seen fit; and
(d) Parties and interested third parties shall be given a reasonable opportunity to comment on proposed changes, having regard to the urgency of the matter.
1.4.6 Detailed procedures relating to the processing of changes to the existing CSDs and the creation of new CSDs are set out in BSCP40.
1.4.7 The Panel has delegated its powers, functions and responsibilities to approve changes to most CSDs to identified Panel Committees. The Baseline Statement records which Panel Committee discharges this for each CSD.
1.5.1 Other acronyms and defined terms take the meanings defined in the Balancing and Settlement Code (the Code), Section X.
Acronym / Term | Definition |
BSC | The Balancing and Settlement Code |
The Code | The Balancing and Settlement Code |
BSCP | Balancing and Settlement Code Procedure |
CoP | Code of Practice |
CSD | Code Subsidiary Document |
CVA | Central Volume Allocation |
EMDS | Energy Market Data Specification |
FAA | Funds Administration Agent |
IDD | Interface Definition & Design |
LFM | Load Flow Model |
NETA | New Electricity Trading Arrangements |
PSL | Party Service Line |
REC | Retail Energy Code |
SAA | Settlement Administration Agent |
TAA | Technical Assurance Agent |
2. General Structure of CSDs
2.1 General Principles regarding Style and Content
2.1.1 The following principles should be adopted when modifying an existing CSD or drafting a new CSD:
(a) Whilst recognising the need to be precise and unambiguous, all CSDs should be written in plain English.
(b) Unnecessary duplication should be avoided and requirements should only be documented once. This concept encompasses drafting within individual CSDs, between CSDs and between the CSDs and other non BSC governance documents.
(c) Compliance with the CSDs is a Code requirement and in order to avoid confusion, process steps that relate to good but optional practices should not be documented within CSDs. Optional data items that enable supporting information to be provided are however permitted but must be clearly marked as being optional.
(d) Guidance notes can be inserted in a CSD but must be clearly marked as such.
(e) When a change to a CSD is proposed then where practical, the overall structure of the CSD and any associated CSDs should be reviewed to confirm that the contents comply with this set of Architecture Principles and that the documents contain all the necessary, but not excessive, detail.
2.2 Categories of Configurable Items
2.2.1 All BSC Configurable Items, of which CSDs form a subset, are either Category 1, Category 2 or Category 3 Configurable Items, as defined in BSCP40.
2.2.2 Where a Change Proposal is raised, redlined drafting of any proposed changes to Category 1 Configurable Items must be included with the Change Proposal.
2.2.3 Redlined changes to Category 2 Configurable Items need not be included with the Change Proposal, and may instead be developed as part of the BSC Systems Release in which the relevant Change Proposal is included.
2.2.4 Category 3 Configurable Items may not be amended through a Change Proposal, as each has a dedicated change process set out in BSCP40.
3 Contents of Configurable Item types
3.1 BSC Procedures (BSCPs)
3.1.1 Annex X-1 of the BSC defines a BSC Procedure as being “a document of that title, as established or adopted and from time to time modified by the Panel in accordance with the Code, setting out procedures to be complied with (by Parties, Party Agents, BSC Agents, BSCCo, the Panel and others) in, and other matters relating to, the implementation of the Code”.
3.1.2 The BSCPs define the relationships, timescales and interactions between participants and specify the information or other outputs to be exchanged between them as a step by step process. The BSCPs can contain guidance (e.g. guidance on how a section of a form should be completed) and may contain fields within forms to allow for the provision of optional (but not mandatory) supporting information. Where this is done it should be clearly marked as being guidance or optional respectively.
3.1.3 A number of BSCPs detail the processes carried out by Party Agents. Party Agents are not bound to the BSC as they are not signatories to the BSC. The BSC places obligations on Suppliers which are fulfilled by their agents generally in accordance with these BSCPs. These BSCPs describe the requirements that the Party Agent’s processes must meet in order to ensure that the BSC is correctly implemented, and should avoid prescribing the supporting processes required to implement those requirements. Where ‘best practices’ are identified then it would be appropriate to record this information in a separate guidance note.
3.1.4 All BSCPs should contain the following types of information:
(a) A statement to say which section of the Code the BSCP is derived from;
(b) Details of BSCPs which are referenced by the processes contained in this CSD (‘Related BSCPs’);
(c) The appropriate rules specifying how the information is to be provided;
(d) The actual information to be produced;
(e) The responsibilities for each process step;
(f) Timescales for the delivery of information which are measurable;
(g) Defined interfaces between participants;
(h) The format of information (e.g. forms, flow references);
(i) The Communications method;
(j) The timescales for Communication;
(k) Guidance notes (that are clearly marked as such) where required;
(l) A short list of the overarching Code requirements for the particular Party Agent on the basis that Party Agents are not signatories to the Code (where appropriate); and
(m) Service Levels (where appropriate).
The BSCPs should not contain workflow diagrams, with requirements being captured via interface and timetable tables.
3.2 Party Service Line (PSL)
3.2.1 Annex X-1 of the BSC defines a Party Service Line as being “a document of that title, as established or adopted and from time to time modified by the Panel in accordance with the Code, setting out the requirements as to particular services which are to be performed by Parties and Party Agents.”
3.2.2 There is currently a single Party Service Line that details the non functional requirements that are common to LDSOs and SVA Party Agents. This Party Service Line includes the following generic requirements:
(b) data retention requirements;
(c) data quality requirements;
(d) security control requirements; and
(e) change control requirements.
3.3 Codes of Practice (CoPs)
3.3.1 Annex X-1 of the BSC defines a Code of Practice as being “a code of practice, as established or adopted and from time to time modified by the Panel in accordance with the Code, relating to Metering Equipment or any part or class thereof”
3.3.2 The Codes of Practice detail the technical requirements for Metering Systems. Codes of Practice should contain the following information:
(a) Details of what should be measured and the accuracy of the energy measurements;
(b) The Metering Equipment Specification and the accuracy of each piece of Metering Equipment to be included in the Metering System; and
(c) The details of the defined Metering Points.
3.3.3 It should also be noted that the Codes of Practice versions are not time limited in the same way as other documents. Any Metering System is registered to a particular Code of Practice Issue number. If the Code of Practice is amended, the Metering Systems that are registered to that Code of Practice do not have to be amended in line with the changes to the Code of Practice, and Technical Assurance checks are carried out against the Code of Practice and Issue number applicable to a Metering System at the time of its first registration. This means that most Codes of Practice have several Issues which are still in use. This also includes some versions of Codes of Practice which were developed prior to the introduction of NETA (Codes of Practice A to K2). Updates to Codes of Practice can however only be based on the latest issue of any particular Code of Practice. Codes of Practice have both issue numbers and version numbers. If an update to a Code of Practice results in a material change to that Code of Practice, then the issue number will be incremented along with the version number. If an update to a Code of Practice is minor then the version number will be incremented only. A minor change to a Code of Practice is a change such that existing Metering Equipment/Metering Systems which are fully compliant with the previous version number should remain compliant with the subsequent version numbers of that issue in the Code of Practice.
3.4.1 Annex X-1 of the BSC defines the Data Catalogue as “having the meaning given to that term in Section O1.1.3.”
3.4.2 The Data Catalogues are, for the SVA market, the SVA Data Catalogue and for the CVA market, the CVA Data Catalogue (supported by the NETA Interface Definition and Design document (IDD) part 1 and the FAA IDD part 1).
3.4.3 The SVA Data Catalogue is supplemental to the Energy Market Data Specification, which is administered by the REC Code Manager and governed by the relevant Industry Code. The SVA Data Catalogue contains some of the additional Settlement related flows that are not sent using the Data Transfer Service.
3.4.4 The Data Catalogues should contain the details of the flows to be sent between participants and specifically contain the following:
(a) The data items to be included in the flow;
(b) The format of the flow, including headers and footers;
(c) Descriptions of the data items; and
(d) The format of the data items.
3.5 Communication Requirements Document
3.5.1 Section O2.2.1 (b) of the BSC defines a Communication Requirements Document as being “a document or documents of that title, as established or adopted and from time to time modified by the Panel in accordance with the Code, containing detailed requirements for sending or receiving Communications between Parties and one or more BSC Agents using one or more than one Communications Medium(s)”.
3.5.2 The Communication Requirements Document relates to the sending and receiving of Communications between Parties, Party Agents, Market Index Data Providers and a number of the BSC Agents. There is currently only one Communications Requirement Document which mainly relates to the CVA market (although reference is made to the Managed Data Network and applicable BSCPs as the equivalent in the SVA market).
3.5.3 The content of a Communication Requirements Document is set out in Section O2.3 of the Code, with the requirements of the Communications themselves contained within the CVA Data Catalogue, which refers to the NETA IDD Part 1.
3.5.4 The Communication Requirements Document should include (or include a reference to another CSD which includes) the following elements:
(a) A description and specification of the Communications Medium;
(b) The specification of the systems required by a Party in order to send and receive Communications using the Communications Medium;
(c) Details of the tests that are required of a Party in relation to its Party System;
(d) Any particular requirements applying to a Party where it wishes to modify its Party Systems;
(e) Any security requirements applying in respect of the use of a Communications Medium by a Party;
(f) Any further terms applying to the use of a Communication Medium by a Party;
(g) The basis on which it will be determined whether and when Communications sent using the Communications Medium are deemed to have been received;
(h) The arrangements for the recording and logging and acknowledging the sending and receipt of Communications;
(i) The Time Standard applicable for the Communication; and
(j) Details relating to planned Agent downtime.
3.6 The Reporting Catalogue
3.6.1 Section V1.4 of the BSC defines the Reporting Catalogue as being "the document of that title which sets out the data items to be contained in each of the reports mentioned in Annex V-1".
3.6.2 There is only one Reporting Catalogue which covers both SVA and CVA reporting. It catalogues and provides further information on the content of reports issued by BSC Agents and BSCCo. It provides the details of what should be contained in the reports set out in Section V, annex V1 of the Code. It should also include the provisions of other related reports such as Performance Reports and Exception Reports. It should not however cover reports that can be found in the Data Catalogues. The Reporting Catalogue should not duplicate information that is contained in a Data Catalogue or the Interface Definition & Design Documents.
3.7 BSC Service Descriptions
3.7.1 Annex X-1 of the BSC defines a BSC Service Description as being "a document of that title, as established or adopted and from time to time modified by the Panel in accordance with the Code, setting out requirements as to particular services which are to be provided centrally as provided in Section E".
3.7.2 The BSC Service Descriptions describe the service to be provided by the BSC Agents. As a general rule, there is one BSC Service Description for each BSC Agent. The exception to this rule is for the Technical Assurance Agent (TAA), for which there are two TAA BSC Service Descriptions, one for SVA and one for CVA. These documents form part of the contract with the BSC Agent.
3.7.3 The obligations of the BSC Agent must be captured in the Service Description, whether by explicitly stating the obligation or by adding an umbrella statement and references to another appropriate CSD. The content of BSC Service Descriptions is set out in the Code, section E1.3. They should include (or include a reference to another document which includes) the following elements as the Panel decides to be appropriate:
(a) Specification of the services to be provided by the BSC Agent;
(b) The development and maintenance by the BSC Agents of a contingency plan;
(c) The provision by the BSC Agent of a disaster recovery service and the maintenance of a disaster recovery plan;
(d) The preparation of BSC Agent records; and
(e) The provision to the BSC Auditor of access to any records that it requires.
3.8 Load Flow Model (LFM) Specification
3.8.1 Annex X-1 of the BSC defines the LFM Specification as having "the meaning given to that term in paragraph 2.1 of Annex T-2". It is the specification for the Load Flow Model used to calculate Transmission Loss Factors in accordance with BSC Annex T-2. The mandatory contents of the LFM Specification are set out in section 2 of Annex T-2.
