Please insert at least 3 characters

FAQs on transaction reporting – Question II.3.2.1

Data field (4)

Reference to documents:

  • REMIT-EU 1227/2011, Article 9, paragraph 1
  • Guidance on the application of REMIT, 3rd Edition, Updated 3-June-2015, Section 3.5
  • FAQs on REMIT transaction reporting, item II.2.6
  • ARIS Data Validation v2.1 , section 6.3.2.
  • ARIS Data Validation Rules configuration V3.1 (Rule AT2F15R1 has been disabled on both Testing Framework and Production)

How field (4) of Table 2 “ID of the other market participant or counterparty” in a bilateral transaction should be populated when the other counterparty (non-EU member) does not have an ACER code but is a REMIT participant.

Example: In a reportable Bilateral Contract the “other Market Participant” (counterparty) is a non-EU member but refuses to register for obtaining an ACER code.

Given that according to:

1. FAQs on REMIT transaction reporting, item II.2.6, the fictitious ACER code ACERNONMP.EU is used for cases that the counterparty is a non-REMIT market participant

2. ARIS Data Validation Rules configuration V3.1, the Rule AT2F15R1 has been disabled on both Testing Framework and Production

There are 2 possible solutions:

1. To populate field 4 with any of the codes (EIC/BIC/ LEI/GLN/GS1) if available

OR

2. To populate field 4 with a fictitious code similar to the abovementioned but to clearly indicate that is a non EU non-registered REMIT participant, e.g. ACERNONEU.MP  (this approach covers the (rare) case the said participant does not have any of the EIC/BIC/ LEI/GLN/GS1 codes).


Answer:

Field (4) of Table 2 “ID of the other market participant or counterparty” in a bilateral transaction should be populated with one of the allowed codes if the other counterparty to the contract is a REMIT registered market participant otherwise ACERNONMP.EU  to indicate the counterparty to the contract is not a registered market participant.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.2.2

Data field (11)

Frequently Asked Questions (FAQs) on REMIT transaction reporting – II.2. Questions related to standard contracts Question 2.1.26

The question addresses the issue of assigning a UTI for back loaded standard contracts and states that as the field is mandatory that a UTI is required, but that this doesn’t have to match with the other market participant.

Under the obligation to report non-standard contracts, there is the same issue with regards to the Contract ID for contracts that are subject to back loading; as such the same logic should apply.

Party A and Party B have to report a non-standard contract that is subject to the back loading requirement. As this contract was in existence prior to the obligation to report, a Contract ID will not have been allocated to the contract.


Answer:

Non-standard contracts that are subject to the back loading requirement under REMIT should be reported with a Contract ID, but there would be no expectation that the Contract ID used will match between the two market participants for back loaded contracts.

The Contract ID is required because otherwise the market participant will not be able to link the executions to the contract. The Contract ID can be anything the market participant would like to submit as long as it is unique to the market participant and does not need to match the Contract ID of the other market participant.

RSS_Icon Last update: 24/03/2016  

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.7

Data field (21)

Table 2 Field 21 – Volume optionality

How do we differentiate between “C” for Complex and “O” for Other?

Especially as there are no examples in the TRUM that use “O”.


Answer:

From the Agency’s point of view, “C” for Complex should cover all the cases where the volume optionality cannot be classified as one of the non-Complex options (i.e. Variable, Fix or Min/Max). We are currently not aware of any possible use of “Other”.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.2.8

Data field (24)

Reference to documents: Transaction Reporting User Manual, page 91

Is it mandatory, to fill Table 2, Field 24? If not, what are the features of the contract that release the obligation to report this information? TRUM shows a list of possible values to fill – it allows “Other”, suggesting that this field covers any situation that may occur in practice. Moreover, description does not include any exceptions concerning reporting obligation, which took place in many other fields (in such cases ACER stipulated, that the data are not required if certain conditions are met). On the other hand, i.e. example 2.01 (p. 182 of Annex II to TRUM) field is left blank, indicating existence of specific features of the contract, for which the field may be left blank. We expect the field to be obligatory, despite missing values in provided examples.


Answer:

Table 2 field 24 is NOT a mandatory field in the XSD schema and it should be used according to the examples provided in Annex II to the TRUM.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question II.3.2.9

Data field (24) to (31)

Table 2 Fields 24 to 31 – Data fields related to fixing index details

For non-standard trades with the delivery price linked to a formula, if the formula includes an FX index used to convert the currency of the fixing into the currency of settlement, does that FX index need to be reported in this section.

Annex II: Example 9.01 – Oil Index Gas Physical Formula Deal.

The above example in the TRUM would imply the answer to this question is NO – i.e. you do not have to report FX indexes in this section.

Could ACER explicitly confirm this and detail any other types of indexes or fixings that would NOT need to be reported in this section (if any)?


Answer:

There is no need to report an FX index in the fixing index details session (fields 24 to 30 of Table 2). If any FX index has to be reported, it can be reported in the formula. Only indexes related to the energy commodity should be reported in the fields from 24 to 30 of Table 2.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.2.10

Data field (24) to (30)

Reference to documents: TRUM – Table 2 Reporting – Fixing Index Details (Fields 24-30)

Are FX indexes reportable under this section of Table 2?

If we have transaction to deliver physical gas, with the GBP or EUR price payable linked to a complex formula of USD Oil, the formula will contain a FX conversion index such as Bank Of England reference rate. Is that FX index also reportable as a fixing index under this section of Table 2?

Example 9.01 in Annex II would seem to suggest the answer is no.

Based on Example 9.01, our interpretation is that the answer is No. Could ACER confirm this explicitly as we would like to understand why FX indexes are treated differently from oil commodity indexes, and therefore if there is anything else that is not reportable under this section?


Answer:

In the FAQs document the Agency has already indicated that there is no need to report an FX index in the fixing index details session (fields 24 to 30 of Table 2). If any FX index has to be reported, it can be reported in the formula. Only indexes related to the energy commodity should be reported in the fields from 24 to 30 of Table 2. This would include also oil and coal or any other energy commodity to fix the price of gas or electricity.

Examples of non-standard contracts reportable with Table 2 and available in Annex II to the TRUM, such as 9.01-13.01-14.01-25.01, were provided to the Agency by market participants. These examples clearly indicate that, in the industry’s view, Oil Index and Coal Index should be reported.

RSS_Icon Last update: 26/09/2016  

RSS_Icon Subscribe to this Category’s RSS