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  

FAQs on transaction reporting – Question II.2.2.11

When a group of trades such as spreads are executed, to break them as one trade but where the volume is then agreed to be different to the sum of the constituent parts.

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. It is then mutually agreed to adjust the total volume to for example either 115MW or 125MW, so the total can go either up or down from the sum of the parts.

As an example the following deals are created.

NCG leg (125MW)

TTF leg (125MW)

The open question would be then whether ACER wants the trades tagged as “voice” or some other tag to indicate that the trade does not match the sum of the orders.

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 125MW 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 (125MW) – Order 1, Order 2, Order 3, Order 4

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

Trade 1b (initiate side) TTF leg (125MW) – Order 1, Order 2, Order 3, Order 4

Trade 1c (aggress side) TTF leg (125M0W) – Click trade

Optionally these trades should also be tagged as “voice” or some other tag to indicate a verbal amendment to a screen trade, as these are not “voice” trades in the conventional sense and we think it likely that ACER would want to maintain the link between the screen orders and the resulting trades.


Answer:

Each order must be matched by another order irrespective of whether the latter is a click and trade order/trade or not. Their amendment occurs outside the screen and it may be reported as amendment of one or all of the previously agreed trades or as a separate voice brokered trade (buy or sell trade according to the volume change) if this can be considered a separate transaction. Please see also the previous question and its answer.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.2.12

A question on behalf of a Market Participant who has traded a gas Swing deal with us (we are an OMP).

There is an assumption that the clients have to report the deliveries that result from the daily exercise/nominations on the swing deal – this is shown in your Annex II examples for bilateral swing deals as 26.01 (swing deal) and 26.02 (execution reports for deliveries) – however, there are no examples for reporting any deliveries from an OMP traded swing deal.

Since an OMP traded swing deal cannot be reported on Table 2, then the rules as they currently stand imply that you cannot use the Table 1 report “executions on a non-standard contract” in the same way as if you had a bilateral Swing deal, because the OMP traded deal is “Standard” by REMIT definitions.

Firstly, can you confirm that clients are expected to report the deliveries resulting from Nomination/Exercise of Swing rights?

Secondly, if the answer to question 1 is true then can you advise how this should be done?

Practical example:

A TTF Cal17 Buyer’s Swing

Hourly Quantity Minimum  0MWh

Hourly Quantity Maximum 300MWh

Total Contract Quantity Minimum 720,000MWh

Total Contract Quantity Maximum 720,000MWh

(i.e. 100% take or pay)

Nominated on UK Working days

(Note that this deal if brokered could be identical in characteristics to a bilateral deal direct between counterparties, which would be reported on Table 2 and executions on Table 1 as EXECUTION reports.)


Answer:

Based on the information available to us, the assumption that the clients have to report the deliveries that result from the daily exercise/nominations on the swing deal may not be applicable to this case. It depends on whether the option exercise results into the exercise of nominations or into the exercise of a forward contract that leads to nominations. If the former is the case, there is no need to report additional information. If the latter is the case, the contract results into a new forward contract and then this should be reported. Please see Question 1.1.12 of our  FAQ on transaction reporting document.

As pointed out in the question, since the OMP traded swing deal cannot be reported on Table 2, a workaround to report such swing trades should be applied. For example, we would recommend:

The option should be reported with “Other” in the Option Style field (as opposed to European/American etc.). The Exercise Date field (a repeatable field) should be used to list all the exercise dates.

The premium should be reported as an amount per unit of energy, the same way as a regular Option premium would be reported and in order to report the key additional parameters of the deal the Extra field should be used to provide value pairs. With regard to the use of field “Extra”, this should not be used in other ways unless previously discussed and agreed with ACER.  Please also note that Table 1 Schema V1 is different than T1 Schema V2.

For the following fields for hourly delivery contracts:

HourlyQmin= Hourly Quantity Minimum  0MWh

HourlyQmax= Hourly Quantity Maximum 300MWh

TotalCQmin=Total Contract Quantity Minimum 720,000MWh

