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  

FAQs on transaction reporting – Question II.2.1.27

Data Field (31)

What UTI should be reported for back loaded trades where the MP does not have a UTI for the trade?

Example: Prior to Oct 7, participant enters into a trade. No UTI is assigned to the trade. Trade is still open on Oct 7 and therefore needs to be reported as a back loaded trade.

The MP may omit the UTI for such trades


Answer:

The UTI is a mandatory field in the schema. For back loaded trades where the market participant does not have an UTI for the trade, the market participant should create one. There is NO expectation that the UTI will match the market participant counterparty’s UTI.

The UTI is needed because of the ID of the record, otherwise the market participant will not be able to make any amendments and/or recall the transaction.

The UTI can be anything the market participant would like to submit e.g. the transaction ID available in their system and, as mentioned above, which does not need to match the other counterparty. This applies to any back loading trade.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.28

Data Field (31)

Is it okay for us to flag the transaction on the AdditionalUtiInfo field, which means that:

If a trade is a cross border trade with the Swiss market then we integrate in the AdditionalUtiInfo field the EIC code of Swissgrid in the part of the trade that we will report, right?


Answer:

If a trade is a cross border trade between an EU market and the Swiss market (or any other non-EU market) then the Organised Market Place (OMP) may report the EIC Y code for the non-EU country delivery point.  The AdditionalUtiInfo field can be used to report the EIC Y code of the non-EU country.

Please note that the reporting of EIC Y code for the non-EU country delivery point is not a REMIT requirement. The Agency is aware that REMIT market participants reporting trades (executed on OMPs) through third parties may not possess this information and may therefore not be able to report the EIC Y code for the non-EU country delivery point.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.1.29

Data Field (31)

In case of a cross-NEMO trade, how should OMPs report transactions that take place in the XBID platform for the coupled intraday continuous European market? For example:

OMP_1 reports trades matched within one zone/area,

OMP_2 reports trades matched within another zone/area.

What about cross border transactions between OMP_1 and OMP_2 zones? How should the UTIs of such transactions be reported?


Answer:

An example of how to report such transactions is available in the Annex II to the TRUM: Example 2.53 – Life cycle events for orders that match in intraday market coupled.

The only difference between this guidance and Example 2.53 available in Annex II to the TRUM is that in cross-NEMO trades, OMPs receive the same UTIs from the matching platform and therefore do not need to report two UTIs as in Example 2.53, but just one as described in the example below:

 

TRADE LIST OMP_1:

Transaction with UTI XBID_46752 will be reported by OMP_1.

MarketParticipant PRICE QUANTITY LINKODERID UTI Transaction Time
MarketPaticipantOMP_11 21 50 OMP_1-MC-O-123454 XBID_12345 2018-04-18T19:50:32.000Z
MarketPaticipantOMP_12 21 50 OMP_1-MC-O-123456 XBID_12345 2018-04-18T19:50:32.000Z
MarketPaticipantOMP_13 20 100 OMP_1-MC-O-188593 XBID_46752 2018-04-18T19:40:32.000Z

 

TRADE LIST OMP_2:

Transaction with UTI XBID_46752 will be reported by OMP_2.

MarketParticipant PRICE QUANTITY LINKODERID UTI Transaction Time
MarketParticipantOMP_21 19 30 OMP_2-MC-123411 XBID_67891 2018-04-18T19:47:45.000Z
MarketParticipantOMP_22 19 30 OMP_2-MC-123422 XBID_67891 2018-04-18T19:47:45.000Z
MarketParticipantOMP_23 20 100 OMP_2-MC -123433 XBID_46752 2018-04-18T19:40:32.000Z

.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.1.30

Data Field (35) and (38)

Reporting negative prices & resulting negative notionals

We wish to get clarification on how to report the following scenario under REMIT from 7th April 2016 onwards:

In some cases a trade may be for a “”negative”” price. This is not the same as the trade being the “”other way around””, i.e. a “”buy”” instead of a “”sell””.

Is it permissible to report negative prices in the various fields, i.e. fields 35 or 57 of table 1, or field 15 of table 2?

The same question would apply to resulting notionals.


Answer:

If the Price of the trade is negative, this should be reported with a negative number. For notional values, these should always be reported in absolute value.

RSS_Icon Last update: 24/03/2016  

RSS_Icon Subscribe to this Category’s RSS