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  

FAQs on transaction reporting – Question II.2.1.31

Data Field (35), (38), (40), 41 and (42)

Does ACER care if we submit a trade in kWh and the counterparty submits the opposite side in MWh? Or I submit one side in GBX (pence) and the other side is submitted in GBP (pounds)?

This is unlikely to be a problem where the OMP generates both sides of the trade, but it could happen if the MP is deriving the information themselves.

Second question – if I report NBP gas as an example in one unit, and another broker reports it in the other unit – will that cause a problem? Will ACER define a standard list of units for each delivery point, or will ARIS internally convert all units into one ACER common reference unit for comparison.

I would prefer you to accept all variants of this, otherwise you will have to describe a “reference” implementation for everything, which takes time to do and then time for everyone to implement and time is something that we don’t have a lot of!


Answer:

Transaction reports for orders to trade and trades executed at Organised Market Places should be reported in the unit as advertised by the Organised Market Place. If market participants decide to report their transactions through third parties (e.g. RRMs), they should not indicate other units or currency than the ones advertised by the Organised Market Place for that contract.

With regard to calculated values such as Total Notional Amount and Total Notional Quantity, it is possible to report the information in different units, e.g. EUR or EUX (but not GBP instead of EUR) and MWh or KWh (but not MWh instead of GJ).

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.32

Data Field (39)

The TRUM requires field 39 to be in the “major” unit to avoid “avoid unnecessarily large values”.

Is this necessary to stipulate?

Can we remove this recommendation as it will cause a layer of hard coding and translation that I do not believe is necessary and adds additional complication to our interface as the more things we hard code, the more things we potentially get mixed up.
The schema allows a 15+5 decimal number, so even if you report in the minor unit this allows 13 digits for a GBP or EUR amount – so a single trade of up to 9.9 trillion GBP, which is about the GDP of the whole of Europe for a year.


Answer:

The current version of the TRUM is under revision and the description of field 39 will be amended to clarify this further. Reporting parties can report in the currency stored in their system, but only for notional amount and notional quantity. For prices displayed on the Organised Market Place’s screen, the unit visible to the market should be reported. This applies to both Quantity/Volume and Price.

RSS_Icon Last update: 08/09/2015  

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

Data Fields (48 to 57)

Cash-settled trades reported under EMIR do not require a delivery schedule. Can ACER confirm that MPs who report such trades to their EMIR repository have no obligation to report the delivery schedule?

Example: Participant reports a cash-settled trade to an EMIR trade repository. The Participant omits the delivery schedule from the trade report.

If a MP reports a trade under EMIR, this is sufficient to meet the MP’s REMIT reporting obligation, even if the MP reports the trade without a delivery schedule.


Answer:

Market participants that report a cash-settled trade to EMIR trade repositories (TRs) should seek TRs or ESMA’s guidance.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.36

Data Field (48)

Reference to documents: Annex Table 1 (details of reportable contracts) of Regulation (EU) No 1348/2014

Please be advised of the following data issue which has been identified by our company (OMP)

For pure financial products which never result in physical delivery, what should be filled in for field 48 (delivery point or zone).

Two examples

  1. Spread Dutch TT / Italian PSV
  2. German Power Financial

Please note that there is no consistency between the OMPs. For example for German Power. There are 4 different EIC codes used, but also not applicable and blank.

See https://www.acer-remit.eu/portal/standardised-contract

Because there is no physical delivery, the most logical approach is to make this field not applicable. To avoid misunderstanding (parties forgot to add a EIC code where applicable), it is advisable to use a fictive EIC code, for example 99X-NOT-APPLIC–


Answer:

It is our understanding that every contract related to the supply of electricity or gas, irrespective of if the contract is a spot, a physical forward, a future or an option contract has a reference to a delivery period and a delivery point. Also financial products that are settled in cash and never result in physical delivery have a reference price or other attributes which relate to the commodity. In this case, reporting parties should refer to the reference price or other attributes which relate to the electricity or gas and report its delivery point.

For contracts that involve more than one delivery point, all of them should be reported.

RSS_Icon Last update: 26/04/2017  

RSS_Icon Subscribe to this Category’s RSS