FAQs on transaction reporting – Question II.2.5.4

Articles 40(1), 40(2) and 44(2) make clear the backloading requirements that Market Participants should consider the minimum requirement for the reporting of contracts which were concluded before the date on which the reporting obligation becomes applicable and remain outstanding on that date i.e. 7th April 2016.

Where other information which is required to be reported under REMIT can be extracted from market participants’ existing records, market participants shall also report that information.

But could ACER please provide some clarity as to whether trades would need to be backload reported if trades have a delivery and settlement date prior to the 7th April 2016 but where there may be some scenarios whereby there will be some cash flows/payments that will not be able to be made until after this date but will not impact the trade or the delivery.

An example of this may be the result of the way that a trade is priced e.g. the trade is agreed and concluded pre- 7th April 2016 but priced as an average over all of April 2016 hence the price will not be known until it is calculated after 7th April 2016.

On the basis that all aspects of the trade will be concluded/ settled/delivered prior to the 7th April 2016, XXXX would like to confirm ACERs view that these would be out of scope for the backloading requirement based on:

–   the agreement and conclusion of the trade and/or any delivery will have taken place prior to the 7th April 2016 and that the outstanding cash flow is not material in the context of REMIT transparency or in relation to market manipulation;

–   in the spirit of what REMIT is trying to achieve, reporting these trades to ACER would add little apparent value in terms of transparency, market manipulation or market impact and that

–   the TRUM seems to hint (although not explicit) that the delivery of the contracts is the key factor for reporting requirement generally (3.2.1 point (iv)).


Since the contract and all its aspects have been concluded/ settled/delivered prior to 7 April 2016 the obligation to report backloaded contracts does not apply for the above-mentioned scenario.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.3.4.7

Reference to documents: TRUM 2.0 page 20

We  would like to discuss a trading example and ask you how to report it:


  • Company A sells electricity (bilateral, physical settlement) to Company B for the whole year to spot market conditions
  • Company B pays twelve equal monthly payments to Company A. The amount of the payments is estimated before the beginning of the year. The estimation is based on the volume that was sold the year before and the estimated prices in this year. The monthly bills therefore don’t display a volume.
  • At the end of the year, there is a final invoice. The final invoice is offset with the twelve payments. The final invoice displays the sold volume in this year (it is calculated after the whole year) and the calculation of the difference between the twelve monthly payments and the sold volume to a specific price (derived by the spot market). The final invoice can be positive or negative depending on whether the sum of the monthly payments is above or below the sold volume x sold price.

In our understanding we should use REMIT Table 2 scheme to report the contract (no quantity and price is known before the final invoice). And for the execution it is our understanding that we report the transaction for the whole year using the final invoice with the defined price and volume at the end of the year (table 1)?

In our understanding we shouldn’t report the monthly payments (TRUM 2.0 page 20) because there is no specifying of an outright volume and price.


Based on the information provided above, it is our view that the contract should be reported by using Table 2 and one EXECUTION at the end of the year. Please note that this would apply only to contract with pre-payments.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.3.1.8

How to report a bilateral contract (initially classified as a non-standard contract and also reported in a non-standard format) in cases of any price fixing events (e.g. the client exercises an option)? This especially concerns such events which could be interpreted as a standard contract in a stand-alone perspective. (Vanilla) options are considered as being standard contracts (Table 1) and reportable in Phase 1 if executed over an OMP or identical to a product admitted to trading over an OMP (although the REMIT reporting requirement would be met if the trade falls within the scope of EMIR and has been reported as such).


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

Please see the example in Annex II to the TRUM. In Section 2 of the annex there are several examples on how to report bilaterally traded contracts and executions under those non-standard contracts.

If the price fixing event (e.g. the client exercises an option) is related to a non-standard contract reported with Table 2, then the event should be reported as execution with (Table 1) under the framework of a non-standard contact and not be interpreted as a standard contract. 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.

On the contrary, vanilla options that are considered as standard contracts should be reported with Table 1 and reportable in Phase 1 if traded over an organised market place and do not have reportable executions associated to them.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.3.4.8

The question is about submitting the notional amount (Data Field R1.38). We would do so in a monthly rhythm. There are three dates where we get new information about the amount in month M, i.e. M+1WD, M+14WD, and 2M-10WD (WD being working days). The initial amount could be corrected twice in the course of two month following the month of delivery.

We wonder if we are to correct execution messages as well and if we have to do so every month separately or after the end of the calendar year for the whole delivery year.

In the FAQ document we found Question 3.4.3 which reads that “…the Agency currently would not expect any life-cycle event based on actual values available from the DSOs.” How is this quote to be interpreted to the effect of submission of executions?


As stated in FAQ 3.4.3 there is no expectation to update submitted EXECUTION reports unless Market Participants prefer to do so.

RSS_Icon Last update: 10/07/2017  

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)


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

Related documents: II.3.6 of the Frequently Asked Questions

Question relates to the reporting of executions under back loaded nonstandard contracts.

According to II.3.2 of FAQs, an execution completed before 7 April 2016 does not need to be reported. Executions with delivery period extending beyond 7 April 2016 need to be reported. However, as the deadline for backloading of nonstandard contracts is 7 July 2016, the questions are:

  1. Does an execution with a delivery period ending before the nonstandard contract is back loaded need to be reported?
  2. If yes, what is the deadline for reporting such an execution? Should it be reported within 30 days of the end of the delivery period, even if this is a date earlier than 7 July 2016 (in which case the nonstandard contract should be back loaded not later than the date of reporting of the execution)? Or should such an execution be reported only when the nonstandard contract is back loaded, even if this falls later than 30 days from the end of the delivery period of the execution.

Answer to the second question of II.3.6 of FAQs (which probably should be properly marked as question 3.6.2, instead of 3.6.1) suggests that only executions with delivery periods ending after a nonstandard contract is actually back loaded are reportable. This would mean that executions with delivery period ending after 7 April 2016 but before the nonstandard contract is actually back loaded (which can happen by 7 July 2016) would not be reportable at all. We are not clear if this was the actual intention of the Agency.

As a follow up question: when new executions of a back loaded contract are reported after the backloading is done, do the data reported by each of the counterparties regarding such executions need to match? Many Xxxx market participants are reporting to me that they have significant difficulties in agreeing with some counterparties how the historical contracts are to be reported and it is quite likely that several back loaded contracts will be reported by each of the respective counterparties differently (with non-reconciled data). I would greatly appreciate your input on this. My understanding is that in case of back loaded contracts both data reported by the two counterparties under table 2 and data reported under table 1 for executions of back loaded contracts are not required to match.


Executions under the framework of non-standard contracts with a delivery period ending before the nonstandard contract is back loaded do not need to be reported.

Criteria for back loading are more relaxed. Please refer to TRUM Annex II, e.g. Example 4.05 to see the differences in the back loaded contract reported by two counterparties.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.1.1.24

Related documents: TRUM 3.2.5 (Page 17); TRUM Annex 2: Example 7.01 and 7.02; FAQ 4th Edition March 2016 (Q1.1.11; Q3.1.11; Q3.1.13).

Can you please clarify the reporting route for the following scenario relating to bilateral gas transactions in the UK:

Party A and Party B enter into a framework agreement for executing bilateral gas swaps between UK entry (beach) and exit (NBP) points.  The purpose of the agreement is to agree on how to share the financial savings (benefit) received by Party A paying only the short haul gas tariff rather than Party B paying gas entry commodity charges and Party A paying exit commodity charges.  The framework states that the mechanism for achieving this benefit will be by executing individual back to back bilateral transactions under the general master agreements for beach and NBP transactions respectively each time the traders agree to transact.

The framework agreement doesn’t set a price or volume and doesn’t place any obligations on either party to enter into any transactions.  Whenever the traders agree to trade under the framework agreement, Trader A and Trader B will agree the period, price and volume for each transaction at the time of entering into the individual back to back transactions with the final prices agreed on any day for the beach and NBP transactions being inclusive of the share of any benefits from the short haul tariff savings as set out in the framework agreement.

Example: In practical terms, each time the traders agree to transact under the framework agreement, Party A will agree a price with Party B to buy a set volume of gas over a set period (day) at the beach under a general master agreement and at the same time agree the price to sell the same volume of gas over the same period (day) to party B at the NBP under a separate master agreement.  Both transactions will be executed as bilateral transactions (outside of an OMP) but are the same as contracts admitted to an OMP and therefore classified as standard contracts in accordance with TRUM section 3.2.5.

Our interpretation is that as the framework agreement setting out the mechanism for agreeing the gas swap is a general agreement that doesn’t define a volume or price, it will not be reportable under REMIT.  However, each time the traders agree to enter into back to back transactions in relation to the framework agreement, both transactions should be reported as separate standard contracts carried out under their respective master agreement and reported using Table 1 on Day +1.  This is our preferred approach and we are seeking ACER’s views on this approach.

However, we can also see similarities to the example 7.01 and 7.02 in the TRUM where the framework would be reported as table 2 (D+30) and the individual executions rolled up and reported monthly as table 1s (D+30).


As the price and quantity are set prior to the delivery, the back to back transactions shall be reported via Table 1. The framework contract is not reportable.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.1.1.25

Please give us your clarification on the following issue.

Notwithstanding the below ACER’s explanation published in updated FAQ:


Reference to Article 3 (1) of Commission Implementing Regulation (EU) No 1348/2014. As for the framework agreements such as EFET General Agreement Concerning the Delivery and Acceptance of Electricity, could you please explain if they also should be reported even if an Individual Contract (in the meaning of the EFET General Agreement) wasn’t concluded? Example: The Parties concluded the EFET General Agreement but they didn’t conclude any Individual Contract (in the meaning of the EFET General Agreement). First Individual Contract was concluded three months after conclusion of the EFET General Agreement.

Our understanding is that such master agreement only sets out the rules for trading activities of the two counterparties of a contract, but does not set any obligation to the two parties. In our opinion, the conclusion of such a general agreement of the Delivery and Acceptance of Electricity, i.e. the agreement sets out the general terms for trading, but does not specify the price setting of volume optionality, e.g. the amount of electricity, time and place of delivery and price, is not a reportable contract. Furthermore, only the Individual contracts concluded under the terms of a General Agreement Concerning the Delivery and Acceptance of Electricity shall be reported to the Agency.

Could you please inform us if there is a need to report (backload) the EFET General Agreement in which counterparties agree on maximum yearly gas volume that can be delivered under this contract (not an obligation to any of the parties). Does the following wording make the framework contract non-standard, that have to be reported according to the REMIT:

Ҥ 4 Primary Obligations For Delivery and Acceptance of and Payment For Natural Gas

At the end of §4.1(a) insert: “The amount of Contract Quantities for relevant Total Supply Periods agreed under all Individual Contracts entered hereunder shall not exceed ______ (________) MWh per year.”

According to Ukrainian legislation, the approximate maximum gas volume is a fundamental condition of the contract, due to the Clause 1 of the Regulation on the form of the international agreements (contracts), N201 dd 06.09.2001: “The conditions that need to be defined in the international agreement (contract), if the Parties of such agreement (contract) do not agree on the different defining of the contract conditions and such arrangement does not release the contract of subject, object, purpose and other fundamental conditions, without confirming of which between the parties such contract can be considered as non-executed, or invalid due to the disregard of the provision on the contract form applying under the  applicable Ukrainian law, are the follows:….4. The quantity and quality of goods”

Also for your information, such approximate maximum volume in all already executed EFET General Agreements is variable and is agreed based on the ability of the counterparty to supply. In addition, I would like to emphasize on the fact that this indication of the volume in the Election Sheet is not an obligation to the Seller to deliver and to the Buyer to off-take. This is just an approximate maximum limit, which was approved by Ministry of Economic Development and Trade.

We have several EFET GA executed before the April, 7th, which are all outstanding and in which the approximate maximum gas volume was specified. Thus, we would highly appreciate if you could give us your official opinion on this issue as soon as possible, so we would be ready to backload them in case of need till the July, 6th.


In the light of Question 1.1.11 we do not consider EFET General Agreement with defined maximum amount of delivery of gas per year reportable. The inclusion of the maximum volume in the contract is specific to the national law and does not make the EFET General Agreement a non-standard contract.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.1.1.26

Related documents: FAQ: Question: 1.1.17

Can you please clarify if the EMIR approach to Novations will be applied.

Scenario 1: Trade being fully novated

Will we be required to send a cancel/ exit for the trade (old UTI) against pre novation party and a ‘new’ submission for the trade (New UTI) against the new party? i.e. same UTI cannot be used post novation

Scenario 2: Trade to be split by Novation

Will we be required to send a modify (old UTI) for the trade remaining with the original party and a ‘new’ for the trade (New UTI) with new party?

In order to report a novation, an early termination with the old UTI and a new trade with a new UTI should be reported. Both market participants, MP1 and MP2 have to submit an early termination report with Action Type “C” for Cancel the old trade and e.g. MP1 and MP3 a new submission with Action Type “N” for the new trade between MP1 and MP3 with a new UTI.

Novation of trades: MP 1 will rename itself and become MP 3 with all codes (ACER, LEI etc) from MP 1. Do we need to modify any trades or do we just need to change the data in CEREMP?

MP 2 will merge with MP 3 to one legal entity MP 3 which comprises the assets of former MP 2 and MP 3: do we need to early terminate trades for MP 2 and submit new trade reports for MP 3? Can we resubmit the complete trades under the merged company (MP 3) or do we actually need to split trades in delivered and undelivered segments? Are any differences between table 1 and table 2 to be taken into account?

Example: MP 2 has a deal with MP X (external party) for cal 2016. A merger between MP 2 and MP 3 takes place on August 1. Are the deals already reported and settled to be early terminated and submitted as new under MP 3? Does MP X to do the same? Has MP X to be informed/asked to do the same?

Since we had already submitted a question to ACER previously and received no feedback as to now we would ask you to reply by June 3 in order for us to do necessary preparations.

If we do not receive a response from ACER we will proceed with our best effort: we will send early terminations for open trades for MP 2 and submit new reports for MP 3 without splitting the trades.


All the open trades have to be novated with the name of the new legal entity to notify the change of the counterparty to the contract. In order to report a novation, an early termination with the old UTI and a new trade with a new UTI should be reported.

Both market participants, MP2 and MPX have to submit an early termination report with Action Type “C” for Cancel the old trade and MPX and MP3 have to provide a new submission with Action Type “N” for the new trade between MPX and MP3 with a new UTI.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.1.1.27

We started to report form April the 7th, 2016 and we reported all our standing contracts in backload and added, as it happened, execution of them. All the transactions were accepted.

Now one of our supplier, a company, from outside the EU, asked us to report for it as well. And here is where we have a problem. When we reported our contracts (3) in backload with this supplier he didn’t have an ACER code then and we reported that contract, and later execution, using the ACERNONMP.EU code. Now our supplier informs us that he has his ACER code now and asks us to report for him as well. All contracts were reported and accepted as well as all execution.

We have reported again those contracts and transactions with correct ACER code, and we would like to delete the ones with the ACERNONMP.EU code. My question is how we should do that: report it as error or report denouement?


As specified in the FAQ 2.6.2 a modification report with the updated ACER code should have been reported. It is necessary to modify the original report with the updated ACER code.

RSS_Icon Last update: 10/07/2017  

RSS_Icon Subscribe to this Category’s RSS