TRUM – Section 6.9 Examples of transaction reporting In order to facilitate transaction reporting and the understanding of how to populate the data fields in Table 3 of the Annex to the Implementing Acts, the Agency provides a number of examples of transaction reports. The examples can be found in ANNEX III of this document. It is worth noting that not all the data fields are mandatory for all transactions. The data fields are expected to be reported only when it is applicable according to this manual. The Agency has prepared an extensive list of trading scenarios to show what is expected and applicable to each scenario. However, the Agency is aware of the fact that, given the characteristics of some transactions, not all the possible trading scenarios have been covered in this manual. The Agency will continue to work with relevant stakeholders on the reporting of electricity transportation contracts and will provide more detailed information on this topic in subsequent updates of the TRUM, including additional trading scenarios in Annex II. Last update: 09/05/2016
TRUM – Section 5.2 Data fields related to contract details This section includes the following fields: 1. Contract ID 2. Contract date 3. Contract type 4. Energy commodity 5. Price or price formula 6. Estimated notional amount 7. Notional currency 8. Total notional contract quantity 9. Volume optionality capacity 10. Notional quantity unit 11. Volume optionality 12. Volume optionality frequency 13. Volume optionality intervals Data Field No (11) Contract ID No. Field Identifier Description 11 Contract ID Unique identifier for the contract as assigned by the two market participants. Description of Accepted Values Type Length Examples Up to 100 alphanumerical digits. Alphanumerical 100 AGHDN15832839 This field identifies the unique contract ID as assigned by the two market participants. For a detailed explanation of how to report the Contract ID market participants should refer to ANNEX IV which explains how to generate a unique transaction ID. This can also be used to generate a Contract ID. The Agency recommends that market participants use the ACER algorithm available in ANNEX IV of this manual, unless markets participants agree on their own method of generating a Contract ID. Data Field No (12) Contract date No. Field Identifier Description 12 Contract date The date the contract was agreed or its modification, cancellation or termination. Description of Accepted Values Type Length Examples ISO 8601 date format Date n/a 2014-01-30 This field identifies the contract date on which the contract was agreed. This field must reflect the actual date as a string representation of the ISO 8601 date format. Data Field No (13) Contract type No. Field Identifier Description 13 Contract type The type of contract. Description of Accepted Values Type Length Examples SO=Spot FW=Forward style contract FU=Future style contract OP=Option style contract OP_FW=Option on a forward OP_FU=Option on a future OP_SW=Option on a swap SP=Spread SW=Swap OT=Other Text 2 FW This field identifies the type of contract that is reported. For bilateral contracts forward style contract refers to the forward style which also includes spot transactions. Market participants should not understand forward style as a sort of derivative contract but as the style of the contract itself i.e. for physical delivery at a later date. Data Field No (14) Energy commodity No. Field Identifier Description 14 Energy commodity The classification of the energy commodity for the agreed contract. Description of Accepted Values Type Length Examples NG=Gas EL=Electricity Text 2 NG This field identifies the energy commodity of the product delivered: either natural gas or electricity. Other commodities such as emissions rights, coal, oil, etc. are out of scope of REMIT. Spreads are not commodities. Clean and Dirty Spark Spreads, for trades that involve both electricity and gas have to be reported separately unless the contract itself includes both commodities in which case both, gas and electricity, should be reported in this field. Clean and Dirty Dark Spreads, for a trade that involves electricity, coal and emissions should be reported as an electricity contract. Coal and emissions have not to be reported. Data Field No (15) Price or price formula No. Field Identifier Description 15 Price or price formula Fixed price or price formula used in the contract. Description of Accepted Values Type Length Examples For Price Up to 20 numerical digits in the format xxxxx.yyyyy with a maximum of 5 decimals. For Formula Up to 1000 alphanumerical digits. Number Alphanumeric 20 1000 35.00 HGSG/HBS*+578HSH This field identifies the agreed price per unit of energy as expressed in field 20. In case of options, this field represents the premium. If the contract includes a price formula this shall be reported in this field. The Agency understands that a price formula may be very complex and may not be represented in the same way in the systems of the two counterparties to the contract. When the price formula is very complex, market participants should report a simplified version of the formula. Data Field No (16) Estimated notional amount No. Field Identifier Description 16 Estimated notional amount Estimated notional amount of the contract (if applicable). Description of Accepted Values Type Length Examples Up to 20 numerical digits in the format xxxx.yyyyy with a maximum of 5 decimals. Number 20 53450.00 This field identifies the estimated notional amount of the contract. The notional amount should be calculated using the following formula: Notional Amount = Price x Total notional contract quantity where: Price is defined as the price of the volume as per field 15 Total notional contract quantity is the quantity of energy as per field 18 For example, a contract traded for a price of €50/MWh for a volume of 100MW delivered for 8 hours has the following notional amount: €50 x 100(MW) x 8(h) = €40,000 or for a monthly contract: €50 x 100(MW) x 8(h/day) x 30(days) = €1,200,000 This field should be left blank for contracts that do not have a known price at the time of the trade. The same applies to any contracts which have a floating leg, e.g. gas/electricity financial swaps not reported under EMIR but reportable under REMIT. For example: in April, market participant (A) enters into an electricity financial swap contract for the month of July. Market participant (A) is the seller of the swap. Market participant (A) sells the forward fixed leg today and it buys the spot price (based on a reference price) in July. For the fixed leg, the forward price is known today but the spot price is not known until the end of July. In this case, this field should be left blank. For the calculation of the notional amount for options, the option strike price should be used, and not the option premium. The Agency understands that without a defined price and quantity, market participants will only be able to provide an estimated notional amount that may differ between the two counterparties. Data Field No (17) Notional currency No. Field Identifier Description 17 Notional currency The currency of the estimated notional amount. Description of Accepted Values Type Length Examples ISO 4217 Currency Code, 3 text digits: BGN=Bulgarian lev CHF=Swiss franc CZK=Czech koruna DKK=Danish krone EUR=Euro EUX=Euro cent GBX=Penny sterling GBP=Pound sterling HRK=Croatian kuna HUF=Hungarian forintI ISK=Icelandic króna NOK=Norwegian krone PCT=Percentage PLN=Polish złoty RON=Romanian new leu SEK=Swedish krona/kronor USD=U.S. dollar OTH=Other Text 3 EUR This field identifies the currency for the value indicated in field 15 (price) and/or 16 (estimated notional amount). The notional currency shall be provided in the major unit, e.g. EURO rather than EURO cent and GBP rather than GB pence. The reason for reporting the major unit is, for example, that the price for NBP is quoted in pence per therm, but the notional value of the contract may be much bigger e.g. a gas year forward is 365 days and it may be more appropriate to have GBP 1,000,000 rather than GBp. 100,000,000. If field 15 (price) and 16 (estimated notional amount) is blank, this field should be left blank. Data Field No (18) Total notional contract quantity No. Field Identifier Description 18 Total notional contract quantity The estimated total number of units of the wholesale energy product. This is a calculated figure. Description of Accepted Values Type Length Examples Up to 20 numerical digits in the format xxxx.yyyyy with a maximum of 5 decimals. Number 20 1000 This field identifies the total quantity or energy volume of the transaction (total notional contract quantity). The total notional contract quantity is the overall quantity/volume of energy included in the contract. The notional contract quantity should be calculated using the following formula: Total notional contract quantity = Volume x number of periods, where: Volume is the quantity of energy as per field (19) volume optionality capacity (if available) Number of periods is the number of times that quantity is delivered / received For example, a contract traded for a volume of 100 MW delivered for 8 hours would have the following total notional contract quantity: 100 MW x 8h = 800 MWh or for a monthly contract: 100 MW x 8h x 30days = 240,000 MWh The Agency understands that without a defined quantity market participants will be only able to provide an estimated notional contract quantity that may differ from between the market participants. Where the total notional contract quantity is not known this field shall be left blank. Data Field No (19) Volume optionality capacity No. Field Identifier Description 19 Volume optionality capacity The number of units included in the contract, per delivery time interval if available. Description of Accepted Values Type Length Examples Up to 20 alphanumerical digits. Alphanumeric 20 100/200 This field identifies the number of units included in the contract per delivery time interval if available. For example, if the non-standard contract has optionality identifying the capacity per time interval, this should be reported in this field. Please see examples available in Annex II. Data Field No (20) Notional quantity unit No. Field Identifier Description 20 Notional quantity unit The unit of measurement used in fields 18 and 19. Description of Accepted Values Type Length Examples For field 18: KWh MWh GWh Therm Ktherm MTherm cm mcm Btu MMBtu MJ MMJ 100MJ GJ For field 19: KW KWh/h KWh/d MW MWh/h MWh/d GW GWh/h GWh/d Therm/d KTherm/d MTherm/d cm/d mcm/d Btu/d MMBtu/d MJ/d 100MJ/d MMJ/d GJ/d Text 2 to 8 MWh This field must identify the unit used for the reported quantity in field 18 (total notional contract quantity) and field 19 (volume optionality capacity). Where the units for field 18 and field 19 differ, the two different quantity units should be provided. Data Field No (21) Volume optionality No. Field Identifier Description 21 Volume optionality The volume classification. Description of Accepted Values Type Length Examples V=Variable F=Fix M=Min/Max C=Complex O=Other Text 1 F This field identifies the type of volume classification of the capacity indicated in field 19. This is a representation of the flexibility of the contract capacity. For example, it refers to the volume classification such as variable “V” (e.g. unbound variable capacity), fix “F” (e.g. 100), min/max “M” (e.g. 100 to 200), complex “C” (e.g. 0 [zero] or 100 to 200) or other “O”. Please see the examples in Annex II. Data Field No (22) Volume optionality frequency No. Field Identifier Description 22 Volume optionality frequency The frequency of the volume optionality: e.g. daily, weekly, monthly, seasonal, annual or other, if available. Description of Accepted Values Type Length Examples X=Half hourly H=Hourly D=Daily W=Weekly M=Monthly Q=Quarterly S=Season A=Annual O=Other Text 1 Q This field identifies the frequency of the volume optionality as indicated in field 19. This is a representation of how frequently the capacity of the non-standard contract can be “flexed”. For example, it refers to the hourly, daily, weekly, monthly, seasonal, annual or other volume optionality frequency as specified in the table above. It does not specify the exact dates and times when the contract capacity can be changed, but only the frequency that the capacity can be adjusted. Data Field No (23) Volume optionality intervals No. Field Identifier Description 23 Volume optionality intervals Time interval for each volume optionality if available. Description of Accepted Values Type Length Examples ISO 8601 date format Date n/a 2014-01-01 / 2014-03-31 This field identifies the time interval for each volume optionality, as indicated in field 19, that the market participant of the non-standard contract can adjust the volume capacity. Last update: 09/05/2016
TRUM – Section 7 Reporting of gas transportation contracts The reporting of gas transportation contracts to ACER between two balancing zones within the European Union will be mandatory from 7 April 2016 onwards. In this Chapter, the Agency provides information on how the data fields listed in Table 4 of the Annex to the Implementing Acts should be populated. In subsequent editions of the TRUM, the Agency will also provide further guidance on how to report gas transportation contracts. It should be noted that Table 4 of the Annex to the Implementing Acts shall be used for the reporting of both standard and non-standard gas transportation contracts. It is worth noting that not all the data fields are mandatory for all transactions. Data fields are expected to be populated when applicable according to this manual. The Agency has prepared a list of trading scenarios to show what is expected and applicable to each scenario. The trading scenarios are listed in ANNEX II. The information shall be provided for the following bookable points of the transmission system: (a) all interconnection points; (b) entry points of production facilities; (c) for exit points connected to a single customer; (d) entry and exit points to and from storage; (e) entry and exit points to and from LNG facilities and physical hubs. In case of bundled capacity each reporting entity reports its contractual part of the transaction. The “Description of Accepted Values” only contains examples of values. Last update: 09/05/2016
TRUM – Section 5.3 Data fields related to fixing index details This section includes the following fields: 24. Type of index price 25. Fixing index 26. Fixing index types 27. Fixing index sources 28. First fixing date 29. Last fixing date 30. Fixing frequency 31. Settlement method Data Field No (24) Type of index price No. Field Identifier Description 24 Type of index price Price classified as fixed, simple index (single underlying) or complex price formula (multiple underlying). Description of Accepted Values Type Length Examples F=Fixed I=Simple Index C=Complex Price Formula O=Other Text 1 C This field identifies the type of index or reference price used to sett the price of the contract. Some contracts, both derivatives and non- derivatives, related to the delivery of gas or electricity are traded on the basis that the price will be fixed by an index value or reference price upon its publication. The price can be classified as fixed “F” when the contract has a fix price (e.g. EUR 50.60), simple index “I” (e.g. a single underlying) or complex price formula (multiple underlyings used in a formula). In case none of the above applies, other “O” shall be used. Data Field No (25) Fixing index No. Field Identifier Description 25 Fixing index List of indices determining the price in the contract. For each Index specify the name. In case of a basket of indices for which no unique identifier exist the basket or the index shall be indicated. Description of Accepted Values Type Length Examples Up to 150 alphanumerical digits. Alphanumeric 150 EUGAS day-ahead Publisher Name This field identifies the name of the fixing index used to set the price of the transactions executed under the contract. Market participants shall report the name of the fixing index in this field and where the contract has several fixing indexes each of them should be reported in this field. As the Agency does not intend to publish a list of indexes because most of them are publicly available and can be readily accessed, the Agency recommends that reporting parties use those indexes exactly as advertised by the publisher. If the index is not public, then market participants should make best efforts to minimise any discrepancy with the other market participant when reporting this information. Data Field No (26) Fixing index types No. Field Identifier Description 26 Fixing index types Spot, forward , swap, spread, etc. Description of Accepted Values Type Length Examples SO=Spot FW=Forward style contract FU=Future style contract OP=Option style contract OP_FW=Option on a forward OP_FU=Option on a future OP_SW=Option on a swap SP=Spread SW=Swap OT=Other Text Up to 5 FW This field identifies the type of fixing index indicated in field 25 used in the contract that is being reported. Where the contract has several type of fixing index each of them should be reported in this field. For example, if the index is a spot price published by an exchange the “SO” value shall be reported. If the index is published by a price reporting agency or other publisher and it represents the delivery of the energy commodity during the course of a specific day, week, weekend, month etc., then the “FW” value shall be reported. If the index is a future price published by an exchange the “FU” value shall be reported. Data Field No (27) Fixing index sources No. Field Identifier Description 27 Fixing index sources For each index specify the publication source. In case of basket of indices for which no unique identifier exist the basket or the index shall be indicated. Description of Accepted Values Type Length Examples Up to 100 alphanumerical digits. Alphanumeric 100 Index Source Name This field identifies the source of the fixing index/indexes used in field 25 (fixing index). Where the contract has several sources for the fixing indexes each source should be reported in this field. For each index reported in field 25 (fixing index), market participants shall specify the publication source of each index. In the case of a basket of indices for which no unique publisher exists, market participants shall report all sources of the basket of indices. For example, if in field 25 the index “EU-GAS-CALENDAR-YEAR-2015-PUB-NAME” is reported, the market participants shall report the source of the publication of the index, e.g. the EU-GAS-PRICES-PUB-NAME and the publisher name e.g. PUB-NAME, needed to identify where the index is published. This applies to each individual index reported in field 25. For example, if in field 25 is reported the “EU-GAS-CALENDAR-YEAR-2015-PUB-NAME-ABC” index and “EU-GAS-CALENDAR-YEAR-2015-PUB-NAME-123” index, market participants shall report the source of the publication for both i.e. “PUB-NAME-ABC” and PUB-NAME-123”. Data Field No (28) First fixing date No. Field Identifier Description 28 First fixing date First fixing date determined by the earliest date of all the fixings. Description of Accepted Values Type Length Examples ISO 8601 date format Date n/a 2024-01-29 This field identifies the first date at which the price of the contract can be set using the index indicated in field 25 (fixing index). If the contract has several indexes and each of them may be used to set the contract price, market participants shall report the first date at which the price of the contract can be fixed for each index reported in field 25 (fixing index). For example: 1. index ABC may be used to fix the contract price from 01/01/2015 to 31/12/2017; 2. index 123 may be used to fix the contract price from 01/04/2015 to 31/03/2018; and 3. index XYZ may be used to fix the contract price from 01/04/2016 to 31/03/2019. In this case market participants shall report 01/01/2015, 01/04/2015 and 01/04/2016 for this field. Data Field No (29) Last fixing date No. Field Identifier Description 29 Last fixing date Last fixing date determined by the latest date of all the fixings. Description of Accepted Values Type Length Examples ISO 8601 date format Date n/a 2034-01-29 This field identifies the last date at which the price of the contract can be fixed using the index indicated in field 25 (fixing index). In the contract has several indexes and each of them may be used to set the contract price, market participants shall report the last date at which the price of the contract can be fixed for each index reported in field 25 (fixing index). For example: 4. index ABC may be used to fix the contract price from 01/01/2015 to 31/12/2017; 5. index 123 may be used to fix the contract price from 01/04/2015 to 31/03/2018; and 6. index XYZ may be used to fix the contract price from 01/04/2016 to 31/03/2019. In this case 31/12/2017, 31/03/2018 and 31/03/2019 shall be reported for in this field. Data Field No (30) Fixing frequency No. Field Identifier Description 30 Fixing frequency The frequency the fixing: e.g. daily, weekly, monthly, seasonal, annual or other. Description of Accepted Values Type Length Examples X=Half hourly H=Hourly D=Daily W=Weekly M=Monthly Q=Quarterly S=Seasonal A=Annual O=Other Text 1 W This field identifies the frequency of the fixing of the index for the contract price. For example, it refers to the daily, weekly, monthly, seasonal, annual or other frequency as specified in the table above. It does not specify the exact dates and times when the fixing occurs but its frequency. For example, a contract price can be set on the basis of an index that is used daily or a contract price can be set on the basis of an index that it is used monthly. Data Field No (31) Settlement method No. Field Identifier Description 31 Settlement method Whether the contract is settled physically, in cash, both, optional or other. Description of Accepted Values Type Length Examples P=Physical C=Cash O=Optional for counterparty Text 1 P This field identifies the type of settlement for the contract. “P” shall be indicated if the contract is settled physically and “C” shall be indicated if the contract is settled in cash. “O” shall be indicated if the contract can be physically settled or may be settled in cash at the option of one of the parties. For contract such as option on futures or swaps, as they settle into the underlying future or swap, this should be considered for physical delivery of the underlying contract and the value of “P” should be reported. A majority of contracts traded under REMIT are for physical delivery, but there may also be derivative contracts that are not reported under EMIR and thus reported under REMIT. Consequently, different types of settlement methods can occur. For further clarification on derivatives not reported under EMIR but reportable under REMIT, please refer to point 3.3.3 of this document. Last update: 09/05/2016
TRUM – Section 7.1 Data fields related to common data for total primary and secondary allocation process This section includes the following fields: 1. Sender identification 2. Organised market place identification 3. Process identification 4. Type of gas 5. Transportation transaction identification 6. Creation date and time 7. Auction open date and time 8. Auction end date and time 9. Transportation transaction type 10. Start date and time 11. End date and time 12. Offered capacity 13. Capacity category Data Field No (1) Sender Identification No. Field Identifier Description 1 Sender identification Identification of the party that is the owner of the document and is responsible of its content. Description of Accepted Values Type Length Examples EIC Alphanumeric Maximum 16 10X1001A1001A450 This field indicates the identification of the owner and sender of the document. The sender of the document is identified by a unique coded identification. This code identifies the party that is the “owner” of the information being transmitted in the document and who is responsible for its content. In general this identifies the bidder or its representative. EDIGAS message includes “Standard header information”. It should be borne in mind that for the reporting of transportation contracts, the Agency had to rely on existing industry schemas which were originally defined for different purposes and therefore have to be understood in a way that they comply with the REMIT transaction reporting regime. For its original purpose, the field and its values assume that the sender is normally a TSO or another market participant. However, for the purpose of reporting under REMIT, the sender may not only be a self-reporting market participant, but also a third-party RRM. When the reporting entity is a third-party RRM, the third-party RRM has certain responsibilities for the document content as they have to validate the data they receive from market participants, ensure completeness, accuracy and timely submission of the data according to Article 11(2) of Commission Implementing Regulation (EU) No 1348/2014 and, if necessary, correct and resubmit the rejected data in line with Article 11(2) of Commission Implementing Regulation (EU) No 1348/2014. This is why the sender identification has to identify the third-party RRM in cases where a third-party RRM reports. This field is mandatory. Data Field No (2) Organised market place identification No. Field Identifier Description 2 Organised market place identification Identification of organised market place. Description of Accepted Values Type Length Examples EIC Alphanumeric Maximum 16 10X1001A1001A450 The field should be populated with “21X-XXXXXXXXXXXY” if the capacity was allocated outside of an organised market place. The current schema is designed to provide the identification of the organised market place operator as opposed to the organised market place. This is in conformity with the code provided in the example which is an EIC Party code. This field corresponds to the field ORGANISEDMARKETPLACE_MARKETPARTICIOANT.IDENTIFICATION in the schema. Data Field No (3) Process identification No. Field Identifier Description 3 Process identification The identification of the auction or other process as defined by the capacity allocating entity. Description of Accepted Values Type Length Examples Unique Identification that clearly identifies the auction. Alphanumeric Maximum 35 590825 This field is mandatory if the capacity was allocated bilaterally (shipper – shipper) and outside of organised market place. An identification of the allocation should be provided. This field corresponds to the PROCESS_TRANSACTION.IDENTIFICATION field in the schema. Data Field No (4) Type of gas No. Field Identifier Description 4 Type of gas Identifies the type of gas. Description of Accepted Values Type Length Examples High (H-gas) or Low (L-gas) calorific gas. HC1 = High Calorific LC1 = Low Calorific Alphanumeric Maximum 3 characters. HC1 This field is mandatory for an auction. This field corresponds to the field PROCESS_TRANSACTION.TAXONOMY.ENERGYPRODUCTTYPE in the schema. Data Field No (5) Transportation transaction identification No. Field Identifier Description 5 Transportation transaction identification A uniquely assigned identification number for the capacity allocation as assigned by the organised market place or TSO. Description of Accepted Values Type Length Examples Unique Identification that clearly identifies primary capacity allocation as assigned by the organized market place or TSO. Alphanumeric Maximum 35 Prisma identification number (Deal ID Code) This field provides the identification of the transportation transaction. This data field is used only for successful auctions/other processes. For secondary allocations, the following applies: A uniquely assigned identification number for the allocation made between the transferor and transferee as assigned by the Platform Operator or as agreed between the Balancing group(s)/shipper(s) for bilaterally agreed capacity allocations. This field is mandatory. This field corresponds to the RULES GOVERNING THE TRANSPORTATION_TRANSACTION CLASS field in the schema. Data Field No (6) Creation date and time No. Field Identifier Description 6 Creation date and time Creation date and time of the transaction. Description of Accepted Values Type Length Examples ISO 8601 date format using UTC time format. Date and Time 30 2014-01-29T10:35:56Z This field indicates the date and time of the creation of the record indicating time zone as expressed by ISO 8601 date format / UTC time format. For secondary transaction it means the moment the two counter parties agree upon the conclusion of the deal. This field is mandatory. This field corresponds to the PROCESS_TRANSACTION.TRANSACTION_DATETIME field in the schema. Data Field No (7) Auction open date and time No. Field Identifier Description 7 Auction open date and time The date and time when an auction opens for bidding. Description of Accepted Values Type Length Examples ISO 8601 date format using UTC time format. Date and Time 30 2014-01-29T10:35:56Z This field indicates the date and time when an auction opens for bidding. Auction open date and time expressed by ISO 8601 date format / UTC time format. This field is mandatory but shall be left blank if the process of allocation does not involve an auction or call for orders. This field corresponds to the PROCESS_TRANSACTION.AUCTIONOPEN_DATETIME field in the schema. Data Field No (8) Auction end date and time No. Field Identifier Description 8 Auction end date and time The date and time when an auction closes. Description of Accepted Values Type Length Examples ISO 8601 date format using UTC time format. Date and Time 30 2014-01-29T10:35:56Z This field indicates the date and time when an auction closes for bidding. Auction End Date and Time as expressed by ISO 8601 date format / UTC time format. This field is mandatory but shall be left blank if the process of allocation does not involve an auction or in case the auction is cancelled or in case of call for orders. This field corresponds to the PROCESS_TRANSACTION.AUCTIONEND_DATETIME field in the schema. Data Field No (9) Transportation transaction type No. Field Identifier Description 9 Transportation transaction type The type identifies the nature of transportation transaction to be reported in accordance with current applicable industry standards as specified by Gas Network code on Interoperability and Data Exchange. Description of Accepted Values Type Length Examples Refer to EDIGAS Code list document for valid codes. ZSW = Ascending clock auction ZSX = Uniform price auction ZSY = First come first served ZSZ = Secondary market procedure Alphanumeric Maximum 3 ZSX This field is mandatory. This field corresponds to the PROCESS_TRANSACTION.TYPE field in the schema. Data Field No (10) Start date and time No. Field Identifier Description 10 Start date and time Date and time of the start of the transportation transaction runtime. Description of Accepted Values Type Length Examples ISO 8601 date format using UTC time format. Date and Time 30 2014-01-29T10:35Z This field indicates the start date and time of the transportation transaction runtime. Date and time shall be expressed as: YYYY-MM-DDThh:mmZ. EDIGAS message provides one field to specify the start and end date and time. Fields 10 and 11 are specified by one field in EDIGAS message. This field is mandatory. This field corresponds to the TIMEINTERVAL field in the schema. Data Field No (11) End date and time No. Field Identifier Description 11 End date and time Date and time of the end of the transportation transaction runtime. Description of Accepted Values Type Length Examples ISO 8601 date format using UTC time format. Date and Time 30 2014-01-29T10:35Z This field indicates the end date and time of the transportation transaction runtime. Date and time shall be expressed as: YYYY-MM-DDThh:mmZ. EDIGAS message provides one field to specify the start and end date and time. Fields 10 and 11 are specified by one field in EDIGAS message. This field is mandatory. This field corresponds to the TIMEINTERVAL field in the schema. Data Field No (12) Offered capacity No. Field Identifier Description 12 Offered capacity The quantity of capacity available in the auction expressed in the measure unit. Only relevant for bidding behaviour monitoring. Description of Accepted Values Type Length Examples The maximum length of this information is 17 numeric characters (decimal point included) Numeric Maximum 17 200.5 The Quantity of capacity available in the auction or call for orders expressed in the Measure unit. Measure unit is indicated in field 17. Only for primary allocation process. This field is mandatory. This field corresponds to the field OFFEREDCAPACITY_QUANTITY.AMOUNT in the schema Data Field No (13) Capacity category No. Field Identifier Description 13 Capacity category Applicable capacity category. Description of Accepted Values Type Length Examples The following types are permitted: Z04 = Available total firm capacity Z05 = Interruptible (booked) Z06 = Firm (booked) ZEQ = Freely allocable capacity (FZK) ZER = Capacity with capacity allocation restrictions and capacity usage restrictions (bFZK) ZES = Restricted-allocable capacity (BZK) ZET = Dynamically allocable capacity (DZK) ZEU = Temperature related and restricted capacity (TAK) ZEW = published technical capacity ZFA = Available interruptible capacity ZFB = Available firm capacity ZFD= Available total interruptible capacity (Reference Edig@s AvailabilityType code list) Alphanumeric Maximum 3 Z06 This field is mandatory for auctions. This field corresponds to the PROCESS_TRANSACTION.TAXONOMY.AVAILABILITYTYPE field in the schema. Last update: 09/05/2016
TRUM – Section 3.3 Who shall report? In accordance with Article 8 of REMIT, market participants, or a person or authority on their behalf, shall provide the Agency with a record of wholesale energy market transactions, including orders to trade (‘trade data’). Reporting obligations cover: a) market participants, which means any person, including transmission system operators, who enters into transactions, including orders to trade, in one or more energy markets; b) third parties acting on behalf of market participants; c) trade reporting systems; d) organised market places, trade matching systems or other persons professionally arranging transactions; e) trade repositories registered or recognised under Regulation (EU) No 648/2012 (EMIR); f) competent authorities which have received the information in accordance with Article 25(3) of Directive 2004/39/EC (MiFID) or ESMA when received in accordance with Regulation (EU) No 648/2012 (EMIR). The Implementing Acts establish uniform rules on the reporting of trade data and specify the reporting channels. An overview of the relevant provisions of the Implementing Acts is provided below. For further information on reporting entities and their responsibilities, please consult the Agency’s Requirements for the registration of Registered Reporting Mechanisms (RRM). For further information on the Agency’s understanding of the definition of market participant, please consult the ACER Guidance on the application of REMIT. 1. Wholesale energy products concluded at an organised market place According to Article 6(1) of the Implementing Acts, market participants shall report details of wholesale energy products executed at organised market places including matched and unmatched orders to the Agency through the organised market place concerned, or through trade matching systems or trade reporting systems. The organised market place where the wholesale energy product was executed or the order was placed shall, at the request of the market participant, offer a data reporting agreement. This provision covers the reporting of transactions, including orders to trade, executed at organised market places related to the following wholesale energy products: a) standard supply contracts; b) contracts relating to the transportation of electricity or natural gas concluded between market participants on secondary markets (physical or financial capacity rights or obligations) including resale and transfer of such contracts; and c) derivative contracts (unless already reported under Article 9 of Regulation (EU) No. 648/2012’ ‘EMIR’ or other EU financial markets legislation). 2. Transportation contracts Primary allocation contracts: TSOs or third parties on their behalf shall report details of contracts relating to the transportation of electricity or natural gas concluded as a result of a primary explicit capacity allocation by or on behalf of the TSO (physical or financial capacity rights or obligations), including matched and unmatched orders (Article 6(2) of the Implementing Acts). Secondary transportation contracts: The reporting obligation for secondary transportation contracts applies to the involved market participants. In line with Article 6(1) of the Implementing Acts, market participants shall report details of secondary transportation contracts executed at organised market places including matched and unmatched orders to the Agency through organised market places concerned, or through a trade matching or trade reporting system, which is registered as an RRM. Secondary transportation contracts which have been concluded outside and organised market shall be reported by the market participants or third parties on their behalf (Article 6(3) of the Implementing Acts). 3. Wholesale energy products reported in accordance with EMIR or other EU financial markets legislations According to Article 6(4) of the Implementing Acts, information in relation to wholesale energy products which have been reported in accordance with Article 26 of Regulation (EU) No 600/2014[1] or Article 9 of Regulation (EU) No 648/2012 shall be provided to the Agency by: a) trade repositories referred to in Article 2 of Regulation (EU) No 648/2012; b) approved reporting mechanisms referred to in Article 2 of Regulation (EU) No 600/2014; c) competent authorities referred to in Article 26 of Regulation (EU) No 600/2014; or d) the European Securities and Markets Authority. Furthermore, according to Article 6(5), where persons have reported details of transactions in accordance with Article 26 of Regulation (EU) No 600/2014 or Article 9 of Regulation (EU) No 648/2012, their obligations in relation to reporting under REMIT shall be considered as fulfilled. It is important to note that the financial legislation does not prescribe the reporting of orders to trade. Hence, the latter are not covered by Article 6(4) and 6(5) of the Implementing Acts and shall, in principle, be reported in accordance to Article 6(1) of the Implementing Acts (see above). Clarification on the reporting of derivatives contracts According to the Implementing Acts, the following derivatives contracts shall be reported to the Agency: 1. options, futures, swaps and any other derivatives of contracts relating to electricity or natural gas produced, traded or delivered in the Union (Article 3(1)(a)(viii)); 2. options, futures, swaps and any other derivatives of contracts relating to the transportation of electricity or natural gas in the Union (Article 3(1)(b)(iii)). The Implementing Acts also provide that where persons have reported details of transactions in accordance with Article 26 of MiFIR or Article 9 of EMIR, their obligations in relation to reporting those details under REMIT shall be considered as fulfilled. However, subject to the agreement of organised markets, trade matching or reporting systems, that information may be reported directly to the Agency. Therefore, information on derivatives reportable under EMIR and MiFIR may either be made available to the Agency in the EMIR / MiFIR format or reported directly to the Agency in the REMIT format, that is in accordance with Table 1 of Annex I of the Implementing Acts as regards contracts referred to in Article 3(1)(a)(viii) and Tables 3 or 4 as regards contracts referred to in Article 3(1)(b)(iii). Furthermore, derivatives contracts covered by the Implementing Acts, but not reportable under EMIR or MiFIR (e.g. in a case of market participants not established or resident in the Union and not reporting those derivatives under EMIR or MiFIR), shall be reported in accordance with Table 1 of Annex I of the Implementing Acts as regards contracts referred to in Article 3(1)(a)(ix) and Tables 3 or 4 as regards contracts referred to in Article 3(1)(b)(3). For derivatives not reported under EMIR, including those that are reported under non-EU regulations but still reportable under REMIT, market participants shall refer to this manual on how to report transactions to the Agency. For example, if a U.S. counterparty enters into a transaction on a derivative admitted to trade at an exchange within the EU, most likely the U.S. firm reports that transaction under the U.S. Dodd Frank Act to the U.S. authorities. However, since the firm traded a wholesale energy product as defined in REMIT, the person is a REMIT market participant and must report that transaction to the Agency in order to comply with REMIT. When a person only enters into transactions on derivatives traded outside the European Union that are only for financial settlement even though they are related to EU electricity or natural gas (for example a future or a swap that can only be financially settled) that person should not be considered a REMIT market participant and should not report those transactions, unless that person also enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets. For example, if a person enters into a transaction on a derivative contract related to EU gas and electricity (such as a futures contract only for financial settlement that is traded on exchange located outside the EU), that person will not be considered a REMIT market participant. Another example is when a person enters into a transaction on an exchange traded (or bilaterally) financial swap on two floating gas prices for two monthly contracts i.e. (1) EU Natural Gas Futures contract and (2) U.S. Henry Hub Natural Gas Futures contract of the corresponding contract month, traded outside the EU, that person will not be considered a REMIT market participant. However, if that person also enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets, e.g. enters on a physical trade (or derivative) for the delivery of gas or electricity (or transportation of gas or electricity) within the EU, that person is a market participant and has to report all the transactions on wholesale energy products including those trades outside the EU that are only for financial settlement. If a person trades only REMIT-related financially-settled derivative contracts traded at organised market places outside the EU, that person is not a market participant and should not report those transactions. 4. Wholesale energy products concluded outside an organised market place Under Article 6(3) of the Implementing Acts, market participants or third parties acting on their behalf shall report details of supply contracts (whether standard or non-standard), derivatives contracts, and transportation contracts concluded outside an organised market. This is, therefore, the only instance where trade data may be reported by market participants themselves. However, the reporting may also be delegated to third parties. If a market participant is unsure if they are responsible for reporting specific transactions, please seek legal advice or contact us by e-mail at remit@acer.europa.eu. Market participant registration All market participants entering into transactions which are required to be reported to the Agency in accordance with Article 8(1) of REMIT are required to register with the competent NRA in accordance with Article 9 of REMIT. Market participants can seek information on the registration process here: http://www.acer.europa.eu/remit/MARKET_PARTICIPANTS/Registration/Pages/default.aspx The Agency will establish a European registry of market participants based on the national registers of market participants provided to the Agency by NRAs. In their registration form, market participants must inform the Agency whether or not they wish to rely on third party RRMs reporting on their behalf and if so, identify the relevant RRM. This includes the organised market place or third party on which the market participant relies for the reporting of records of transactions, including orders to trade. [1] Regulation (EU) No 600/2014 of the European Parliament and of the Council of 15 May 2014 on markets in financial instruments and amending Regulation (EU) No 648/2012 (OJ L 173, 12.6.2014, p. 84) Last update: 09/05/2016
TRUM – Section 5.4 Data fields related to option details This section includes the following fields: 32. Option style 33. Option type 34. Option first exercise date 35. Option last exercise date 36. Option exercise frequency 37. Option strike index 38. Option strike index type 39. Option strike index source 40. Option strike price Data Field No (32) Option style No. Field Identifier Description 32 Option style Indicates whether the option may be exercised at a fixed date (European and Asian style), a series of pre-defined dates (Bermudan) or at any time during the life of the contract (American). Description of Accepted Values Type Length Examples A=American B=Bermudan E=European S=Asian O=Other Text 1 B This field identifies the option style, usually defined by the dates on which the option may be exercised: American, European, Bermudian, Asian or other style. An American style option can be exercised anytime during its life allowing option holders to exercise the option at any time prior to and including its maturity date. A European style option can only be exercised at the maturity date. A Bermudian style option can only be exercised on specified dates indicated in the contract. Reporting parties should refer to financial markets in order to identify the option style they are reporting. The reporting of exotic option styles such as binary, barrier, window options, etc., it should be reported with the value of “O”. Data Field No (33) Option type No. Field Identifier Description 33 Option type Indicates whether the option is a call, put or other. Description of Accepted Values Type Length Examples P=Put C=Call O=Other Text 1 C This field identifies the type of right the option holder owns, if it is a call option or a put option. “P” shall be indicated if the option is a put option and “C” shall be indicated if the option is a call option. If the option holder owns a type of right different from a put or a call, the value “O” for other shall be reported in this field. Reporting parties should refer to financial markets in order to identify the option style they are reporting. Data Field No (34) Option first exercise date No. Field Identifier Description 34 Option first exercise date First exercise date determined by the earliest date of all the exercises. Description of Accepted Values Type Length Examples ISO 8601 date format Date n/a 2014-01-29 This field identifies the first date at which the option holder has the right, but not the obligation, to buy or sell the commodity or underlying instrument at a specified price using the index indicated in field 37 (option strike index) or the price as reported in field 40 (Option strike price). For example, the counterparty to the contract that holds the option may exercise against the option strike index indicated in field 37, the right to buy or sell the energy commodity from 01/01/2015 to 31/12/2017 (on specific dates or at specific intervals), the market participant shall report 01/01/2015 in this field. Where the contract has several indexes and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report the first date at which the option can be exercised per each index reported field 37 (option strike index). For example: 1. index ABC may be used to exercise the option from 01/01/2015 to 31/12/2017; 2. index 123 may be used to exercise the option from 01/04/2015 to 31/03/2018; and 3. index XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019. In this case 01/01/2015, 01/04/2015 and 01/04/2016 shall be reported in this field. Data Field No (35) Option last exercise date No. Field Identifier Description 35 Option last exercise date Last exercise date determined by the latest date of all the exercises. Description of Accepted Values Type Length Examples ISO 8601 date format Date n/a 2024-01-29 This field identifies the last date at which the option holder has the right, but not the obligation, to buy or sell the commodity or underlying instrument at a specified price using the index indicated in field 37 (option strike index) or the price as reported in field 40 (Option strike price). For example, a counterparty to the contract that holds the option may exercise, against the option strike index indicated in field 37, the right to buy or sell the energy commodity from 01/01/2015 to 31/12/2017 (on specific dates or at specific intervals), the market participant shall report 31/12/2017 in this field. Where the contract has several indexes and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report the last date at which the option can be exercised per each index reported field 37 (option strike index). For example: 1. index ABC may be used to exercise the option from 01/01/2015 to 31/12/2017; 2. index 123 may be used to exercise the option from 01/04/2015 to 31/03/2018; and 3. index XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019. In this case 31/12/2017, 31/03/2018 and 31/03/2019 shall be reported in this field. Data Field No (36) Option exercise frequency No. Field Identifier Description 36 Option exercise frequency The frequency of the Volume optionality: e.g. daily, weekly, monthly, seasonal, annual or other. Description of Accepted Values Type Length Examples D=Daily W=Weekly M=Monthly S=Seasonal A=Annual O=Other Text 1 W This field identifies the frequency at which the option holder has the right, but not the obligation, to buy or sell the commodity or underlying instrument at a specified price using the index indicated in field 37 (option strike index) or the price as reported in field 40 (Option strike price). For example, a counterparty to the contract that holds the option may exercise, against the option strike index indicated in field 37, the right to buy or sell the energy commodity on monthly basis, the market participant shall report “M” in this field. Same applies to the other type of frequencies. Where the contract has several indexes and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report frequency at which the option can be exercised per each index reported field 37 (option strike index). For example: 1. index ABC may be used to exercise the option from 01/01/2015 to 31/12/2017 on a daily basis; 2. index 123 may be used to exercise the option from 01/04/2015 to 31/03/2018 on a monthly basis; and 3. index XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019 on a weekly basis. In this case “D”, “M” and “W” shall be reported in this field Data Field No (37) Option strike index No. Field Identifier Description 37 Option strike index For each Index specify the name. In case of a basket of indices for which no unique identifier exist the basket or the index shall be indicated. Description of Accepted Values Type Length Examples Up to 150 alphanumerical digits. Alphanumeric 150 Index Name This field identifies the name of the strike index used in the index option embedded in the contract. Market participants shall report the name of the index in this field. An index option is a call or put option contract in which the underlying asset is an index of any sort. For example, in a call, a market participant may buy the right to an index on or before the expiration date at a certain strike index. Some options, both derivatives and non-derivatives, related to physical delivery of gas or electricity are traded on the basis that the option may be exercised against an index or reference price upon its publication. As the Agency does not intend to publish a list of indexes because most of them are publicly available and can be readily accessed, the Agency recommends that reporting parties use those indexes exactly as advertised by the publisher. If the index is not public, than market participants should make best efforts to minimise any discrepancy with the other market participant when reporting this information. Market participants may consider using the following convention: [commodity]-[delivery area]-[delivery period]-[index name]-[publisher name] 1. GAS-NBP-DAYAHEAD-INDEX-PUBLISHERNAME 2. GAS-EU- FRONTMONTH-AVERAGEPRICE-PUBLISHERNAME 3. ELECTRICITY-GERMANY-FRONTMONTH-FUTURE-EXCHANGENAME Data Field No (38) Option strike index type No. Field Identifier Description 38 Option strike index type Spot, forward , swap, spread, etc. Description of Accepted Values Type Length Examples SO=Spot FW=Forward style contract FU=Future style contract OP=Option style contract OP_FW=Option on a forward OP_FU=Option on a future OP_SW=Option on a swap SP=Spread SW=Swap OT=Other Text 2 FW This field identifies the type of strike index of the option used in the contract as reported in field 37. For each index, market participants shall specify the type of index. For example, if the index is a spot price published by an exchange the “SO” value shall be reported. If the index is published by a price reporting agency or other publisher and it represents the delivery of the energy commodity during the course of a specific day, week, weekend, month etc., than the “FW” value shall be reported. If the index is a future price published by an exchange the “FU” value shall be reported. Where the contract has several indexes and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report the type of index used against which the option can be exercised per each index reported field 37 (option strike index). For example: 1. the spot price published by Exchange ABC may be used to exercise the option from 01/01/2015 to 31/12/2017; 2. the index value for a forward contract published by Publisher 123 may be used to exercise the option from 01/04/2015 to 31/03/2018; and 3. future price published by Exchange XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019. In this case “SO”, “FW” and “FU” shall be reported in this field. Data Field No (39) Option strike index source No. Field Identifier Description 39 Option strike index source For each index specify the fixing type. In case of a basket of indices for which no unique identifier exist the basket or the index shall be indicated. Description of Accepted Values Type Length Examples Up to 100 alphanumerical digits. Alphanumeric 100 Index Source Name This field identifies the source of strike index of the option used in the contract as reported in field 37 (option strike index). For each index, market participants shall specify the source of index. For example, if the index is a spot price published by Exchange ABC, the name of the exchange shall be reported. If the index is published by a price reporting agency or other publisher, then the name of the publisher shall be reported. Where the contract has several indexes and where each of them may be used to exercise the option, market participants shall report the source of each index reported in field 37 (option strike index) against which the option can be exercised. For example: 1. the spot price published daily by the Exchange ABC may be used to exercise the option from 01/01/2015 to 31/12/2017; 2. the index value for a forward contract published by Publisher 123 may be used to exercise the option from 01/04/2015 to 31/03/2018; and 3. future price published by the Exchange XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019. In this case “Exchange ABC”, “Publisher 123” and “Exchange XYZ” shall be reported in this field. Data Field No (40) Option strike price No. Field Identifier Description 40 Option strike price The strike price of the option. Description of Accepted Values Type Length Examples Up to 20 numerical digits in the format xxxxx.yyyyy with a maximum of 5 decimals. Number 20 125.98 This field identifies the price at which the owner of the option can buy (in the case of a call option), or sell (in the case of a put option), the energy commodity (gas or electricity) or the instrument as indicated in the option contract, e.g. future/forward/swap. This field shall be reported only if the strike price is available. In the case of an option strike index where the strike price is not available this field should not be blank. Where the option has several strike prices and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report all the strike prices at which the option can be exercised. Last update: 09/05/2016
TRUM – Section 7.2 Data fields for lifecycle reporting This section includes the following fields: 14. Action type Data Field No (14) Action type No. Field Identifier Description 14 Action type Status code of the report to be reported in accordance with current applicable industry standards as specified in Gas Network code on Interoperability and Data Exchange. Description of Accepted Values Type Length Examples Refer to EDIGAS Code list document for valid codes. 62G = Active. 63G = Cancelled. 66G = Changed. Alphanumeric Maximum 3 62G This information provides the status of the document. The sender indicates if the report submitted is valid and never modified, updated or not valid anymore: 62G = Active. This data means that the report is valid and has never been updated 63G = Cancelled. This data means that the report is not valid anymore 66G = Changed. This data means that the report is valid after being updated. This field is mandatory. This field corresponds to the field PROCESS_TRANSACTION.ACTION_STATUS.CODE in the schema. Last update: 09/05/2016
TRUM – Section 3.4 Start of reporting and reporting frequency 1. Start of reporting According to Article 12 of the Implementing Acts, the following trade data shall be reported to the Agency nine months following the entry into force of the Implementing Acts: a) Details of wholesale energy products in relation to the supply of electricity and gas executed at organised market places, including matched and unmatched orders. Furthermore, according to Article 12 of the Implementing Acts, the following trade data shall be reported to the Agency fifteen months following the entry into force of the Implementing Acts: a) details of wholesale energy products in relation to the supply of electricity and gas which have been concluded outside an organised market; b) details of wholesale energy products in relation to the transportation of electricity and gas, including options, futures, swaps and other derivatives of contracts relating to the transportation of electricity or natural gas in the Union. 2. Frequency of reporting According to the Implementing Acts, the following reporting frequency applies for trade data: a) details of standard contracts, including orders to trade, shall be reported no later than on the working day following the conclusion of the contract or the placement of the order. Any modification or the termination of the concluded contract or the order placed shall be reported no later than the working day following the modification or termination; b) details of non-standard contracts including any modification or the termination of the contract as well as transactions executed within the framework of non-standard contracts specifying at least an outright volume and price shall be reported no later than one month following conclusion, modification or termination of the contract; c) details of contracts relating to the transportation of electricity or natural gas concluded as a result of a primary explicit capacity allocation shall be reported no later than the working day following the availability of the allocation results. Last update: 09/05/2016
TRUM – Section 5.5 Data fields related to delivery profile This section includes the following fields: 41. Delivery point or zone 42. Delivery start date 43. Delivery end date 44. Load type Data Field No (41) Delivery point or zone No. Field Identifier Description 41 Delivery point or zone EIC code(s) for the delivery point(s) or market area(s). Description of Accepted Values Type Length Examples EIC Y code, 16 character alphanumeric code. Alphanumeric 16 10YCB-EUROPEU–8 This field identifies the commodity delivery point or zone. This field shall report the EIC Y code (or an alternative code to be agreed with the Agency if the EIC is not available) to identify the delivery and/or balancing point for the contract. Example: A contract for the supply of gas at the NBP hub (GB market) will report the EIC Y code to identify that balancing area. A contract for the supply of electricity in the German-Austrian area shall be reported using the EIC Y code to identify the balancing area where the supplier/consumer is located which in this case can be either in Germany or Austria. However, because gas can also be delivered at the interconnection point, then the EIC-Z Code for that interconnector maybe used. Data Field No (42) Delivery start date No. Field Identifier Description 42 Delivery start date Start date and time of delivery. For physically delivered contracts this would be the delivery start date of the contract. Description of Accepted Values Type Length Examples ISO 8601 date format Date n/a 2014-01-29 This field identifies the date that delivery of the commodity under the reported contract starts. Data Field No (43) Delivery end date No. Field Identifier Description 43 Delivery end date End date and time of delivery. For physically delivered contracts this would be the end delivery date of the contract. Description of Accepted Values Type Length Examples ISO 8601 date format Date n/a 2014-01-29 This field identifies the end date of delivery of the commodity under the reported contract. Data Field No (44) Load type No. Field Identifier Description 44 Load type Identification of the delivery profile (base load, peak load, off-peak, block of hours or other). Description of Accepted Values Type Length Examples BL=Base load PL=Peak load OP=Off-Peak load BH=Hour/Block Hours SH =Shaped GD=Gas Day OT=Other Text 2 BL This field identifies the delivery profile (base load, peak load, off-peak, block of hours or other) of the contract. The load type should be identified as defined in the contract if available. If a delivery profile is not defined in the contract, market participants shall report “OT” for other. Last update: 09/05/2016
