Please insert at least 3 characters

TRUM – Section 4.4

Data fields related to transaction details

This section includes the following fields:

30. Transaction timestamp
31. Unique transaction ID
32. Linked transaction ID
33. Linked order ID
34. Voice-brokered
35. Price
36. Index value
37. Price currency
38. Notional amount
39. Notional currency
40. Quantity/Volume
41. Total notional contract quantity
42. Quantity unit for field 40 and 41
43. Termination date

 

Data Field No (30) Transaction timestamp

No. Field Identifier Description
30 Transaction timestamp The date and time of the contract execution or order submission, or their modification, cancellation or termination.

 

Description of Accepted Values Type Length Examples
ISO 8601 date and time format using UTC time format. Date and Time n/a 2014-01-29T10:35:56.000Z

 

This field identifies the transaction timestamp, meaning the time at which the reported event occurred. This field must reflect the actual time as a string representation of the ISO 8601 date and time format. The timestamp will always be represented in UTC time format. Transactions that occur in a different time zone have to be converted and represented in UTC time format.

For orders in continuous markets, the transaction timestamp is the time at which the orders were placed into the market or at which any subsequent modifications or cancellations of the order transaction occurred.

For orders in auction markets, the transaction timestamp is the time at which the orders were placed into the market and considered for the auction.

For trades in continuous markets, the transaction timestamp is the time at which the orders were matched and trades were created in the market or at which any subsequent modifications or cancellations of the trade transaction occurred.

For trades in auction markets, the transaction timestamp is the time of the announcement of the auction results or any subsequent modifications or cancellations of the trade transaction.

For bilateral trades, the actual trading time (the time at which the trade was agreed by the two traders) shall be reported rounded to the nearest minute in the UTC format, e.g. 2014-01-29T10:35Z. However, where reporting market participants are unable to meet the requirement to populate the trading time field with the actual trading time and instead give the time at which the trade is entered into their system (when this is not materially different from the actual trading time), market participants should make best efforts to minimise any discrepancy between the trading time and the booking time.

With regards to the statement “materially different from the actual trading time”, this has to be assessed on a case-by-case basis.

Where the trading time is not made available (e.g. for back-to-back transactions or when market participants do not have direct access to the markets and the trading time is not available or the trading time is not forwarded by the broker/trading firm) the default time of 00:01:00 UTC time must be used. A default time should only be used as a last resort and market participants should take reasonable steps to report the actual time that the transaction was executed. Using this default time will ensure that these transaction reports are included in the Agency’s monitoring of trading before a price-sensitive announcement.

 

Data Field No (31) Unique transaction ID

No. Field Identifier Description
31 Unique transaction ID Unique identifier for a transaction as assigned by the organised market place of execution, or by the two market participants in case of bilateral contracts to match the two sides of a transaction.

 

Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 1234567890abcdefrgf

 

This field is populated with a unique identifier assigned by the organised market place where execution takes place in order to match the two sides of a transaction or by the two market participants in the case of off-organised market place bilateral contracts.

Unique transaction ID: generation, dissemination and usage

The Agency appreciates that the UTI reporting requirements under REMIT may be slightly different than requirements set by transaction reporting regimes under other European legislations. The Agency encourages market participants to follow the guidelines set out in this manual for a correct interpretation of how to report the trade UTI under the REMIT transaction reporting regime.

Market participants should bear in mind that it is their obligation to comply with REMIT and it is their obligation to make sure that the Agency receives the correct UTI in the correct format for their transactions as required by the Implementing Acts. This should be the unique identifier for a transaction (UTI) as assigned by the organised market place of execution or by the two market participants in the case of bilateral contracts to match the two sides of a transaction.

Regardless of whether the trade takes place in a continuous market, through brokers or bilaterally, the buyer and the seller of a trade must report the same UTI for the matched trade.

In a matched trade, there should always be two sides of the trade (reported separately) irrespective of being one-to-one, one-to-many or many-to-many matches. As far the Agency is aware, there are not two sides for each matched trade in auction markets. All transactions have one price and this is set by the auction algorithm for all the counterparties at the same time. In these particular markets, all transactions shall have a different ID to distinguish them from each other.

It is crucial that market participants use the UTI generated by the organised market place as indicated in the legislation to avoid reporting trades that cannot be matched in the Agency’s system and therefore labelled as incorrect.

The Agency believes that there are a few UTI generation and dissemination scenarios which need to be considered, namely:

 

The trade is executed: The UTI should be generated by The trade/order report is sent to ACER by Need for MPs generating the UTI Lifecycle events reported by
At OMP The OMP The OMP No Third parties

(or OMP if this offers the service)

Third parties No Third parties
Bilaterally Market participants or third parties on their behalf Market participants Yes Market participants or third parties
Third parties Yes Market participants or third parties

 

As far as the Agency is aware, most of the organised market places where wholesale energy products are admitted to trade already have a system in place to generate a UTI which conforms to the REMIT Implementing Acts’ requirements, i.e. a unique transaction ID to identify the two sides of the trade.

However, if there are organised markets that do not have such a system, they should put one in place by the time the reporting obligation starts. Article 6(1) of the Implementing Acts states that “….The organised market place where the wholesale energy product was executed or the order was placed shall at the request of the market participant offer a data reporting agreement”. In reporting the transaction on behalf of a market participant, the organised market shall provide the Agency with a UTI compliant with the requirements in the Implementing Acts and in this user manual.

In summary:

1. for auction markets, each transaction shall have a different ID generated by the exchange;

2. for continuous markets in energy and derivative exchanges, transactions shall identify the buy side and the sell side with the same UTI generated by the exchange, e.g. :

    • (A) matches a trade with (B), both (A) and (B)’s trade reports shall have the same UTI (e.g. 123);
    • (A) matches a trade with (B) and (C), if (A)’s trade report is considered just one execution, then (A), (B) and (C)’s trade reports shall have the same UTI (e.g. 123). If A’s trade with (B) and (C) is split into two trades, then (A) and (B) trade reports shall have the same UTI (e.g. 123) and (A) and (C) shall have the same UTI (e.g. 567) which is different from the (A) and (B) trade report UTI (123);

3. for brokers’ platforms including voice-brokered transactions (bilateral trades), the UTI shall identify the buy side and the sell side with the same UTI (e.g. 123) generated by the broker’s platform;

4. for bilateral trades that take place outside an organised market place, the two market participants shall assign the same UTI to their trade reports.

The Agency is aware of a few situations where the UTI generation, dissemination and its usage may not be harmonised across organised market places and/or market participants.

If an organised market place does not generate or/and disseminate, for any reasons, the UTI to the market participant or the broker client or exchange’s member market participants may follow the guidance below.

Generation and usage of the UTI for bilateral trades that take place outside an organised market place may be more complicated than for trades taking place on organised market places. The Agency has developed and made public an ACER algorithm which would enable market participants to generate the same UTI from the economic terms of the bilateral trade without any communication between the two market participants. Please see ANNEX IV.

The ACER algorithm is based on the concatenation of economic terms included in the contract and their anonymisation. The Agency recommends using the ACER algorithm unless market participants agree to submit a UTI which is generated by a system/guidance which is publicly available or they agree to use one of the two parties’ UTI generation methods and agree on its dissemination and usage.

Therefore, for bilateral trades that take place outside an organised market place, the Agency recommends that market participants shall use the ACER algorithm available in ANNEX IV of this manual, unless:

 

    1. markets participant agree to submit a UTI which is generated by a publicly-available system/guidance.  Please refer to ANNEX IV for the most update-to-date list with the web address of the organisations providing such a system/guidance. In this case, market participants should bear in mind that it is their responsibility to agree on the division of tasks and their timing and submit the same UTI to the Agency; or
    2. market participants may agree on how to generate their UTI: for example, they may agree to accept one of the two parties’ UTI generation methods and agree on its dissemination and usage. This is entirely at their discretion how they opt to do it. In this case, market participants should bear in mind that it is their responsibility to agree on the division of tasks and their timing and submit the same UTI to the Agency.

 

Data Field No (32) Linked transaction ID

No. Field Identifier Description
32 Linked transaction ID The linked transaction identifier must identify the contract that is associated with the execution.

 

Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 1234567890abcdefrgf

 

This field indicates if two or more transactions are linked to each other or transactions executed within the framework of non-standard contracts linked to the non-standard contract. The value populated in this field is the unique ID as defined by the field 31 for standard contracts or field 11 of Table 2 for non-standard contracts. The linked trade ID shall be used in the following scenarios:

1. When a trade occurs across multiple products due to the nature of the product, e.g. a product which is a spread of two or more products falling under the scope of REMIT. The trade for each product is to be reported and the different trades are to be linked to each other when they are executed simultaneously on the organised market place.

Examples:

a. Clean and Dirty Spark Spreads for a trade that involves electricity and gas: the two contracts are reported separately, with one leg for the electricity and one leg for the gas trade. The two legs, i.e. gas and electricity trades, should be linked together through this field.

b. Physical Swaps for a trade that involves two gas or electricity trades: a geographical physical swap involves two trades, e.g. selling gas in a particular delivery point and buying it at another delivery point. Both trades have to be reported separately and linked together through this field if they are traded simultaneously.

2. When a transaction is executed within the framework of a non-standard contract, the details of the transaction specifying at least an outright volume and price will be reported and linked to the non-standard Contract ID (Data Field No 11 of table 2).

 

Data Field No (33) Linked order ID

No. Field Identifier Description
33 Linked order ID The linked order identifier must identify the order that is associated with the execution.

 

Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 1234567890abcdefrgf

 

This field identifies a transaction which is the result of an executed order. The linked order ID shall be used in the following scenarios:

  • when an order is executed, the trade report or results report (for auctions) should contain the field “Linked Order ID” to identify the order that triggered the trade to occur; and
  • when an order has a special condition that links the order to another order, e.g. the order type is a block or exclusive order.

 

Data Field No (34) Voice-brokered

No. Field Identifier Description
34 Voice-brokered Indicates whether the transaction was voice brokered, “Y” if it was, left blank if it was not.

 

Description of Accepted Values Type Length Examples
Y=YES Text 1 Y

 

This field identifies if the transaction was voice brokered. If the transaction was voice brokered, this field shall be populated with “Y”. If the transaction was not voice-brokered, this field should be left blank.

 

Data Field No (35) Price

No. Field Identifier Description
35 Price The price per unit.

 

Description of Accepted Values Type Length Examples
Up to 20 numerical digits in the format xxxxx.yyyyy with a maximum of 5 decimals. Number 20 53.45

 

This field identifies the agreed price per unit of energy as expressed in field 40. In the case of options, this field represents the premium while, in the case of orders, this field represents the bid or offer price for that order.

If a price/time interval is specified in field 57, this field should be left blank. The trading examples in ANNEX II explain in which circumstances this field should not be reported.

 

Data Field No (36) Index value

No. Field Identifier Description
36 Index value The value of the fixing index.

 

Description of Accepted Values Type Length Examples
Up to 20 numerical digits in the format xxxxx.yyyyy with a maximum of 5 decimals. Number 20 +/- 0.02

 

This field identifies the value of the fixing index indicated in field 25. The index value represents the value of the index at the time the contract was traded.

When an index value is not known when the contract is traded, the market participant should report a null value as “0” (zero). Market participants often enter into transactions and agree on a difference (+/-) from the fixing index price that will be published after the trade occurs, e.g. by the end of the day or a few weeks or months after. The agreed difference (+/-) from the fixing index value may be expressed in currency (e.g. +/- EUR 0.05) or in percentage terms (e.g. +/- 0.1 %). If the price differential is reported in percentage terms, then the value “PCT” shall be used in the currency field 37. If there is no deviation from the value of the fixing index, the value should be 0.

 

Data Field No (37) Price currency

No. Field Identifier Description
37 Price currency The manner in which the price is expressed.

 

Description of Accepted Values Type Length Examples
ISO 4217 Currency Code, 3 alphabetical digits:

BGN=Bulgarian lev
CHF=Swiss franc
CZK=Czech koruna
DKK=Danish krone
EUR=Euro
EUX=Euro cent
GBX=Penny sterling
GBP=Pound sterling
HRK=Croatian kuna
HUF=Hungarian forint
ISK=Icelandic króna
NOK=Norwegian krone
PCT=Percentage
PLN=Polish złoty
RON=Romanian new leu
SEK=Swedish krona/kronor
USD=U.S. dollar
OTH=Other

Text 3 EUR

 

This field identifies the currency for the value indicated in field 35.

If the transaction is priced as a percent of the value of the fixing index (e.g. +/- 0.1 %), this field should be reported as “PCT” which is one of the accepted values.

If fields 35 and 36 are blank, this field should be left blank.

 

Data Field No (38) Notional amount

No. Field Identifier Description
38 Notional amount Value of the contract.
Description of Accepted Values Type Length Examples
Up to 20 numerical digits in the format xxxxx.yyyyy with a maximum of 5 decimals. Number 20 53450.00

 

This field identifies the total notional value of the contract. The notional amount should be calculated using the following formula:

Notional Amount = Price x Volume x Number of periods, where:

  • Price is the defined as the price of the volume as per field 35
  • Volume is the quantity of energy as per field 40
  • Number of periods is the number of times that quantity is delivered / received (as derived from the delivery profile)

This can also be calculated using the following formula:

Notional Amount = Price x Total notional contract quantity where:

  • Price is the defined as the price of the volume as per field 35
  • Total notional contract quantity is the quantity of energy as per field 41

For example, a contract traded for a price of €50/MWh for a volume of 100MW delivered for 24 hours has the following notional amount:

€50 x 100(MW) x 24(h) = €120,000

or for a monthly contract:

€50 x 100(MW) x 24(h/day) x 30(days) = €3,600,000

Index trades may not have a value for the contract as this type of contract may not have a fixed price available at the time of the reporting. These index trades may have +/- EUR (or any other currency) 0.05 or +/- 0.1% differential from the published index value which is not available to the organised market place.

The index value may be published after the trading hours or in some cases days/weeks/months after the trade, e.g. a month forward on an index where market participant A enters into a contract for the delivery of gas three months ahead from the trading date (a physical forward). The price of that physical forward will be set the day before the delivery starts based on the front month average price of the month before the delivery takes place. For example, a trade occurs in April for the delivery in July; the average front month (July) price in June is calculated on 30 June and the delivery starts on 1 July at the price of the average front month (July) price in June.

This field should be left blank for trades that do not have a known price at the time of the trade. The same applies to any contracts which have a floating leg, e.g. gas/electricity financial swaps not reported under EMIR but reportable under REMIT. For example: in April, market participant (A) enters into an electricity financial swap contract for the month of July.  Market participant (A) is the seller of the swap. Market participant (A) sells the forward fixed leg in April and it buys the spot price (based on a reference price) in July. For the fixed leg, the forward price is known today, but the spot price is not known until the end of July. In this case, this field should be left blank.

For the calculation of the notional amount for options, the notional amount calculation should use the option strike price and not the option premium.

For orders and their lifecycle events, this field shall not be reported.

 

Data Field No (39) Notional currency

No. Field Identifier Description
39 Notional currency The currency of the notional amount.

 

Description of Accepted Values Type Length Examples
ISO 4217 Currency Code, 3 alphabetical digits:

BGN=Bulgarian lev
CHF=Swiss franc
CZK=Czech koruna
DKK=Danish krone
EUR=Euro
EUX=Euro cent
GBX=Penny sterling
GBP=Pound sterling
HRK=Croatian kuna
HUF=Hungarian forint
ISK=Icelandic króna
NOK=Norwegian krone
PCT=Percentage
PLN=Polish złoty
RON=Romanian new leu
SEK=Swedish krona/kronor
USD=U.S. dollar
OTH=Other

Text 3 EUR

This field identifies the currency for the value indicated in field 38. The notional currency shall be provided in unit as stored in the system of the reporting party.

However, reporting parties may want to report in a major unit e.g. EUR rather than EUX for euro cent and GBP rather than GBX for penny sterling. The reason for reporting the major unit is to avoid unnecessarily large values. For example, that the price for NBP is quoted in pence per therm, but the notional value of the contract may be much bigger, e.g. a gas year forward is 365 days so it may be more appropriate to have GBP 1,000,000 rather than GBX 100,000,000.

If field 38 is blank, this field should be left blank.

Data Field No (40) Quantity/Volume

No. Field Identifier Description
40 Quantity / Volume Total number of units included in the contract or order.

 

Description of Accepted Values Type Length Examples
Up to 20 numerical digits in the format xxxxx.yyyyy with a maximum of 5 decimals. Number 20 100

This field identifies the quantity or energy volume (delivery capacity) for the contract, i.e. the contract size or clip size. The value that shall be reported in this field is the volume per time unit, e.g. the number of MWh/h or therm/day.

For example, consider the two scenarios: market participant A enters into a contract and sells 10 MW (MWh/h) of electricity (or gas) at €50/MWh on the day-ahead market whilst market participant B enters into a contract and sells 10 therms (therm/day) of gas at €50/therm on the day-ahead market. In both scenarios, the value of 10 should be reported in this field.

The same applies if the contract is an hourly or monthly delivery contract.

If delivery capacity is specified in field 55, this field should be left blank. Please refer to the trading scenarios in ANNEX II.

Data Field No (41) Total notional contract quantity

No. Field Identifier Description
41 Total notional contract quantity The total number of units of the wholesale energy product.

 

Description of Accepted Values Type Length Examples
Up to 20 numerical digits in the format xxxxx.yyyyy with a maximum of 5 decimals. Number 20 1000

This field identifies the total quantity or energy volume of the transaction (total contract volume). The total notional contract quantity is the overall quantity/volume of energy included in the transaction. The notional contract quantity should be calculated using the following formula:

Total notional contract quantity = Volume x number of periods, where:

  • Volume is the quantity of energy as per field 40
  • Number of periods is the number of times that quantity is delivered / received (as derived from the delivery profile)

For example, a contract traded for a volume of 50 MW delivered for 24 hours would have the following notional contract quantity:

50 MW x 24h = 1,200 MWh

or for a monthly contract:

50 MW x 24h/day x 30 days = 36,000 MWh

Continuing this example, if the above contract was for delivery for 10 hours, the Notional Contract Quantity would be 500 MWh (50 MW x 10h), however if the contract for delivery was for 10 hours for 30 days, then the notional  quantity would be 15,000 MWh (50 MW x 10 h/day x 30 days).
For orders and their lifecycle events, this field shall not be reported.

Data Field No (42) Quantity unit for fields 40 and 41

No. Field Identifier Description
42 Quantity unit for field 40 and 41 The unit of measurement used for fields 40 and 41.

 

Description of Accepted Values Type Length Examples

For field 40:

KW
KWh/h
KWh/d
MW
MWh/h
MWh/d
GW
GWh/h
GWh/d
Therm/d
KTherm/d
MTherm/d
cm/d
mcm/d
Btu/d
MMBtu/d
MJ/d
100MJ/d
MMJ/d
GJ/d

<For field 41:

KWh
MWh
GWh
Therm
Ktherm
MTherm
cm
mcm
Btu
MMBtu
MJ
MMJ
100MJ
GJ

Text 2 to 8 MW

This field identifies the unit used for the reported quantity in field 40 and field 41 as specified in the contract. Since the units for field 40 and field 41 differ, the two different quantity units should be provided according to the above list.

Data Field No (43) Termination date

No. Field Identifier Description
43 Termination date Termination date of the reported contract. If not different from delivery end date, this field shall be left blank.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format. Date 10 2014-01-29

This field identifies the termination date of the contract, where the contract is terminated before the end of the previously reported delivery period. In this case, a cancellation report has to be submitted with the termination date of the contract in this field.

Example: market participant (A) and market participant (B) trade a monthly physical forward for the month of July. During the course of the month of July, (A) and (B) agree to terminate the contract on 25 July instead of the original delivery end date of 31 July. In this case, the date of 25 July should be reported as termination date in this field and the cancelled report should also include the time and date of such the termination agreement in the transaction timestamp (field 30).

 

RSS_Icon Last update: 09/05/2016  

RSS_Icon Subscribe to this Category’s RSS