Annex II

Transaction Reporting User Manual (TRUM)

Annex II

Examples of Transaction Reporting  

For actual examples, please download the PDF version of Annex II  

Version history

Version Effective Date
Annex II Version 1.0 06 May 2015
Annex II Version 2.0 30 September 2015
Annex II Version 2.0* *(with comments on non-standard contract examples) 16 November  2015
Annex II Version 2.1 (included additional non-standard contract examples an corrected a few typos in non-standard examples) 15 February 2016
Annex II Version 3.0 (included Electricity and Gas transportation contract examples) 23 March 2016
Annex II Version 4.0 (included additional standard and non-standard examples including market coupling, added the scenario description for each example, and corrected some examples in order to ensure consistency with TRUM 4.0) 30 April 2021
Annex II Version 4.1 (included new Gas transportation contract examples) 31 March 2022

1 Introduction

Annex II to the TRUM presents examples of transaction reporting for transactions, including orders to trade, related to contracts reportable to the Agency pursuant to Article 3(1) of the REMIT Implementing Acts. The examples in this Annex show what has to be included in the transaction reports of wholesale energy products traded either on auction and continuous markets, or through broker platforms (both on screen and voice-brokered) and bilateral trades.

Important: if reporting entities do not find relevant transaction reporting examples in this document, they are advised to submit a trading example to the Agency. The trading examples should describe the trading scenario and provide suggestions on what to report for each specific transaction. The template for the submission of additional trading examples is available in the REMIT Documents section of the ACER website at https://www.acer.europa.eu/remit-documents/remit-reporting-guidance and should be sent to transaction.reporting@acer.europa.eu once completed.

If reporting entities are still unsure about what has to be included in the transaction reports even after consulting this document, they are advised to contact the Agency via the REMIT Query Form available at https://support.acer-remit.eu/forms/remit-query-form (the relevant question categories related to Transaction Reporting – TRUM Annex II should be selected).

2 The structure of Annex II

Annex II is composed of three sections: Section (1), Section (2) and Section (3):

  a) Section (1): reporting of orders and contracts with Table 1 of the Annex to the REMIT Implementing Acts:

  1. Index of examples included in Section 1
  2. Example of transactions executed on auction markets
  3. Example of transactions executed on continuous markets
  4. Example of transactions executed through brokers (including voice brokered trades)
  5. Examples of bilateral transactions executed off-market
  6. Examples of delivery profiles for both gas and electricity transactions

  b) Section (2): reporting of contracts with Table 2 of the Annex to the REMIT Implementing Acts:

  1. Index and description of examples included in Section 2
  2. Example of non-standard contracts

  c) Section (3) reporting of contracts with Table 3 and Table 4 of the Annex to the REMIT Implementing Acts:

  1. Index and description of examples included in Section 3
  2. Example of Electricity Transportation Contracts
  3. Example of Gas Transportation Contracts

3 The different parts of Table 1 and Table 2

Table 1 of the REMIT Implementing Acts Annex is composed of seven sections:

  1. Parties to the contract
  2. Order details
  3. Contract details
  4. Transaction details
  5. Option details
  6. Delivery profile
  7. Lifecycle information

Table 2 of the REMIT Implementing Acts Annex is composed of six sections:

  1. Parties to the contract
  2. Contract details
  3. Fixing index details
  4. Option details
  5. Delivery profile
  6. Lifecycle information

4 Trading scenarios

The present Annex shows what has to be reported according to Table 1, Table 2, Table 3 and Table 4 of the Annex to the REMIT Implementing Acts.

Trading scenarios included in Annex II encompass transactions, including orders to trade, related to both standards and non-standards contracts. Annex II shows what has to be reported for a specific trading scenario, while the technical implementation, i.e. how to report a trading scenario, is not covered in this Annex. The descriptions of relevant trading scenarios have been included for each example.

