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  

FAQs on transaction reporting – Question II.2.1.21

Data Field (27)

For voice-brokered deals on listed products what should we populate in the OMP field,

Suggested solution: should we populate the OMP field with ‘XBIL’ but use Table1Schema for the XML


Answer:

For any voice-brokered deal on listed products, reporting parties should report the ID of the Organised Market Place.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.22

Data Field (28)

Data Field No (28) Contract trading hours in case of auction markets

1 case: Day ahead market: flow date 20150708

Contract Trading Start: 29/06/2015 08:00 local time

Contract Trading End: 07/07/2015 12:00 local time

Last Trading Date and time field 29: 07/07/2015 12:00 local time

Auction Result:  07/07/2015 13:00 local time

2 case: Intraday market: flow date 20150707

Contract Trading Start: 06/07/2015 17:30 local time

Contract Trading End: 07/07/2015 03:45 local time

Last Trading Date and time field 29: 07/07/2015 03:45 local time

Auction Result:  07/07/2015 04:00 local time

3 case:  intraday market: flow date 20150708

Contract Trading Start: 07/07/2015 12:55 local time

Contract Trading End: 07/07/2015 15:00 local time

Last Trading Date and time field 29: 07/07/2015 15:00 local time

Auction Result:  07/07/2015 15:30 local time

1 case: Day ahead market: flow date 20150708

We will report all orders, considered valid and submitted in the timeframe between  29/06/2015 08:00  and  07/07/2015 12:00, considering:

<contractTradingHours>

<startTime>00:00:01+02:00</startTime>

<endTime> 23:59:59+02:00</endTime>

<contractTradingHours>

Thus without any indication of the date, indicated only in field 29:

<lastTradingDateTime>2015-07-07T12:00:00+02:00</lastTradingDateTime>

2 case: Intraday market: flow date 20150707

We will report all orders, considered valid and submitted in the timeframe between  06/07/2015 17:30 and  07/07/2015 03:45 considering:

<contractTradingHours>

<startTime>00:00:01+02:00</startTime>

<endTime> 23:59:59+02:00</endTime>

<contractTradingHours>

<lastTradingDateTime>2015-07-07T03:45:00+02:00</lastTradingDateTime>

Otherwise we propose to consider in this case:

<contractTradingHours>

<startTime>17:30:00+02:00</startTime>

<endTime> 03:45:00+02:00</endTime>

<contractTradingHours>

<lastTradingDateTime>2015-07-07T03:45:00+02:00</lastTradingDateTime>

3 case:  intraday market: flow date 20150708

We will report all orders, considered valid and submitted in the timeframe between  07/07/2015 12:55 and  07/07/2015 15:00, considering:

<contractTradingHours>

<startTime>12:55:00+02:00</startTime>

<endTime>15:00:00+02:00</endTime>

<date>2015-07-07</date>

<contractTradingHours>

<lastTradingDateTime>2015-07-07T15:00:00+02:00</lastTradingDateTime>


Answer:

The correct way to report the <contractTradingHours></contractTradingHours> is:

Case 1 above:

<contractTradingHours>

<startTime>00:00:00+02:00</startTime>

<endTime> 23:59:59+02:00</endTime>  (or 24:00:00+02:00)

</contractTradingHours>

Case 2 above:

<contractTradingHours>

<startTime>17:30:00+02:00</startTime>

<endTime> 03:45:00+02:00</endTime>

</contractTradingHours>

Case 3 above:

<contractTradingHours>

<startTime>12:55:00+02:00</startTime>

<endTime>15:00:00+02:00</endTime>

<date>2015-07-07</date>

<contractTradingHours>

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.23

Data Field (28)

The implementing acts define field 28 as “the trading hours of the contract”. Although we do open and close our electronic markets, this is not always done at fixed times, the times can change from day to day, and even outside of those times we will be available to broker trades if customers require.

Our proposal is to list our markets hours as 00:00 to 00:00 which we believe reflects the service that we offer.


Answer:

The TRUM indicates that “in case of continuous markets, exchanges or broker platforms shall report the trading hours in which their clients may place orders and trade in that market: e.g. 09:00Z to 17:00Z or 00:00Z to 24:00Z if no restrictions are imposed by the exchange.”

In the Agency’s view “the trading hours of the contract” should represent the hours within which the electronic orders are displayed in the screen, e.g. 09:00 to 17:00 if there are restrictions. If a voice brokered trade takes place outside the core trading hours 9:00 to 17:00 the contract should be reported with the same hours but flagged as “voice-brokered” in field 34.

When there are not any trading restrictions on a particular contract then 00:00Z to 24:00Z or 00:00Z to 00:00Z should be reported.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.24

