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 shall always be represented in UTC time format, thus indicating Z or a time zone offset. 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 centralised coupling system.
For orders placed for continuous markets, the transaction timestamp is the time at which the order is placed or at which any subsequent modification or cancellation of the order occurred. If an order is partially matched in several consecutive steps, these should be reflected also via the timestamp of the order lifecycle events.
For trades concluded on continuously traded contracts, the transaction timestamp is the time at which the linked orders were matched and trades were created in the market or at which any subsequent modifications or cancellations of the trade transaction occurred.
For orders placed for auction contracts, the transaction timestamp is the time at which the orders were placed and considered for the auction.
For trades in auction markets, the transaction timestamp is the time of the announcement of the auction results or any subsequent modification or cancellation of the trade.
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 time at which the trade was agreed by the two market participants shall be reported. The timestamp shall be rounded to the nearest minute in the UTC format, e.g. 2014-01- 29T10:35Z. However, where market participants are not able 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 deal capture systems (when this is not materially different from the actual trading time), market participants should make best efforts to minimise any discrepancy between the actual agreement trading time and the booking time.
With regards to the statement “materially different from the actual trading time”, this shall be assessed on a case-by-case basis.
Where the trading time is not made available to the market participant (e.g. for back-to-back transactions or when market participants do not have access to the markets and the trading time is not available or the trading time is not forwarded by the organised market place) 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 trade was concluded. Using this default time will ensure that these transaction reports are included in the Agency’s monitoring, however the accuracy is key to when the information is analysed against the publication of inside information.
|
Representation of Data Field (30) Transaction timestamp in the electronic format (Table 1 XML Schema) Data Field (30) Transaction timestamp is represented by the following fields in the schema:
Execution timestamp Execution timestamp is part of Trade Report. It can be used to indicate that the legally binding execution takes place shortly after the orders have matched. Such an event might occur, for example, when market participants trade bilaterally or over a broker-type organised market place and the trades are eventually cleared on exchange. Please note that <executionTime> should be reported only if different than <transactionTime>. When <executionTime> is different than <transactionTime>, this can be reported under code <executionTime></executionTime>. E.g. for a trade: <transactionTime>2015-06-11T15:58:44.593Z</transactionTime> <executionTime>2015-06-11T16:01:15.000Z</executionTime> Please see also “Table1 vs Schema T1 Mapping” document available on the ACER website. Original entry time The OrderReport in the schema includes field <originalEntryTime> which shall be used to report orders with 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 using Table 1, the exact transaction timestamps reported by the involved market participants may be different. Therefore, this field should indicate the timestamp when each market participant confirms the price and the quantity for the particular contract. Since the exact and matching execution time may be not known by the market participants reporting each its own side of the trade, this field should be populated indicating the date only. As the field in the schema is a datetime 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. 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 refers to the disclosure of the preliminary results carried out by the relevant organised market places (NEMOs) with its market participants. In case the final global result does not differ from the preliminary result, no lifecycle event of the trade is required 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 shall be populated with a unique transaction identifier (UTI) assigned by the organised market in order to allow for the matching of the two sides of a trade. In case of bilateral trades, the UTI shall be agreed and reported by the two market participants.
Generation, dissemination and usage of the UTI
The Agency understands 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 or agreed 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 on an organised market place 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. This rule does not apply to auction markets. All transactions have one clearing price and this is determined by the auction algorithm for all the market participants at the same time. In these particular market segments, all transactions reported by particular market participants shall have a different UTI 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.
The Agency believes that there are a few UTI generation and dissemination scenarios which need to be considered, namely:
| The trade is concluded: | 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 on their behalf (or OMP if it offers the service) |
| Market participants or third parties on their behalf | No | Market participants or third parties on their behalf | ||
| Bilaterally | Market participants or third parties on their behalf |
Market participants or third parties on their behalf |
Yes | Market participants or third parties on their behalf |
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 UTI generated by the exchange;
2. For continuously traded contracts traded on exchanges, transactions shall identify the buy side and the sell side with the same UTI generated by the exchange, e.g. :
o (A) matches a trade with (B), both (A) and (B)’s trade reports shall have the same UTI (e.g. 123);
o (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).
o 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 broker organised market places, the trade reports shall identify the buy side and the sell side with the same UTI generated by the organised market place’s platform.
4. For bilateral trades that take place outside an organised market place, the two market participants shall align and 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 for any reason an organised market place does not generate or/and disseminate the UTIs to the market participants, the market participants shall follow the guidance on the generation of the UTI provided below.
In order to facilitate the reporting of bilateral contracts, the Agency has developed and published an ACER algorithm which enables market participants to generate the same UTI from the economic terms of the bilateral trade. Please consult Annex IV to the TRUM.
Therefore, for bilateral trades, the Agency recommends that market participants use the ACER algorithm available in Annex IV to the TRUM, unless:
1. Markets participants 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 both cases, 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 Stakeholders have proposed the requirement to assign a unique identification code to each execution report in Data Field (31) Unique Transaction ID of Table 1. This requirement enables reporting of lifecycle events related to these transaction reports. The UTI can be any identifier the market participant prefers, as long as it is unique for that market participant and not used for other execution reports. It could be, for example, any progressive unique number for the market participant who is reporting the execution, or the identifier available in their deal capturing systems. There is no expectation that the buyer and seller unique number for the execution match. For further guidance on UTI and the UTI generator tool, please see Annex IV to the TRUM Guidance on “Additional unique transaction info” field 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 an 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 (concluded 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 execution transactions within the framework of non-standard contracts are linked to the non-standard contract. The value populated in this field is the UTI 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 contracts due to the nature of the contracts, e.g. a contract which is a spread of two or more contracts falling under the scope of REMIT. The trade for each contract 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 trades are reported separately, with one leg for the electricity and one leg for the gas trade. The two legs should be linked together through the Linked transaction ID 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 an execution within the framework of a non-standard contract, the details of the transaction specifying at least an outright volume and price shall 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 the order that is associated with the concluded trade. The linked order ID shall be used in the following scenarios:
- When an order is matched, the trade report should contain the field “Linked Order ID” to identify the order that resulted in the trade; 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 of bilateral trading off-organised market place The Agency is aware that there are 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 and trades are placed/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-type organised market place, 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, meaning that the schema element “voiceBrokered” shall be left empty.
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 Data Field 42 for Data 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 types, 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:
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.
In order to fix the price of the trade, market participants often agree on a difference (+/-) from the fixing index price that will be published after the trade occurs, e.g. by the end of the particular day or month.
In case there is no difference from the fixing index price and:
- the value of the fixing index is not known when the contract is traded, this field shall be left blank.
- the value of the fixing index is known when the contract is traded, this value is to be reported in this field.
In case there is a difference from the fixing index price, field (36) shall be populated with:
- the agreed price differential from the fixing index, including the positive (‘+’) or negative (‘-‘) sign respectively (e.g. +0.05).
In case the index value is not known when the contract is traded, the market participant should populate the field with “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 particular day or month. 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 Data Field (37) Price currency. In REMITTable1_V3 schema, “PCT” shall be indicated in the dedicated elements in the order and trade parts of the schema “indexCurrency”.
For further guidance and examples on the reporting of transactions where an index or reference price is used to fix the price of the traded contract, please refer to Data Field (25).
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:
|
Text | 3 | EUR |
This field identifies the currency to be considered for the unit of measurement of the value indicated in Data Field (35) Price. 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) Price currency and Data Field (42) Quantity unit for field with reference to Data Field (40) per one unit of time.
Example:
If Data Field (37) populated with EUR and Data Field (42) for Data Field (40) populated with MWh/h, 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.
If Data Fields (35) Price and (36) Index value are blank, this field should be left blank.
|
Guidance on reporting price currency for transactions where the contract is advertised by the OMP Reports for orders and trades concluded at OMPs 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 advertised by the OMP 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 amount value of the trade. 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 (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 EUR/MWh for a volume of 100 MW delivered for 24h (hours) has the following notional amount:
50EUR/MWh x 100MW x 24h = EUR 120,000
or for a monthly contract:
50EUR/MWh x 100 MW x 24h/day x 30days = EUR 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 trade. Such trades may also include a differential from the published index value which is not available to the organised market place. For example, + EUR 0.05 or -0.1%.
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 buys gas three months ahead from the trading date (a forward). The price of that 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.
In some cases (e.g. trade at settlement), reporting parties may be able to calculate the notional amount of the trade and populate field (38) by the time the REMIT reporting of the trade is due. Such information always provides an added value to the transaction record.
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 is not expected to 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:
|
Text | 3 | EUR |
This field identifies the currency for the value indicated in Data Field (38) Notional amount. 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. 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 sells 10 MW of electricity at 50 EUR/MWh on the day-ahead market, whilst market participant B sells 10 therms of gas at 50 EUR/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) Delivery capacity, the Data Field (40) Quantity/Volume shall 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 notional contract quantity of the transaction including orders to trade. The total 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) Quantity/Volume or Data Field (55) Delivery capacity
- Number of periods is the number of times that quantity is delivered (as derived from the delivery profile)
The total notional contract quantity shall always be calculated based on the information on the volume and number of periods as provided in the respective transaction (i.e. order and trade) report. This implies that the total notional contract quantity of an order shall change accordingly if any components of the above formula (i.e. the volume as defined in Data Field (40) and/or the number of periods) is being modified throughout the lifecycle of the order. This also implies that that the total notional contract quantity of the trade resulting from the matched order might differ from the total notional contract quantity of the order originally placed.
For example, a contract traded for a volume of 50 MW and delivered for 24h would have the following total notional contract quantity:
50 MW x 24 h = 1,200 MWh
or for a monthly contract:
50 MW x 24 h/day x 30days = 36,000 MWh
Continuing this example, if the above contract was for delivery for 10h, the total notional contract quantity would be 500 MWh (50 MW x 10 h), however if the contract for delivery was for 10h for 30 days, then the total 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 is not expected to 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:
For field 41:
|
Text | 2 to 8 | MW |
This field identifies the unit used for the reported quantity in Data Field (40) Quantity/Volume and Data Field (41) Total notional contract quantity. 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 concluded at an organised market place The Agency stresses that for Data Field (40) Quantity/Volume, reports for orders to trade and trades concluded at OMPs 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 and time format using UTC time format | Date and Time | 10 | 2014-07-31T00:00:00Z |
This field identifies the termination date of the contract, where the contract is terminated before the end of the previously reported delivery period (i.e. early-termination). In this case, a cancellation lifecycle report has to be submitted with the termination date of the contract in this field.
Please consult Annex VII to the TRUM available on the REMIT Portal.
Example: In June, market participant A and market participant B traded a monthly forward for the month of July. During the course of the delivery period, (the market participants agree to terminate the contract on 25 July instead of the original delivery end date of 31 July. In this case a cancellation lifecycle event shall be reported, indicating the date of 25 July in Data Field (43) Termination date. Data Field (30) Transaction timestamp should instead report the time and date of the agreement on the termination of the contract.