FAQs on transaction reporting – Question II.3.3.4

How should bilaterally traded contracts (with a floating price) and an option to fix the price be reported, once the fixing has been executed by the buyer?

Should the price fixing event be reported as lifecycle event update to the existing contract, or instead reporting the fixing as a separate ‘new’ contract?

Company X sells 20MW/h +/-10% Q116 gas to counterparty ‘XYZ’ @ TTF + 2 and counterparty ‘XYZ’ decides to fix 10MW/h Q116 at 24.  We then invoice each month 10MW/h at 24 and leftover consumed gas at arithmetic average of daily TTF quotations +2.


Answer:

Please see Annex II to the TRUM. In Section 2 of the annex there are several examples on how to report bilaterally traded contracts (with a floating price) and an option to fix the price that is being reported, once the fixing has been executed by the buyer.

For any of above types of optionality, such as the daily flexibility, there is no expectations of reporting on a daily or individual basis, but on an aggregated basis according to the guidance provided in Annex II to The TRUM.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.3.5

Regarding the reporting of transactions with big energy consumers, does the exercise of a contractual right of a transaction already registered (e.g a “price switch” clause which allows the customer to modify the contractual price formula for part of offtaken quantities and contractual period) generate a new duty of reporting?


Answer:

Please see Annex II to the TRUM. In Section 2 of the annex are several examples on how to report bilaterally traded contracts (with a floating price) and an option to fix the price that is being reported, once the fixing has been executed by the buyer.

For any types of optionality, such as the daily flexibility, there is no expectations of reporting on a daily or individual basis, but on an aggregated basis according to the guidance provided in Annex II to the TRUM.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.4.1

Modification of Execution events. When we are sending an execution event in Table1 that links to a trade in Table2 the examples say that the UTI of those events is “NA”.

This would work for the New event.

What would we do if there is the need to modify an execution event if there is no unique ID on the original “New” record?


Answer:

The Agency has received additional input from its stakeholders who raised the issue of the modification of the EXECUTION report. They suggested to allow for the reporting of a unique number in the UTI field in case of modification.

Please note that for the purpose of the reporting of the details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price and reportable with Table 1 of the Annex to the Implementing Acts, the examples presented in Annex II to the TRUM have been modified to reflect the input provided by the industry to the Agency.

In particular, the Agency’s stakeholders have highlighted and requested the need to assign a unique number to the each execution reports in Field (31) Unique Transaction ID of Table 1.

This requirement makes sure that in case it is needed to report a modification report this can be submitted to modify a previously reported execution uniquely identified in Field (31) Unique Transaction ID of Table 1.

The Unique Number can be any number the market participant likes as long as it is unique for that market participant and not used for other executions. It could be, for example, any progressive unique number for the market participant who is reporting the execution.

There is no expectation that the buyer and seller unique number for the execution will have to be the same. This is a unique number that will identify the report uniquely.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.4.2

What UTI should be reported for the reporting of EXECUTIONS where the Market Participant does not have a UTI for the trade?

Example: Prior to Oct 7, participant enters into a trade. No UTI is assigned to the trade. Trade is still open on Oct 7 and therefore needs to be reported as a back loaded trade.

The Market Participant may omit the UTI for such trades.


Answer:

The UTI is a mandatory field in the schema. For executions under the framework of non-standard contracts where the market participant does not have an UTI for the trade, the market participant should create one.

The UTI is needed for the ID of the record, otherwise the market participant will not be able to make any amendments and/or recall the transaction.

The UTI can be anything the market participant would like to submit e.g. the transaction ID available in their system.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.4.3

We need to understand how quantity data for Non-Standard Contracts are required for transaction reporting according to REMIT.

We act as Direct Marketer in Germany with a portfolio of wind and solar based virtual power plants. Typically these PPAs are agreed with a 1-2 year duration. We just purchase from the power plant operator the whole production based on actual values.

When we sign the contract we need to report such a new deal with Action Type New and Quantity field empty (because the actual values are not available yet. The actual values are available from the DSOs (around 99% completeness) until 10 working days after each delivery month, and they are usually available with 100% completeness before the Balance Circle Agreement (8 months after delivery month).

The question is now when we need to report modified transactions for these PPAs and based on which data? Shall we report each month the actual values of the previous delivery month even if they are not yet complete?

Another question is the 30 day rule. Is the obligation to report the transaction within 30 days only related to new transactions (Action Type new) or also related to any modifications later on?

Further question regarding Field 41 Delivery Area: What should be represented by this Y EIC Code – the TSO area (which is a 16 digits Y Code) or the DSO Delivery area (which is a 16 digits Y Code as well). I´m already sure the balance circle of the Balance Responsible is not meant as this a 16 digits X Code.


Answer:

For the purpose of the reporting of 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 REMIT Implementing Regulation (EU) No 1348/2014, 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 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 not later than 30 days after the discovery of price and quantity. Although the actual values are available from the DSOs, the Agency currently would not expect any life-cycle event based on actual values available from the DSOs.

With regard to the timing of the reporting,  if a “new” report is due to be reported on T+1 basis, all the life cycle events related to that report have to be reported on a T+1 basis. If a “new” report is due to be reported on T+1 month basis, all the life cycle events related to that report have to be reported on a T+1 month basis.

With regard to the second part of the question, as indicated in the TRUM, Field 41 Delivery Area identifies the commodity delivery point or zone. In this specific case, the delivery area is the TSO EIC Y code of the balancing area for which the market participant has a balancing agreement with the TSO. This is the area where the market participant delivers the energy commodity through nominations/scheduling.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.4.4

In our opinion the transaction executed under the framework of a non-standard contract (paragraph 3.2.6 of the TRUM in the separated box), is the inception of the contract itself (i.e. signature of the contract) or contractual amendments issued. On the contrary the specific lifecycle events that occur after the signature (e.g. price switch, additional quantities) are the mere exercise of a contractual right. Could you confirm it?


Answer:

In the Agency’s view the explanation in paragraph 3.2.6 of the Transaction Reporting User Manual (TRUM) in the separated box is clear: each exercise of the contractual right is a reportable transaction.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.4.5 [DELETED]

The question was deleted due to duplication.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.4.6

Regarding contracts with a joint venture of producers of certain fields, it could be the case that there are separate contracts with each of the parties participating in that field, but that invoicing is done with only one partner, often referred to as ‘the operator’ of the field. Do we have to report one execution on the basis of this invoice and refer to only one of the contracts’ IDs, or do we have to report the invoice as many times as the number of counterparties to contracts related to the same field? In the latter case, do we have to report the same amount multiple times.


Answer:

Where there are separate contracts with each of the parties participating in that field, those contracts should be reported separately, allocating the delivered volume to the respective contracts (counterparties) and report as many transactions as the number of counterparties to contracts related to the same gas field.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question II.3.4.7

Reference to documents: TRUM 2.0 page 20

We  would like to discuss a trading example and ask you how to report it:

Scenario:

  • Company A sells electricity (bilateral, physical settlement) to Company B for the whole year to spot market conditions
  • Company B pays twelve equal monthly payments to Company A. The amount of the payments is estimated before the beginning of the year. The estimation is based on the volume that was sold the year before and the estimated prices in this year. The monthly bills therefore don’t display a volume.
  • At the end of the year, there is a final invoice. The final invoice is offset with the twelve payments. The final invoice displays the sold volume in this year (it is calculated after the whole year) and the calculation of the difference between the twelve monthly payments and the sold volume to a specific price (derived by the spot market). The final invoice can be positive or negative depending on whether the sum of the monthly payments is above or below the sold volume x sold price.

In our understanding we should use REMIT Table 2 scheme to report the contract (no quantity and price is known before the final invoice). And for the execution it is our understanding that we report the transaction for the whole year using the final invoice with the defined price and volume at the end of the year (table 1)?

In our understanding we shouldn’t report the monthly payments (TRUM 2.0 page 20) because there is no specifying of an outright volume and price.


Answer:

Based on the information provided above, it is our view that the contract should be reported by using Table 2 and one EXECUTION at the end of the year. Please note that this would apply only to contract with pre-payments.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.3.4.8

The question is about submitting the notional amount (Data Field R1.38). We would do so in a monthly rhythm. There are three dates where we get new information about the amount in month M, i.e. M+1WD, M+14WD, and 2M-10WD (WD being working days). The initial amount could be corrected twice in the course of two month following the month of delivery.

We wonder if we are to correct execution messages as well and if we have to do so every month separately or after the end of the calendar year for the whole delivery year.

In the FAQ document we found Question 3.4.3 which reads that “…the Agency currently would not expect any life-cycle event based on actual values available from the DSOs.” How is this quote to be interpreted to the effect of submission of executions?


Answer:

As stated in FAQ 3.4.3 there is no expectation to update submitted EXECUTION reports unless Market Participants prefer to do so.

RSS_Icon Last update: 10/07/2017  

RSS_Icon Subscribe to this Category’s RSS