Data Field (30)

The XXX trade matching system recognises two time stamps in the non-MTF trade execution process (which currently represents virtually 100% of screen trading in the physical energy markets).

The first is the time at which an order is aggressed and potentially matched. This time is recorded in the system as “time”. However, under the non-MTF trading workflow, the operator of the venue has to exercise discretion in respect of every transaction meaning that this is not the point of execution. Nevertheless, at this point in the workflow the order is removed from the trading screen and the time is printed to the market to show the initial match on a trade ticker.

The second time stamp (known as “execution time”) is the point of execution and which takes place when a broker for the trading venue matches the two orders and executes them in the system as a legally binding transaction.

Order initiated at 13:00:00

Aggressed at 13:02:00  – order removed from the market at this point and the market sees the potential trade in the ticker

Executed by a broker at 13:03:00.

The confirmation requested is that the second “time executed” time stamp is treated an internal administrative process and is not a reportable event.

From a market manipulation/market abuse perspective, the first time stamp – which indicates the moment at which an order has been potentially matched and shown to the market – is the more important.

It serves no useful purpose to publish the second “execution time” stamp and we cannot, in any event, see how that would be reported under the schema as there is no way to describe it. We would be sending a modify record with no fields modified.

Given the scope for misunderstanding and a disparate approach to time stamp reporting, we ask that ACER makes a clear statement about the time stamp which needs to be reported (i.e. the first initial match time).


Answer:

Please see Field 30 “Transaction timestamp“ in the TRUM: “The date and time of the contract execution or order submission, or their modification, cancellation or termination.” . This should be understood as the time at which two orders match.  In the above case we would expect to receive 13:02:00 in the timestamp field.

If reporting parties would also like to report <executionTime > to indicate that the legal execution time takes place a few second/minutes after the order have matched this can be done.

When <executionTime > is different than <transactionTime>, this can be reported under <executionTime></executionTime> code. For the example above:

<transactionTime>2015-06-11T13:02:00.000</transactionTime>

<executionTime>2015-06-11T13:03:00.000</executionTime>

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.25

Data Field (30)

The question is related to the timings in the reporting: in the TRUM it is indicated that timings have to be expressed in UTC format (ISO 8601 date and time format using UTC time format). However in the trading examples we see two ways of representing timings:

2014-01-29T10:35:56.000Z  or 2014-01-29T12:35:56.000+02 :00

It seems more pertinent to use the “+02:00” expression as indicated in the attached trading example.

Could you please confirm that one can report in local timings followed by “+02:00”?


Answer:

According to ACER’s schemas and the ISO 8601 standard  date and time in UTC can be either reported as

2014-01-29T10:35:56.000Z or 2014-01-29T12:35:56.000+02 :00

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.26

Data Field (30)

The schema has two Date/Time fields for an Order and Trade.
Are we required to populate both Date/Time fields?

Trade

<transactionTime>2015-06-11T15:58:44.593</transactionTime>
<executionTime>2015-06-11T15:58:44.593</executionTime>

Order

<transactionTime>2015-06-11T05:39:29.469Z</transactionTime>
<originalEntryTime>2015-06-11T05:39:29.469Z</originalEntryTime>


Answer:

Please see Field 30 “Transaction timestamp” in the TRUM: “The date and time of the contract execution or order submission, or their modification, cancellation or termination”. This should be understood as the time at which two orders match. 

The latest version of the schema includes:

1.    <transactionTime></transactionTime>  and

2.    <executionTime></executionTime>

Execution Time should be reported if different than Transaction Time. There is no need to report the same timestamp twice. Please see also “Mapping between the IAs Table 1 data fields and the XSD Schema_Table1_v1” file available at https://www.acer-remit.eu/portal/document-download?documentId=k186ka340eb  which says

  • (non in use)   REMITTable1 >TradeList>TradeReport>executionTime
  • (optional)      REMITTable1 >OrderList>OrderReport>originalEntryTime

If reporting parties would also like to report <executionTime > to indicate that the legal execution time takes place a few seconds/minutes after the orders have matched, this can be done.

When <executionTime > is different than <transactionTime>, this can be reported under <executionTime></executionTime> code. E.g. for a trade:

<transactionTime>2015-06-11T15:58:44.593</transactionTime>

<executionTime>2015-06-11T16:01:15.000</executionTime>

For order reports:  < originalEntryTime>  may be used to report orders that have a persistent Order ID when these are removed from the order book at the end of the day (or trading session) and reintroduced the following day (session) :

<transactionTime>2015-06-11T09:00:00.000Z</transactionTime> (at the opening)

<originalEntryTime>2015-06-07T12:39:29.469Z</originalEntryTime> (originally placed)

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS