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

FAQs on transaction reporting – Question II.2.1.36

Data Field (48)

Reference to documents: Annex Table 1 (details of reportable contracts) of Regulation (EU) No 1348/2014

Please be advised of the following data issue which has been identified by our company (OMP)

For pure financial products which never result in physical delivery, what should be filled in for field 48 (delivery point or zone).

Two examples

  1. Spread Dutch TT / Italian PSV
  2. German Power Financial

Please note that there is no consistency between the OMPs. For example for German Power. There are 4 different EIC codes used, but also not applicable and blank.

See https://www.acer-remit.eu/portal/standardised-contract

Because there is no physical delivery, the most logical approach is to make this field not applicable. To avoid misunderstanding (parties forgot to add a EIC code where applicable), it is advisable to use a fictive EIC code, for example 99X-NOT-APPLIC–


Answer:

It is our understanding that every contract related to the supply of electricity or gas, irrespective of if the contract is a spot, a physical forward, a future or an option contract has a reference to a delivery period and a delivery point. Also financial products that are settled in cash and never result in physical delivery have a reference price or other attributes which relate to the commodity. In this case, reporting parties should refer to the reference price or other attributes which relate to the electricity or gas and report its delivery point.

For contracts that involve more than one delivery point, all of them should be reported.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.2.1.4

Data Field (3)

Reference to documents: Annex IV to Transaction Reporting User Manual

Is it mandatory for OTC contracts, to fill Table 1, Field 3? In the examples provided by ACER, such fields are filled only for standard contracts and examples 15.2-18.2. What features of examples 15.2-18.2 are triggers for reporting this field? What is the understanding of the person concluding the contract in case of OTC market? Is it a person whose signature appears on the contract?

In our opinion, this field should not be required for contracts concluded OTC.


Answer:

Data Field (3) ID of Trader is required to be populated for any contract executed at organised market places and bilaterally as already indicated in the TRUM. For executions executed under the framework of non-standard contracts, examples are available in Section (2) of Annex II to the TRUM. The Agency would not expect this filed to be reported in line with the examples provided in Annex II to the TRUM.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question II.2.1.30

Data Field (35) and (38)

Reporting negative prices & resulting negative notionals

We wish to get clarification on how to report the following scenario under REMIT from 7th April 2016 onwards:

In some cases a trade may be for a “”negative”” price. This is not the same as the trade being the “”other way around””, i.e. a “”buy”” instead of a “”sell””.

Is it permissible to report negative prices in the various fields, i.e. fields 35 or 57 of table 1, or field 15 of table 2?

The same question would apply to resulting notionals.


Answer:

If the Price of the trade is negative, this should be reported with a negative number. For notional values, these should always be reported in absolute value.

RSS_Icon Last update: 24/03/2016  

RSS_Icon Subscribe to this Category’s RSS