It is mandatory to provide input in all the fields that are populated in the examples for each type of transaction. Fields that are blank are not required to be reported for that type of transaction. If a transaction report requires a higher or lower number of fields than what is reported in each trading scenario included in this Annex, that transaction report needs to be covered by a new example. In such a case, the reporting entities are invited to submit that trading example to the Agency using the template available in the REMIT Documents section of the ACER website.

It is responsibility of the reporting parties to make sure their transaction reports comply with the reporting details set out in the REMIT Implementing Acts, further defined in the TRUM, and are aligned the examples reported in this Annex. If reporting parties do not find trading examples that represent their transactions in this Annex, they are advised to submit their trading scenarios to the Agency by completing the template available at https://www.acer.europa.eu/remit-documents/remit-reporting-guidance and sending it to transaction.reporting@acer.europa.eu

However, before reporting parties submit their additional trading examples, they should make sure that this Annex contains no individual examples or any combination of examples which may already represent their reports. Reporting parties may combine, for example, the data fields from one section, e.g. Contract details or Transaction details, with data fields from Delivery profile of another scenario.

For example: if a 15-minute contract trading scenario is not represented in the examples of transactions executed on continuous markets, this should not prevent the reporting party from using the 15-minute delivery profile details used in the examples of transactions executed on auction markets.

The list of examples represented in this Annex will not be able to cover all possible trading scenarios, but combining the examples should make it possible to represent the majority of scenarios. In case market participants and reporting parties have any doubts as to what to include in their trading reports, it is their responsibility to contact the Agency via the REMIT Query Form available at https://support.acer-remit.eu/forms/remit-query-form, where they should select the relevant question categories related to Transaction Reporting – TRUM Annex II.

As regards the technical implementation of transaction reporting and the submission of the XML files, market participants and reporting parties should refer to the Manual of Procedures available at https://documents.acer-remit.eu/category/remit-reporting-user-package/manual-of-procedures-mop-on-data-reporting.

Please read carefully

The fields populated in the trading examples below are mandatory for each type of transaction. Blank fields in the examples are not expected to be populated when reported for that type of transaction. The mandatory nature of the fields in the examples below is in line with the latest version of the TRUM, which provides clarifications on the cardinality of fields from the data reporting point of view.

In some circumstances, reporting parties may provide additional information not required or described in the trading examples simply because it is easier to report what is in their system than it is to sift through the information. This may be the case for the field ‘Total notional amount’ in the order report, where reporting parties may decide to provide this value in the order to trade report even if this field is not required. Such additional information may be reported on the condition that it does not violate the validation rules set by the Agency. In general, the Agency will not reject files containing non-required additional information, unless this is incompatible with the data validation rules set out in the ‘ACER REMIT Information System Data Validation Document’ published in the REMIT Documents section of the ACER website.

Please contact your RRM in case of any further questions about this topic.

For phase one of REMIT transaction reporting (started on 7 October 2015), as regards the technical implementation of transaction reporting and the submission of the XML files, market participants had to liaise with the RRMs that submitted the reports on their behalf. For phase two of REMIT transacting reporting (started on 7 April 2016), i.e. the submission of trades occurring outside organised markets, market participants were able to gain access to the technical standards if they decided to report their own transactions as an RRM.

 

Clarification of standard vs non-standard contract

 Standard vs. Non-standard contracts updated graph

(1) Trades not reported under EU financial legislations

(2) Contracts admitted to trade at organised market places and traded bilaterally

(3) Non-standard contracts with a defined price and quantity (indicated as ‘BILCONTRACT’ in the transaction report under Contract Name in Data Field (22)) and details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price (indicated as ‘EXECUTION’ in the transaction report under Contract Name in Data Field (22)) shall be reported using Table 1 of the Annex to REMIT Implementing Regulation.

 

Decision tree for the reporting of standard and non-standard contracts and the use of Table 1 or Table 2

5 Reporting bilateral contracts traded outside organised market places and executions under non-standard contracts: Table 1

In order to facilitate the reporting of bilateral contracts traded outside organised market places (standard and non-standard contracts with a defined price and quantity) and executions under non-standard contracts, some validation rules for these bilateral contracts are more relaxed than those for orders to trade and trades executed on organised market places.

Market participants and reporting parties have to report bilateral contracts traded outside organised market places and executions under non-standard contracts with Table 1 of the Annex to the Implementing Acts. Before the backloading exercise expired according to the deadlines specified in the Implementing Acts, Table 1 was also used for the reporting of the backloading of standard contracts. Market participants and reporting parties are expected to report the value of ‘BILCONTRACT’, or ‘EXECUTION’ under Contract Name in Data Field (22) according to the trading scenarios available in this Annex.

Please note that Article 5(1) of the Implementing Acts states that ‘Details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price shall be reported using Table 1 of the Annex’. This implies that even if a contract is considered a non-standard contract (reportable no later than within 30 days of its execution) but has an agreed price and quantity, the contract has to be reported using Table 1 of the Implementing Acts. See point 3.2.5 of the TRUM.

‘BILCONTRACT’: should be reported under Contract Name in Data Field (22) of Table 1 to identify standard contracts and non-standard contracts (that have a defined price and quantity, irrespective of default clauses’ application) that are traded outside organised market places.

‘EXECUTION’: should be reported under Contract Name in Data Field (22) of Table 1 to identify the reporting of the details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price. These executions under the framework of non-standard contracts are reportable no later than 30 days after the invoicing date.

‘BACKLOADING’ (no longer applicable): had to be reported under Contract Name in Data Field (22) of Table 1 to identify the reporting of details of wholesale energy contracts which were concluded before the date on which the reporting obligation became applicable and remained outstanding on that date. These contracts had to be reported to the Agency within 90 days of the reporting obligation becoming applicable. Please see also ‘Additional clarification on the back loading requirement’ available in the TRUM (point 3.2.7). Please be aware that the backloading exercise has expired according to the deadlines specified in the Implementing Acts.

For the purpose of reporting the details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price, reportable with Table 1 of the Annex to the Implementing Acts, the Agency understands that these transactions should be reported according to the billing cycle industry standards, as the invoicing date is the last point in time that the price and quantity can be discovered.

The Agency understands that the billing cycle industry standards refer to calendar months and therefore twelve transactions per year (if the executions take place every month of the year) are expected to be reported no later than 30 days after the discovery of price and quantity. However, nothing prevents market participant from reporting the details of transactions executed within the framework of non-standard contracts on a more frequent basis even if the Agency would not expect it.

6 Reporting of non-standard contracts: Table 2

n drafting the guidance on the reporting of non-standard contracts and executions under non-standard contracts, the Agency widely consulted its stakeholders to obtain their valuable input. The Agency and the industry have aligned their understanding of the reporting of non-standard contracts and executions under non-standard contracts and have created some basic reporting rules.

For the purpose of the reporting of non-standard contracts that do not have a defined price and quantity (at the time entering into the contract), non-standard contracts may have different characteristics based on:

a) volume scenarios;

b) price scenarios; and

c) delivery scenarios.

Each of the above scenarios has some variations; their descriptions can be found below. In the contract scenario descriptions below, each volume scenario is represented by scenarios (V1) to (V5), each price scenario by scenarios (P1) to (P5), and each delivery scenario by scenarios (D1) to (D4).

a) Volume Scenarios

1. Fixed Flat Volume Scenario (V1): Supply to a customer in Europe for a term of one calendar year (e.g. 2016) with a fixed daily supply. No customer volume optionality.

2. Simple Nominated Volume Scenario (V2): The customer must nominate changes in offtake within a defined period prior to delivery period. For example, the delivery is for the 2016 calendar year and the customer sends a monthly nomination three days before the start of the delivery month. The offtake nomination must be within a contract-defined MIN/MAX range.

3. Cascade Nominated Volume Scenario (V3): The customer can choose to nominate changes in offtake using a time cascade of deadlines. The customer could nominate a next month delivery three days before the end of the month prior to delivery month, or choose to nominate volume a day ahead, or could use a combination of both, nominating ‘certain’ volume a month ahead and refining that offtake with day-ahead nominations. The offtake nomination must be within a contract-defined MIN/MAX range.

4. Not Nominated (full supply) Volume Scenario (V4): The customer takes the volume required at the factory gate without giving any prior nomination of offtake. There will be an estimated profile provided before the contract deliveries begin but on any day offtake can be anywhere between zero and the capacity of the pipeline feeding the plant.

5. Fixed Shape Volume Scenario (V5): The customer contract defines the daily volume that will be delivered during the summer and a separate (different) daily volume that will be delivered during the winter. The customer has no flexibility to change the defined seasonal deliveries – daily delivered volume will be the same for every day of the season.

b) Price Scenarios

1. Fixed Price Scenario (P1): Supply to a customer for a term of one calendar year at a fixed price, e.g. 20 EUR/unit for the year.

2. Trigger Price Scenario (P2): The customer can choose to fix the price of a future delivery period at the closing forward price (e.g. as published by an organized market place or a price intelligence service) for that forward period on the day the trigger is pulled. However, if the price is not fixed, the contract price will default to a contract-specified index, e.g. day-ahead.

3. Index Basket Scenario (P3): First, the contract price is determined by a basket of indexes calculated over a specified period (for the average of closing prices), then the contract is characterised by a specified period between the end of the calculation period and the beginning of the delivery period (the ‘lag’), and finally the calculated price is applied to a specified delivery period (model X-Y-Z). For example, for a calendar year 2016 delivery with the calculation averaging over three months, delivery beginning immediately after the end of the averaging period and the calculated price applied to a three-month period, the model would be 3-0-3, with X=3 months, Y=0 (delivery starts immediately after the calculation period), and Z=3 months.

4. Index Switch Scenario (P4): The contract price is determined by one of two defined indexes, where three days prior to the pricing period the customer can nominate one index for the calculation. For the chosen index there is a specified period (for the calculation of the average of closing prices), a specified period between the end of the calculation period and the beginning of the delivery period (the ‘lag’) and a specified delivery period to which the calculated price applies (model X-Y-Z as described above). For example, for a calendar year 2016 delivery with the calculation averaging over three months, delivery beginning immediately after the end of the averaging period and the calculated price applied to a three-month period, the model would be 3-0-3, with X=3 months, Y=0 (delivery starts immediately after the calculation period), and Z=3 months.

5. Simple Index Scenario (P5): The contract price for the month of delivery for a calendar year 2016 delivery is calculated as the average of the closing price of the front-month futures contract for the last calendar month of trading days prior to the month of delivery. For example, the price for the delivery of the calendar year contract ‘January 2016’ is the average of the January 2016 futures closing prices during the month of December 2015.

c) Delivery Scenarios[1]

1. Fixed Delivery Scenario (D1): Delivery to a single identified delivery point over a one year period with the same volume delivered every hour of every day.

2. Delivery Point Switching Scenario (D2): The customer can choose to be 100% supplied at one of two different locations specified in the contract (with two separate EIC codes[2]) and must nominate their choice three days before the delivery for the next month starts. This choice will be valid until the end of the contract, or until a new nomination is done three days before a new delivery month starts.

3. Multiple Fixed Point Delivery Scenario (D3): Same as the Fixed delivery scenario, but the delivery is split using fixed percentages (that add up to 100%) between three different locations. The fixed percentages cannot change during the contract term.

4. Multiple Variable Point delivery Scenario (D4): Same as the Multiple fixed point delivery scenario, but the customer can change the percentage split (possible for up to two percentages to be 0% but the total must add up to 100%) between three different locations. The customer must nominate their choice three days before the delivery for the next month starts. The choice will be valid until the end of the contract, or until a new nomination is done three days before a new delivery month starts.

a) Volume scenarios: table reporting volume scenarios described above with some example values for relevant fields referring to transaction reporting with Table 2 of REMIT Implementing Acts

    V1 V2 V3 V4 V5
Field # Field name Fixed Flat Simple Nominations Cascaded Nominations No-nominations (Full Supply) Fixed Shape
  Short definition: If volume, shape and duration known them populate, otherwise blank
18 Total notional contract quantity volume x days blank blank blank (Winter daily vol. x days) + (Summer daily vol. x days)
  Short definition: Indicate either agreed volume or maximum / minimum values, as stated in the contract, otherwise blank
19 Volume optionality capacity 100 0-2400 0-2400 blank 100,000 and 400,000
20 Notional quantity unit MW MW MW Therm mcm
  Short definition: Reflect type of volume optionality: V = Variable, F = Fix, M = Min/Max, C = Complex, O = Other (see accepted values in TRUM)
21 Volume optionality F M M V F
  Short definition: How often can customer exercise optionality. If no optionality, left blank
22 Volume optionality frequency blank M D blank blank
  Short definition: The earliest date on which a customer can exercise their optionality and also the last possible date in the contract term on which optionality can be exercised. If no optionality, left blank
23 Volume optionality intervals 29-12-2015/29-12-2015 29-12-2015 / 28-11-2016 29-12-2015 / 30-12-2016 blank 29-12-2015/29-12-2015

Please note that “blank” means empty field

b) Price scenarios: table reporting price scenarios described above with some example values for relevant fields referring to transaction reporting with Table 2 of REMIT Implementing Acts

    P1 P2 P3 P4 P5
Field #  Field name Fixed Trigger Index Basket Index Switch Simple Index
15 Price or price Formula 20 Simplified Formula Simplified Formula Simplified Formula Simplified Formula
  Short definition: If volume, shape, price and duration are known on the contract date then populate, otherwise blank
16 Estimated notional amount Price x daily volume x days Blank Blank Blank (Price x Winter daily vol. x winter days) + (Price x summer daily vol. x summer days)
17 Notional currency EUR EUR EUR GBP EUR
  Short definition: Price classified as fixed, simple index (single underlying), complex price formula (multiple underlying), or other
24 Type of index price F O C C I
  Short definition: List all indexes used in the formula (if there is one) otherwise blank
25 Fixing index Blank Blank GO FM mid, NG FM mid,  CPI UK GO FM mid, NG FM mid FM Close
  Short definition: Futures, Forward or other. Completed in sequence (Data Fields (24) to (30)) for each index
26 Fixing index types Blank DAH FU, FW, OT FU, FW FU
  Short definition: Publication source. Completed in sequence (Data Fields (24) to (30)) for each index
27 Fixing index sources Blank Heren ICE, Heren, UK Stats ICE, Heren ICE
  Short definition: Earliest date when the first price is included for the calculation of that index - e.g. For a front-month index (average of closing prices for last month before expiry) then January 2016 front month will be the average of closing January futures prices averaged from 1 December to 26 December 2015, so this field would be populated as 01-12-2015
28 First fixing date Blank 2015-12-01 2015-12-01 2015-12-01 2015-12-01
  Short definition: Similar to Data Field (28), but the last day. So if contract is calendar 2016 deliveries with front-month pricing, then the last date would be the last pricing date of December 2016 futures contract, say, 27 November 2016, so populate field as 27-11-2016
29 Last fixing date Blank 2016-12-30 2016-09-30 2016-09-30 2016-11-27
  Short definition: How long is the closing price averaging period
30 Fixing frequency Blank O Q Q M

Please note that “blank” means empty field

c) Delivery scenarios: table reporting delivery scenarios described above with some example values for relevant fields referring to transaction reporting with Table 2 of REMIT Implementing Acts

    D1 D2 D3 D4
Field # Field name Fixed Delivery switch Multiple points  (Fix %) Multiple points (Variable %)
  Short definition: Table 2 fields do not enable you to distinguish between switching between delivery points or adjusting the volume delivered at multiple points, so include all delivery points where it is possible to deliver (according to the contract)
41 Delivery point or zone 10YCB-EUROPEU--8
  • 10YCB-EUROPEU--8
  • 10YCB-EUROPEU-9
  • 10YCB-EUROPEU--7
  • 10YCB-EUROPEU--8
  • 10YCB-EUROPEU-9 1
  • 0YCB-EUROPEU--7
  • 10YCB-EUROPEU--8
  • 10YCB-EUROPEU-9
  • 10YCB-EUROPEU--7
  Short definition: First delivery date according to contract
42 Delivery start date 2016-01-01 2016-01-01 2016-01-01 2016-01-01
  Short definition: Last possible date of delivery according to the contract
43 Delivery end date 2016-12-31 2016-12-31 2016-12-31 2016-12-31
  Short definition: Identification of the delivery profile (base load, peak load, off-peak, block of hours or other). Considering an example on natural gas contract, the shape for natural gas is always GD
44 Load type GD GD GD GD

Please note that “blank” means empty field

Combining the volume, price and delivery scenarios: examples

The combination of a volume scenario with a price scenario and a delivery scenario should be able to represent most of the non-standard contracts that have to be reported to the Agency. Based on the scenarios above, there are 100 (5 volume X 5 price X 4 delivery) possible scenarios that market participants and reporting parties should be able to represent.

Example 1: a market participant may want to report a contract with the following combinations:

a) Volume scenario: (V4) - Not Nominated (full supply)

b) Price scenario: (P5) - Simple Index Scenario

c) Delivery scenarios: (D1) - Fixed Delivery Scenario

Contract Description:

a) V4: The customer takes the volume required at the factory gate without giving any prior nomination of offtake. There will be an estimated profile provided before the contract deliveries begin but, on any day, the offtake can be anywhere between zero and the capacity of the pipeline feeding the plant.

b) P5: Contract for a calendar year 2016 delivery. The contract price for the month of delivery is calculated as the average closing price of the front-month futures contract for the last calendar month (only trading days)prior to the month of delivery i.e. January 2016 delivery price is the average of the January 2016 futures closing prices during the month of December 2015.

c) D1: Delivery to a single identified delivery point over a one-year period with the same volume delivered every hour of every day.

  Full Supply / Simple Index Price / Fixed Delivery Point   
N Field Identifier (buyer side) (seller side)
  Contract details    
11 Contract ID LTC0001 LTC0001
12 Contract date 2015-07-18 2015-07-18
13 Contract type FW FW
14 Energy commodity NG NG
15 Price or price formula Avg(FMC(month-1)) Avg(FMC(month-1))
21 Volume optionality V V
  Fixing index details    
24 Type of index price I I
25 Fixing index Front Month Close Front Month Close
26 Fixing index types FU FU
27 Fixing index sources ICE ICE
28 First fixing date 2015-12-01 2015-12-01
29 Last fixing date 2016-11-27 2016-11-27
30 Fixing frequency M M
31 Settlement method P P
  Delivery profile    
41 Delivery point or zone 10YCB-EUROPEU--8 10YCB-EUROPEU--8
42 Delivery start date 2016-01-01 2016-01-01
43 Delivery end date 2017-12-31 2017-12-31
44 Load type GD GD

Example 2: a market participant may want to report a contract with the following combinations:

a) Volume scenario: (V3) - Cascade Nominated Volume Scenario

b) Price scenario: (P3) - Index Basket Scenario

c) Delivery scenarios: (D3) - Multiple Fixed Point Delivery Scenario

Contract Description:

a) V3: The customer can choose to nominate changes in offtake using a time cascade of deadlines. The customer could nominate next month delivery three days before the end of the month prior to delivery month, or choose to nominate volume a day ahead, or could use a combination of both, nominating ‘certain’ volume a month ahead and refining that offtake with day-ahead nominations. In this example, delivery is for the calendar year 2016.

