4.4 Data fields related to transaction details

4.4 Data fields related to transaction details

This section includes the following fields:

Field No. Field name Traded on OMP - Orders Traded on OMP - Trades Traded outside OMP - BILCONTRACT Traded outside OMP - EXECUTIONS
30 Transaction timestamp M M M M
31 Unique transaction ID - M M M
32 Linked transaction ID - M* M* M
33 Linked order ID M* M* - -
34 Voice-brokered M* M* M* -
35 Price M* M* M* M
36 Index value M* M* M* -
37 Price currency M* M* M* M
38 Notional amount - M* M* M
39 Notional currency - M* M* M
40 Quantity/Volume M* M* M* M*
41 Total notional contract quantity - M M M
42 Quantity unit for field 40 and 41 M* M M M
43 Termination date - M* M* -

M = mandatory; O = optional; - = does not apply; * = conditionally required; DV = default value specified in TRUM

Data Field (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.050Z Or 2014-01-29T12:35:56.050+02.00

This field identifies the transaction timestamp, meaning the time at which the reported event occurred. This field must reflect as accurately as possible 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. In case of coupled markets, the transaction timestamp should reflect the one provided by the centralized coupling system.

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. If order is partially matched in several consecutive steps, these should be reflected also via the timestamp of the order lifecycle events.

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.

The transaction timestamp reported should reflect the same time granularity as used in organised market places’ systems. If an organised market place operates in milliseconds the timestamp reported should be in milliseconds granularity. For example if an order was placed in an order book on 08.10.2019 at 14:45:23.123, exactly the same timestamp should be also reported to the Agency. Any rounding should be strictly avoided.

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.

Representation of Data Field (30) Transaction timestamp in the electronic format (schema)

Data Field (30) Transaction timestamp is represented by the following fields in the schema:

  • Transaction timestamp (<transactionTime>
    )
  • Execution timestamp (<executionTime>)
  • Original entry time (<originalEntryTime>)


Execution timestamp

Execution timestamp is part of Trade Report. It can be used to indicate that the legal execution time takes place a few seconds/minutes after the orders have matched.

<executionTime> should be reported only if different than <transactionTime>
.


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.593Z</transactionTime>



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



Please see also “Mapping between the IAs Table 1 data fields and the XSD Schema_Table1_v1” file available in the REMIT Documents section of the ACER website.






Original entry time



When submitting an order report, OrderReport in the schema includes field <originalEntryTime> which may be used to report orders that have a persistent Order ID when the orders 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)



Transaction timestamp in executions reported in Table 1 under the framework of non-standard contracts



When reporting executions in Table 1 (EXECUTION) the transaction timestamps may be different for the two market participants. Therefore, this field should indicate the date each MP confirms the price and the quantity for the delivery period. As the execution time might be not known by the market participants, this field should be populated indicating the date only. As the field in the schema is a date-time one, it can be indicated the default time of 00:01:00 UTC .






Transaction timestamp in case of auctions in market coupling



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. However when dealing with auctions in market coupling, the Agency understands that preliminary results of the auction might be shared with market participants before the final global results are published. In such cases, the transaction timestamp for the trade refer to the disclosure of the preliminary results carried out by the relevant NEMOs with its market participants. In case the final global result does not differ from the preliminary result, no lifecycle event of the trade has to be reported.

Data Field (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 REMIT Implementing Regulation. 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 report is sent to ACER by Need for MPs to generate the UTI Lifecycle events reported by
At OMP The OMP The OMP (or third parties on its behalf) No Market participants or third parties (or OMP if this offers the service)
Market participants or third parties on their behalf No Market participants or third parties
Bilaterally Market participants or third parties on their behalf

Market participants or third parties on their behalf

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 Regulation’ 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 REMIT Implementing Regulation 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 REMIT Implementing Regulation 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 generated by the brokers’ 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 anonymization. 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.

Additional guidance on the UTI when reporting executions in Table 1 under the framework of non-standard contracts

The Agency’s stakeholders have highlighted and requested the need to assign a unique number to each execution report in Data Field (31) Unique Transaction ID of Table 1. This requirement makes sure that in case it is needed to report a modification report, this can be submitted to modify a previously reported execution uniquely identified in Data Field (31) Unique Transaction ID of Table 1. The UTI is needed for the ID of the record, otherwise the market participant will not be able to make any amendments and/or recall the transaction.

For executions under the framework of non-standard contracts where the market participant does not have an UTI for the trade, the market participant should create one.

The Unique Number can be any number the market participant likes (as long as it is unique for that market participant and not used for other executions. It could be, for example, any progressive unique number for the market participant who is reporting the execution, or the transaction ID available in their system.

There is no expectation that the buyer and seller unique number for the execution have to be the same. This is a unique number that will identify the report uniquely.

For further guidance on UTI and the UTI generator tool, please see Annex IV to the TRUM.

Guidance on “Additional unique transaction info” field in REMIT Table1_V2

Data Field (31) Unique transaction ID is represented by the following fields in the schema: Unique transaction ID and Additional UTI info. The AdditionalUtiInfo field can be used to report the EIC Y code for a delivery point or zone in a non-EU country.

For example, if a trade is a cross border trade referring to a EU delivery point or zone and the Swiss delivery point or zone (or any other non-EU delivery point or zone), then the organised market place may report the EIC Y code for the non-EU country delivery point or zone in the “Additional unique transaction info” field. It should be noted that reporting EIC Y code for delivery point or zone in the non-EU country is not a REMIT requirement.

The Agency is aware that REMIT market participants reporting trades (executed at 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 or zone.

  Data Field (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 Data Field (31) for standard contracts or Data Field (11) of Table 2 for non-standard contracts. The linked transaction 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:

2.

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.

3. 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 (11) of table 2).

4. When an option is exercised, then the resulting transactions should be reported and linked to the option via this field.

5. For reporting sleeve trades, Data Field (32) Linked Transaction ID shall be used in order to report the UTI of the linked sleeve trade report. Please refer to Annex II to the TRUM for examples on reporting sleeve trades.

  Data Field (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.

Reporting Linked order ID in a trade report in case the order was not visible to the market

The Agency is aware that there cases when a standard contract is admitted to trading at a spot market, but the contract was traded bilaterally between two market participants of the spot market and it has been sent to spot market system for clearing. In this case, the trade takes place on an exchange without orders on screen (e.g. cleared), and this trade should be reported as any other trade that takes place on exchange. Data Field (33) Linked order ID should be reported with the value of “NA” to indicate that there was not any order visible to the market.

Reporting exchange traded contracts when orders are placed and trades are executed on two different organised market places

In case of exchange traded contracts, if the trade takes place on an exchange with orders to trade placed on the broker’s screen or voice brokered, there is no expectation that the order report and the trade report are linked together as they were placed first and executed after on two different organised market places. This implies that in this specific case Data Field (33) should be left blank in the trade report.

  Data Field (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 (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 one unit of energy as expressed per unit of time in Data Field (40).

For example: an hourly electricity contract is reported by indicating the total units of energy as 50 (indicated in field 40), the unit of measurement as MWh/h (indicated in field 42 for field 40), and Data Field (35) is populated with 53.45 with a price currency expressed in EUR (indicated in field 37). This implies that the price for 1 MWh of electricity is 53.45 EUR.

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 the price of the trade/contract is set by a fixing index or a reference price indicated in Data Field (25), this field should be left blank.

If a price/time interval is specified in Data Field (57), this field shall be left blank.

In case of spreads, this field should be populated with the spread value only for the leg for which the spread applies with positive sign.

In case of MAR and MTL orders, this field shall be left blank.

The trading examples in Annex II explain in which circumstances this field should not be reported.

Clarification on how to interpret the unit of measurement for quantity and total notational contract quantity in relation to the price field

If the price is expressed in a certain currency (e.g. EUR) in Data Field (37), then, depending on the quantity unit reported in Data Field (42) for Data Field (40), the unit of measurement for Data Field (35) Price shall be interpreted the following way:

Quantity units reported in Data Field (42) for Data Field (40) Interpretation of the unit of measurement related to the price reported in Data Field (35)
  • KW
  • KWh/h
  • KWh/d
EUR/KWh
  • MW
  • MWh/h
  • MWh/d
EUR/MWh
  • GW
  • GWh/h
  • GWh/d
EUR/GWh
Therm/d EUR/Therm
KTherm/d EUR/Ktherm
MTherm/d EUR/MTherm
cm/d EUR/cm
mcm/d EUR/mcm
Btu/d EUR/Btu
MMBtu/d EUR/MMBtu
MJ/d EUR/MJ
100MJ/d EUR/100MJ
MMJ/d EUR/MMJ
GJ/d EUR/GJ

Reporting a trade with negative price

In certain cases, market participants may enter into a trade with a negative price. If the price of the trade is negative, price Data Field (35) should be reported with a negative number.

Data Field (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 Data 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 price currency Data Field (37). If there is no deviation from the value of the fixing index, the value should be 0.

Data Field (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 to be considered for the unit of measurement of the value indicated in Data Field (35). As the value indicated in Data Field (35) indicates the price per unit of energy, the unit of measurement of the price refers to values indicated in Data Field (37) and Data Field (42) with reference to Data Field (40) per one unit of time.

Example:

Considering that:

  • Data Field (37) populated with EUR
  • Data Field (42) for Data Field (40) populated with MWh/h

In this case, the unit of measurement of the value reported in Data Field (35) is intended to be expressed in EUR/MWh.

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” for percentage which is one of the accepted values.

If Data Fields (35) and (36) are blank, this field should be left blank.

Guidance on reporting price currency for transactions where the contract is advertised by the OMP

Transaction reports for orders to trade and trades executed at organised market places should be reported in the unit as advertised by the OMP. If market participants decide to report their transactions through third parties (e.g. RRMs), they should indicate the same currency as the one advertised by the Organised Market Place for that contract.

Data Field (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. In case the Notional amount is provided by the OMP, this field shall be populated with the value as provided by the OMP.

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 Data Field (35)
  • Volume is the quantity of energy as per Data 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 Data Field (35)
  • Total notional contract quantity is the quantity of energy as per Data 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(€/MWh) x 100(MW) x 24(h) = €120,000

or for a monthly contract:

50(€/MWh) 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.

Guidance on reporting notional amount if the price of the trade is negative

Data Field (38) Notional amount should always be reported in absolute value even if Data Field (35) Price is reported with a negative number.

Data Field (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 Data Field (38). The notional currency shall be provided in the 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 (but not GBP instead of EUR). 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 Data Field (38) Notional amount is blank, this field should be left blank.

Data Field (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.

In case of orders, this field is intended to represent the visible quantity on the order book. Hence, if a hidden quantity is present (e.g. iceberg orders), then the overall quantity of the order should be derived as:

Data Field (19) Undisclosed Volume + Data Field (40) Quantity/Volume

If delivery capacity is specified in Data Field (55), this field should be left blank. Please refer to the trading scenarios in Annex II.

Data Field (41) Total notional contract quantity

No. Field Identifier Description
41 Total notional contract quantity The total number of units of the wholesale energy product. This is a calculated figure.
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 Data Field (40) or Data Field (55)
  • 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 and 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 Contract 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 (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 Data Field (40) and Data Field (41) as specified in the contract. Since the units for Data Field (40) and Data Field (41) differ, the two different quantity units should be provided according to the above list.

Reporting quantity units for transactions executed at an organised market place

The Agency stresses that for Data Field (40) Quantity/Volume, transaction reports for orders to trade and trades executed at organised market places should be reported in the unit as advertised by the OMP. If market participants decide to report their transactions through third parties (e.g. RRMs), they should indicate the same unit as the one advertised by the OMP for that contract.

With regards to Data Field (41) Total notional contract quantity, it is possible that reporting parties report the information in major unit, e.g. MWh or KWh (but not MWh instead of GJ).

Data Field (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.

The field identifies when the termination of the contract takes into effect.

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 in the transaction timestamp in Data Field (30) the cancelled report should also include the time and date of the agreement on the termination of the contract.

Date-Time format for Termination date field in the electronic format

Reporting parties should be aware that even though Data Field (43) for Termination date is defined as a Date type field in the TRUM, the schema allows also to report DateTime format. Hence, when populating the TerminationDate field in the schema, this can be reported as <YYYY-MM-DDT00:00:00Z>. Time shall be expressed in UTC format.

Updated: 
31/03/2022