FAQs on transaction reporting – Question II.3.1.38

Reference to documents: Ref [1]: The XSD that defines how the Table1 fields can be put together in the XML: ”REMITTable1_V2.xsd” Ref [2]: ACER_REMIT_TRUM_ANNEX_II_v2.0.pdf

We want to repeat the Delivery Profile section of Table1 for each “Delivery point or zone”. This does not seem to be possible according to Ref [1].

For example: We have a non-std contract (using Table2) for a “delivery point or zone”= Sweden (“10YSE-1——–K”). For this contract we will have executions (using Table1 for this), in up to four different “delivery point or zone”s (LUL:”10Y1001A1001A44P”, SUN:“10Y1001A1001A45N”, STO:“10Y1001A1001A46L”, MAL:“10Y1001A1001A47J”).

What we really would like is to be able to repeat only the fields: [48, 55 and 57] four times, i e we want to state “Delivery capacity” and “Price/time interval quantity” for each of the four delivery points respectively, while all other fields in the report are the same. This does not seem to be possible according to ref [1].

We have seen examples in the pdf that are close to what we want, see ref [2]:

– pages 210-211: field 48 is multiplied

– page 58: fields 54-57 are multiplied

– page 131: fields 49-57 are multiplied.

Our question is whether our example with having at least these three fields together, repeated [48,55 and 57], also could be possible?

Our interpretation is that with the current XSD it is not possible to achieve what we want to do.


Answer:

Based on the information provided above, it is our understanding that each execution for each delivery point should be reported separately. The FAQs document on transaction reporting has already addressed this question, please see Question 3.1.6.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.39

As we do not find a relevant transaction reporting examples suitable to our case, please find enclosed the description of our specific transaction and how we propose to submit it.

For its procurement of grid losses, TSO X tenders on yearly basis a certain amount of power to the market:

  • This is a yearly shaped profile with a fixed volume, e.g. 10 lots à 43395 MWh per lot for the year 2017 (8760 hours) were tendered in 2015/ 2016 with a certain shape.
  • Market participants willing to participate in the tender could offer their prices for the overall profile (e.g. EUR 31, 69) and the market participants with the cheapest price are contracted.
  • We consider that as a non-standardized transaction, but with a fixed volume and price, so will use TABLE 1 for reporting, see example below.
  • For field 40 “Quantity / Volume” we will use the average clip size rounded with two decimal places, i.e. 43.395 MWh / 8760 hours = 4,95 MW.
  • In field 54 “Load Delivery Intervals” we enter “00:00/24:00” per default.

Please find the complete example and how we intend to report in the Excel file enclosed.

We would welcome, if you could approve our suggestion and add the example to the ANNEX II of the TRUM, so we could communicate accordingly to our counterparties.


Answer:

Based on the information provided above, it is our understanding that this is a BILATERAL contract with shaped profile. Each hour with different quantity and price should be reported in the report.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.40

Related documents: Article 2, Article 2(2) and (3) of 1348/2014, Article 5(1) а,b (2) of 1348/2014; Article 7 (2) of 1348/2014; Regarding field TRUM Table 1 Transaction Timestamp field 30 and reporting Table 1 – bilateral in T+1

How to classify (standard or non-standard) complex day-ahead hourly electricity products executed bilaterally outside the organised market place is not admitted to trading at an organised market place and if classified different than our view then when to report and with which table?

  1. With some of our partners we trade day-ahead hourly electricity products executed within the framework of general/master agreement bilaterally outside the organised market place. This master agreement sets the rules for trading activity of the two counterparties to the contract and it is specifying the range of the volumes available for trading as sometimes these volumes can differ regarding the buy and sell positions in the counterparties portfolios and these positions, during the trade period (one month) will be technically still open until the end of the month when is the invoicing date and the correct price and quantity can be discovered.

In our opinion, this contract may be classified as non-standard complex shaped/profile contract as it is not traded at an organised market place, but only bilaterally between the two parties and it is not admitted to trading at an organised market place (not visible to the market, not available for trading to market participants, would be traded only once and would then expire and not be tradable any more).

Our understanding is that we should report the abovementioned trade with Table 1 to identify the details of transactions executed within the framework of non-standard contract reported with Table 2. This execution will be reported once the delivered quantity and the price are known after the invoicing cycle, but no later than 30 days after the discovery of price and quantity. Can you confirm this?

Also, could we use the details (time of the invoicing) from the invoice for filling the Transaction Timestamp in the Table 1 field? For this kind of contract our positions will become clear and will be known after the invoicing cycle, so that is our only reasonable option.

  1. With other partners we have master agreement and annex based executions with clear and closed positions regarding the price and quantity. In our opinion, this annex may be classified as non-standard contract for base load, pick load off-pick load annex contract as it is not traded at an organized market place, but only bilaterally between the two parties. Could we report this contract just with Table 1 as Bilateral on T+30 or Bilateral on T+1?
  2. The qualification whether the contract is “standard contract” or “non-standard contract” is specified by ACER`s list of standard wholesale energy contracts as it defines the types of such contracts. Decisive for the reporting as standard contract or non-standard is the fact whether a contract is or is not listed as such in the Agency’s REMIT database.

According to the primary criterion stated by Article 2(2) and (3) of the REMIT Implementing Regulation if contract (for example in our case day-ahead hourly electricity products) has been traded bilaterally and has not been admitted to trading at an organised market place (not visible to the market and not available for trading to market participants and would be traded only once and would then expire and not be tradable any more), but in the same time this kind of contract has been published in the ACER list of standard contracts, (for example Bulgaria Baseload (CET 00-24) with delivery zone 10YCB-BULGARIA-F). Does the fact that the contracts which have been published in ACER`s list as standard for 10YCB-BULGARIA-? delivery zone makes these contracts standard, despite the fact that are traded bilaterally and have not been admitted to trading at an organised market place? How do we need to report, for example this year contract Baseload 00-24 CET with delivery zone 10YCA-BULGARIA-R? Could you please answer when do we need to report the contract: on T+1 or T+30 as Bilateral with Table 1?


Answer:

Please see FAQ 3.1.28.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.41

I have questions regarding REMIT reporting obligations.

  1. As it is noted in the Fundamental Acts market participants are obliged to report contracts concluded outside organized market but which have defined quantity and price as Standard Contracts with the deadline of one working day. Our questions regarding this type of contracts are as follows:
  • What if the price is defined but quantities are flexible during the contract duration does this mean it should be reported as Standard Contract with deadline of one working day?
  • What if the price is contracted in one currency but denominated and paid by the customer in another currency does this considers as defined price? Example: we have contracts signed with defined fixed prices in EUR but this price changes on monthly basis due to conversion of price from EUR to HRK.

2. What is the deadline for bilateral contracts signed outside the organised market place for sublet of transportation capacity? If we understand it correctly these contracts should be reported within the same deadline as non-standard contracts (this means the deadline is 30 days)?


Answer:

If the price is defined but quantities are flexible during the contract duration, this it is a non-standard contract, unless traded on Organised Market Place. Please see FAQ 1.1.20 for the timeline of reporting.

Based on the information provided above, it is our understanding that if the contract is signed with defined prices in EUR, this is by definition a contract with defined price. This contract should be reported with the price in EUR by both sides of the contract. It is our view that the fact that the contract is registered in another currency in the market participants’ systems, being subject to currency fluctuations, does not change the nature of the contract itself.

Bilateral contracts signed outside the organised market place for sublet of transportation capacity should be reported within the same deadline as non-standard contracts, T+1 month.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.42

Related documents: REMIT Implementing Regulation Art 3.

REMIT requires the reporting of contracts in wholesale energy products to ACER. However, certain transactions may be split into separate ‘legs’ for the purpose of recording the information in market participants systems.  These contracts may have more than one counterparty, relate to more than one product, e.g. LNG and natural gas, contain multiple delivery points and have more than one price setting mechanism.   It should be noted that these ‘legs’ do not represent executions.

To report these ‘legs’ as a single contract it would be necessary to aggregate them together. Aggregation may reduce transparency of the data provided to ACER, particularly if the contract is reported as table 1 as no execution data will be reported.  In addition, it is currently not possible, for all contracts, to aggregate and report the contract as a single message under table 1 due to limitations with the schemas, e.g. different legs may have different transaction details.  Any solution, if possible, will, at best result, in a considerable loss of detail of contract information. Aggregation will also involve considerable effort on the part of market participants in terms of changes required to systems.   This seems inefficient given the small number of such transactions.

Finally, we understand that other market participants face this issue. Therefore, different reporting by CPs may make matching more difficult for ACER, so guidance in this area would be very helpful.

Example: In this example there is only one contract between MP1 and MP2/MP3. However, the contract is booked as a number of different deals in the trading system due to product, locational and pricing factors.  We note that there are no current examples of how to report such a trade within the TRUM.

Legal entity Counterparty No of contracts Deals booked in trading system Product Location Formula
MP1 MP2 1 3 LNG Grain NBP
Bilbao
Huelva Brent
MP2 1 2 NG AOC NBP
NG AOC Brent

 

For table 1 we would prefer to report the individual ‘legs’ of the contract separately and to use the ‘Linked ID’ field generated separately by each market participant for each report to recognise that the reports are related. We would finally note that such contracts only represent a handful of the overall transactions currently undertake.


Answer:

Based on the information provided above, it is our view that each party should report a separate contract by using Table 2. For example, in the case of a tri-party agreement, contracts between MP1 and MP2, and MP1 and MP3 shall be reported by using Table 2 and individual executions after that agreement shall be reported by using Table 1.

Each party should report a separate contract (Table 2), e.g. a tri-party agreement, MP1 with MP2, MP1 with MP3 and individual executions after that.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.43

Reference to documents: TRUM V2 page 18 and Annex II p. 183/184

A colleague reported back that of their PPA providers we are the only one who think there is a monthly reporting requirement. (Executions under a non-standard frame contract reporting according to the billing cycle.)

Another market participant has legal advice and has also received guidance from ACER that it is a one off reporting requirement. Just to report the contract. Furthermore, they got informed that the monthly reporting would kill the ARIS system.

In this context, we have the question if this information is correct? Do we only need to report the frame contract in the non-standard contract and do not need to report the executions (actual volumes) each month (billing cycle)? The same then would apply to all other metered business.


Answer:

It is our understanding that a Power Purchase Agreement (PPA) is a bilateral agreement with defined Pricing, Delivery point and Billing and Payments conditions. Furthermore, it is our understanding that a contract under a PPA is not traded at an organised market place. The contract will be reported under Table 2 and, following the billing, the executions specifying an outright volume and price will be reported no later than 30 days after the invoicing date, using Table 1 of the Annex to Commission Implementing Regulation (EU) No 1348/2014.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.44

As we are going to finalize our RRM registration process, we will be very grateful if you could clarify our doubt as regards the way of transmitting our non-standard contract. We have bilateral contract for the purchase of electricity to cover losses, concluded in result of public procurement. The price and volume is known in the moment of concluding of this agreement. We have prepared both: Table 2 (which we are going to send to ACER once a year) and Table 1 (with executions which we are going to send each month).

In your documentation (TRUM) it is said that non-standard contracts specifying at least an outright volume end price shall be reported using Table 1. Is it mean that we should report only Table 1 or that we should report Table 2 and Table 1.


Answer:

If each transaction has a price and quantity defined prior to the delivery of the electricity, these should be reported as bilateral contracts with Table 1. Please see FAQ 3.1.14.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.45

Our issue is about bilateral contracts signed after a tender procedure. In France, at the end of the contract award procedure, suppliers whose offer was rejected have 11 days to bring an action against the rejection decision. The contracts are signed at the end of this withdrawal period. Under REMIT, standard contracts have to be reported to the agency no later than the working day following the conclusion of the contract. Under REMIT, what is the date of conclusion of the contract that must be retained: the date on which both parties agree on the transaction or the contract signing date (12 days after)?

Example: A tender procedure ends on January 14th, 2016 by awarding the contract to a supplier. On January 14th suppliers who have not been selected are informed of the decision. They can challenge the decision until January 25th, 2016. If there is no dispute, the contract between the buyer and the supplier selected is signed on January 26th, 2016. When do both parties have to report the transaction to the agency (assuming it is a standard contract)?


Answer:

In case of bilateral contracts signed after a tender procedure the contract signing date should be considered as the date of the contract.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.1.30

As OMP we are planning to expand our portfolio of services with implementation of a centralized market for bilateral contracts. Our trading activities will be based on two matching mechanisms: auctions based mechanism and continuous trading mechanism. Therefore, we will offer standardized products as base load, peak load, off peak load products with different delivery time intervals (hourly products, weekly, monthly, half-year, year, etc.) via continuous trading mechanism. Our REMIT reporting problem issue is that we cannot classify some of our products that we will offer through this auctions market mechanism according to ACER manuals criteria.

Our OMP will act as a central counter party for the products traded via the auctions based trading mechanism as the products traded on the continuous trading screen will be dealt bilaterally.

For example, we will offer a product that according to REMIT guidance could not be classified as block hour and neither as base load, so we could not decide how to classify in the list with standard contracts or more precisely, is it possible to standardize products with daily deviations of +/- 10% or 20% traded via auctions trading mechanism?

Also, how do we need to report offers and trades for products traded via auctions mechanism? May be we need to report them on T+1 with table 1, but for a one-year delivery contract, dealt on auctions mechanism we will have different quantities each hour in the coming days with possibility for different daily deviations between  +/- 20%?

We have classified and specified in ACER`s list of standard contracts product Customizable (+/20%) one-year Base Load with deviations in the load of +/- 20%. This product will be available for trading via our OMP auctions trading mechanism. Every day, MP may have different quantities with +/- 20% for each hour during one-year period.

This kind of contacts usually on XYZ market are reported via Table 2 and as execution with Table 1 after the delivery and after counterparts have received invoices clarifying the prices and the quantity. As OPM, how do we need to report this contract as the future quantities will not be clear to us at time when this contact is concluded, as the quantity deviations will be dealt between the both parties one day before the delivery day?

As the MP`s will have agreed one contract by OMP auctions mechanism with defined terms of payment, what is the right way to report this kind of trades? Do we need to report on a daily basis the different quantities under one-year Customizable (+/20%) Base Load product for this contract every day regarding the nominations schedules not clarifying that this kind of contact is one-year contract under which conditions MP could trade +/-20% deviations from the base load or do we need report this kind of contract just once on T+1 after the auction is finished?

If we have one year contract with base load 10 MW and +/-20% deviations at price of 30 Euro/MW, than the MP that won the auction session will have contract for execution and the buyer will need to send nominations schedules to the seller day before the delivery day regarding his needs, with quantities between 8 MW and 12 MW at price of 30 Euro/MW. If this contract is been concluded once on auctions mechanism at the OMP together with this contract details, what is the right way for reporting?

The auction is anonymous and XXXX is always central counterparty. For example:

  1. company A initiates an auction for sale;
  2. XXXX on behalf of company A holds an auction, as XXXX publishes the auction on the webpage and in the ETS;
  3. company B and C are the buyers;
  4. XXXX signs a contract for purchase with company A and two contracts for sale with companies B and C;
  5. company A sends nominations to the TSO for delivery and to XXXX for consumption;
  6. XXXX sends nominations for delivery to the TSO for company B and C and companies B and C also sent nominations for consumption to XXXX;
  7. companies A, B, C remain anonymous for each other, as they sign contracts only with XXXX.

Answer:

Based on the information provided above, although the exchange acts as counterparty it seems that the auction is organised on behalf of one party and there is no organised market place. Please see Question 1.1.15.

Therefore, based on the above assumptions,  the Agency would expect the following transaction reports on a T+1 month basis the following transactions:

Sell Side: One report for a contract between:

  • MP1 (the generator) and other market participant (OMP ID) of the exchange to be reported with Table 2 (including the details of the Price, quantity and any flexibility of the contracts)

When the exchange has an ACER code (e.g. is also an RRM) or an LEI (the one used for the registration to the list of OMPs) one of the two can be used. However when the OMP does not have and ACER code or an LEI but only a MIC code, then a fictitious code such as  XMIC00000.EU can be used (where XMIC is the MIC code of the exchange acting as central counterparty, please see also  Q. 2.1.5).

Buy side: several reports as many buyers entered into transaction, between:

  • MP2 (the buyer) and other market participant (OMP ID) to be reported   with Table 2 (including the details of the Price, quantity and any flexibility of the contracts)
  • MP3 (the buyer) and other market participant (OMP ID) to be reported   with Table 2  (including the details of the Price, quantity and any flexibility of the contracts)
  • MP….. (the buyer) and other market participant (OMP ID) to be reported   with Table 2  (including the details of the Price, quantity and any flexibility of the contracts)

All the above with the same CONTRACT ID.

Table 2 has a field called CONTRACT ID (rather than UTI) and this should be filled in with the same ID for all the above transactions.

At this point, the following should be considered:

1) If the total quantity it not know prior to the delivery and the delivery is nominated every day during the contract, e.g. a contract for December is nominated daily according to the flexibility of the contract, meaning that the total volume on 30 November is not known, then the execution should be reported according to the example in Annex II, Section 2 of the TRUM .e.g. once a month after the delivery on a T+1 month basis.

Please see Annex II of the TRUM for further guidance. The final agreed delivered volume and price, from the sell side and from the buy side should be reported with Table 1 as EXECUTION and linked to the CONTRAC ID reported in Table 2.

2) If the price and volume are fix prior to the delivery e.g. are known in November for all the delivery period of December, both party have agreed on the final volume and price. Once these are set, cannot be changed and therefore these contracts a forward contracts. The final agreed delivered volume and price, from the sell side and from the buy side should be reported with Table 1 as BILCONTRACT contract and linked to the CONTRAC ID reported in Table 2.

Please note that given the complex nature of these contracts, if they have a defined volume and price prior to delivery of the commodity, these executions should be treated as forward contracts (please FAQs document on transaction reporting, Question 3.1.14 and 3.1.28), meaning that they are reportable as BILCONTRACT contracts linked to TABLE 2 which was previously reported. This implies that the report has to represent the same granularity of information of any other BILCONTRACT contract (please see examples in Annex II, Section 1 for bilateral contracts) and not the type of information with the granularity of the EXECUTION as per ANNEX II, Section 2.

Irrespective of the type of execution, e.g. BILCONTRACT contract or EXECUTION, these have to be reported with Table 1 within 1 month from when the price and quantity are known and, they should include:

Sell Side: One report for a contract between:

  • MP1 (e.g. the generator) and other market participant (OMP ID) to be reported with Table 1 (including the details of the price and quantity, and if the contract is BILCONTRACT type one, with a full delivery profile of the contract). Please see Annex II for examples.

Buy side: several reports as many buyers entered into transaction, between:

  • MP2 (the buyer) and other market participant (OMP ID) to be reported with Table 1 (including the details of the price and quantity, and if the contract is BILCONTRACT type one, with a full delivery profile of the contract). Please see Annex II for examples.
  • MP3 (the buyer) and other market participant (OMP ID) to be reported with Table 1 to be reported with Table 1 (including the details of the price and quantity, and if the contract is BILCONTRACT type one, with a full delivery profile of the contract). Please see Annex II for examples.
  • MP….. (the buyer) and other market participant (OMP ID) to be reported  with Table 1 (including the details of the price and quantity, and if the contract is BILCONTRACT type one, with a full delivery profile of the contract). Please see Annex II for examples.

All of the above (both sell side and buy side) with the same UTI (only for BILCONTRACT contract type) in Table 1 and (still in table 1) Linked transaction ID reporting the CONTRACT ID previously reported with Table 2.

Please note that while there is no obligation for the exchange that is organising the auction to report the market participants records (the obligation lays with market participant) nothing prevents the exchange to provide the reporting service to their clients.

In addition, as already stated in Question 1.1.15, if the Auction is or is not a multilateral system (or any other system or facility in which multiple third-party buying and selling interests in wholesale energy products are able to interact in a way that results in a contract) and therefore not an Organised Market Place, has to be assessed by the person who runs the Auction.

RSS_Icon Last update: 14/12/2016  

FAQs on transaction reporting – Question II.3.1.21

Contracts for the supply of LNG before the entry flange (FAQs on REMIT transaction reporting, Answer to Question 1.1.9) of an EU LNG regasification terminal  include, for example an exchange of title on the high seas with a free delivery clause/full diversion rights or at a non- EU liquefaction terminal. Based on the principle that the above delivery points are not at an EU LNG regasification terminal, then these contracts should not be reported.

However, if the buyer subsequently decides to send a cargo bought under this type of contract to an EU LNG regasification terminal, the cargo unloading will be subject to fundamental data reporting by the buyer. If the cargo — once bought under this type of contract — is “re-traded” by the buyer at or after the entry flange of an EU LNG regasification terminal then the contract relevant to this new transaction will be subject to reporting.


Answer:

In the Agency’s view contracts for the supply of LNG before the entry flange of an EU LNG regasification terminal, for example an exchange of title on the high seas outside the E.U., are not subject to transaction reporting.

Cargos traded under such contracts are subject to the reporting of fundamental data provided once the cargo is unloaded at an EU LNG regasification terminal.

If the cargo – once bought on the high seas outside the E.U. under this type of contract is re-traded by the buyer at or after the entry flange of an EU LNG regasification terminal then the transaction related to the new contract will be subject to reporting.

RSS_Icon Last update: 14/12/2016  

RSS_Icon Subscribe to this Category’s RSS