TotalCQmax=Total Contract Quantity Maximum 720,000MWh

Example:

Schema Table 1_V1:

<Extra>HourlyCQmin_0MWh HourlyCQmax_300MWh TotalCQmin_720000MWh TotalCQmax_720000MWh</Extra>

Schema Table 1_V2:

<Extra>HourlyCQmin==0MWh;HourlyCQmax==300MWh;TotalCQmin==720000MWh; TotalCQmax==720000MWh</Extra>

Or for daily delivery contacts such as gas:

DailyQmin= Daily Quantity Minimum  0MWh

DailyQmax= Daily Quantity Maximum 24000MWh

TotalCQmin=Total Contract Quantity Minimum 720,000MWh

TotalCQmax=Total Contract Quantity Maximum 720,000MWh

Example:

Schema Table 1_V1:

<Extra>DailyCQmin_0MWh DailyCQmax_300MWh TotalCQmin_720000MWh TotalCQmax_720000MWh</Extra>

Schema Table 1_V2:

<Extra>DailyCQmin==0MWh; DailyCQmax==300MWh;TotalCQmin==720000MWh; TotalCQmax==720000MWh</Extra>

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.2.3.1

For Cash Settled products, do we need to provide all the delivery details?  For example, Delivery Start date, Delivery end dates and Delivery Profile are currently mandatory fields.

Are there default values that we should use to indicate they are Cash Settled or will the field be made optional in the next version of the Table1 Schema?

Suggested solution: e.g. we could use “00:00Z to 24:00Z” in the Delivery Start/End dates.


Answer:

For Cash Settled products the delivery details should be provided as for physical products. Delivery Start date, Delivery End date and Delivery Profile are mandatory fields. Any derivative related to EU gas or electricity (or their transportation) has a reference price or index. This reference price (or index) is related to the commodity which is delivered somewhere in the EU on a specific date and time.

Please note that for delivery periods “00:00Z to 24:00Z” format is not valid. Delivery profiles are reported in local time e.g. 00:00 to 24:00.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.3.2

Futures trades on exchanges can cascade. Are cascades reportable?

Example: Participant executes a futures trade on an exchange. Trade goes into delivery, resulting in the creation of one or more physical trades by the exchange.

Cascaded trades are not reportable because the original futures trade will have been reported by the participant.


Answer:

Please see the TRUM and Annex III to the TRUM which already clarify what it is a reportable transaction. Cascade trades are post-trade events and not reportable because the original futures are reported by the participant. Cascade trades are not transactions in the REMIT sense. This is in line with the meaning of entering into transaction according to Article 5 of MiFID I where the meaning of entering into transaction does not include actions related to option exercise, settlement or clearing.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.3.3

We would like to know whether the orders introduced in retail CFD trading platforms for the trading of electricity or gas CFDs, are covered by the REMIT reporting obligation.

For example, currently there are CFDs on gas and electricity trades that are being reported to comply with EMIR reporting obligations. Since these trades are done in “retail” platforms, we are wondering if the orders associated to them are reportable under REMIT. The doubt arises because these platforms are commonly known as retail platforms and REMIT normally applies to wholesale trading.


Answer:

The Agency understands that Contracts For Difference (CFD) are derivatives (similar to futures). Guidance on reporting derivatives can be found in the TRUM and in Annex III of the TRUM available on the REMIT portal. The Agency believes that the question raised is already sufficiently addressed in Annex III of the TRUM.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.3.4

If ‘alpha’ trades identified by the UTI generated by the OMP are reportable under REMIT (if not reported under EMIR) then do the lifecycle events of the ‘gamma’ trade qualify as eligible for reporting, if so how is the UTI of the ‘gamma’ trade linked and is the Clearing Broker expected to report their side?


Answer:

The Agency has already provided its understanding in Annex III to the TRUM (available on the REMIT portal), according to which clearing brokers do not have reporting obligations under REMIT for their clearing activity. The UTI of the transaction executed at the exchange may be different than the UTI of the back to back transaction reported by the executing broker (or other member of the exchange) and their clients. Still, both transactions should indicate the Organised Market Place they were originating from.

Executing Brokers can report their transactions in two ways:

  • reporting two trade reports: one trade executed on the exchange and one trade as a back-to-back transaction with their client; or
  • reporting one trade report: one trade report which includes their client information in the Beneficiary ID field (8) if the client is a REMIT market participant.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.3.5

Art. 6(1) REMIT implementing regulation

Since X Exchange doesn’t have an order book, X Exchange doesn’t receive any orders and therefore X Exchange doesn’t have the obligation to send their orders to ACER, nor it needs to offer the service to its members to report the orders (which as commented are inexistent) to ACER. Please confirm.


Answer:

If X Exchange does not have an order book and does not receive any orders, then X Exchange does not have the obligation to offer to their clients the reporting service for their orders to the Agency.

If there are no orders to be reported, X Exchange may offer the reporting service to their clients for trades reportable under REMIT.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.3.6

In some cases where trades are executed via a broker, these trades are in the broker’s books for some time until the position is allocated to the respective customers.

Are these brokers considered to be market participants? If so, (how) would this interfere with them being OMPs?

By consequence: do these trades with brokers as counterparties need to be reported under REMIT? Or are only the allocations (give-up/take-up) to be reported?


Answer:

Our understanding is that firms may have several business activities. When a firm is an executing broker (exchange member) and is also an Organised Market Place (it runs a Broker platform) the firm has two different types of business and it should be treated as such. For their executing broker business the firm may need to register with the competent NRA as market participant. Further details can be found in Annex III to the TRUM available on the REMIT Portal.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.3.7

For Exchange Traded Commodity Derivatives only, executed by an Executing broker and cleared at a Clearing Broker. From the Executing Brokers point of view only:

  1. Can ACER confirm that if an underlying client is not a REMIT market participant, then we as the executing broker have no obligation to populate them as the beneficiary in field 8?
  2. Can ACER confirm that if an underlying client has registered as a REMIT market participant, however only executes cash settled derivatives, with no ability to make or take delivery and is not an exchange member, they would not be considered market participants for the purpose of reporting these trades only and therefore we as the executing broker have no obligation to populate them as the beneficiary in field 8?
  3. Can ACER confirm that if an executing broker knows they are giving up an executed transaction to an EMIR regulated clearing broker, or for a client who is required to report under EMIR, they can place reliance on the fact that the beneficiary will be reported under EMIR? Order details will still be reported as standard by us via the OMP.

Answer:

With regard to point (1) field (8) Beneficiary ID indicates the ID of the beneficiary of the transaction in the case that the trade is executed by a third party on behalf of a market participant. If an executing broker’s underlying client is not a REMIT market participant, then the executing broker may not populate the beneficiary in field (8).

With regard to point (2), if an executing broker underlying client has registered as a REMIT market participant (meaning that that person enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets) even if only executes cash settled derivatives, with no ability to make or take delivery and is not an exchange member, that person would be considered market participant for the purpose of reporting all their trades and orders and therefore the executing broker may populate that market participant as the beneficiary in field (8).

If a person is a market participant that person has to report all their transactions in wholesale energy markets irrespective of where they take place. If field (8) is not populated, a back to back transaction between the executing broker and their underlying client should be reported, unless that transaction was already reported under EMIR.

With regard to point (3) above, according to the ANNEX III of the TRUM, under REMIT the executing broker (e.g. firm ABC) has to submit the order details only. This reporting must be done by delegation to the Organised Market Place or third party service provider. Firm ABC does not have to submit any trade report if the trade was reported under EMIR. Contract details reported by the clearing broker (Firm XYZ) and by the executing broker’s client (Client 123), under EMIR and, according to the Agency’s understanding, should make reference to the executing broker.

RSS_Icon Last update: 14/12/2016  

RSS_Icon Subscribe to this Category’s RSS