Please insert at least 3 characters

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

Does the MoP on data reporting describe how to disclose inside information?


Answer:

A distinction should be made between the data collection under Article 8 of REMIT and the disclosure of inside information to the general public under Article 4(1) of REMIT. The scope of the MoP (section 7 on the ‘Reporting of Inside Information’) is not the disclosure of inside information but the provision of web feeds that enable ACER to collect such information in an efficient way. The REMIT Implementing Regulation in its Article 10(1) and (2) on ‘reporting procedures’ defines rules for the provision of such information to the Agency through web feeds. The revised version of the ‘MoP on data reporting’ by the Agency addresses only the standards that should be used for the reporting of such information via web feeds to the Agency.

RSS_Icon Last update: 31/03/2016  

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

Shall I open my web-feed for the public?


Answer:

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


Answer:

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  

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

In case the web-feed is made available both on the market participant’s own website and on an inside information platform on behalf of the market participant, from which source ACER is going to retrieve the UMM data?


Answer:

The primary source of UMM collection will be the platforms and other service providers for the disclosure of inside information. However the Agency will also collect data from the websites of individual market participants.

RSS_Icon Last update: 31/03/2016  

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

Do I have to send my disclosed inside information to the Agency?


Answer:

According to Article 10 of Commission Implementing Regulation (EU) No 1348/2014 on ‘Reporting procedures’, inside information should be collected by the Agency through a specific method: web feeds. In the ‘MoP on data reporting’, the Agency explains in Chapter 3 that “disclosed inside information made available through web feeds is collected by ARIS via a pull mechanism.”

Therefore, inside information should not be sent to the Agency. The collection point is the site where the web feed is embedded (should be the same site where the inside information is disclosed). The Agency will be able to identify the location of the web feed through the URL provided by the market participant in Section 1 of its registration form provided according to Article 9 of REMIT.

According to Article 9(5) of REMIT market participants are required to keep the registration fields updated. Failure to do so will constitute a breach of REMIT and will not allow the Agency to adequately collect the information included in the web feed. The field in Section 1 of the registration form should, therefore, include the exact location of the web feed. A generic reference to a homepage of a website is not considered by the Agency as a complete fulfilment of the registration obligation.

RSS_Icon Last update: 31/03/2016  

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

Could the Agency clarify if, on 1 January 2017, inside information web feeds will be collected from third party inside information platforms and from market participants or only from third party inside information platforms?


Answer:

Market participants and third parties acting on their behalf are obliged to provide the Agency with Inside Information web feeds according to Article 10(1) of Commission Implementing Regulation (EU) No 1348/2014 which entered into force on 7 January 2015. The Agency started the collection of Inside Information web feeds on 1 January 2017 through inside information platforms that publish Urgent Market Messages (UMMs) on behalf of market participants. The list of third party inside information platforms is available at https://www.acer-remit.eu/portal/list-inside-platforms.

The Agency is reviewing the approach for the disclosure of inside information in order to further improve the transparency of the market and enable the Agency itself to collect web feeds more efficiently.

RSS_Icon Last update: 08/01/2019  

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

When should third party platforms be ready to provide inside information web feeds on behalf of market participants in compliance with the Agency’s technical standards?


Answer:

As of 1 January 2017 the Agency is collecting inside information through web feeds made available by inside information platforms. The Agency would expect the inside information platform providers that will be ready as of 1 January 2017 to notify the Agency by 30 November 2016 about the URLs they will use to publish web feeds according to the Agency’s Guidance on the implementation of web feeds for Inside Information Collection.

The Agency also invites those inside information platform providers that may be subject to any implementation delay of the technical standards to notify the Agency about the date by which they will be ready with the implementation in order to enable the Agency to collect the inside information efficiently, as defined in Article 10(1) of the Implementing Regulation. The Agency would expect that existing inside information platforms listed on the Agency’s REMIT Portal will provide web feeds for Inside Information Collection no later than 30 June 2017.

Both notifications should be sent to inside.information@acer.europa.eu by no later than 30 November 2016.

Inside Information Platforms not listed at the Agency’s REMIT Portal and able to provide the Agency with web feeds for Inside Information Collection only after 30 June 2017 can notify the Agency at any time. They would then be listed only once they are able to provide the Agency with web feeds.

RSS_Icon Last update: 08/01/2019  

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


Answer:

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.


Answer:

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


Answer:

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  

RSS_Icon Subscribe to this Category’s RSS