FAQs on transaction reporting – Question II.2.1.13

Data Field (15)

Reference to documentation: REMIT Transaction Reporting User Manual

What order status should be given when reporting “Stop-loss” when it is not activated?

Example:

The TRUM does not contain any examples of reporting “Stop-loss” order whereas it is quite commonly used by market participants.

Because “Stop-loss” order before its activation is not visible in the order book of the organised market place it cannot be reported as ACT (active). Should it be reported in the field “Order status” as SUS (Suspended) or OTH (Other)?


Answer:

Orders have to be reported when they are visible to the market. This means that in some circumstances they may not be visible to the market and they are not reportable. Once triggered and visible to the market, these orders are reportable with the information that triggered and made them active in the market.

If a “Stop-loss” order is not activated and not visible in the order book of the Organised Market Place, it cannot be reported as active (ACT). Once the order is triggered, this will be reported with the following information:

Once the market order is triggered at 50 EUR and it is entered into the market

  Order details  
13 Order ID I4R9Q3Q6K3D2C1J5O0H8
14 Order type MAR
15 Order Condition SLO
16 Order Status ACT
17 Minimum Execution Volume
18 Price Limit
19 Undisclosed Volume
20 Order Duration GTC
58 Action type N

 

and in the XML file:

<triggerDetails>

<priceLimit>

<value>50</value>

<currency>EUR</currency>

</priceLimit>

</triggerDetails>

Or, if the order was a Price Limit order:

  Order details  
13 Order ID I4R9Q3Q6K3D2C1J5O0H8
14 Order type LIM
15 Order Condition SLO
16 Order Status ACT
17 Minimum Execution Volume
18 Price Limit 50
19 Undisclosed Volume
20 Order Duration GTC
58 Action type N

 

and in the XML file:

<triggerDetails>

<priceLimit>

<value>50</value>

<currency>EUR</currency>

</priceLimit>

</triggerDetails>

The Agency understands that there may be other combinations of order types and order conditions that may require additional guidance. This can be provided on an ad-hoc basis.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.1.29

Data Field (31)

In case of a cross-NEMO trade, how should OMPs report transactions that take place in the XBID platform for the coupled intraday continuous European market? For example:

OMP_1 reports trades matched within one zone/area,

OMP_2 reports trades matched within another zone/area.

What about cross border transactions between OMP_1 and OMP_2 zones? How should the UTIs of such transactions be reported?


Answer:

An example of how to report such transactions is available in the Annex II to the TRUM: Example 2.53 – Life cycle events for orders that match in intraday market coupled.

The only difference between this guidance and Example 2.53 available in Annex II to the TRUM is that in cross-NEMO trades, OMPs receive the same UTIs from the matching platform and therefore do not need to report two UTIs as in Example 2.53, but just one as described in the example below:

 

TRADE LIST OMP_1:

Transaction with UTI XBID_46752 will be reported by OMP_1.

MarketParticipant PRICE QUANTITY LINKODERID UTI Transaction Time
MarketPaticipantOMP_11 21 50 OMP_1-MC-O-123454 XBID_12345 2018-04-18T19:50:32.000Z
MarketPaticipantOMP_12 21 50 OMP_1-MC-O-123456 XBID_12345 2018-04-18T19:50:32.000Z
MarketPaticipantOMP_13 20 100 OMP_1-MC-O-188593 XBID_46752 2018-04-18T19:40:32.000Z

 

TRADE LIST OMP_2:

Transaction with UTI XBID_46752 will be reported by OMP_2.

MarketParticipant PRICE QUANTITY LINKODERID UTI Transaction Time
MarketParticipantOMP_21 19 30 OMP_2-MC-123411 XBID_67891 2018-04-18T19:47:45.000Z
MarketParticipantOMP_22 19 30 OMP_2-MC-123422 XBID_67891 2018-04-18T19:47:45.000Z
MarketParticipantOMP_23 20 100 OMP_2-MC -123433 XBID_46752 2018-04-18T19:40:32.000Z

.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.4.10

Lifecycle events reporting: For a reported trade, during the delivery period, the two parties agree to amend the price and the quantity. The two market participants report the trade modification and they have to report “Total Notional Contract Quantity” and “Notional Amount” in accordance with TRUM and “Open letter on REMIT transaction reporting data quality” (16 February 2017). Please let us know what is the proper way to calculate “Total Notional Contract Quantity” and “Notional Amount” in this case (trade modification).


Answer:

According to the Agency’s understanding, if for a reported trade, during the delivery period, the two parties agree to amend the price and the quantity, this is a new transaction. The early termination should be reported first and the new contract should be reported after. We do understand that market participants may treat this contract as the same contract. But we believe that while it is treated by the system as the same contract, this is in effect a new transaction executed at a different point in time, with different market information leading to different economics.

Example: MP1 and MP2 agree in September 2016 on a yearly supply (forward) contract for the delivery of 10MW at 30 EUR/MW. In the course of July 2017 (or any month during the delivery of such a contract) the two parties decide to change the price or quantity.  A termination “C” of the previous agreement should be reported, as well as a new transaction “N” with a new UTI with the new price and quantity (and delivery period left).

Please note that this applies to Table 1 only when both price and quantity were already agreed on. For Table 2 it is reasonable to believe that the terms and conditions of these contracts may be modifiable and such modifications can be reported with “M” Modify type lifecycle event.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.4.11

How to report in REMIT report case where OMP XXX will remove a trade (standard contract) where a buy order was wrongly submitted and market participant has contacted us and asked for the trade to be removed? Other market participant which was a seller has been contacted and accepts the removal of the trade. In this case, where XXX makes the trade removal from the system, should the actionType be Error (cancellation of wrongly submitted report) or Cancel (a termination of an existing contract or order to trade)?

Practical example:

Market participant C has made an error while adding buy bid, bid was meant to be 45 MWh, but it went into trading system as of 450 MWh. There was already sell bid on the platform (Market Participant A 500 MWh), so bids were matched and trades made. Market participant C contacts us and tells there was a mistake and asks if we can remove the trade from the system. We contacted Market Participant A and told what has happened, and asked if the trade can be removed from the trading system. Market Participant A accepts that. There was also Market Participant B, who made buy bid of 50 MWh which was matched with market participant A’s sell bid. Figures below.

Orders:

  • Market Participant A: Sell bid 500 MWh à Order status: ACT – PMA (with 50 MWh) – MAC
  • Market Participant B: Buy bid 50 MWh à Order status: ACT – MAC
  • Market Participant C: Buy bid 450 MWh à Order: ACT – MAC

Trades:
1st trade

  • Market Participant A: Sell 50 MWh
  • Market Participant B: Buy 50 MWh

2nd trade

  • Market Participant A: Sell 450 MWh
  • Market Participant C: Buy 450 MWh

Both trades in trade 2 (450 MWh sell and 450 MWh buy) will be removed from the trading system by XXX, but orders remain as they are (those cannot be changed). How should this trade removal/cancellation be reported in REMIT report, especially Market Participant A´s order?

REMIT report correction:

For these Transaction timestamp: The time when trade has been removed and Action type: C (Cancel)

  • ORDER Market Participant C: Buy bid 450 MWh à
  • TRADE Market Participant A: Sell 450 MWh
  • TRADE Market Participant C: Buy 450 MWh

For this, does it need something for the correction?

  • Market Participant A: Sell bid 500 MWh à Order status: ACT – PMA (with 50 MWh) – MAC

Answer:

In the Agency’s view, when a trade is cancelled because ‘an order has been wrongly submitted to the trading system by a market participant’, the trade should be cancelled by using Action type “C”.

As the order is visible to the market, it should not be removed from the system and should be reported as an MAC or PMA order, even if it was erroneously submitted by a market participant. Then the trade will be first reported as New (Action type “N”) and then reported as Cancelled (Action type “C”).

For Action type “E” Error, in the TRUM it is explained that ‘when the report contains a cancellation of a wrongly submitted report, it will be identified as ‘error’. This means that Action type “E” for Error should be used when a transaction has been incorrectly sent to ARIS and needs to be removed from the database. Then, a new transaction should be submitted by using a different UTI.

However, the above question describes a case where the error occurs in the system of an OMP (as a result of their client’s mistake) and not in the reporting to ARIS, for example preparation of the file, extraction of data from the system, bugs etc.

Example:  if an OMP reports a trade with the price of 50 EUR instead of 50 GBP, that trade was incorrectly sent. The same applies if the real price is 50 and the OMP reports 35 (or any other price). Therefore, you would report an ‘Error’ transaction and resubmit is with the right price. This is not the case for your question.

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  

FAQs on transaction reporting – Question II.2.1.42

Data Fields (49) and (50)

Could the Agency clarify further “contract start date and delivery start date may be different: e.g. the contract starts on 1 January 2017, but for peak contracts the delivery starts on Monday morning, which is 2 January 2017.“ statement available on its Open letter on REMIT transaction reporting data quality?


Answer:

As indicated in the letter, market participants should refer to the Agency’s guidance on transaction reporting, namely the TRUM, Annex II to the TRUM and the FAQs on transaction reporting and they should also liaise with the RRMs reporting on their behalf as they may provide with additional instructions.

Based on the Agency’s schemas, and the ISO 8601 standard which says “Midnight is a special case and may be referred to as either “00:00” or “24:00″, our understanding is that midnight may be represented as either 00:00:00, 24:00:00 or 23:59:59.

For example, 2016-08-01 00:00:00 represents the same date and time of 2016-07-31 23:59:59 or 2016-07-31 24:00:00.

However, according to the guidance, 23:59:59 and 24:00:00 should not be reported for delivery start time. Time 23:59:59 or 24:00:00 on Day X should be reported as 00:00:00 in day X+1. The same applies to 06:00:00 and 05:59:59 to represent the end of a gas day.

Example: a typical yearly electricity baseload contract is wrongly reported if the delivery start date and time is 2016-12-31 00:00, 2016-12-31 23:59:59 or 24:00:00. The delivery start date and time should be reported as 2017-01-01 00:00:00.

With regard to “contract start date and delivery start date may be different: e.g. the contract starts on 1 January 2017, but for peak contracts the delivery starts on Monday morning, which is 2 January 2017” reporting parties should pay attention to the guidance.

REMIT transaction reporting fields include Field N. (53) “Days of the week” which plays a pivotal role in the simplification of the reporting of delivery profiles. Please see also FAQs on transaction reporting – Question II.2.1.40.

When “Days of the week” is reported correctly, the reported delivery profile will always be the same of the “actual delivery profile” of the contract.

Case 1 – delivery period falls within the calendar period

For electricity contracts, e.g. see example 2.11 in Annex II to the TRUM, a report for the monthly electricity peak load delivery for August 2014. The hourly delivery profile is defined by the fields:

Field N. (49) “Delivery Start Date”: 01/08/2014 identifies the date at which the delivery of the commodity starts as specified in the contract.

Field N. (50) “Delivery End Date”: 31/08/2014 identifies the date at which the delivery of the commodity ends as specified in the contract.

Field N. (53) “Days of the week”: WD identifies on which days of the week the delivery takes place, i.e. week days, as specified in the contract.

Field N. (54) “Load Delivery Intervals”: 08:00/20:00, as specified in the contract

In this specific case 1 August 2014 is Friday, therefore the physical delivery starts on that date. 31 August 2014 is Sunday, thus the physical delivery ends on Friday 29 August.

Case 2 – delivery period falls outside the calendar period

Furthermore, reporting parties should also pay attention to some special circumstances.

For gas contracts, e.g. see example 2.8 in Annex II to the TRUM, given a gas day 06:00 on day D to 06:00 to D+1 may affect the reporting of their monthly contracts. A monthly gas delivery for August 2014, with physical delivery starting on 1 August 2014 delivers gas from 06:00 to 06:00 and the actual physical delivery ends on 1 September 2014 at 06:00. Therefore, the correct way of reporting this contract is:

Field N. (49) “Delivery Start Date”: 01/08/2014

Field N. (50) “Delivery End Date”: 01/09/2014

Field N. (53) “Days of the week”: empty to indicate every day

Field N. (54) “Load delivery intervals”: 06:00/06:00 Another special circumstance is when a monthly electricity off-peak load delivery for August 2014 start at 19:00:00 on 31/07/2014. These are typical monthly contracts but the delivery period falls outside the calendar days, rather than within them.

We are aware that these are industry standards and are used by Organised Market Places (OMPs) and the Agency would expect the reporting of delivery Start and End Date as shown above and in Annex II to the TRUM. The Agency is also aware that in most cases the same standards are used in bilateral trades (non-OMPs trades).

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.37

Data Field (48)

A Market Participant is buying gas for its own needs (fuel gas) outside an OMP via bilateral contract. The delivery point of the gas under the contract conditions (where the commodity changes hands) is an Entry point ABC from production facility. The point ABC is a connection point between the production facility and the gas transmission system of the TSO.

For reporting purposes under the requirements of Article 3(1)(a) of Commission Implementing Regulation (EU) N1348/2014, what data shall be provided in the respective field of schema REMITTable 1 or REMITTable 2: DELIVERY POINT OR ZONE – the EIC of the Entry point ABC or the EIC of the Balancing zone to which the gas is entering?

If the EIC of the Entry point ABC shall be filled in the XML field DELIVERY POINT OR ZONE, the MP needs to add said EIC code to the list of valid EICs. Could you please confirm that it will be possible to add such an EIC via the Agency’s web-tool for mapping/supply of EIC information, e.g. via using “Other” in the point type drop down?


Answer:

The EIC of the Balancing zone should be reported. There is no need to add the Entry point ABC via the Agency’s web-tool for mapping/supply of EIC information.

The same would apply to Domestic/Industrial aggregate points and Distribution zones/networks. If these points are connected to a balancing zone from where the gas/electricity is withdrawn/supplied from, the EIC of the balancing zone should be reported.

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.38

Data Field (48)

A Market Participant is buying gas for its own needs (fuel gas) outside an OMP via bilateral contract.

The delivery point of the gas under the contract conditions (where the commodity changes hands) is a connection point between a storage facility and gas transmission system. The point name is XYZ. Point XYZ is bidirectional.

XYZ (entry) is the point direction from the Storage facility to the Gas transmission system;

XYZ (exit) is the point direction from the Gas transmission system to the Storage facility.

Q. 1  For reporting purposes under the requirements of Article 3(1)(a) of Commission Implementing Regulation (EU) No 1348/2014, what data shall be provided in the respective field of schema REMITTable 1 or REMITTable 2:

  • DELIVERY POINT OR ZONE, if the commodity changes hands at XYZ (entry) or
  • the EIC of the connection point between a storage facility and gas transmission system (XYZ entry) or the EIC of the Balancing zone to which the gas is entering?

Q. 2  For reporting purposes under the requirements of Regulation (EU) No 1348/2014, point 3.1 (a), what data shall be provided in the respective field of schema REMITTable 1 or REMITTable 2: DELIVERY POINT OR ZONE, if the commodity changes hands at XYZ (exit)?


Answer:

Q 1. The Balancing zone the gas is entering into.

Q 2. The Balancing zone the gas storage facility belongs to.

Q 3. There is no need to add a connection point between a storage facility and gas transmission system via the Agency’s web-tool for mapping/supply of EIC information.

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.39

Data Field (48)

Could the Agency clarify the reporting of EICs and their mapping to the balancing zones/areas, interconnection points, LNG and storage facilities?


Answer:

In the Transaction Reporting User Manual (TRUM) after consulting the industry through two public consultations, the Agency has indicated that the Energy Identification Code (EIC) to be reported for transaction reporting purposes for Table 1 and Table 2 has to identify the commodity delivery point or zone.

This field reports the EIC Y code (or an alternative code to be agreed with the Agency if the EIC is not available) to identify the delivery and/or balancing point for the contract. In addition, the TRUM clarifies that since gas can also be delivered at the interconnection point, then the EIC Z Code for that interconnector may be used.

Furthermore, in the FAQs on transaction reporting – Question II.3.1.23, the Agency has indicated that where the gas is delivered at an LNG or a gas storage facility, then the EIC W code for that facility should be reported.

Based on more than 1 billion transactions (Table 1 and Table 2) reported to the Agency, it was found that market participants and organised market places are using more than 4000 codes to indicate the delivery points. In some occasions more than 1000 different codes were used to indicate the same balancing zone.

Since the Agency (supported by the input provided by the industry) does not find this diversification reasonable and has seen that 95% of the overall transactions have been reported with the correct EICs, on 26 June 2017 the Agency has published Annex VI to the TRUM (including the list of accepted EICs) in the REMIT portal and will only consider the codes listed in the list of accepted codes.

In the Agency’s view, if 95% of the reported transactions are compliant with REMIT, there is no reason for the remaining 5% of transactions to be reported with alternative codes.

Market participants that use different codes for nomination purposes at domestic/industrial aggregate points, distribution zones/networks or production sites should report in any case the EIC of the balancing zone these points are connected to. While they may want to keep using those codes for nomination purposes, they will need to translate those codes into the EIC of the balancing zone they are related to when reporting the transaction to the Agency for REMIT purposes.

With regard to interconnection points, the Agency has explained in Annex VI to the TRUM that the reportable Y EIC code has to belong to the interconnection point where gas is delivered and then transferred to the other side of the interconnection point by the system operator. This case applies to unbundled interconnection capacity only.

In Annex VI to the TRUM the Agency has explained that only the EICs in the list of accepted codes are reportable codes. All the other codes available in the sheet “EICs Validity Check” and flagged as “Invalid” , “ENTSO-E” and “Missing” (please carefully read Annex VI to the TRUM) are not considered compliant with the Agency’s guidance according to Article 5(2) of Commission Implementing Regulation (EU) No 1348/2014.

However, in order to help market participants and organised market places to comply with REMIT, the Agency has given the opportunity to clear their transaction reporting history (related to the EICs) through the online “EIC mapping form” (please see Annex VI to the TRUM for the link).

The online form allows reporting parties to map a previously reported EIC (Missing, Invalid, ENTSO-E list) to a code listed in the “List of Accepted EICs” and to report a code for a zone/area/facility that is not included in the “List of Accepted EICs” (or changing its name/function).

However, market participants that have submitted new codes for domestic/industrial aggregate points, distribution zones/networks or production sites connected to a balancing zone, should not expect the inclusion of those codes in the list of accepted codes, unless the Agency believes there is reasonable ground for their inclusion in the list.

The Agency has already updated the list of EICs codes to accommodate TSOs or market participants requests where the Agency believed there was a reasonable ground for the inclusion of new EICs (this is visible in the EIC list of accepted codes spreadsheet attached to Annex VI to the TRUM).

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.1.40

Data Field (48)

A Market Participant is buying gas for its own needs (fuel gas) outside an OMP via bilateral contract. The location where commodity changes hands under the contract conditions is a Gas storage facility.

For reporting purposes under the requirements of Regulation (EU) No 1348/2014, point 3.1 (a), what data shall be provided in the respective field of schema REMITTable 1 or REMITTable 2: DELIVERY POINT OR ZONE – the EIC of the Gas storage facility or the EIC of the Balancing zone to which the Gas storage facility belongs?


Answer:

 

Assuming that the seller is withdrawing the gas from the system and injecting it into the storage, then handing it over to the buyer, or if the seller sells the gas that he already owns in the storage to the buyer, the EIC of the Gas storage facility should be reported.

RSS_Icon Last update: 08/12/2017  

RSS_Icon Subscribe to this Category’s RSS