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.11 [DELETED]

The question (in previous edition: Question 3.2.10) was deleted due to duplication.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.2.15

Data field (42)

Reference is made to the lifecycle event for Non Standard contracts and in particular to amendment of long-term contracts where there is no delay in the start of the delivery. When a MODIFY for TAB2 is submitted which value for Field 42 (Delivery start date) should be used?

  1. Should the field be populated with the date since which the amendment is effective or;
  2. Should the field always maintain the same value (date) as the one that was reported for the NEW lifecycle event

Reference:

Transaction Reporting User Manual (TRUM)

Practical Example:

In case ACER guidance is for 2) we highlight the risk that, since normally the long term contract’s formula (if contract price is one of the contractual sections affected by the amendment) becomes retroactively effective since the date of effectiveness of the amendment, maintaining in Field 15a also the previous info for such formula (that was valid previously) and the text describing the time switches, could soon saturate the 1000 characters currently allowed. Again, in option 2), could it be acceptable that Field 15a only reports the price formula valid due to the last amendment originating the MODIFY (with an explicit info stating the first day in which such formula is valid) and that also information in Fixing Indexes and Volume Optionality be reported with sole reference to the last amendment originating the MODIFY event?


Answer:

In the Agency’s view, when an amendment of a long-term contract has to be reported, the modified record should be submitted with the Action type “M” (‘Modify’) and should include the same delivery start date in Field 42 and the new price formula in Field 15. The ‘explicit info stating the first day on which such formula is valid’ can also be reported in Field 15.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.3.2

Reference to:

  • Article 3(1) of the Implementing Acts. List or reportable contracts: Options, futures, swaps and any other derivatives of contracts relating to electricity or natural gas produced, traded or delivered in the Union.
  • Option Details from ANNEX “Details of Reportable Contracts” in the Implementing Acts: Tables 1 and Table 2
  • TRUM, Table 1 #44: Option Exercise Date

“A European style option can only be exercised at the maturity date.”

  • TRUM, Table 1 #46: Option Exercise Date:

“This field identifies the date at which the option holder has the right, but not the obligation, to buy or sell the commodity or underlying instrument at a specified price on or before a specified date. In the case of an American, European or Asia option style, one exercise date is reported. In the case of a Bermudian option style, several dates may be reported.”

The issue:

1)  How should market participants report strip options?

2)  What is the reporting guidance from ACER for fields #44 Option Style and #46 Option Exercise date (Table 1) in regards to strip options? According to TRUM guidance, only Bermudian options can have more than one exercise date. For European option style, only one exercise date is required to be reported based on same text in TRUM.

Example:

Business Case: Market Participant A is trading strip options European style.

According to Market Participant A’s perspective, a strip option of the European style is a series of vanilla European options (a series of European puts or a series of European calls) on a number of consecutive contracts (e.g. January, February and March), each with the same strike price, but with a different expiry date.

Example: A strip option is concluded for delivery in January/February/March (three consecutive months). There are three exercise dates; each exercise date is two days before delivery start (e.g. 29th of December for delivery in January, 30th of January for delivery in February, 27th of February for delivery in March). Market Participant A has the right, but not the obligation, to exercise the option with delivery for January on 29th of December. In line with that, on 30th of January Market Participant A has the right, but not the obligation to exercise the option for delivery for February with the same strike price, and the same for delivery in March.

According to our current interpretation strip options are a kind of concatenated European style options, thus our interpretation is the report in the following manner:

  • Field #44 Option Style: Report as “European option style”
  • Field #46 Option Exercise Date: Report all relevant exercise dates of the strip option in this field, i.e. not just one exercise date as per the existing ACER guidance.

We would be grateful for ACER’s views on this envisioned approach, please.


Answer:

[UPDATED] to clarify Option Style of strip options

[Added] Since the introduction of the validation rule 2AODOEDR2x (in June 2017) – which prevents the reporting of records with a Contract Delivery Start Date prior to Contract Option Exercise Date unless the Option Style is ‘O’ for Other – strip options should be reported with Option Style ‘O’.

We understand that the option described above can be reported as:

  • Field #44 Option Style: “Other” “European option style”
  • Field #46 Option Exercise Date: the field should be repeated three times, where each value corresponds to a different exercise date, relevant to the individual delivery period (see below)
  • Fields #49 and #50 Delivery Start/End Date: these two fields should also be repeated three times, once for each corresponding delivery period (in this case it is one month per each delivery period).

The example below clarifies further the way to report the three fields above.

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

RSS_Icon Last update: 20/07/2018  

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

FAQs on transaction reporting – Question II.3.5.7

FAQ Question 3.1.17 states that for a Phase 2 reports in the Table 1 format that a change in UTI may be implemented through a modification of the existing report using either the <previousUniqueTransactionIdentifier>  for the Version 1 schema or the < additionalUtiInfo> field in the case of the Version 2 schema. The following question has been raised: For Table 1 Phase 2 reports is this process mandatory, or can the Phase 1 Table 1 process of erroring out the first report and resubmitting a new report with a new UTI (without a link to the previous UTI) be used as an alternative process?

Practical example: a new Phase 2 Table 1 report is successfully submitted by an MP but subsequently they wish to correct the UTI after discussion with the counterparty. They submit a report for that UTI with ActionType = “E” and they then submit a new report for the same deal with a new UTI (matching the counterparty’s UTI) with ActionType = “N”, they do NOT include any information about the original report or its UTI in the newly submitted report. Is this an acceptable process for correcting the UTI?


Answer:

Market participants should clearly distinguish the Error “E” from the Modification “M” case. As indicated in the TRUM, “E” for Error should be used to denote a cancellation of a wrongly submitted report, while “M” for Modification should be used for the modification of the details of a previously reported contract.

In order to correct the UTI that was wrongly submitted, the original report needs to be cancelled with Action type “E” and a new report with a new UTI (matching the counterparty’s UTI) has to be submitted for the same deal with Action type “N”. The new report does not have to include any information about the original report or its UTI, since the original report was wrongly submitted in the first place.

However, with regard to Question 3.1.17 of the FAQs on REMIT transaction reporting, if a market participant’s counterparty provides the UTI after T+1 day or T+1 month, or alternatively not at all, the market participant who is reporting its reports should submit a temporary UTI. Once they have received the UTI from their counterparty, a ‘Modify’ report should be submitted to modify the previous report, recalling the old UTI.

If a report is due to be reported on a T+1 day basis, all life cycle events related to that report have to be reported on a T+1 day basis. Otherwise, if a new report is due to be reported on a T+1 month basis, all life cycle events related to that report have to be reported on a T+1 month basis. Examples of ’modification‘, ’early termination‘ and ’error‘ reports are available in Annex II to the TRUM.

RSS_Icon Last update: 20/07/2018  

RSS_Icon Subscribe to this Category’s RSS