Please insert at least 3 characters

FAQs on transaction reporting – Question II.2.2.1

We understand that an order will not be required for Click & Trade as per Annex II of the Trum, but is there a way of indicating that the Trade is a Click and Trade so that it won’t get rejected for not having a valid Order associated with it?

Suggested solution:  We think the answer to this is already in the .XML sample.  There’s an optional tag called ‘clickAndTradeDetails’ which we would use to indicate the Trade type.


Answer:

It is our understanding that a Click & Trade is a Limit order which aggresses the initiator order. When reporting click an trade transactions the reporting parties have two options:

1) to create a Limit Order and report it as an order; or

2) to report a transaction with the ‘clickAndTradeDetails’ filled in (i.e. “LIM” for Limit Order in the order type).

Please see examples in Annex II to the TRUM and XML examples related to them available on the REMIT portal at https://www.acer-remit.eu/portal/data-submission

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

A European gas within day trade ends up on a different “contract” to the order due to the nature of European within day gas.

Orders for example for TTF within-day gas are placed on a generic “TTF Within day” contract that has a definition of a delivery time of 6 AM the current day to 6AM the following day.

Post deal, the actual start time is verbally agreed between the participants so the “contract” does not match the contract of the order.

Would ACER accept the fact that an order did not match the trade (different contract) or would it get rejected?

A proposal would be that ACER accepts the fact that the contract for the trade will not always match the contract of the order. However, doing so would mean that a lot of validations end up being turned off.

An alternative would be use the “voice” flag on the trade, but still attach it to an order. The voice flag would indicate that the trade was modified/clarified by voice.

An alternative would be that ACER adds an additional field to the transaction details part of the schema to allow the transaction to be flagged in a way that says “this does not match the order” or “this trade was clarified by voice”.  This may be useful for other scenarios too.


Answer:

As far as we understand there are some European countries where gas within-day contracts can be delivered from 06:00 am to 06:00 am of the following day (daily balancing), while in other European countries there are 24 tradable contracts one for each hour from 06:00 am to 06:00 am of the following day (hourly balancing). When these hourly contracts are traded on exchanges each contract should have a different ID. This is the same as for most of the hourly electricity contracts represented in Annex II of the TRUM which applies to gas within-day contracts, too. However, in some circumstances, e.g. when gas within-day contracts are traded in broker platforms and related to markets with hourly balancing, this may be handled differently.

As the gas within-day contracts are advertised for the 06:00 am to 06:00 am delivery on the broker platforms, after the orders have matched on the screen, the two parties agree the starting time of the delivery during the day which will last until 06:00 am of that gas day.

Therefore, reporting parties may report for example:

1.    two orders that are matched at 10:00 am on a gas within-day contract for a 06:00 am to 06:00 am delivery as advertised by the broker platform;

2.    two trades, on the gas within-day contract for a 06:00 am to 06:00 am delivery, with a total quantity that reflects the starting delivery time of that gas day.

For a 30MW capacity:

Example 1: the trade has total volume 180 (meaning that with 30MW capacity the start time is 24:00)

Example 2: the trade has total volume 360 (meaning that with 30MW capacity the start time is 18:00)

Example 2: the trade has total volume 450 (meaning that with 30MW capacity the start time is 15:00)

In this case the trades are related to the same contract ID as the orders. However, if the broker platform advertises 24 different contracts, these should be reported with different IDs.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.7

Reporting of Electricity hourly trade of a standard contract available to trading at XXXX SPOT Market yet which has been performed on the OTC between two participants of XXX SPOT Market and has been sent to XXXX SPOT market system for clearing.

How to report such trades?


Answer:

If the trade takes place on an exchange without orders on screen (e.g. cleared), this trade should be reported as any other trade that takes place on exchange. In this case, field (33) Linked order ID should report the value of “NA” to indicate that there was not any order visible to the market. Please see Example (2.07) in Annex II to the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.8

Reporting of LFOK basket of two orders:

  • an Electricity block (of 3 hours)
  • an hourly order

The two orders are part of a basket which has a “Linked Fill or Kill” condition (either all the orders of the basket are entirely and immediately executed or all the orders of the basket are immediately cancelled)

Would it be possible to report it using the linked order ID with the addition of a prefix to the linked order ID?


Answer:

Please see example (1.07) in Annex II to the TRUM. Although the example (1.07) is for auction markets and refers to Exclusive Group of Blocks, the same principle can be applied to orders placed on continuous markets. The first Linked Order ID (33) value should report the Block ID for the block order and the second Linked Order ID (33) value should report the Unique Basket ID.

Please see also example (2.18) in Annex II to the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.9

What is a trade? In order to be able to report trades it is important that there is a clear definition of a “trade”. The legislation refers to a “contract” and “both parties to the contract should report the required details of the concluded contract” which confirms our view that a “trade” is only reportable if it is accepted by all parties to be a legally binding contract for delivery of gas or power.

Example 1:  “trades” entered in error by a human – i.e. against the incorrect trader, counterparty, or at the wrong price.

Example 2; temporary “trades” entered into the system by a broker as a placeholder in the course of processing a trade such as:

(a)     a sleeve trade pending the creation of the final trades;

(b)     a spread trade where the headline spread trade is deleted and replaced by the constituent physical legs.

There is a precedent here for only reporting the legally binding and mutually agreed trades.

Our view, backed up by our lawyer, is that these are not “contracts” because it does not constitute an agreement or contract for the delivery of gas or power. In practical terms, the parties do not book placeholder “trades” in their ETRM systems and would therefore be unable to report them in any event.

Indeed, placeholder “trades” or “trades” entered into the system in error might not be able to be booked into a market participant’s systems at all for a number of reasons such as:

  • the other party to the “trade” not existing as a counterparty in the system;
  • not having available bilateral credit with the counterparty;
  • not having completed know your customer (KYC) on the counterparty; or
  • being prohibited from dealing with the counterparty due to sanctions.

Screen orders that were traded in error would be visible to the Agency indirectly – because the Agency would see an “orphaned” matched order, with no corresponding trade referencing it, so the Agency would be aware that the market had seen a “trade” which was subsequently cancelled. Details of the precise workflow would be available to the Agency upon request.

We monitor orders that were traded in error for signs of market abuse as part of our standard monitoring processes.


Answer:

With regard to matched orders that for some reasons do not become “contracts” and do not constitute an agreement or contract for the delivery of gas or electricity, only matched orders may be reported. In any transaction there are always two orders that match: the buyer’s and the seller’s one and they both have to be reported as order placed in the market first, and then as matched orders and cancellation life cycle events for both of them to indicate that those orders have not originated a contract and that the transaction was cancelled for some reasons.

If a system stores only the initiator order and the click and trade order/trade for the aggressor, than the reporting parties should report the initiator matched order, the initiator trade that would have been reported if the transaction went through, and the aggressor click and trade order/trade which matches the initiator order. Then a life cycle event of the two transactions should be reported to indicate that the trade was not finalised.

Alternatively, if a system stores only the initiator order and the click and trade order/trade for the aggressor, than the reporting parties may report the initiator matched order and the aggressor click and trade order/trade which matches the initiator order and link it to it. Then a life cycle event should be reported to indicate that the trade was not finalised.

Please see example (3.54) in the Annex II to the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.10

A common workflow in our broking system is the aggregation of a number of similar deals into one “big ticket” – particularly prevalent where the deals are going to have a manual process applied to them anyhow such as sleeve deals or spread deals.

The clarification requested is how to report these deals

Party A and B trade 4 times today the NCG/TTF spread for June – so Party A initiated 4 orders at of 30 MW, at 0.225 and party B aggressed them.

The result is 4 x NGC/TTF Jun spreads at .225. These trades are not reportable as they are spread trades – however when the spreads are broken individually into an NCG leg and a TTF leg, they would reference the relevant orders – so 8 resulting trades in all (16 reportable sides).

2 trades would reference each order – the initiated side for the NCG and the initiated side for the TTF leg. The aggressed side would be a “click to trade” report.

Order 1 NCG/TTF 30MW

Order 2 NCG/TTF 30MW

Order 3 NCG/TTF 30MW

Order 4 NCG/TTF 30MW

Trade 1 (initiate side) NCG leg (30MW) – Order 1

Trade 1a (aggress side) NCG leg (30MW) – Click trade

Trade 1b (initiate side) TTF leg (30MW) – Order 1

Trade 1c (aggress side) TTF leg (30MW) – Click trade

Trade 2 (initiate side) NCG leg (30MW) – Order 2

Trade 2a (aggress side) NCG leg (30MW) – Click trade

Trade 2b (initiate side) TTF leg (30MW) – Order 2

Trade 2c (aggress side) TTF leg (30MW) – Click trade

Trade 3 (initiate side) NCG leg (30MW) – Order 3

Trade 3a (aggress side) NCG leg (30MW) – Click trade

Trade 3b (initiate side) TTF leg (30MW) – Order 3

Trade 3c (aggress side) TTF leg (30MW) – Click trade

Trade 4 (initiate side) NCG leg (30MW) – Order 4

Trade 4a (aggress side) NCG leg (30MW) – Click trade

Trade 4b (initiate side) TTF leg (30MW) – Order 4

Trade 4c (aggress side) TTF leg (30MW) – Click trade

However, the market convention here is to break the spreads not as four individual trades, but as a single trade of 120 MW. The question is how to report this.

Our view is that when a number of trades are bagged up into a single trade, that the reporting should be as below:

The single pair of 120MW trades (1 NCG and 1 TTF trade) would each reference the orders concerned

  • Order 1 NCG/TTF 30MW
  • Order 2 NCG/TTF 30MW
  • Order 3 NCG/TTF 30MW
  • Order 4 NCG/TTF 30MW
  • Trade 1 (initiate side) NCG leg (120MW) – Order 1, Order 2, Order 3, Order 4
  • Trade 1a (aggress side) NCG leg (120MW) – Click trade
  • Trade 1b (initiate side) TTF leg (120MW) – Order 1, Order 2, Order 3, Order 4
  • Trade 1c (aggress side) TTF leg (120MW) – Click trade

This way ACER will be able to see the relationship between the orders and resulting deals. Otherwise, ACER will get 3 matched orders with no resulting deal records at all, and 1 order with a deal record that does not match the order.


Answer:

Each order must match another order irrespective if the latter is a click and trade order/trade or not.

The correct way to report the above transitions is:

(initiator side) (aggressor side)
Orders

1.    Order 1 NCG/TTF 30MW

2.    Order 2 NCG/TTF 30MW

3.    Order 3 NCG/TTF 30MW

4.    Order 4 NCG/TTF 30MW

 

 

Orders

Because these are Click and Trade orders, they are reported with the trade reports under Click and trade section of the Schema

(nothing prevents the broker to create orders and report them under the order report section of the schema)

Trades

1.    NCG leg (120MW) – UTI 123NCG

linked to Order 1 – linked to UTI 123TTF

2.    TTF leg (120MW) – UTI 123TTF

linked to Order 1 – linked to UTI 123NCG

…….

3.    NCG leg (120MW) – UTI 345NCG

linked to Order 2  – linked to UTI 345TTF

4.    TTF leg (120MW) – UTI 345TTF

linked to Order 2 – linked to UTI 345NCG

…….

5.    NCG leg (120MW) – UTI 678NCG

linked to Order 3  – linked to UTI 678TTF

6.    TTF leg (120MW) – UTI 678TTF

linked to Order 3 – linked to UTI 678NCG

…….

7.    NCG leg (120MW) – UTI 901NCG

linked to Order 4  – linked to UTI 901TTF

8.    TTF leg (120MW) – UTI 901TTF

linked to Order 4 – linked to UTI 901NCG

 

Trades

1.    NCG leg (120MW) – UTI 123NCG

Click and trade – linked to UTI 123TTF

2.    TTF leg (120MW) – UTI 123TTF

Click and trade – linked to UTI 123NCG

…….

3.    NCG leg (120MW) – UTI 345NCG

Click and trade – linked to UTI 345TTF

4.    TTF leg (120MW) – UTI 345TTF

Click and trade – linked to UTI 345NCG

…….

5.    NCG leg (120MW) – UTI 678NCG

Click and trade – linked to UTI 678TTF

6.    TTF leg (120MW) – UTI 678TTF

Click and trade – linked to UTI 678NCG

…….

7.    NCG leg (120MW) – UTI 901NCG

Click and trade – linked to UTI 901TTF

8.    TTF leg (120MW) – UTI 901TTF

Click and trade – linked to UTI 901NCG

 

In our view, nothing prevents that the brokers or exchanges (those that do not store the aggressor order and treat this action as a click and trade) to create orders in their systems and report them under the order report section of the schema. When a trader aggresses an order on the screen and he accepts the initiator order price, he places a limit order. The fact that this order is not stored in the broker’s or exchange’s platform as an order does not means that it is not an order.

Please see example (3.19) in Annex II to the TRUM.

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS