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

Particular situations of gas transmission unavailability – Example 1.

How should the event be properly presented by using the available daily capacity units (kWh/d)?

How to calculate and correctly publish the amount of available and unavailable capacity?

The Agency’s guidance and the format for the XMLs for “Unavailabilities for gas facilities” allow the usage of kWh/day or mcm/day as the only acceptable units for events related to gas transmission system unavailabilities.

Example: Publication of UMM in case of unavailability of gas transmission for an event that lasts several hours during a single gas day.

Case:

    • Event start: 2015-11-06 08:00
    • Event stop: 2015-11-06 14:00
    • Technical capacity in normal circumstances: 1000 kWh/h
    • The event lasts 6 hours during a single gas day and the value of the affected capacity is constant during the whole event

Description of the event and the capacity unavailability:

Gas day: 2015-11-06
Gas hour: Available kWh/h Unavailable kWh/h
6 1000 0
7 1000 0
8 50 950
9 50 950
10 50 950
11 50 950
12 50 950
13 50 950
14 1000 0
15 1000 0
16 1000 0
17 1000 0
18 1000 0
19 1000 0
20 1000 0
21 1000 0
22 1000 0
23 1000 0
24 1000 0
1 1000 0
2 1000 0
3 1000 0
4 1000 0
5 1000 0

Answer:

The new schema “REMITUMMGasSchema_V1.xsd” (available from: https://documents.acer-remit.eu/remit-reporting-user-package/mop-on-data-reporting/viii-xml-schema-for-inside-information-reporting/) contains also “kWh/h” as an allowed unit and the schema can be already used for gas inside information reporting.

The previous schema REMITUMMGasSchema_V1_OLD.xsd without the “kWh/h” unit is still supported by ARIS and can be used for gas inside information reporting. If the old schema is used the below conversion from kWh/d to kWh/h applies. In the future (expected time: 2019/2020) the Agency will discontinue using the OLD version of the schema. Provided example represents one event and is reportable with following elements:

Event start: 2015-11-06 08:00 – Event stop: 2015-11-06 14:00

  • the unavailable capacity is 950 kWh/h = 950*24 = 22800 kWh/d
  • the available capacity is 50 kWh/h = 50*24 = 1200 kWh/d

Technical capacity is 1000 kWh/h= 1000*24= 24000 kWh/d.

RSS_Icon Last update: 08/01/2019  

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

Particular situations of gas transmission unavailability – Example 2.

How should the event be properly presented by using the daily capacity units (kWh/d) and how should the changing capacity values during the different hourly sub-periods be published?

By publishing one UMM message for the whole period – 3 days?

By publishing one UMM message for each gas day?

By publishing one UMM message for each of the sub-periods?

How to calculate and correctly publish the amount of available and unavailable capacity?

The Agency’s guidance and the format for the XMLs for “Unavailabilities for gas facilities”, allow the usage of kWh/day or mcm/day as the only acceptable units for events related to gas transmission system unavailabilities.

Example: Publication of UMM in case of unavailability of gas transmission for an event that lasts more than one gas day and contains sub-periods that differ in the number of the affected hours and the values of the available and unavailable capacity per day and per hour.

Case:

  • Event start: 2015-11-06  01:00
  • Event stop: 2015-11-08 18:00
  • Technical capacity in normal circumstances: 1000 kWh/h
  • The event lasts 3 gas days and contains 3 sub-periods that differ in the number of the affected hours and the values of the available and unavailable capacity per day and per hour, as follows:
    • 5 hours during the 1st gas day, the unavailability is 950 kWh/h
    • 24 hours during the 2nd gas day, for 20 hours the unavailability is 900 kWh/h and for 4 hours the unavailability is 850 kWh/h
    • 6 hours during the 3rd gas day, the unavailability is 850 kWh/h
    • The values of the available and unavailable capacity could vary each sub-period

Description of the event and the capacity unavailability:

Gas day: 2015-11-06 2015-11-07 2015-11-08
Gas hour: Available kWh/h Unavailable kWh/h Available kWh/h Unavailable kWh/h Available kWh/h Unavailable kWh/h
6 1000 0 100 900 150 850
7 1000 0 100 900 150 850
8 1000 0 100 900 150 850
9 1000 0 100 900 150 850
10 1000 0 100 900 150 850
11 1000 0 100 900 150 850
12 1000 0 100 900 1000 0
13 1000 0 100 900 1000 0
14 1000 0 100 900 1000 0
15 1000 0 100 900 1000 0
16 1000 0 100 900 1000 0
17 1000 0 100 900 1000 0
18 1000 0 100 900 1000 0
19 1000 0 100 900 1000 0
20 1000 0 100 900 1000 0
21 1000 0 100 900 1000 0
22 50 950 100 900 1000 0
23 50 950 100 900 1000 0
24 50 950 100 900 1000 0
1 50 950 100 900 1000 0
2 50 950 150 850 1000 0
3 50 950 150 850 1000 0
4 50 950 150 850 1000 0
5 50 950 150 850 1000 0

Answer:

The new schema “REMITUMMGasSchema_V1.xsd” (available from: https://documents.acer-remit.eu/remit-reporting-user-package/mop-on-data-reporting/viii-xml-schema-for-inside-information-reporting/) contains also “kWh/h” as an allowed unit and the schema can be already used for gas inside information reporting. The previous schema REMITUMMGasSchema_V1_OLD.xsd without the “kWh/h” unit is still supported by ARIS and can be used for gas inside information reporting. If the old schema is used the below conversion from kWh/d to kWh/h applies. In the future (expected time: 2019/2020) the Agency will discontinue using the OLD version of the schema.

The provided example consists of three events to be reported.

1) Event start: 2015-11-06 22:00 – Event stop: 2015-11-07 06:00:

  • the unavailable capacity is 950 kWh/h = 950*24 = 22800 kWh/d
  • the available capacity is 50 kWh/h = 50*24 = 1200 kWh/d

2) Event start: 2015-11-07 06:00 – Event stop: 2015-11-08 02:00:

  • the unavailable capacity is 900 kWh/h = 900*24=21600 kWh/d
  • the available capacity is 100 kWh/h = 100*24 = 2400 kWh/d

3) Event start: 2015-11-08 02:00 – Event stop: 2015-11-08 12:00:

  • the unavailable capacity is 850 kWh/h = 850*24=850*24=20400 kWh/d
  • the available capacity is 150 kWh/h = 150*24 = 3600 kWh/d

Technical capacity is 1000 kWh/h = 1000*24=24000 kWh/d.

RSS_Icon Last update: 08/01/2019  

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

Particular situations of gas transmission unavailability – Example 3.

 

How should the event be properly presented by using the daily capacity units (kWh/d) and how should the changing capacity values during the different hourly sub-periods be published?

By publishing three UMM messages – one for each of the sub-periods as follow:

UMM 1_001= The 1st gas day (13:00-6:00) -> 950×17/24 = 672.9 kwh/d

UMM 2_001= The 2nd gas day (6:00-6:00) -> 950×24/24=950 kwh/d

UMM 3_001= The 3rd gas day (6:00- 18:00) -> 950×12/24 = 475 kwh/d

or

By publishing one UMM message for the whole period – 3 days?

UMM 1_001= [The 1st gas day (13:00-6:00) + The 2nd gas day (6:00-6:00) + The 3rd gas day (6:00- 18:00)] / 3 = (672.9 kwh/d +950 kwh/d +475 kwh/d) /3= 699.3 kwh/d

How to calculate and correctly publish the amount of available and unavailable capacity?

The Agency’s guidance and the format for the XMLs for “Unavailabilities for gas facilities”, allow the usage of kWh/day or mcm/day as the only acceptable units for events related to gas transmission system unavailabilities.

Example: Publication of UMM in case of unavailability of gas transmission for an event that lasts several gas days.

Case :

  • Event start: 2015-11-06 13:00
  • Event stop: 2015-11-08 18:00
  • Technical capacity in normal circumstances: 1000 kWh/h
  • The event lasts 3 gas days and contains 3 sub-periods, as follows:
    • 17 hours during the 1st gas day, the unavailable is 950 kWh/h
    • 24 hours during the 2nd  gas day,  the unavailable is 950 kWh/h
    • 12 hours during the 3rd gas day, the unavailable is 950 kWh/h

Description of the event and the capacity unavailability:

Gas day: 2015-11-06 2015-11-07 2015-11-08
Gas

hour:

Available kWh/h Unavailable kWh/h Available kWh/h Unavailable kWh/h Available kWh/h Unavailable kWh/h
6 1000 0 50 950 50 950
7 1000 0 50 950 50 950
8 1000 0 50 950 50 950
9 1000 0 50 950 50 950
10 1000 0 50 950 50 950
11 1000 0 50 950 50 950
12 1000 0 50 950 50 950
13 50 950 50 950 50 950
14 50 950 50 950 50 950
15 50 950 50 950 50 950
16 50 950 50 950 50 950
17 50 950 50 950 50 950
18 50 950 50 950 1000 0
19 50 950 50 950 1000 0
20 50 950 50 950 1000 0
21 50 950 50 950 1000 0
22 50 950 50 950 1000 0
23 50 950 50 950 1000 0
24 50 950 50 950 1000 0
1 50 950 50 950 1000 0
2 50 950 50 950 1000 0
3 50 950 50 950 1000 0
4 50 950 50 950 1000 0
5 50 950 50 950 1000 0

Answer:

The new schema “REMITUMMGasSchema_V1.xsd” (available from: https://documents.acer-remit.eu/remit-reporting-user-package/mop-on-data-reporting/viii-xml-schema-for-inside-information-reporting/) contains also “kWh/h” as an allowed unit and the schema can be already used for gas inside information reporting.

The previous schema REMITUMMGasSchema_V1_OLD.xsd without the “kWh/h” unit is still supported by ARIS and can be used for gas inside information reporting. If the old schema is used the below conversion from kWh/d to kWh/h applies. In the future (expected time: 2019/2020) the Agency will discontinue using the OLD version of the schema.

The provided example represents one event with following elements:

Event start: 2015-11-06 13:00 – Event stop: 2015-11-08 18:00

  • the unavailable capacity is 950 kWh/h = 950*24 = 22800 kWh/d
  • the available capacity is 50 kWh/h = 50*24 = 1200 kWh/d

Technical capacity is 1000 kWh/h = 1000*24=24000 kWh/d.

RSS_Icon Last update: 08/01/2019  

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

Can the Agency provide technical specifications that describe how ACER’s system will connect to platform’s RSS feed and what kind of information the RSS feed will extract?


Answer:

Please consult the REMIT Guidance on the implementation of web feeds for Inside Information Platforms.

RSS_Icon Last update: 08/01/2019  

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

When will the Agency start collecting inside information web feeds from individual Market Participants’ websites?


Answer:

The Agency will not be collecting web feeds from Market Participants’ websites until further notice.

RSS_Icon Last update: 18/05/2017  

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

How should this particular event be presented for inside information reporting on LNG deliverability restrictions (within UMM)?

Case: the event lasts more than one gas day.

  • Event start: 2015-11-06 01:00 (am)
  • Event stop: 2015-11-08 18:00

The event lasts 3 gas days and contains 3 sub-periods that differ in the number of the affected hours and the values of the availability and unavailability per day as follows:

Technical availability in normal circumstances: (6,78 GWh/h*24h) = 162,72 GWh per gas day

o 5 hours during the 1st gas day, the unavailability is 33,9 GWh

o 24 hours during the 2nd gas day, for 24 hours the unavailability is

162,72 GWh

o 12 hours during the 3rd gas day, the unavailability is 81,36 GWh

The values of the availability and unavailability could vary each sub-period.

Gas day: 2015-11-06 2015-11-07 2015-11-08
Gas

hour:

Availability

GWh/h

Unavailability

GWh/h

Availability

GWh/h

Unavailability

GWh/h

Availability

GWh/h

Unavailability

GWh/h

6 6,78 0 0 6,78 0 6,78
7 6,78 0 0 6,78 0 6,78
8 6,78 0 0 6,78 0 6,78
9 6,78 0 0 6,78 0 6,78
10 6,78 0 0 6,78 0 6,78
11 6,78 0 0 6,78 0 6,78
12 6,78 0 0 6,78 0 6,78
13 6,78 0 0 6,78 0 6,78
14 6,78 0 0 6,78 0 6,78
15 6,78 0 0 6,78 0 6,78
16 6,78 0 0 6,78 0 6,78
17 6,78 0 0 6,78 0 6,78
18 6,78 0 0 6,78 6,78 0
19 6,78 0 0 6,78 6,78 0
20 6,78 0 0 6,78 6,78 0
21 6,78 0 0 6,78 6,78 0
22 6,78 0 0 6,78 6,78 0
23 6,78 0 0 6,78 6,78 0
24 6,78 0 0 6,78 6,78 0
1 0 6,78 0 6,78 6,78 0
2 0 6,78 0 6,78 6,78 0
3 0 6,78 0 6,78 6,78 0
4 0 6,78 0 6,78 6,78 0
5 0 6,78 0 6,78 6,78 0
=128,82 GWh = 33,9 GWh = 0 GWh = 162,72 GWh = 81,36 GWh = 81,36 GWh

According to the Manual of Procedures (MoP) on data reporting: ANNEX VI Fundamental data reporting, VI.V XML SCHEMA FOR LNG DATA document, presentation of this event for LNG data on unavailability (within the fundamental data reporting to ACER) is:

Case:

  • Event start: 2015-11-06 01:00 (am)
  • Event stop: 2015-11-08 18:00

o 5 hours during the 1st gas day, the unavailability is 33,9 GWh

o 24 hours during the 2nd gas day, for 24 hours the unavailability is

162,72 GWh

o 12 hours during the 3rd gas day, the unavailability is 81,36 GWh

Then unavailability = (33,9 GWh + 162,72 GWh + 81,36GWh)/3 gas days = (277,98 GWh)/3 gas days = 92,66 GWh/d

Unavailability = average per gas day is 92,66 GWh/d

According to the Manual of Procedures (MoP): ANNEX VII Data fields for inside information reporting, UMM schema II. and FAQs on REMIT fundamental data and inside information collection (3rd edition, 15 November 2016) documents, the presentation of this event for inside information reporting on LNG deliverability restrictions (within UMM) should be:

There are three events and three UMMs are published:

The first UMM: 001_001

  1. Event start: 2015-11-06 01:00 (am) – event end: 2015-11-07 05:59:
  • the unavailability is 6,78 GWh/h * 5h = 33,9 GWh
  • the availability is 6,78 GWh/h * 19h= 128,82 GWh

The unavailability for the first gas day is 33,9 GWh

The second UMM:002_001

2) Event start: 2015-11-07 06:00 – event end: 2015-11-08 05:59

  • unavailability is 6,78 GWh/h * 24h = 162,72 GWh
  • the availability is 6,78 GWh/h * 0h= 0 GWh

The unavailability for the second gas day is 162,72 GWh

The third UMM:003_001

3) Event start: 2015-11-08 06:00 – event stop: 2015-11-08 18:00:

  • the unavailability is 6,78 GWh/h *12h=81,36 GWh
  • the availability is 6,78 GWh/h *12h =81,36 GWh

The unavailability for the second gas day is 81,36 GWh

Conclusion:

For this particular event:

  • ACER receives information within fundamental data reporting that the unavailability is, on average, 92,66 GWh per gas day for the whole event.

The market within UMM publications (and ACER within RSS for UMMs) receives information that the unavailability is respectively: 33,9 GWh (for the first gas day), 162,72 GWh (for the second gas day) and 81,36 GWh (for the third gas day).


Answer:

  1. Fundamental Data reporting

MoP on data reporting: The unavailability report is used to report any planned or unplanned unavailability of a facility for a gas day or period within a gas day. The unavailableCapacity shall be reported with a GWh/d unit.

In the example provided above one lngUnavailabilityReport shall be sent to the Agency:

lngUnavailabilityReport

  • unavailabilityStart: 2015-11-07 01:00 – unavailabilityEnd: 2015-08-18:00
  • unavailableCapacity: 6,78 GWh/h*24h/d=162,72 GWh/d

2. Inside Information

This is one event:

  • Event start: 2015-11-07 01:00 – Event stop: 2015-11-08 18:00
  • the unavailable capacity is 6,78 GWh/h = 6,78 GWh/h*24h/d = 162,72 GWh/d

Please note the recent update of the MoP on data reporting v 4.0; the GWh/d unit can be selected for LNG deliverability restrictions events.

 

RSS_Icon Last update: 18/05/2017  

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

Could you advise us how to fill the field 10 “Available Capacity” in case of overlapping partial unavailability? Or could you reconsider to make the field “Available Capacity” optional?

Practical Example

A generation, production, or consumption unit may have different, overlapping unavailabilities with different reasons, types, start and end dates. In such cases, the “available capacity” of the entire facility may change over the duration of an individual event. Since a reader can easily calculate the available capacity from the fields 9 and 11/a-11/b by aggregating over all open events at a certain point in time, requiring field 10 does not add any further information.

In our opinion, field 10 should be optional, as any mandatory usage of the field could be misleading.


Answer:

Please find below the graphical representation of two overlapping unavailabilities with different start and end dates including examples on how to populate UMM reports:

UMM Reports:

10 am

1st Report (Event 1)

Message ID:12345-28X-TradingAG-BR-C_001

Event Start and Stop: 10 and 12pm

Available capacity: 70

Unavailable capacity:30

 

11 am

2nd Report (Event 2)

Message ID:12345-28X-TradingAG-SD-D_001

Event Start and Stop: 11 and 1pm

Available capacity: 30

Unavailable capacity:40

Optional: “Remarks” field in the 2nd Report : “Additional Unavailability to ID:12345-28X-TradingAG-BR-C_001”

RSS_Icon Last update: 15/11/2016  

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

In the Agency’s Manual of Procedures, v.3 and 4, in the part describing the requirements of the attributes of the two types of UMM XMLs, the description of the “Message ID” attribute says:

“The field ‘Message ID’ consists of two parts: ‘UMM thread ID’ and ‘Version Number’ separated by the underscore character. ‘Message ID’ = ‘UMM thread ID’_‘Version Number’

‘UMM thread ID‘part is the identifier of a series of UMMs reporting on the same event after potential updates. The ‘UMM thread ID‘remains unchanged even if the UMM is updated. The format of the ‘UMM thread ID‘part is to be set by the entity disclosing the information but should include no more than 25 alphanumeric characters.

‘Version Number’ is the unique identifier of UMM versions in a single UMM thread. It helps to reconstruct the history of prior publications. ‘Version Number’ consists of a sequential number with 3 numeric characters where 001 stands for the first UMM in a thread, 002 marks the first update, 003 the second update and so on.

Context of the question:

  • UMMs publication by an MP on any Platform for Inside Information publication and on its own web-site;
  • definition of convention for creation of the “UMM thread ID” part of the ”Messaged ID”.

Question:

How should we interpret the requirement: “The ‘UMM thread ID‘part is the identifier of a series of UMMs reporting on the same event after potential updates. The ‘UMM thread ID‘remains unchanged even if the UMM is updated. The format of the ‘UMM thread ID‘part is to be set by the entity disclosing the information”?

Who should define the ‘UMM thread ID’ – the MP or the Platform for publication of inside information? Do you require the published ‘UMM thread ID’ and the one submitted to ARIS to be one and the same?

In case that an MP would like to publish UMMs on its own web-site and on a Platform for disclosure of Inside information, it is reasonable to expect the Message ID for both publications for one and the same event to be equal.

One interruption event of gas infrastructure may affects many assets or units (points). If an MP publishes one single UMM for one event, including all of its affected points, both on its own web-site and on a Platform for Inside Information disclosure,

  • According to the Agency’s Manual of Procedures’ requirements, the information for every single affected asset or unit shall be made available via web-feeds to the Agency by individual XMLs.

Possible approaches:

Taking the above-mentioned into consideration, the Platform operator would have two options for identifying the messages submitted/made available via web-feeds to the Agency:

1) The Platform operators uses the Message ID (‘UMM thread ID’) provided by the MP for the UMM publication and replicates it for all XMLs for each affected by an event assets or units (points). Thus, in case of several affected points within one event, there will be several UMM XMLs (made available via web-feeds to the Agency) with one and the same Message ID (‘UMM thread ID’). It will still be possible to differentiate them via the “Affected asset or unit name” attribute content.

OR

2) The Platform operator generates completely new Message ID for every single XML (made available via web-feeds to the Agency), per affected asset or unit (point) by an event. The Message IDs (‘with the original Message ID (‘UMM thread ID’), used for the UMM publication on the MP web-site and on the Platform for Inside Information disclosure. It could be possible to see both Message IDs when accessing the published UMMs on the Platform operator/MP web-site, but the XMLs made available to the Agency will contain only the Message ID (‘UMM thread ID’) defined by the Platform operator.


Answer:

The Message ID is to be set either by a Market Participant or the entity disclosing the information on behalf of the Market Participant. The Message ID shall be unique per XML, thus if multiple assets are affected by the same event each XML specifying the affected asset will have its unique Message ID.

RSS_Icon Last update: 15/11/2016  

RSS_Icon Subscribe to this Category’s RSS