b) P3: First, the contract price is determined by a basket of indexes calculated over a specified period (for the average of closing prices), then the contract is characterised by a specified period between the end of the calculation period and the beginning of the delivery period (the ‘lag’), and finally the calculated price is applied to a specified delivery period (model X-Y-Z). For example, for a 2016 calendar year delivery with calculation averaging over three months, delivery beginning immediately after the end of the averaging period and the calculated price applied to a three-month period, the model would be 3-0-3, with X=3 months, Y=0 (delivery starts immediately after the calculation period), and Z=3 months.

c) D3: Same as Fixed delivery scenario, but the delivery is split using fixed percentages (that add up to 100%) between three different locations. The fixed percentages cannot change during the contract term.

  Cascaded Nom / Index Basket Price / Multiple Fixed Delivery Points 
N Field Identifier (buyer side) (seller side)
  Contract details    
11 Contract ID LTC0001 LTC0001
12 Contract date 2015-07-18 2015-07-18
13 Contract type FW FW
14 Energy commodity NG NG
15 Price or price formula Avg(GO FM mid,NG FM mid) Avg(GO FM mid,NG FM mid)
19 Volume optionality capacity 0-2400 0-2400
20 Notional quantity unit MW MW
21 Volume optionality M M
22 Volume optionality frequency D D
23 Volume optionality intervals 2015-12-29 / 2016-12-30 2015-12-29 / 2016-12-30
  Fixing index details    
24 Type of index price C C
25 Fixing index GO Front Month mid GO Front Month mid
26 Fixing index types FU FU
27 Fixing index sources ICE ICE
28 First fixing date 2015-12-01 2015-12-01
29 Last fixing date 2016-09-30 2016-09-30
30 Fixing frequency Q Q
24 Type of index price C C
25 Fixing index NG Fronth Month mid NG Fronth Month mid
26 Fixing index types FW FW
27 Fixing index sources Heren Heren
28 First fixing date 2015-12-01 2015-12-01
29 Last fixing date 2016-09-30 2016-09-30
30 Fixing frequency Q Q
31 Settlement method P P
  Delivery profile    
41 Delivery point or zone 10YCB-EUROPEU--8 10YCB-EUROPEU--8
41 Delivery point or zone 10YCB-EUROPEU-9 10YCB-EUROPEU-9
41 Delivery point or zone 10YCB-EUROPEU--7 10YCB-EUROPEU--7

7 Reporting of executions under the framework of non-standard contracts

The executions under the framework of non-standard contracts have to be reported with Table 1 of the Annex to the Implementing Acts.

To see examples please download the PDF version of Annex II below.

Disclaimer on TRUM Annex II examples [NEW]

The examples in the TRUM Annex II are intended to provide guidance to market participants and reporting parties on how standard, non-standard, and transportation contracts shall be reported to the Agency within the data reporting obligations.

All identification codes, including delivery point or zones or contract ID and contract names adopted in the examples in following sections, are fictitious and are not based on any real events or codes.

In particular, when dealing with Data Field (48) Delivery point or zone, typically the following codes have been adopted in the examples:

10YXX-EUROPOW--8 or 10YXX-EUROPOW—8 or 10YXX-EUROPOW--9 or 10YXX-EUROPOW--10 (electricity contracts)

10YXX-EUROGAS--8 or 10YEU-EUROGAS--8 (natural gas contracts)

Such codes are not intended to represent real delivery point or zone codes.

Data Field (48) Delivery point or zone should be populated according to Annex VI of the TRUM and the List of the Accepted EIC codes available in the REMIT Documents section of the ACER website.

 


[1] Delivery points or locations to be indicated in the field(48) in Table 1 and field(41) in Table 2 have to be chosen among the EIC codes reported in the List of Accepted EIC codes published in the REMIT Documents section of the ACER website.

[2] Please see footnote 1.

Download ANNEX II - Examples of Transaction Reporting

Updated: 
31/03/2022