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  

FAQs on transaction reporting – Question II.2.1.15

Data Field (21)

Would it be possible to extend the max length of the Contract ID?

We use this field as a reference and it is displayed in a number of lists and platforms (including XXXXX) together with the UTI, the Action and the parties to a transaction (unlike the Contract name, which is only available by searching the XML)

Our contract ID  includes the Instrument and the Period and immediately pinpoints potential issues with a given contract

Example:

Spread:

Germany_Baseload_vs_Germany_Baseload_NOMX_Futures_Sep_15


Answer:

The length of the Contract ID field is predefined in ACER’s XSD schema. 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 amendments to the schemas will require a new consultation with the industry.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.1.16

Data Field (21)

The TRUM and its Annexes have been updated to state that for Backloading trades, you should set field 21 (contract ID) to NA and field 22 (name) to BACKLOADING.

Market participants reporting bilateral contracts traded off-organised market places, backloading and executions under the framework of non-standard contracts are not expected to submit a contract ID but only “NA” for not available.

Can I question the contract ID please, since in the XML file the contract ID is used to link the trade to the contract, and if it’s all set to NA then you cannot have more than one trade in a file as you cannot reference which contract the trade refers to.


Answer:

Market participants reporting backloading and executions under the framework of non-standard contracts should report “NA” in Field 21 (Contract ID) and “BACKLOADING” or “EXECUTION” in Field 22 (Contract Name). However, while reporting this information, market participants have to report details of the contracts in each Trade Report and not in the Contract List section of the XML file.

In order to use the Contract List section of the XML file, market participants can use any unique contract ID they prefer. There is no expectation that the other counterparty will report the same contract ID. The contract ID links Trade Reports to the contract in the Contract List section within the same XML file. For Example:

<contractList>

<contract>

<contractId>Contract1</contractId>

<contractName>BACKLOADING</contractName>

………

</contract>

<contract>

<contractId>Contract2</contractId>

<contractName>BACKLOADING</contractName>

………

</contract>

</contractList>

 

<TradeList>

……….

<contractInfo>

<contractId>Contract1</contractId>

</contractInfo>

</TradeList>

<TradeList>

……….

<contractInfo>

<contractId>Contract2</contractId>

</contractInfo>

</TradeList>

 

Or

 

<TradeList>

……….

<contract>

<contractId>NA</contractId>

<contractName>BACKLOADING</contractName>

</contract>

</TradeList>

<TradeList>

……….

<contract>

<contractId> NA </contractId>

<contractName>BACKLOADING</contractName>

</contract>

</TradeList>

RSS_Icon Last update: 16/11/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.18

Data Field (23)

Inter-period and Inter-product spreads are split into contract and legContract.

Should the ContractType be SP or FW on a bilateral spread?

<INSTRUMENT ID=”713″ FirstSeqID=”68″ FirstSeqItemID=”20″ SecondSeqID=”68″ SecondSeqItemID=”0″>NCG/TTF € H 51.6 D.A</INSTRUMENT>

<contract>

<contractId>8_689_68_20</contractId>

<contractName>NCG_DA</contractName>

<contractType>FW</contractType>

<energyCommodity>NG</energyCommodity>

<settlementMethod>P</settlementMethod>

<organisedMarketPlaceIdentifier>

<lei>549300FR3U1PB1Y6LV13</lei>

</organisedMarketPlaceIdentifier>

<contractTradingHours>

<startTime>00:00:00Z</startTime>

<endTime>23:59:59Z</endTime>

</contractTradingHours>

<lastTradingDateTime>2015-06-12T05:59:59</lastTradingDateTime>

<deliveryPointOrZone>37Y701125MH0000I</deliveryPointOrZone>

<deliveryStartDate>2015-06-12</deliveryStartDate>

<deliveryEndDate>2015-06-13</deliveryEndDate>

<duration>D</duration>

<loadType>GD</loadType>

<deliveryProfile>

<loadDeliveryStartDate>2015-06-12</loadDeliveryStartDate>

<loadDeliveryEndDate>2015-06-13</loadDeliveryEndDate>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

</contract>

<legContract>

<contract>

<contractId>8_243_68_20</contractId>

<contractName>TTFH516_DA</contractName>

<contractType>FW</contractType>

<energyCommodity>NG</energyCommodity>

<settlementMethod>P</settlementMethod>

<organisedMarketPlaceIdentifier>

<lei>549300FR3U1PB1Y6LV13</lei>

</organisedMarketPlaceIdentifier>

<contractTradingHours>

<startTime>00:00:00Z</startTime>

<endTime>23:59:59Z</endTime>

</contractTradingHours>

<lastTradingDateTime>2015-06-12T05:59:59</lastTradingDateTime>

<deliveryPointOrZone>21YNL—-TTF—1</deliveryPointOrZone>

<deliveryStartDate>2015-06-12</deliveryStartDate>

<deliveryEndDate>2015-06-13</deliveryEndDate>

<duration>D</duration>

<loadType>GD</loadType>

<deliveryProfile>

<loadDeliveryStartDate>2015-06-12</loadDeliveryStartDate>

<loadDeliveryEndDate>2015-06-13</loadDeliveryEndDate>

<loadDeliveryStartTime>06:00:00</loadDeliveryStartTime>

<loadDeliveryEndTime>06:00:00</loadDeliveryEndTime>

</deliveryProfile>

</contract>

The result is two forward trades but this particular order strategy is a spread so I would expect to put SP when inter-period or inter-product spread but this could be interpreted differently since the result is two forward trades.


Answer:

Even if the result is two forward trades, the order placed on the screen is a spread order so we would expect reporting parties to report ‘SP’ when they report inter-period or any other inter-product spreads. These orders should be reported as spark spreads or physical swaps in the same ways as presented in Annex II of the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.19

Data Field (25)

Lifecycle of order traded based on index.

If a price of a trade is fixed on index, and the price of the index is not known in the time when the trade occurs is it sufficient to report the trade only with the name of fixing index, or we shall send lifecycle event modification after the price of the index is published?

It is sufficient to report the trade with the name of the index without updating the trade report with published price for that index.


Answer:

It is correct to report the trade with the name of the index without updating the trade report with the published price for that index. Please also see the trading examples in Annex II of the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.20

Data Field (27)

Duplication of organisedMarketPlaceIdentifier in the schema organisedMarketPlaceIdentifier appears in the contract definition as well as order and trade.

Your examples, such as example 3.10 show the OMP ID listed in both locations. Since each order or trade must have a contract, this does not appear to make sense since what would happen if they contradict

<contractList>

<contract>

<organisedMarketPlaceIdentifier>

<mic>XMIC</mic>

</organisedMarketPlaceIdentifier>

And then under each order or trade

<OrderList>

<OrderReport>

<organisedMarketPlaceIdentifier>

<mic>XMIC</mic>

</organisedMarketPlaceIdentifier>

<TradeReport>

<organisedMarketPlaceIdentifier>

<mic>XMIC</mic>

</organisedMarketPlaceIdentifier>

So path

REMITTable1 >OrderList>OrderReport>contractInfo>contract>organisedMarketPlaceIdentifier>lei

Is duplicated in

REMITTable1 >OrderList>OrderReport>organisedMarketPlaceIdentifierlei

Path

REMITTable1 >TradeList>TradeReport>contractInfo>contract>organisedMarketPlaceIdentifier>lei

Is duplicated in

REMITTable1 >TradeList>TradeReport>organisedMarketPlaceIdentifierlei

And if you use a ContractList , they are all duplicated in

REMITTable1 >ContractList>contract>organisedMarketPlaceIdentifier>lei

I would prefer you to remove OMP ID from the orders and trades area of the schema, leaving it in just the Contract (which can be provided as the ContractList , or individually as Contracts under each

If the schema cannot be changed, guidance or example to only include it in the Contract would be welcome.

So guidance that if you use a ContractList , only use

REMITTable1 >ContractList>contract>organisedMarketPlaceIdentifier>lei

And if you don’t use a contract list but embed the contract in each order or trade, only use:

REMITTable1 >OrderList>OrderReport>contractInfo>contract>organisedMarketPlaceIdentifier>lei

Or

REMITTable1 >TradeList>TradeReport>contractInfo>contract>organisedMarketPlaceIdentifier>lei

And never use

REMITTable1 >OrderList>OrderReport>organisedMarketPlaceIdentifierlei

Or

REMITTable1 >TradeList>TradeReport>organisedMarketPlaceIdentifierlei


Answer:

When a <ContractList> is used, the field <organisedMarketPlaceIdentifier> is required to be reported twice because if the RRM reports two different contracts traded in different markets but with the same contract ID, it will not be possible to match which contract a trade or order report is referring to. For this reason the schema was designed in a way that if a <ContractList> is used in the report, then the reporting party has to report the field <organisedMarketPlaceIdentifier> in the <ContractList> and in the Trade Report and Order Report section.

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS