FAQs on transaction reporting – Question II.2.1.22

Data Field (28)

Data Field No (28) Contract trading hours in case of auction markets

1 case: Day ahead market: flow date 20150708

Contract Trading Start: 29/06/2015 08:00 local time

Contract Trading End: 07/07/2015 12:00 local time

Last Trading Date and time field 29: 07/07/2015 12:00 local time

Auction Result:  07/07/2015 13:00 local time

2 case: Intraday market: flow date 20150707

Contract Trading Start: 06/07/2015 17:30 local time

Contract Trading End: 07/07/2015 03:45 local time

Last Trading Date and time field 29: 07/07/2015 03:45 local time

Auction Result:  07/07/2015 04:00 local time

3 case:  intraday market: flow date 20150708

Contract Trading Start: 07/07/2015 12:55 local time

Contract Trading End: 07/07/2015 15:00 local time

Last Trading Date and time field 29: 07/07/2015 15:00 local time

Auction Result:  07/07/2015 15:30 local time

1 case: Day ahead market: flow date 20150708

We will report all orders, considered valid and submitted in the timeframe between  29/06/2015 08:00  and  07/07/2015 12:00, considering:

<contractTradingHours>

<startTime>00:00:01+02:00</startTime>

<endTime> 23:59:59+02:00</endTime>

<contractTradingHours>

Thus without any indication of the date, indicated only in field 29:

<lastTradingDateTime>2015-07-07T12:00:00+02:00</lastTradingDateTime>

2 case: Intraday market: flow date 20150707

We will report all orders, considered valid and submitted in the timeframe between  06/07/2015 17:30 and  07/07/2015 03:45 considering:

<contractTradingHours>

<startTime>00:00:01+02:00</startTime>

<endTime> 23:59:59+02:00</endTime>

<contractTradingHours>

<lastTradingDateTime>2015-07-07T03:45:00+02:00</lastTradingDateTime>

Otherwise we propose to consider in this case:

<contractTradingHours>

<startTime>17:30:00+02:00</startTime>

<endTime> 03:45:00+02:00</endTime>

<contractTradingHours>

<lastTradingDateTime>2015-07-07T03:45:00+02:00</lastTradingDateTime>

3 case:  intraday market: flow date 20150708

We will report all orders, considered valid and submitted in the timeframe between  07/07/2015 12:55 and  07/07/2015 15:00, considering:

<contractTradingHours>

<startTime>12:55:00+02:00</startTime>

<endTime>15:00:00+02:00</endTime>

<date>2015-07-07</date>

<contractTradingHours>

<lastTradingDateTime>2015-07-07T15:00:00+02:00</lastTradingDateTime>


Answer:

The correct way to report the <contractTradingHours></contractTradingHours> is:

Case 1 above:

<contractTradingHours>

<startTime>00:00:00+02:00</startTime>

<endTime> 23:59:59+02:00</endTime>  (or 24:00:00+02:00)

</contractTradingHours>

Case 2 above:

<contractTradingHours>

<startTime>17:30:00+02:00</startTime>

<endTime> 03:45:00+02:00</endTime>

</contractTradingHours>

Case 3 above:

<contractTradingHours>

<startTime>12:55:00+02:00</startTime>

<endTime>15:00:00+02:00</endTime>

<date>2015-07-07</date>

<contractTradingHours>

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.2

Different but valid interpretations of delivery profiles

As an example –  an off peak trade I currently build as

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>08:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>20:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>WN</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

but it could equally, legally be described as this.

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>20:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>08:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>WN</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

We would prefer our version as it is clearer, does it matter? They are both schema valid and correct to our mind

Same question for NBP gas. We currently generate this

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

<deliveryProfile>

<daysOfTheWeek>WN</daysOfTheWeek>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

but equally it could be this

<deliveryProfile>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

again, we prefer our version as being clear, again does it matter – will ACER accept both?

We would prefer AER to accept all variants of this , otherwise ACER will have to describe a “reference” implementation for everything , which takes time to do and then time for everyone to implement and time is something that we don’t have a lot of.


Answer:

With regard to the code:

1.    <deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>20:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>08:00:00</loadDeliveryEndTime>

</deliveryProfile>

2.    <deliveryProfile>

<daysOfTheWeek>WN</daysOfTheWeek>

<loadDeliveryStartTime>00:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>00:00:00</loadDeliveryEndTime>

</deliveryProfile>

In the first case (1) this would be mean that Mon 20:00 to 00:00 and Tue 00:00 to 08:00 and 20:00 to 00:00, etc. but that means it misses the period between 00:00 to 08:00 on Mon

With regard to the code:

<deliveryProfile>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

This applies to every day delivery from 06:00 am to 06:00 am irrespective of the day.

While WD from 06:00 am to 06:00 am + WN from 06:00 am to 06:00 am may represent the same thing of all days from 06:00 am to 06:00 am, the use of the smallest possible set of information is the correct way to report such a transaction: e.g. all days 06:00 am to 06:00 am and not WD + WN.

The reporting of WD + WN profiles should be avoided when it is not needed.  For example: a yearly forward contract for the delivery of gas from 06:00 am to 06:00 am every day of the year can be represented with one delivery period for all days as seen above, WD + WN profiles or it can be repeated 365 days, one per each deliver day. Since the all-day from 06:00 am to 06:00 am profile is the simplest one, this should be used.

Reporting parties that aim at a successful transaction reporting should pay attention to the trading examples reported in Annex II of the TRUM and should not deviate from it unless previously discussed with the Agency.

In addition, for electricity delivery profiles that start at 23:00, e.g. a baseload contract delivery starts at 23:00 on Sunday and delivery ends at 23:00 on Friday, this should be reported as SUtoFR from  23:00 to 23:00

<deliveryProfile>

<daysOfTheWeek>SUtoFR</daysOfTheWeek>

<loadDeliveryStartTime>23:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>23:00:00</loadDeliveryEndTime>

</deliveryProfile>

The profile WD from 23:00 to 23:00 :

<deliveryProfile>

<daysOfTheWeek>WD</daysOfTheWeek>

<loadDeliveryStartTime>23:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>23:00:00</loadDeliveryEndTime>

</deliveryProfile>

would not represent the same thing and it should not be used.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.44

Data Field (52)

ACER Transaction Reporting User Manual – Reporting of Standard Supply Contracts – Field 52

How to correctly map to the ACER load type values ‘Shaped’ and ‘Other’ What is the difference between these two values?

We trade the following structures:

Overnights (Blocks 1+2)

Extended Peaks (Blocks 3+4+5+6)

Weekday Block 4

Would these load types be ‘Shaped’ or ‘Other’?

We think the above fall under ‘Other’


Answer:

If the price is the same for all the hours within the blocks, then BH for block hours should be used. If the price is different per each hour of the blocks, then it is a shaped product. In some cases it is possible to have a shaped product that has the same price for all the hours, but still a shaped product. Usually this is an OTC bilateral contract or voice brokered.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.23

Data Field (28)

The implementing acts define field 28 as “the trading hours of the contract”. Although we do open and close our electronic markets, this is not always done at fixed times, the times can change from day to day, and even outside of those times we will be available to broker trades if customers require.

Our proposal is to list our markets hours as 00:00 to 00:00 which we believe reflects the service that we offer.


Answer:

The TRUM indicates that “in case of continuous markets, exchanges or broker platforms shall report the trading hours in which their clients may place orders and trade in that market: e.g. 09:00Z to 17:00Z or 00:00Z to 24:00Z if no restrictions are imposed by the exchange.”

In the Agency’s view “the trading hours of the contract” should represent the hours within which the electronic orders are displayed in the screen, e.g. 09:00 to 17:00 if there are restrictions. If a voice brokered trade takes place outside the core trading hours 9:00 to 17:00 the contract should be reported with the same hours but flagged as “voice-brokered” in field 34.

When there are not any trading restrictions on a particular contract then 00:00Z to 24:00Z or 00:00Z to 00:00Z should be reported.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.3

Due to idiosyncrasies of the Gas market, on certain times every month there are contracts that are in effect duplicates of each other, from a delivery point of view.

For example, on Fri 24th July, both the “Balance of Month” and “Working days next week” contract quoted on screen will result in delivery of the same commodity – from 27-31st July inclusive.

These are shown as 2 different contracts on the broker screen so have 2 different order books and clients can place orders and trade in either contract.

We would like to check that reports of, for example, 2 orders on 2 different contract IDs would be accepted, even though the details of the two contracts and delivery profiles would in effect be the same.

We can see the test ARIS system accepts this, we just want assurance that you do not think that this violates any rules.

We can see why this may be undesirable as you would not want people making up different contract IDs all of the time, however in this instance the traders see 2 distinct order book on the screen and we feel that it is valid to report in this way, if the order books are separate.


Answer:

If there are two different contracts and these are shown as two different contracts on the broker screen, so they have two different order books and the traders see two distinct order books on the screen, these contract should be reported with different IDs.

The fact that on certain times every month there are contracts that are in effect duplicates of each other, from a delivery point of view, it does not mean that they are the same. They are two different contracts with the same delivery profiles (and they may trade at the same price, but traded in two different order books and they should be reported separately.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.24

Data Field (30)

The XXX trade matching system recognises two time stamps in the non-MTF trade execution process (which currently represents virtually 100% of screen trading in the physical energy markets).

The first is the time at which an order is aggressed and potentially matched. This time is recorded in the system as “time”. However, under the non-MTF trading workflow, the operator of the venue has to exercise discretion in respect of every transaction meaning that this is not the point of execution. Nevertheless, at this point in the workflow the order is removed from the trading screen and the time is printed to the market to show the initial match on a trade ticker.

The second time stamp (known as “execution time”) is the point of execution and which takes place when a broker for the trading venue matches the two orders and executes them in the system as a legally binding transaction.

Order initiated at 13:00:00

Aggressed at 13:02:00  – order removed from the market at this point and the market sees the potential trade in the ticker

Executed by a broker at 13:03:00.

The confirmation requested is that the second “time executed” time stamp is treated an internal administrative process and is not a reportable event.

From a market manipulation/market abuse perspective, the first time stamp – which indicates the moment at which an order has been potentially matched and shown to the market – is the more important.

It serves no useful purpose to publish the second “execution time” stamp and we cannot, in any event, see how that would be reported under the schema as there is no way to describe it. We would be sending a modify record with no fields modified.

Given the scope for misunderstanding and a disparate approach to time stamp reporting, we ask that ACER makes a clear statement about the time stamp which needs to be reported (i.e. the first initial match time).


Answer:

Please see Field 30 “Transaction timestamp“ in the TRUM: “The date and time of the contract execution or order submission, or their modification, cancellation or termination.” . This should be understood as the time at which two orders match.  In the above case we would expect to receive 13:02:00 in the timestamp field.

If reporting parties would also like to report <executionTime > to indicate that the legal execution time takes place a few second/minutes after the order have matched this can be done.

When <executionTime > is different than <transactionTime>, this can be reported under <executionTime></executionTime> code. For the example above:

<transactionTime>2015-06-11T13:02:00.000</transactionTime>

<executionTime>2015-06-11T13:03:00.000</executionTime>

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.4

How to correctly link a Gas Sleeve Spread executed voice by a broker.

We have the following trades resultant from a voice traded Sleeve Spread between two customers using a Sleeve:

Trade 1: Cust1 Vs Sleeve 1

Trade 2: Sleeve 1 Vs Cust2

Trade 3: Cust2 Vs Sleeve 1

Trade 4: Sleeve 1 Vs Cust1

The question is how to link the legs of the trades.

We suggest that the trades should be linked in the following manner:

We have used the combined logic from the Sleeve trading example and Dirty Spark Spread example.

Trade1 Cust 1 Vs Sleeve1
  Linked ID of  Trade 4   Linked ID of Trade 2
       
Trade 2: Sleeve1 Vs Cust2
  Linked ID of Trade 1   Linked ID of trade 3
       
Trade 3: Cust 2 Vs Sleeve 1
  Linked ID of Trade 2   Linked ID of Trade 4
       
Trade 4: Sleeve 1 Vs Cust 1
  Linked ID of Trade 3   Linked ID of Trade 1

Answer:

When a trade occurs across multiple products due to the nature of the product, e.g. a product which is a spread of two or more products falling under the scope of REMIT, a trade report for each product has to be reported and the different trades are to be linked to each other when they are executed simultaneously on the Organised Market Place /platform. For example, Dirty Spark Spreads for a trade that involves electricity and gas: the two contracts are reported separately, with one leg for the electricity and one leg for the gas trade. The two legs, i.e. gas and electricity trades, need to be linked together through this field.

Same applies to Physical Swaps for a trade that involves two gas or electricity trades: a geographical physical swap involves two trades, e.g. selling gas in a particular delivery point and buying it in another delivery point. Both trades have to be reported separately and linked together through this field if they are traded simultaneously.

The whole chain of trade reports and the Linked Transaction ID fields should look like the example (3.20) in Annex II to the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.25

Data Field (30)

The question is related to the timings in the reporting: in the TRUM it is indicated that timings have to be expressed in UTC format (ISO 8601 date and time format using UTC time format). However in the trading examples we see two ways of representing timings:

2014-01-29T10:35:56.000Z  or 2014-01-29T12:35:56.000+02 :00

It seems more pertinent to use the “+02:00” expression as indicated in the attached trading example.

Could you please confirm that one can report in local timings followed by “+02:00”?


Answer:

According to ACER’s schemas and the ISO 8601 standard  date and time in UTC can be either reported as

2014-01-29T10:35:56.000Z or 2014-01-29T12:35:56.000+02 :00

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.5

Since it is possible to enter orders that remain in the system for more than one day, we consider it to be likely that some orders which had been entered on 6 October 2015 or before are still valid on 7 October 2015. However, these orders will not show in the system again until they are modified, matched or cancelled.

It is not clear how to deal with such orders that have already been active at the reporting start date.

For sake of clarity it would be very useful to have a special chapter GoLive in TRUM. For example:

  • 5 October 2015 – order is inserted in the market (with status ACTIVE)
  • 6 October 2015 – order is modified
  • 7 October 2015 – order is matched

There will be no “BACK LOADING” of order data; only order lifecycle events that take place on 7 October 2015 or later will need to be reported.


Answer:

Orders that remain in the system on 7 of October 2015, for example they were entered on 6 October 2015 or before, and are still active on 7 October 2015, should be reported in one of the two following ways:

1.    New order (Action Type “N”) on 7 October 2015 either with the real timestamp, e.g. 2015-10-06T08:23:24 or with the time of opening the market, e.g. 2015-10-07T00:00:00 or 2015-10-07T09:00:00 in UTC format. Any subsequent modifications of those orders should be reported as modification (Action Type “M”) with the real timestamp of modification.

The values to be reported are those at the point of reporting (the current active values) and not the values that were originally entered. For example, if it was entered at 3 EUR, but then modified to 2 EUR, it should only be reported as 2 EUR because this is the value at the time of the loading day (7 October).

OR

2.    New (Action Type “N”), modified (Action Type “M”) or cancelled (“Action Type C”) with its lifecycles or related trades and real timestamps. An order that is active on 7 October 2015 will be reported according to its history.

For example, if the order is active on 7 October 2015 but before this date the order was modified 2 times and then partially matched, the report will cover the first submission of order (Action type “N” and transaction timestamp before 7 October 2015), its 2 modifications (Action type “M”), partial acceptance (trade report) and the rest that remains active in the system.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.6

Data Field (4)

Identifier to represent a “sleeve” action taken by a broker

This requirement is dependent on other interpretations which may require that matched orders get reported.

The question is to how a matched order when a “non Market Participant” is on one side or the other is to be reported.

Brokers often aggress orders placed on screen as a result of a voice instruction from another client. The resulting “trade” is not really a trade as one of the parties to it is a broker who is not a market participant.

The “trade” is in reality an internal broker placeholder for further work to be done by the broker in order to generate a binding trade. These internal trades will always get deleted as the broker cannot contractually deliver or receive any commodity.

The problem is that the broker does not have an ACER code, so if he needs to report any actions then it gets messy.

The suggestion is that ACER allocates a generic ACER code for Broker’s internal processes, so allowing brokers to report these processes if required in a consistent fashion.

Suggestion would be an ACER code something like this as a generic code:
SLEEVE000.EU

Or it may be preferred to have one code per broker such as this:
SPECSLEEV.EU
GRIFSLEEV.EU
ICAPSLEEV.EU

This way, anything reported with a code like this can be identified as being acted upon by the broker.


Answer:

Brokers (that are Organised Market Places rather than Executing Brokers) are not market participants and therefore should not appear as counterparty. For sleeve trades with orders on screen, please see example (3.19) in Annex II to the TRUM and at the end of this document.

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS