FAQs on transaction reporting – Question II.3.1.50

There is a type of transaction that occurs in the UK (and perhaps elsewhere) referred to Gas-Retro-Deals. These are physical trades executed after the gas day at beach terminals. Shippers are incentivised to enter into such deals on occasion to reduce transportation costs or imbalances. These are done after delivery but before settlement. Therefore, they would have a timestamp after the delivery start date.

We do not believe an example is required here but if it necessary, please let me know.

We believe that Gas-Retro-Deals fall within the scope of ‘…day after markets.’ We believe this is a common understanding amongst industry participants who trade such contracts. We would appreciate confirmation from ACER on this interpretation. In addition, any other guidance ACER would like to provide at the same time on the reporting of such contracts would also be helpful.


Answer:

[UPDATED] based on additional input provided by the Agency’s stakeholders

In the Agency’s view, a balancing trade is a contract between a party and a System Operator (SO), in most cases TSO, who is in charge of keeping the energy in the network/system (either gas or electricity) in balance.

It is our understanding that in “…day after markets”, and any other retro-deal market, [added] where an SO or TSO is not involved, market participants balance/adjust their positions with other market participants. If this is the case, these contracts should be reported by both parties as wholesale energy products.

In the Agency’s view, balancing trades are well defined in Articles (2)9 to (2)11 of COMMISSION IMPLEMENTING REGULATION (EU) No 1348/2014, in the sense that they are related to balancing energy and services:

(9) ‘balancing energy’ means energy used by TSOs to perform balancing;

(10) ‘balancing capacity (reserves)’ means the contracted reserve capacity;

(11) ‘balancing services’ means

  • for electricity: either or both balancing capacity and balancing energy;
  • for natural gas: a service provided to a TSO via a contract for gas required to meet short term fluctuations in gas demand or supply.

In addition, whenever market participants (MP) may have any doubts about the delivery point, we would recommend (MP A) to report the transaction in any case, even if the other counterparty (MP B) would not agree with (MP A). In this case (MP A) would not take the risk of not reporting a reportable contract according to REMIT. The EIC for the destination delivery point can be reported in this case.

We also recommend market participants to read Questions 3.1.21, 3.1.22, 3.1.23 and 3.1.24 of the FAQs on transaction reporting document which, in the Agency’s view, would help to understand the scope of LNG contracts under REMIT.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.1.51

Does technical delivery of natural gas for gasification purposes or emergency delivery has to be reported under REMIT?

A “service company” has been asked by TSO or DSO to provide natural gas in case of network failure/damage. This action can take up to 2-3 days of delivery realized for a relatively small group of final consumers within specific area of the network, where regular delivery is not possible due to supply failure. Sometimes such delivery is not direct, but one service company sells natural gas to another service company. Does such contract have to be reported under REMIT?

As volumes are very small, transaction has no influence on the market and this delivery has semi-balancing purpose, it does not have to be reported.

A “service company” is a firm which repairs a transmission or distribution network in case of its damage. Let’s say that there is a small village supplied with gas by a single pipe. This pipe has been damaged due to some construction works. A service company has been called to repair the pipe. The repair work has been scheduled for two business days. During this time the village is without gas supply. To avoid such gas supply interruption (especially during the winter), the service company provides gas to the village, usually using LNG cistern and small regasification station (short time emergency delivery).

In such situation a service company does not sell gas to the final customers, it just provides gas to the network and sells it to the operator (in our understanding this is for balancing purposes). Sometimes there are two service companies due to technical specifics of repair works and it happens that one service company (main contractor of repair works) sells gas to another service company (subcontractor of repair works).

Our question is whether such contracts should be subject to REMIT reporting. In our view this is balancing (or filling the network) so it is not subject to REMIT reporting.


Answer:

In the Agency’s view, based on the information provided above, this contract seems to be a contract for the supply of gas for a period of maintenance, and not for a balancing service.

In the Agency’s view, balancing trades are well defined in Articles (2)9 to (2)11 of COMMISSION IMPLEMENTING REGULATION (EU) No 1348/2014, in the sense that they are related to balancing energy and services:

(9) ‘balancing energy’ means energy used by TSOs to perform balancing;

(10) ‘balancing capacity (reserves)’ means the contracted reserve capacity;

(11) ‘balancing services’ means,

  • for electricity: either or both balancing capacity and balancing energy;
  • for natural gas: a service provided to a TSO via a contract for gas required to meet short term fluctuations in gas demand or supply.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.1.52

There are different views within the industry about the reporting of purchase seller agreement when transactions consist of different parts. For example:

  • Company A can sell electricity to Company B in accordance with the terms and conditions of their purchase seller agreement; but also
  • Company B can sell electricity to Company A in accordance with the terms and conditions of their purchase seller agreement

How should such a contract be reported?

  1. Some market participants believe that the contract should be split in two different reporting streams: one contract for the sold quantity and one contract for the bought quantity
  2. Other market participants suggested to report one contact using C as buy/sell indicator

This different views may result in the reporting of the same contract with different formats:

  1. Company A reports a Table 2 with a “C” as buy/sell indicator;
  2. Company B report two separate Table 2, one for the sold quantity and one contract for the bought quantity
    What is the right way to report such purchase seller agreement transaction?

Answer:

In the Agency’s view, purchase-seller agreements should be reported with Table 2, as per the examples available in Annex II to the TRUM provided by the Agency’s stakeholders.

With regard to the reporting of a transaction under a purchase-seller agreement with Table 2, if market participants have different views on the reporting of such contracts, they can report their purchase-seller agreement with Table 2 either as one contract with a “C” as buy/sell indicator, or two separate contracts, one as “B” for Buy and one as “S” for Sell, provided that the meaning of the reports is the same.

As a result, any EXECUTION under that framework agreement should be reported with Table 1. Please see examples in Annex II to the TRUM.

RSS_Icon Last update: 20/07/2018  

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  

RSS_Icon Subscribe to this Category’s RSS