FAQs on fundamental data and inside information – Question III.5.1.11

Separation of more than one market participant or market participant codes (inside information).

Field 17 allows to indicate more than one market participant. It is not clear how different names shall be separated if the unit concerned is owned by various market participants.

Field 18 refers to the market participant code. We were of the opinion that various names in field 17 would have to be accompanied by the same number of market participant codes in field 18. However, the number of eligible character leaves it open whether this is really meant.

There might be owners of a unit who do not have a market participant code such as pension funds. It is not clear who to indicate that.

We suggest to use a semicolon “;” in fields 17 and 18 for the separation of different market participants and different market participant codes. If a market participant has no code we recommend to use “NA”.

This makes sure that there is always the same number of owners and respective codes or respective “NA” and helps to cross-reference publications for any market participant if needed.


Fields 17 and 18 are unbounded in the XML schema meaning that you can repeat multiple values (multiple MPs’ names and EIC codes) inside the schema. The number of Market Participants in field (17) ‘Market Participant’ has to be the same as the number of EIC codes provided in field (18) ‘Market Participant code’. The obligation to publish inside information rests with the Market Participant. If the unit’s owner is not a Market Participant then it should not be reported in fields (17) and (18).

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.5.1.12

ANNEX VII p77/90 Data Field No. 4b Type of Event – It would appear that we can only select one value. As a SSO where we have a TOTAL outage, does this mean that we have to report the loss of injection and withdrawal capacity separately? Hence we would have 2 UMMs for the same event detailing loss in both directions?

In the case of bidirectional sites we would expect to see loss of capacity in both directions on a single UMM however we have interpreted the Data field above as 2 UMMs reporting loss of availability, one for injection and one for withdrawal.


In case of a total outage of a gas storage facility when a loss of both injection and withdrawal capacity occurs, the value ‘Storage unavailability’ shall be provided in the (4/b) Type of Event field. The value ‘Storage unavailability’ represents a combination of both ‘Injection unavailability’ and ‘Withdrawal unavailability’ and hence only 1 UMM is reportable for a total outage.

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.4.1.10

Does the Agency need to be aware about the point direction for which the affected capacity is announced? If yes, how this information shall be provided through XML based on UMM Schema No 2 “Unavailabilities for gas facilities”?

The format for the XMLs for “Unavailabilities for gas facilities” (Schema No2) does not contain attribute for the point direction.

In the context of publication of unavailabilities for gas facilities, an “Affected asset or units” could be the connection point (cross-border, interconnection point, delivery point, measurement point etc.). In case that the affected point is bidirectional, the point capacity is direction dependent, respectively the values of the UMM Schema No2 attributes: Technical capacity, Available capacity and Unavailable capacity depend on the point direction.

In summary, the technical, available and booked capacities in normal circumstances are different for the different point direction. This means that during an event of unavailability both sites of a point could be affected and respectively – the affected capacities are different per point direction.


The point direction shall be identified via field (15/b) Balancing zone in case that the affected point is bidirectional. The field allows for multiple EIC codes identifying balancing zones and the point direction will be determined by the order of EIC codes in the XML schema. The first EIC code should refer to the ENTRY point (IN= Balancing Zone where the flow starts), and the second EIC code should refer to the EXIT point (OUT= Balancing Zone where the flow ends).

When a connection point between a transmission system and LNG terminal or transmission system and Storage facility, or transmission system and TSO from a non-EU country is affected, the submission of IN and OUT balancing zones should reflect the direction of the flow with the above IN/OUT logic applied to the facilities.

For example: if the outage is related to the flow from an LNG facility towards the Gas Transmission Network, the first EIC should represent the LNG facility and the second the Balancing zone. Example:

W EIC LNG facility= Entry point

Y EIC Balancing zone= Exit point

The same applies to storage facilities and bidirectional interconnection points.

For complex cases when one point connects more than two balancing zones, the following logic shall apply:

If the direction is from Entry Point (EIC 1) to several exit points, the first EIC code represents the entry point, the second (EIC 2) and third (EIC 3) /fourth (EIC 4) EICs represent the exit points. If the outage occurs at EIC 1 then the first code will be EIC 1 and then all the possible EICs affected zones should be reported after that. Example:

Reporting party: TSO 1

EIC 1 = Entry point

EIC 2= Exit point

EIC 3 = Exit point

EIC 4 = Exit point

If the outage is at the exit point (e.g. EIC 4) the report should indicate two points as the TSO/operator of EIC 4 will not be able to publish any information about EIC 2 and EIC 3. Example

Reporting party: TSO 4

EIC 1 = Entry point

EIC 4 = Exit point

Or in case or reverse flow:

If the outage is at the entry point (e.g. EIC 4) the report should indicate two points as the TSO/operator of EIC 4 will not be able to publish any information about EIC 2 and EIC 3. Example

Reporting party: TSO 4

EIC 4 = Entry point

EIC 1 = Exit point

If the outage is at the exit point (e.g. EIC 2) the report should indicate two points as the TSO/operator of EIC 2 will not be able to publish any information about EIC 4 and EIC 3. Example:

Reporting party: TSO 2

EIC 1 = Entry point

EIC 2 = Exit point


RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.4.1.14

Unavailability of unit EIC for gas consumption units (inside information).

Field 16 requires an EIC for the identification of a physical asset. We received the information from market participants that the EIC issuing body for gas consumption units in Germany is not able to provide those codes before the end of 2016 or beginning of 2017. Therefore, it is rather likely that those codes are not available.

The issue does not refer to power production, storage or consumption units where code availability is no problem.

The respective field 16 would remain empty. We suggest to allow us to provide the inside information without EIC on a temporary basis.


The above proposal is reasonable. Once the EIC codes are available they should be provided in the UMMs collected by the Agency.

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.4.1.8

Where the “other market information” schema (annex VII .111) is produced by a market participant – does this require reporting through the “Storage Unavailability report” (pg 69)?

Our interpretation is that the “storage unavailability report” will not be sent where we are reporting “other market information”.


The “Storage Unavailability Report” is designed for reporting of fundamental data according to Article 9(5) of Commission Implementing Regulation (EU) No 1348/2014 while the “Other market information” is designed for inside information reporting according to Article 10(1) of Commission Implementing Regulation (EU) No 1348/2014. The reporting of the “Other market information” report does not replace the obligation to provide the “Storage Unavailability Report”.

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.4.1.9

Thank you for the clarifications made in the FAQ on REMIT fundamental data and insider information collection.

Related to question 5.1.8 I have another question. According to the answer, all events shall be reported as per affected unit. This means that one event that affects three units shall be reported in three unique web feed messages.

Now considering the case of an event affecting one unit but with a time varying capacity (e.g. three different values for capacity for the different time frames). Shall this event also be reported as three separate web feed messages each containing only one capacity value?

Our proposal earlier was in this case was to only report the lowest capacity value. That solution would mean that one event maps to one web feed message. Depending on your answer to the question above, the alternative would be to map one event with three web feed messages when we have time varying capacity. In any case, our design is highly dependent on a clarification of the raised point and I hope you are able to give some guidance on this matter.


The Agency has discussed possible solutions on how to report the above mentioned event during the Inside Information Platforms roundtable meetings and concluded the following guidance for the reporting of planned and unplanned unavailability:

Planned unavailability: three separate UMMs are published for each of the three intervals.

The three messages should be published with the same timestamps unless they are different events.

Unplanned unavailability: one UMM is published (e.g. at 10 am). The UMM will be updated at 11:30 am and 12:30 pm. The three messages should have different timestamps.

RSS_Icon Last update: 15/11/2016  

FAQs on fundamental data and inside information – Question III.5.1.8

Regarding fields 16 (“Affected Asset or Unit”) and 17 (“Affected Assets or Unit EIC Code”), shall market participants submit only one message when there is an event that affects several units or assets due to the same reason?


The provision of web feeds should be simultaneous to the disclosure of inside information under Article 4(1) of REMIT. If more than one message is published then more than one should be submitted.

If the UMM disclosed publicly refers to more than one facility, and as the schema for reporting only allows the identification of one facility per web feed message, the message needs to be disaggregated by facility for data collection purposes. Another option is to use a single web feed message according to the 3rd schema type – “Other market information” in case the event affects a large number of facilities (e.g.: in case of general strike, floods affecting hydro generation etc.).

RSS_Icon Last update: 16/06/2016  

FAQs on fundamental data and inside information – Question III.4.1.2

Shall I open my web-feed for the public?


According to Article 10(1) of the REMIT Implementing Regulation, the requirement to provide the feeds is towards the Agency. However, in order to further increase wholesale market transparency the Agency encourages market participants and platforms for the disclosure of inside information to make their web feeds available for all stakeholders.

RSS_Icon Last update: 31/03/2016  

FAQs on fundamental data and inside information – Question III.5.1.5

Consumption unit, injection and offtake capacity of gas storage facilities has thermal capacity in MW. How can it be measured in other units?


If the time element of the event is considered, the thermal capacity can be converted into units of energy. For a consumption unit, the unavailable capacity is the total technical capacity which cannot be used in the period of the outage, even if under normal circumstances it is not utilised at full capacity.

The time element of an event allows for the conversion from units of power into units of energy. Further, storage withdrawal and injection capacity availabilities can be expressed in MWh/d.

Using GWh/d or MWh/d is the general practice for measuring outages in the gas market.

Example on how to convert MW into MWh/d for a loss in the gas consumption: Assuming we have a gas power plant with a technical capacity of 200 MW and a net efficiency of 46%. If this unit would be completely unavailable it would result in an unavailable capacity of 200MW*24h/0.46 ≈ 10435 MWh/d.

However, for a five minute partial outage in which the average unavailability will be a rough estimate the extrapolation for the whole day may be somehow less accurate. Nevertheless, according to the samples collected by ACER the number of outages which lasted less than half an hour were extremely low in recent years. Therefore, based on the evidence currently available, ACER does not see a need to expand the list of available units of measurement with MW for gas related UMMs.

RSS_Icon Last update: 31/03/2016  

FAQs on fundamental data and inside information – Question III.4.1.3

What is the deadline for the implementation of web feeds; and what happens if a market participant is not ready to send the information by this deadline?


As explained in point III.7.2 of the 14th Edition of the ‘Questions & Answers on REMIT’: “In line with Article 10(1) of Commission Implementing Regulation (EU) No 1348/2014, (i) market participants disclosing inside information on their website or (ii) service providers disclosing such information on market participants’ behalf, shall provide web feeds to enable the Agency to collect these data efficiently. In principle, this obligation applies as of 7 January 2015 when Commission Implementing Regulation (EU) No 1348/2014 entered into force. However, the Agency will only start collecting such data as of 1 January 2017.”

RSS_Icon Last update: 31/03/2016  

RSS_Icon Subscribe to this Category’s RSS