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  

FAQs on transaction reporting – Question III.4.2.23

According to Art. 21 Paragraph 3 Commission Regulation (EU) 2017/459 (CAM NC), the European Gas TSOs are obliged to offer a capacity conversion mechanism for their network users to enable them to convert unbundled capacities in bundled capacities. Some TSOs have already started to offer such service as an early implementation approved by their NRAs.
ENTSOG has prepared a model describing the minimum functions of the capacity conversion service (see attached document CAP0717-17 ENTSOG’s Capacity conversion model, 24 July 2017) and especially in its annex 2 the possible conversion scenarios.

However, the model leaves some discretion how to implement the conversion of the transportation contracts legally, especially how the national civil law arrangements/GT&Cs are structured to complete the conversion in a legal manner. Therefore, we as European TSOs like to propose a way, how to properly report these contractual changes under REMIT, taking into account the different possible conversion scenarios and the different national legal implementations.


Answer:

Generally, there are two basic approaches regarding the reporting of a fully converted contract, depending on national implementation:

A) The original contract with unbundled capacity is modified and a new contract is reported.

The capacity amount of the old unbundled contract is reduced to zero and this reduction is reported within the REMIT reporting as a change of the existing contract.

In addition, a new (bundled) contract is reported. This bundled contract contains the whole amount of the capacity. (Please note that reporting data with the approach described in this option does not necessarily imply that a new contract has been concluded under national law.)

OR

B) The original contract with unbundled capacity is modified.

The full conversion is done without reporting a new contract. Such a conversion of capacity is reported as a modification of the existing contract of the unbundled capacity. In this case, the following information should be updated (note that some fields are filled with the existing information):

All relevant information covering the allocation process (TRUM table 4, Data Field No 2-13) as well as information on the lifecycle reporting (TRUM table 4, Data Field No 14), on the premium price (TRUM table 4, Data Field No 21), on the specifications of bundling, and on the counter TSO (TRUM table 4, Data Field No 26).

Regarding the conversion of only part of the unbundled capacity into bundled capacity the following applies:

  • The original contract is modified by reducing the capacity amount by the part of the capacity that is converted into bundled capacity (updating the information in TRUM table 4, Data Field No 15).

AND

  • The part of the capacity that is converted into bundled capacity is reported as a new contract for bundled capacity.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.2.12

A question on behalf of a Market Participant who has traded a gas Swing deal with us (we are an OMP).

There is an assumption that the clients have to report the deliveries that result from the daily exercise/nominations on the swing deal – this is shown in your Annex II examples for bilateral swing deals as 26.01 (swing deal) and 26.02 (execution reports for deliveries) – however, there are no examples for reporting any deliveries from an OMP traded swing deal.

Since an OMP traded swing deal cannot be reported on Table 2, then the rules as they currently stand imply that you cannot use the Table 1 report “executions on a non-standard contract” in the same way as if you had a bilateral Swing deal, because the OMP traded deal is “Standard” by REMIT definitions.

Firstly, can you confirm that clients are expected to report the deliveries resulting from Nomination/Exercise of Swing rights?

Secondly, if the answer to question 1 is true then can you advise how this should be done?

Practical example:

A TTF Cal17 Buyer’s Swing

Hourly Quantity Minimum  0MWh

Hourly Quantity Maximum 300MWh

Total Contract Quantity Minimum 720,000MWh

Total Contract Quantity Maximum 720,000MWh

(i.e. 100% take or pay)

Nominated on UK Working days

(Note that this deal if brokered could be identical in characteristics to a bilateral deal direct between counterparties, which would be reported on Table 2 and executions on Table 1 as EXECUTION reports.)


Answer:

Based on the information available to us, the assumption that the clients have to report the deliveries that result from the daily exercise/nominations on the swing deal may not be applicable to this case. It depends on whether the option exercise results into the exercise of nominations or into the exercise of a forward contract that leads to nominations. If the former is the case, there is no need to report additional information. If the latter is the case, the contract results into a new forward contract and then this should be reported. Please see Question 1.1.12 of our  FAQ on transaction reporting document.

As pointed out in the question, since the OMP traded swing deal cannot be reported on Table 2, a workaround to report such swing trades should be applied. For example, we would recommend:

The option should be reported with “Other” in the Option Style field (as opposed to European/American etc.). The Exercise Date field (a repeatable field) should be used to list all the exercise dates.

The premium should be reported as an amount per unit of energy, the same way as a regular Option premium would be reported and in order to report the key additional parameters of the deal the Extra field should be used to provide value pairs. With regard to the use of field “Extra”, this should not be used in other ways unless previously discussed and agreed with ACER.  Please also note that Table 1 Schema V1 is different than T1 Schema V2.

For the following fields for hourly delivery contracts:

HourlyQmin= Hourly Quantity Minimum  0MWh

HourlyQmax= Hourly Quantity Maximum 300MWh

TotalCQmin=Total Contract Quantity Minimum 720,000MWh

TotalCQmax=Total Contract Quantity Maximum 720,000MWh

Example:

Schema Table 1_V1:

<Extra>HourlyCQmin_0MWh HourlyCQmax_300MWh TotalCQmin_720000MWh TotalCQmax_720000MWh</Extra>

Schema Table 1_V2:

<Extra>HourlyCQmin==0MWh;HourlyCQmax==300MWh;TotalCQmin==720000MWh; TotalCQmax==720000MWh</Extra>

Or for daily delivery contacts such as gas:

DailyQmin= Daily Quantity Minimum  0MWh

DailyQmax= Daily Quantity Maximum 24000MWh

TotalCQmin=Total Contract Quantity Minimum 720,000MWh

TotalCQmax=Total Contract Quantity Maximum 720,000MWh

Example:

Schema Table 1_V1:

<Extra>DailyCQmin_0MWh DailyCQmax_300MWh TotalCQmin_720000MWh TotalCQmax_720000MWh</Extra>

Schema Table 1_V2:

<Extra>DailyCQmin==0MWh; DailyCQmax==300MWh;TotalCQmin==720000MWh; TotalCQmax==720000MWh</Extra>

RSS_Icon Last update: 08/12/2017  

RSS_Icon Subscribe to this Category’s RSS