Please insert at least 3 characters

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  

FAQs on transaction reporting – Question II.3.4.9

Is an execution message required for a delivery period without supplied volumes?

A non-standard contract provides the client with flexible rights to offtake the quantity. During a certain period (especially summer period for gas) there is no delivery under the contract.

Page 20 of the TRUM and FAQ 3.1.1 requires to report update messages of the table 2 contract as soon as the market participants are aware about the “outright volume and price for transactions executed within the framework of non-standard contracts”. This does not explicitly refer to positive volumes. Our interpretation is that also periods without delivery should be reported to ensure that a report for all periods is available. But this would lead to zero values for field 41 of the execution messages which might be contradicting to the opinion of the open letter.


Answer:

Market participants should report the delivered energy as indicated in the execution report. When there is no delivery, there is no need to report execution.

However, where the framework of a non-standard contract allows for the sale and purchase of energy under the same contract, market participants should NOT net those EXECUTIONS, as they may in some circumstances lead to 0 (zero) volume at the end of the month.

Market participants should report the sold and bought volumes separately with different EXECUTIONS reports.

RSS_Icon Last update: 20/07/2018  

RSS_Icon Subscribe to this Category’s RSS