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

Data Field (1) and (8)

Some market participants place orders on screen on behalf of more than one legal entity.

For example, a trading house may has a US head office and a European subsidiary and they enter into master agreements with various trading counterparties with either the US head office or the European registered entity, depending upon the preference of the counterparty. US entities would for example contract with the US parent for example to be governed by US law whereas European entities would typically contract with the European based subsidiary.

A trader at one of these “double headed” companies places a single order onto the market. For every counterparty that has good credit with them the number appears tradable, but the resulting trade can end up as being between one of several entities. So a single order can result in a trade with a different “principal” depending on who the counterparty name is. The order is in effect placed on behalf of two (or more) legal entities. I can’t see a way in the schema of representing this.

Example – trader at DoubleCo that has 2 entities – Usco and EUco.

With counterparty A they have a master agreement between A and USco.

With counterparty B they have a master agreement between A and EUco.

DoubleCo initiates an order onto the market, and depending on whether it is aggressed by A or B determines whether there is a trade between USCo and A, or EUCo and B.

The difficulty is how to represent the single order that is on behalf of more than one entity.

USCo is not acting as an agent for EUCo, both USCo and EUCo would be principals to the trade. Company A would report a trade with USCo and company B would report a trade with EUco.

The suggestion would be that ACER accepts that for certain participants, that the idOfMarketParticipant reported for the order may not match the idOfMarketParticipant reported on the linked trade.

An alternative would be to update the schema to allow more than one participant ID on an order (but not on a trade, since we know the correct legal entity at this point).


Answer:

When market participants place orders to trade on broker platforms on behalf of more than one legal entity the Organised Market Place should decide or/and agree with their clients which market participant is placing the order for the reporting purpose. By placing an order the legal entity is a market participant even if it will not be a counterparty to the trade.

Data Field (1) ID of the market participant or counterparty, requires that the ID of the market participant or counterparty on whose behalf the record of transaction is reported shall be identified by a unique code.

In the Agency’s view, this means that market participants that place orders on the screen of the brokers or exchanges have to be identified in the trade report as responsible for the reporting of the report. This does not imply that they are counterparty to the contract, but that they are responsible for the reporting of the order or the trade.

When a single order can result in a trade with a different “principal” depending on who the counterparty name is and the order is still placed on behalf of two (or more) legal entities, there is no need to indicate in the order report who is the beneficiary if and only if the beneficiary may be either the USco and EUco (as for the example above).

With regard to the trade, once it is clear to the Organised Market Place (and the market participant who placed the order) who is the beneficiary of the trade, this can be added in field (8) “Beneficiary ID” if this is different than the market participant reported in Field (1) “ID of the market participant or counterparty” in the order report. Please see the example below.

Firms Placing the order

(any of the three legal entities e.g. EUCo)

Matched orders Other side of the trade
EUCo EUCo and MP 1 MP 1
USCo EUco USCo and MP 2 MP 2
JPCo JPCo and MP 3 MP 3

 

The trade report should look like:

 Field # Case 1

EUCo and MP1

Case 2

EUCo and MP1

(alternative to case 1)

Case 3

USCo and MP2

Case 4

JPCo and MP3

#1 (ID MP) EUCo EUCo EUCo EUCo
# 4 (ID Other MP) MP 1 MP 1 MP 2 MP 3
# 8 (Beneficiary ID) EUCo USCo JPCo
#10 (Capacity) P A A A

 

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.2

Data Field (2)

Allowable format of BIC Codes.

The TRUM and XSD schema both show the BIC as being an 11 character field.

However, in the marketplace the BIC code is actually an 8 character reference, with an optional 3. And in ACER’s list of Participant’s

We suggest that the XSD be modified to allow BIC submission with a minLength of 8.

<xs:simpleTypename=”bic“>

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

<xs:maxLength value=”11“/>

<xs:minLength value=”118“/>

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

</xs:restriction>

As background, the BIC is made up by;

  • Business Party Prefix (4 Characters)
  • Country Code (2 Characters)
  • Business Party Suffix (2 Characters)
  • Optional Branch Identifier (3 Characters)

Numerous instances of 8 character BIC codes in the marketplace.  A small selection below for reference:

KRONDK22

NDEAFIHH

DABAFIHH

RABONL2U

OKOYFIHH

BREXPLPW

TATRSKBX

BAWAATW

Suggestion is that in order to successfully use BIC within the ACER XML schema, the validation on BIC should allow for a minimum of 8 characters (currently 11) and a maximum of 11.


Answer:

Our understanding is that the SWIFT code is 8 or 11 characters long. According to ISO 9362:2009 (dated 2009-10-01).

The SWIFT code is 8 or 11 characters long, made up of:

  • 4 letters: Institution Code or bank code.
  • 2 letters: ISO 3166-1 alpha-2 country code
  • 2 letters or digits: location code

If the second character is “0”, then it is typically a test BIC as opposed to a BIC used on the live network.

If the second character is “1”, then it denotes a passive participant in the SWIFT network

If the second character is “2”, then it typically indicates a reverse billing BIC, where the recipient pays for the message as opposed to the more usual mode whereby the sender pays for the message.

3 letters or digits: branch code, optional (‘XXX’ for primary office)

Where an 8-digit code is given, it may be assumed that it refers to the primary office and therefore should be reported as:

<bic>12345678XXX</bic>

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS