FAQs on transaction reporting – Question II.2.1.32

Data Field (39)

The TRUM requires field 39 to be in the “major” unit to avoid “avoid unnecessarily large values”.

Is this necessary to stipulate?

Can we remove this recommendation as it will cause a layer of hard coding and translation that I do not believe is necessary and adds additional complication to our interface as the more things we hard code, the more things we potentially get mixed up.
The schema allows a 15+5 decimal number, so even if you report in the minor unit this allows 13 digits for a GBP or EUR amount – so a single trade of up to 9.9 trillion GBP, which is about the GDP of the whole of Europe for a year.


Answer:

The current version of the TRUM is under revision and the description of field 39 will be amended to clarify this further. Reporting parties can report in the currency stored in their system, but only for notional amount and notional quantity. For prices displayed on the Organised Market Place’s screen, the unit visible to the market should be reported. This applies to both Quantity/Volume and Price.

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

Data Field No (9)

With regard to the Trading Capacity and the connected information final beneficiary we have a question: Our understanding is that a Trading Capacity setting of Agent only adds value in the context of also providing a final beneficiary that is then the actual owner of the transaction. A setting of Agent without the indication of the final beneficiary will need to be considered as if it were for the member (acting as an agent) until the actual beneficiary is acknowledged.

The current assumption is that the final beneficiary information for exchange trades will be provided starting April 2016 based on a back-to-back Non-Standard ACER Transaction between the member and the final beneficiary.

(The direct information for the final beneficiary is not an information that is available on the exchange platforms).

Based on these facts, our best effort suggestion is that all exchange trades should be reported as P – Principal until in April 2016 the complete set including the final beneficiaries (with their related Non-standard transaction between member and final beneficiary) can and needs to be reported.


Answer:

The definition of Trading Capacity is available in the TRUM. If the Organised Market Place knows that the trading capacity of the market participant is “Agent” then “A” should be reported irrespective or the availability of the Beneficiary ID. This always adds value to the transaction report.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.33

Data Field (40)

Trading Electricity day shaped voice brokered order. Is it possible to report zero power quantity <TradeList/TradeReport/priceIntervalQuantityDetails/quantity> in example 03.11? OMP provide market participants with possibility to trade orders through broker screen with different power in different hours. In some hours the power can be 0 (zero) MW or nothing.  Do we have to report these “empty” hours?

Hours where there is power offered doesn’t need to be reported.

Both trades and the order will have the same Unique Transaction ID that will link them together.


Answer:

Please see Annex II of the TRUM, trading examples for auction and continuous markets.

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  

FAQs on transaction reporting – Question II.2.1.11

Data Field (11)

How to apply “buy”, “sell”, or “Combined” (Data Field No (11) Buy/sell indicator, Standard Contracts Table) to an order with volume 0 that acts as null in a linear interpolation

At an exchange, buy or sell is indicated by the sign of the volume

(no sign = buy ,negative sign = sell)

If a buy and sell combination is submitted as a linear interpolation between price steps, including a 0 volume order, that 0 volume order acts as both, endpoint of the buy interpolation and start point of the sell interpolation.

For example:

(Volume 50;Price 35)    (Volume 0;Price 40)   (Volume -50;Price 45)

In that case, the volume that is bought depends on the auction price that is calculated. If the price is 35, 50 is bought. If the price is 40, 0 is bought. If the price is between 35 and 40, the buy volume is linearly interpolated.

The same applies for the sell side. The sell volume is interpolated between 40 and 45, if the price is in that range.

So in that example, three orders are submitted by the trader. One is clearly a buy order and one is clearly a sell order. Should the order in the middle be reported to the Agency with buy/sell indicator = C (Buy and Sell)?


Answer:

Please see linear and/or step order examples available in Annex II to the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.34

Data Field (43)

TerminateDate is defined as DateTime in the schema but as a date in the TRUM document.

Suggested solution:

<xs:element name=”terminationDate” type=”xs:dateTime” minOccurs=”0″>

<xs:annotation>

<xs:documentation>Field No. 43</xs:documentation>

</xs:annotation>

</xs:element>


Answer:

When reporting the termination date this can be reported as YYYY-MM-GGT00:00:00, for example:

<terminationDate>2014-07-31T00:00:00</terminationDate>

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

Data Field (21)

Are the character restrictions in the Contract ID field necessary?

<xs:simpleType name=”contractIdType”>

<xs:restriction base=”xs:string”>

<xs:maxLength value=”50″/>

<xs:pattern value=”[A-Za-z0-9_:-]+”/>

</xs:restriction>

</xs:simpleType>

Is it possible to relax the restriction to be a normal string? Having a restricted character set makes this harder than it needs to be; contractNameType which is defined in the TRUM the same (as an alphanumeric) does not have these restrictions


Answer:

The schemas for data delivery and the restrictions imposed by characters in the contract identifier are limited to those fields which are to be used as primary keys in the ARIS database. It is typical for character restrictions to be imposed to prevent non-printable or special characters from being used and to ensure that primary keys can be easily matched.

At present there are no plans to change the schema. Schema REMITTable1_V1.xsd and REMITTable1_V2.xsd have been widely consulted with the industry. Any future changes to the schemas will need a new consultation with the industry prior to amending the schemas.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.35

Data Fields (48 to 57)

Cash-settled trades reported under EMIR do not require a delivery schedule. Can ACER confirm that MPs who report such trades to their EMIR repository have no obligation to report the delivery schedule?

Example: Participant reports a cash-settled trade to an EMIR trade repository. The Participant omits the delivery schedule from the trade report.

If a MP reports a trade under EMIR, this is sufficient to meet the MP’s REMIT reporting obligation, even if the MP reports the trade without a delivery schedule.


Answer:

Market participants that report a cash-settled trade to EMIR trade repositories (TRs) should seek TRs or ESMA’s guidance.

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS