FAQs on transaction reporting – Question II.3.1.11

If a non-standard trade is transacted and reported under Table 2, and a Day 1 cross delta trade is also performed with the same counterparty and reported under Table 1, does the Table 1 trade need to be linked to the Table 2?

Also is the Table 1 trade classed as an execution and therefore reported each month after invoicing, or just reported once as a bilateral trade?

We enter into a non-standard trade which is a Calendar strip of monthly options to purchase a physical spark spread position – i.e. similar to the example provided in Appendix A.  The non-standard option deal will give a delta of being Long Power / Short Gas.

To hedge the position, we therefore at the same time enter into a fixed price physical transaction with the same counterparty to Sell Power & Buy Gas.

Whilst the 2 trades are booked independent as the flow of one is not dependent to the other, they are still linked in the sense that the second trade is a direct hedge of the first trade and performed with the same counterparty.

Our interpretation is that the non-standard trade would be reported using Table 2.  The fixed price physical hedge would then be reported under Table 1, and linked to the Table 2 trade via Field 32.  However the Table 1 trade would be classed as a bilateral trade and not an execution trade and therefore only reportable once (assuming no lifecycle events) and not each month the trade deliveries.


Answer:

In the Agency’s view that the delta trade performed with the same counterparty and reported under Table 1 is a separate transaction unless it is executed within the framework of a non-standard contract.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.1.12

Article 7 (6) of Commission Implementing Regulation (EU) No. 1348/2014

Transaction Reporting User Manual (TRUM) – Annex II Examples of transaction reporting

Should lifecycle events be reported to ACER for transactions that have been reported on the back loading requirement?

Market participant concluded bilateral contract outside an organized market place before 7th April 2016. Regarding to the fact that market participants shall report contracts which were concluded before the date on which reporting obligations becomes applicable and remain outstanding on that date, Market participant reports this contract within 90 days after 7th April 2016 in the context of back loading requirement.

If the terms of the original contract (e.g. price or quantity) are modified after 7th April 2016 should market participant reported this fact (lifecycle event) to ACER?


Answer:

Contracts that are back loaded and then amended are subject to the life cycle event reporting.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.1.13

Reference to documents: Article 3 (1) of Commission Implementing Regulation (EU) No. 1348/2014 – Transaction Reporting User Manual (TRUM) – Annex II Examples of transaction reporting

In connection with practical example indicated below we would like to ask how such a trading situation should be reported?  Please indicate what combination of trading scenarios included in Annex II must we choose?

Trading scenarios included in Annex II envisage two steps: reporting bilateral contract and execution. What kind of reporting scenarios should be chosen when trading activities include three (or more) sequence? Example indicated below:

1.       Parties concluded General Agreement X (and they didn’t conclude any Individual Contract), there is no specified price and volume; after a few months.

2.       Parties concluded Individual Contract with maximum quantity, but they didn’t specify price; after a few months.

3.       Parties concluded Individual Contract with defined quantity and price.


Answer:

The FAQs document on transaction reporting (please see question 1.1.11) and Annex II to the TRUM address this question. Master agreements are not reportable. If the first report is about the non-standard contract, then executions under the framework of that non-standard contract have to be reported.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.1.14

As part of our analysis for REMIT Phase 2 reporting for commencement on 07/04/2016, we have encountered a scenario which is not illustrated in the examples for non-standard contracts. When a non-contract contract, which has been running for some years is cancelled by mutual agreement of both parties, how should this be reflected in the report to ACER?

We’ve reviewed the examples in ACER_REMIT_TRUM_ANNEX_II_v2.0.pdf (published 16th November 2015) for Non-Standard Contracts and there are no examples of cancellations.

  • Is it just a case of sending a Table 2 message with an “Action type” (Field 45 of ACER Table 2) of “C”?
  • Are we also required to populate “Termination Date” (Field 43 of ACER Table 1) for the last execution?
  • We have a non-standard contract (Power Purchase Agreement) that runs from 1st January 2008 through 31st December 2018.
  • The last execution of the contract is a purchase of 400 MW of Electricity on 30th August 2016.
  • On the 15th September 2016, both parties agree to cancel the existing contract with effect from 30th September 2016.

Answer:

In case of cancellation of a non-standard contract previously reported with Table 2, market participants should submit a new lifecycle event report related to the non-standard contract indicating “C” in Field (45) “Action type” of Table 2. The report should also indicate the date of the cancellation of contract in the “Contract date” Field (12) of Table 2.

In the above case the non-standard contract that runs from 1 January 2008 through 31 December 2018 and with final execution on 30 August 2016, the market participant will be able to report the cancellation of the contract with 15 September 2016 in Field (12) “Contract date” and the amended delivery end date in Field (43) as 30 September 2016.

With regard to the reportable execution, it is our understanding that the last execution of the contract on 30 August 2016 (the date that they agree the price and the quantity) may refer to either the delivery of electricity in August 2016 or September 2016 (forward contract).

If the execution of the contract on 30 August 2016 is related to the delivery of the energy in August 2016, this should be reported as any other EXECUTION and reported on a T+1 month basis. Please see Annex II Section II of the TRUM for example of how to report transaction executed under the framework of non-standard contracts.

If the agreement of the contract on 30 August 2016 is a forward contract for the delivery of the energy in September 2016, this should be reported as any other BILATERAL forward contracts and reported on a T+1 month basis. Please see Annex II Section I of the TRUM for examples of how to report bilateral contracts.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.1.15

Reference to documents: TRUM V2.0 , 3.2.6, page 20

TRUM V 2.0 3.2.10, pages 26-26; TRUM Annex II v 2.0* (2015-11-16) pages  6-9; TRUM Annex II v 2.0*, example 3.09

Reporting of Executions in case of a standard/non – standard Option contract (volume optionality)

As understood, EXECUTIONS need to be reported in case volume is not defined when concluding the contracts.

However, it is not clear if the same logic applies with Option contract with a definite strike prices and delivery period. As described in TRUM, an option exercise is not considered a lifecycle event. In the example 3.09 (option via a broker platform), it is not clear whether any subsequent event (“execution”) needs to be reported in order to specify the final volume.

A swing option, traded outside OMP

-fixed premium

-fixed strike price

-fixed delivery period

-maximum daily volume

-minimum total volume (for the entire delivery period)


Answer:

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

The reporting of these type of flexible contracts is based on the reporting of non-standard contracts with Table 2 followed by EXECUTION or BILCONTRACT contract EXECUTION (s) no later than 1 month after the price and the volume are known. Please see Q. 3.1.28 whether the execution should be reported as EXECUTION or BILCONTRACT contract, also considering that examples reported in Annex II to the TRUM are non-exhaustive.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.3.1.16

Implementing Acts – Article 3(1)(a)(vi) – Other contracts for the supply of electricity or natural gas with a delivery period longer than two days where delivery is in the Union irrespective of where and how they are traded, in particular regardless of whether they are auctioned or continuously traded.

Tolling agreements allow for the conversion of a fuel into electricity between one party and another. The fuel that is nominated to the party converting the fuel remains in the ownership of the party requiring the electricity and the resultant electricity belongs to this same party. There is no transfer of title of either commodity and the financial settlement of the agreement relates to the availability of the converting party to convert the fuel.

Party A nominates a volume of its own gas to Party B, the converter (i.e. a power station). The resultant electricity is scheduled into the account of Party A. On a regular basis Party A will make a payment to Party B based on the availability of Party B.


Answer:

If there is no transaction between the two parties in relation to a wholesale energy product, then this would mean there are no reportable transactions under the reporting obligation of REMIT. Market participants should assess if they enter into transactions for the delivery of the energy commodity or for the provision of services.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.1.17

REMIT Implementing Act Article 5(1)(b) and Annex, table 1 data field 31 (Unique transaction ID), table 2 data field no 11 (contract ID).

We understand that market participants need to agree on their method of generating a Contract ID – this can include using the UTI algorithm provided by ACER. However, what should a MP do if its counterparty provides the ID after T+1 or T+30 or indeed not at all and they have not agreed to use the ACER algorithm? This is particularly of concern as the use of the ACER algorithm is not mandatory.

Under REMIT, phase 2 transactions need to be provided either under table 1 (for contracts that specify and outright price and volume) or under table 2.

In submitting a table 1 or 2 report the UTI field must be completed. However, it is possible a counterparty, who is not using the ACER algorithm, may not provide their UTI to us to enable us to report in the necessary timescales.

We are engaging with our CPs to ensure this does not occur but it is always a risk.

Our preferred approach is to:

1) Submit a temporary UTI, calculated based on the ACER algorithm.

2) Once we have received the UTI from the CP an ‘error’ report will be submitted to remove the previous report and a ‘new’ transaction report with the correct UTI will be submitted.

As an alternative to 2) we are also happy to simply submit a modify report if that is preferable to ACER.  Can ACER please confirm this is acceptable?


Answer:

Market participants should submit a temporary UTI, then once they have received the UTI from their counterparty, a ‘Modify’ report will be submitted to modify the previous report recalling the old UTI. In the schema there is a field called “AdditionalUtiInfo” field where the old UTI should be reported in the modified report. e.g.

Using Schema Table 1_Version 2

1st report Using Schema Table 1_Version 1

<uniqueTransactionIdentifier>UTI123</uniqueTransactionIdentifier>

<actionType>N</actionType>

2st report Using Schema Table 1_Version 1

<uniqueTransactionIdentifier>UTI456</uniqueTransactionIdentifier>

<previousUniqueTransactionIdentifier> UTI123 </previousUniqueTransactionIdentifier>

<actionType>M</actionType>

Using Schema Table 1_Version 1

1st report Using Schema Table 1_Version 1

<uniqueTransactionIdentifier>UTI123</uniqueTransactionIdentifier>

<actionType>N</actionType>

2st report Using Schema Table 1_Version 1

<uniqueTransactionIdentifier>UTI456</uniqueTransactionIdentifier>

< additionalUtiInfo> UTI123 </ additionalUtiInfo>

<actionType>M</actionType>

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question II.3.1.18

Reference to documents: TRUM – Table 2 Reporting

We can trade transactions which will be reportable under Table 2, for which a premium or fee is payable at inception, regardless of the delivery or flow of the underlying commodity, however the deal is not considered an option.

We are therefore unsure as to where to report the deal premium or fee. If the trade was an option, it would be reported under Field 15, but this could already be populated with the pricing formula of the trade.

As per example 9.01 in Annex II of the TRUM which is an annual gas swing contract. If a fee or premium was payable for that contract on transaction date, regardless of the final delivery flow, where in Table 2 would that premium be recorded?

An obvious place would be Field 15, but this has already been populated with the pricing formula for transaction.

A possible solution would be to describe the formula in Field 15 and then add the premium as an absolute amount at the end of the formula. Would this be acceptable to ACER?


Answer:

When a transaction reportable under Table 2 includes a premium or fee payable at inception, regardless of the delivery or flow of the underlying commodity and the deal is not considered an option, that deal premium or fee, if it pertains to the service the trade is providing and unrelated to the volume of said product, would not be reportable.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question II.3.1.19

Reference to documents: ACER_REMIT_TRUM_v2.0, point 5

Question 1:

What has to be reported in the monthly reports of power Non-standard contracts, Table 1?

Question 2:

What has to be reported in the monthly reports of gas Non-standard contracts, Table 1?

Question 3:

Backloading for non-standard contracts table I: reporting obligation starting July 6th, 2016?

Question 1:

  • the total volume and the resulting average price of the contract (1 report) OR
  • the volume summarised by each transmission system operator (4 TSOs) (1 report including 4 volumes and prices) OR
  • the volume summarised by each transmission system operator (4 TSOs) (4 reports)

Question 2:

  • the total volume and the resulting average price of the contract (1 report) OR
  • the volume summarised by each gas market area (2 market areas) (1 report including 4 volumes and prices) OR
  • the volume summarised by each gas market area (2 market areas) (4 reports)

Question 3:

In our understanding the backloading of bilateral non-standard contracts have to be reported from July 6th on: these are contracts which were concluded before April 7th and are still in delivery since April 7th or will start in the future.

  • Is it correct that we report the framework contracts until July 6th and the first monthly table 1 report will be send in August?

Question 1:

  • the volume summarised by each transmission system operator (4 TSOs) (1 report including 4 volumes and prices)

Question 2:

  • the volume summarised by each gas market area (2 market areas) (1 report including 4 volumes and prices)

Question 3:

  • Is it correct that we report the framework contracts until July 6th and the first monthly table 1 report will be send in August?

Answer:

It is the Agency’s understanding that each transaction with each transmission system operator (different delivery point) has to be reported separately.

With regard to the backloading of bilateral non-standard contracts it is the Agency’s understanding that contracts which were concluded before 7 April and are outstanding on 7 April have to be reported by 6 July 2016.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question II.3.1.20

Is a Hydro Storage Virtual Power Plant deal considered to be a contract for the supply of electricity and therefore reportable as a non-standard transaction under REMIT?

An example term sheet for such a deal would be:

Period: Cal-16

Delivery Point: French Power

Storage Volume: 50,000 MWh

Max Storage Level: 50,000 MWh

Min Storage Level: 0 MWh

Initial Storage Level: 30,000 MWh

Final Storage Level: 30,000 MWh

Inflows: 150,000 MWh – These would have a Hourly MW profile

Outflows: 50 MW – Daily nomination

The holder of the contact would then effectively be able to take physical power from the writer as long as they operated within the above constraints. The power taken would be at zero price in return for a premium paid upfront.

In the draft FAQ’s issues after the Dec-15 ACER roundtable meeting, we note that Virtual Gas Storage contracts are not considered contracts for the supply of gas and therefore not reportable.

Based on this, we do not deem a Hydro Storage Virtual Power Plant deal to be a contract for the supply of electricity due to the significant similarities between this type of transaction and that of a Virtual Gas Storage transaction.

Could ACER confirm this view is correct?


Answer:

If the holder of the contact is able to take physical power from the writer, this is a contract for the supply of electricity. This is a reportable contract pursuant to Article 3 of Commission Implementing Regulation (EU) No 1348/2014.

RSS_Icon Last update: 26/09/2016  

RSS_Icon Subscribe to this Category’s RSS