Please insert at least 3 characters

FAQs on transaction reporting – Question II.2.1.5

Data Field (4)

This question pertains to exchange contracts traded on a broker. These contracts are typically traded anonymously, so that neither party to the trade knows who the other party is. The question is what value should be supplied for TRUM field 4 for trades on such contracts. An example would be a XXX Germany Baseload contract traded on broker platform.

We believe the counterparty should be omitted. This would be consistent with the rule that exchange-traded contracts do not require a counterparty.


Answer:

If the trade takes place on an exchange with orders to trade placed on the broker’s screen or voice brokered, this trade should be reported as any other trade that takes place on exchange.

If traded on the broker’s screen, the orders should be reported as orders placed on the exchange’s contract. There is no expectation that the order report and the trade report are linked together as they were placed first and executed after on two different Organised Market Places.

When orders on futures traded on exchanges are placed on the broker platforms, e.g. Indication of Interest (IOI), Field (4) “ID of the of the market participant” should include the ID of the Exchange.

This can be reported in the form of the LEI, BIC, EIC, or ACER code. When only the Exchange’s MIC code is available to the reporting party, this can be reported (as a last resource) in the format XMIC0000.EU – where the 4 first digits represent the Exchange’s MIC code, followed by 5 zeros, followed by “.EU” to replicate an ACER code.

For the reporting of the trades and for the reporting of the orders, please see examples (2.17) and (3.21) respectively included in the Annex II to the TRUM.

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  

FAQs on transaction reporting – Question II.2.1.7

Data Field (8)

If the beneficiary of the contract as referred in Article 8(1) of Regulation (EU) No 1227/2011 is counterparty to this contract the field is to be left blank. If the beneficiary of the contract is not counterparty to this contract the reporting counterparty has to identify the beneficiary by a unique code.

If an order is placed by an agent we don’t know the ID/name of the beneficiary.

Has the beneficiary information to be reported as OTC deal by the trading participant (between trading participant/agent and beneficiary)?

We will leave the field “Beneficiary ID” blank because we do not know the beneficiary if the beneficiary is not identical to the trading participant.


Answer:

Please see guidance on field (8) Beneficiary ID available in the TRUM at https://www.acer-remit.eu/portal/data-submission

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.8

Data Field (8)

Article 4 (1)(a) of the Regulation 1348/2014 – Reporting of intragroup transactions and beneficiary identification.

A broker concludes a back-to-back transaction in an organised market place. It acts as a Principal, however the Beneficiary of the transaction will ultimately be a market participant belonging to the same capital group as the broker.

Can ACER confirm that:

1) the transaction concluded by the broker in the organised market place should be reported without indicating the Beneficiary in the Field 8 (as it is a back-to-back transaction);

2) the transaction between the broker and the market participant should not be normally reported at all (as it is an intragroup transaction and takes place OTC).

Hence, ACER will not have information about the beneficiary of the transaction?


Answer:

A back-to-back transaction is a bilateral transaction not executed on the exchange. The transaction concluded by the executing broker at the Organised Market Place should be reported by the exchange indicating the Beneficiary in the Field 8 if this information is available to the exchange. Please see the TRUM, guidance on Field 8.

The transaction between the broker and the market participant may not be reported if this is an intragroup transaction and takes place OTC. However, nothing prevents the market participant from reporting the back-to-back transaction to ACER.

Based on the above, the Beneficiary will be the executing broker who is also a market participant if the back-to-back transaction is an intragroup transaction. It is worth noting that if no beneficiary is provided, then the market participant indicated in Filed (1) will be assumed to be the beneficiary.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.9

Data Field (8)

The TRUM is not explicit about whether beneficiary information should be included as a lifecycle event for order data both on unexecuted orders and orders which result in a trade. It is clear that Participants will have to report the beneficiary information on trades, but it is not clear if they should have to for orders. Please could ACER clarify?

Example: Where a transaction needs to be updated with the beneficiary information as a lifecycle event; does ACER expect market participants to also update the related orders that led to the transaction with the beneficiary information?

The beneficiary information should only be required to be reported on executed trades


Answer:

When a trade report is updated with the beneficiary information as a lifecycle event there is no expectation that market participants also update the related orders that led to the transaction with the beneficiary information.

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

Data Field (15)

Reference to documents: TRUM, Annex II, standard contracts – order conditions PTR & SLO (Data Field No 15)

XXXX Exchange (organized marketplace) offers order type named „stoploss”, where price trigger may either be related to the same instrument or to a different instrument (trader’s choice at the time order is entered). How should such orders be reported, are we correct to assume that such orders should always be reported with “order condition” = PTR (Price Trigger)?

Example:

1. order of XXXX Exchange type “stoploss” is entered at XXXX Exchange, in instrument X, with price trigger related to the same instrument X;

2. order of XXXX Exchange type “stoploss” is entered at XXXX Exchange, in instrument X, with price trigger related to a different instrument Y.

Reading description related to order conditions (Data Field No 15) in TRUM p. 43-44/150, are we correct to assume that we should report orders of XXXX Exchange type “stoploss” in the following manner:

Data Field No 15 (Order condition) – should have value „PTR” regardless of the fact whether actual price condition is related to the same instrument or is related to a different instrument.


Answer:

Data Field No 15 (Order condition) aims at capturing the condition for the order to execute.

A Stop Loss order (SLO) is submitted to the market as a limit order or market order once a certain price condition of an instrument is met (including profit taking). The price trigger refers to the same tradable instrument.

Price Trigger condition (PTR) applies to an order which will not be available for execution unless a specific trigger price is reached, similar to a Stop Loss, but may be triggered across product pricing, i.e. the price trigger may be based on a different contract or index.

With regard to the question above, the Agency understands that:

1. order of XXXX Exchange type “stoploss” is entered at XXXX Exchange, in instrument X, with a price trigger related to the same instrument X, which should be reported as SLO (stop loss); and

2. order of XXXX Exchange type “stoploss” is entered at XXXX Exchange, in instrument X, with a price trigger related to a different instrument Y, which should be reported as PTR (price trigger).

In both cases the orders have to be reported when visible to the market. This means that in some circumstances these orders are not visible to the market and they are not reportable. Once the non-visible orders are triggered and visible to the market, these orders become reportable with all the information that triggered and made them active in the market.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.1.13

Data Field (15)

Reference to documentation: REMIT Transaction Reporting User Manual

What order status should be given when reporting “Stop-loss” when it is not activated?

Example:

The TRUM does not contain any examples of reporting “Stop-loss” order whereas it is quite commonly used by market participants.

Because “Stop-loss” order before its activation is not visible in the order book of the organised market place it cannot be reported as ACT (active). Should it be reported in the field “Order status” as SUS (Suspended) or OTH (Other)?


Answer:

Orders have to be reported when they are visible to the market. This means that in some circumstances they may not be visible to the market and they are not reportable. Once triggered and visible to the market, these orders are reportable with the information that triggered and made them active in the market.

If a “Stop-loss” order is not activated and not visible in the order book of the Organised Market Place, it cannot be reported as active (ACT). Once the order is triggered, this will be reported with the following information:

Once the market order is triggered at 50 EUR and it is entered into the market

  Order details  
13 Order ID I4R9Q3Q6K3D2C1J5O0H8
14 Order type MAR
15 Order Condition SLO
16 Order Status ACT
17 Minimum Execution Volume
18 Price Limit
19 Undisclosed Volume
20 Order Duration GTC
58 Action type N

 

and in the XML file:

<triggerDetails>

<priceLimit>

<value>50</value>

<currency>EUR</currency>

</priceLimit>

</triggerDetails>

Or, if the order was a Price Limit order:

  Order details  
13 Order ID I4R9Q3Q6K3D2C1J5O0H8
14 Order type LIM
15 Order Condition SLO
16 Order Status ACT
17 Minimum Execution Volume
18 Price Limit 50
19 Undisclosed Volume
20 Order Duration GTC
58 Action type N

 

and in the XML file:

<triggerDetails>

<priceLimit>

<value>50</value>

<currency>EUR</currency>

</priceLimit>

</triggerDetails>

The Agency understands that there may be other combinations of order types and order conditions that may require additional guidance. This can be provided on an ad-hoc basis.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.1.14

Data Field (21)

The TRUM defines the Contract ID as the “unique contract ID provided by the market place.” Provided in which manner? Will the ID on the marketplace’s trading screen suffice?

Example: Participant executes trade on a marketplace and receives a record of the trade from the marketplace, via the marketplace’s trade feed. The record of the trade from the marketplace contains the unique contract ID as defined on the marketplace’s trading screen. Participant now wishes to report the trade to an RRM.

The ID on the marketplace’s trading screen will suffice, provided it is unique.


Answer:

Please see the TRUM which explains the following: “This field identifies the unique contract ID provided by the organised market place at which the contract is traded. The contract ID is venue-specific. The contract ID is needed to link all the orders to a specific contract.”

Orders and trades executed on Organised Market Places are required to use the Organised Market Places’ contract ID in order and trade reports. Market participants or RRMs should not make their contract ID in substitution of the contract ID used by the Organised Market Place for the reporting or orders to trade and trades.

The Organised Market Place must have only a single contract identifier for the contract for the lifetime of the tradable contract. The contract identifier must be unique and is not shared with any other contract. The contract must always be represented using the same contract identifier throughout the life of the contract, i.e. up to the date of delivery.

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS