FAQs on transaction reporting – Question II.3.2.3

Data field (16) and (18)

Regarding the reporting of transactions with big energy consumers, should the field “contact date” indicate the date of signature of the contract or the date of the preliminary contract already binding?


Answer:

The reportable date of the contract is the date of the first binding agreement.

For historical contracts the date of the last adjustment should be used at the time of reporting (new report).

The last adjustment in this context is the last agreed contract modification, which would be a life cycle event modification to the previous contract version, once the reporting obligation started.  An example of a contract modification is when two parties agree to amend one or more terms of the original agreement (e.g. price, quantity) or any other information from the contract that would need to be reported as life cycle event, once the reporting obligation started.

Any following adjustment should be reported as life cycle event (modification).

For example, if a contract was signed in 2005 and reported as backload (new report), this should report the 2005 date:

Example 1: Contract signed in 2005 and reported to the agency in April 2016: the date to be reported is 2005.

If a contract was signed in 2005 and adjusted in 2015, then the report (new report) should show the 2015 date:

Example 2: Contract signed in 2005 and adjusted in July 2015 and reported to the Agency in April 2016: the date to be reported is July 2015.

Once the contract is reported to the Agency, then any amendment to it should be reported as life cycle event (modification) of the original contract:

Example 3, the contract was already reported to the Agency in April 2016 and modified in July 2016. This should be reported as modification report to the original contract with July 2016 date.

Please note that the REMIT Implementing Regulation makes reference to Article 40(1) of Directive 2009/72/EC and Article 44(1) of Directive 2009/73/EC which stipulate record keeping obligations of at least five years for the relevant data relating to all transactions in electricity and gas supply contracts and electricity and gas derivatives.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.2.4

Data field (16) and (18)

The quantity required by the TRUM description to calculate both the values for fields “Total notional contract quantity” and “Estimated notional amount” is the one in field “Volume optionality capacity”.

Our understanding is that in the field “Volume optionality capacity” the Contractual Capacity shall be reported. Considering the typical structure of non-standard contracts, where Capacity is a maximum threshold for the physical offtake, and it is variable due to flexibility of deliveries, if Capacity is used as volume indication to calculate the “Estimated notional amount”, that will be overestimated in the most of the contracts, since usually a customer offtakes much less volumes than the Contractual Capacity. We would rather indicate the best estimate of the offtake in available (i.e. Total notional contract quantity) as volumes to estimate the Economic value of the contracts.

We would like to understand whether our interpretation is correct.


Answer:

As stated in the Transaction Reporting User Manual (TRUM), we understand that without a defined quantity in the contract, market participants will only be able to provide an estimated notional contract quantity that may differ from market participant to market participant.  We would expect the best available estimate of the offtake in “Total notional contract quantity” as volumes to estimate the economic value of the contracts. Where the total notional contract quantity is not known this field shall be left blank.

Please see the examples in Annex II to the TRUM.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.2.5

Data field (19)

It seems that there is an inconsistency between the example in the TRUM and the type definition in the xsd. The following field is affected:

Non-Standard Contract: (19) Volume optionality capacity

The TRUM-example (ACER_REMIT_TRUM_v2 0.pdf) is alphanumeric with the values “100/200”

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 Example
Up to 20 alphanumerical digits. Alphanumeric 20 100/200

 

while in the xsd (REMITTable2_V1.xsd  03/11/2015)  it is defined as numberType which is an decimal with 20 digits and 5 fraction digits.

Please could you clarify how to report different optionality intervals/ranges?


Answer:

Whenever a capacity value must be reported, this needs to be reported with the capacity unit, start and end date along with it. Please see below:

When multiple values of capacity have to be reported, e.g. 0 /100 (o to 100 range) or 0, 100/200 (0 or 100 to 200 range) then the xml code has to be reported as many time as the number of capacity values (numberType).

Also it is worth taking a look at the mapping between the Table 2 data fields and the XSD schema Table2_v1. This document is available on the REMIT portal. The document explains the mapping between Table 2 fields and Table2_v1 schema.

Indicating a 0-100 range should be reported as:

faqs-on-transaction-reporting-question-ii-3-2-3-text

Indicating 0 or 100 to 200 range should be reported as:

faqs-on-transaction-reporting-question-ii-3-2-3-text2

Given that start and end date become mandatory fields when a capacity value is reported in the xml file and, if for some reasons, Start and Date is not applicable to the capacity value, then 1900-01-01 should be used to indicate that no optimality intervals are available:

faqs-on-transaction-reporting-question-ii-3-2-3-text3

Alternatively, the start and end dates, fields No. (42) and (43) period can be used.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.2.6

Data field (21), (22) and (23)

We hereby request your answer to our below questions in connection with the interpretation of the reporting obligations under the “Implementing Acts.

On the basis of Article 5 (1) of the Implementing Acts, 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. According to Section 3.2.5 of the REMIT Transaction Reporting User Manual, even if the contract is considered a non-standard contract, but has an agreed price and quantity, the contract has to be reported using Table 1 of the Implementing Acts.

Can you please confirm that our below interpretation is correct, or in case any of our below statements would not be correct, we would be grateful if you could please provide us with your interpretation:

  • Fields No 21 to 23 of Table 2 of the Implementing Acts provides for the possibility to report optionality of the volumes supplied under a given contract. In our interpretation, the right of the purchaser under the Contract to waive its right to off-take a pre-defined percentage of the monthly and daily volumes of electricity may be reported in Fields No 21 to 23 of Table 2.

Answer:

The above interpretation is correct. Market participants may refer to Annex II to the Transaction Reporting User Manual (TRUM) which contains examples of transaction reporting for both standard and non-standard contracts. Section (2) of Annex II contains examples of non-standard contracts to be reported with Table 2 of the Annex of the REMIT Implementing Regulation.

In Annex II of the TRUM, our understanding of the reporting of non-standard contracts and the execution under non-standard contracts is presented.  In addition, some basic rules for their reporting are listed.

The Guidance is supported by examples of non-standard contracts which include the possibility to report optionality of the volumes supplied under a given contract.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.2.13

Data field (28) and (29)

In the fields “First fixing date” and “Last fixing date”, our understanding is to report the first and the last date of application of the price index within the contractual period, coherently with the example (e.g. If the XYZ index is used to calculate the price from the 1/03/16 to the 1/09/16, the 2 dates will be respectively the first and the last fixing dates). Furthermore, regarding field “Fixing frequency” our understanding is to report the frequency related to the publication of the index values from the provider. Is our interpretation correct?


Answer:

As stated in the Transaction Reporting User Manual (TRUM), market participants have to use the “First fixing date” and “Last fixing date” fields to report the first date and last date, respectively, 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 are used to set the contract price, then 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). Same applies to “Last fixing date”.

With regard to “Fixing frequency” this field identifies the frequency of the fixing of the index for the contract price.  For example, a contract price can be set on the basis of an index that is used daily or on the basis of an index that it is used monthly.

RSS_Icon Last update: 16/02/2016  

RSS_Icon Subscribe to this Category’s RSS