4.3 Data fields related to contract details

4.3 Data fields related to contract 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
21 Contract ID M M DV DV
22 Contract name M M DV DV
23 Contract type M M M M
24 Energy commodity M M M M
25 Fixing index or reference price M* M* M* M*
26 Settlement method M M M M
27 Organised market place ID/OTC M M DV DV
28 Contract trading hours M M DV -
29 Last trading date and time M* M* - -

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

Data Field (21) Contract ID

No. Field Identifier Description
21 Contract ID The contract shall be identified by using a unique code identifier provided by the market place or counterparties.
Description of Accepted Values Type Length Examples
Up to 50 alphanumerical digits. Alphanumerical 50 AGHDN15832839

This field identifies the unique contract ID provided by the organised market place at which the contract is traded. The contract ID is venue-specific. The contract ID is needed to link all the orders to a specific contract.

Where an organised market place has not yet identified a contract with a unique ID, the Agency believes that the organised market may decide to do so using the following rules:

a. for auction markets: gate closure (+ commodity + delivery point if the exchange organises more than one commodity and/or delivery points);

b. for exchange continuous markets:  delivery date (or month) + hrs (if needed) (+ commodity and or + delivery point if the exchange organises more than one commodity and /or delivery points);

c. for Brokers: delivery point + commodity + delivery date (or month) + hrs (if needed).

The examples above are just one way to illustrate how to construct a unique contract ID in those situations where the organised market places have not yet a unique contract ID.

Market participants reporting bilateral contracts traded off-organised market places, back-loading and executions under the framework of non-standard contracts are not expected to submit a contract ID, but only “NA” for ‘not available’.

Guidance on reporting contract ID for transactions executed at an organised market place

The contract ID of the organised market place is required to be reported in order and trade reports executed at OMPs. Market participants or RRMs should not create their contract ID in substitution of the contract ID used by the OMP for the reporting of orders to trade and trades.

The OMP must have only a single contract identifier for the contract for the lifetime of the tradable contract. The contract identifier must be unique and is not shared with any other contract. The contract must always be represented using the same contract identifier throughout the lifecycle of the transaction/contract, i.e. up to the date of delivery.

Data Field (22) Contract name

No. Field Identifier Description
22 Contract name The name of the contract as identified by the organised market place.
Description of Accepted Values Type Length Examples
Up to 200 alphanumerical digits. Alphanumeric 200 XYZ abc day-ahead

This field identifies the name of the contract as identified by the organised market place hosting the trading of the contract. The contract name should be unique within a particular organised market place, but the same name can also be used by other organised market places.

The contract name should be the same as used by the organised market place to advertise the contract in their system to their clients. If market participants delegate third parties to report their transactions executed at organised market places, then they should use the same contract name if made available to them.

Sometimes the contract name and the contract ID may be the same. In this case, both fields should be populated with the same value.

Market participants reporting bilateral contracts traded off-organised market place are expected to report the value of “BILCONTRACT”, “BACKLOADING” or “EXECUTION” according to the trading scenarios available in Annex II.

Population of “Contract name” when reporting bilateral contracts traded off-organised market places, back loading of standard contracts and execution under non-standard contracts in Table 1

“BILCONTRACT”: should be reported to identify standard contracts and non-standard contracts (that have a defined price and quantity) that are traded outside the organised market places.

”BACKLOADING”: was reported to identify the reporting of details of wholesale energy contracts which were concluded before the date on which the reporting obligation becomes applicable and remains outstanding on that date shall be reported to the Agency within 90 days after the reporting obligation becomes applicable for those contracts.

Please be aware that the back-loading exercise has expired according to the deadlines as specified in the REMIT Implementing Regulation.

“EXECUTION”: should be reported to identify the reporting of the details of transactions executed within the framework of non-standard contracts, specifying at least an outright volume and price.

Data Field (23) Contract type

No. Field Identifier Description
23 Contract type The type of the contract.
Description of Accepted Values Type Length Examples
  • AU=Auction
  • CO=Continuous
  • FW=Forward style contract
  • FU=Future style contract
  • OP=Option style contract
  • OP_FW=Option on a forward
  • OP_FU=Option on a future
  • OP_SW=Option on a swap
  • SP=Spread
  • SW=Swap
  • OT=Other
Text Up to 5 FW

This field identifies the type of contract that is reported.

For contracts traded in auction or exchange markets, the value of “AU” (for auction) or “CO” (for continuous on exchange) shall be reported respectively, unless the contract type is one of the other type of contracts listed above. If the contract type is not one of the allowed values listed above, e.g. AU to SW, then “OT” (for other) should be used.

For bilateral trades that take place on broker platforms or bilateral trades off-organised market places, “AU” or “CO” should not be used. “FW” (for forward style contract) refers to the forward style which also includes spot transactions. Market participants should not understand forward style as a sort of derivative contract, but as the style of the contract itself, i.e. for physical delivery at a later date.

Physical swaps or dark spreads are usually executed under two master agreements and they should be reported as separate contracts. However, where such transaction is represented by one legal agreement, then market participants should report it as “SW” for swap contract, or “SP” for spread contract, using one of the examples available in Annex II of the TRUM.

Guidance on reporting Data Field (14) Order type and Data Field (23) Contract type for orders on spreads

When market participants enter into a trade on inter-period or inter-product spreads (bilateral trades that take place on broker platforms), the order placed on the screen is a spread order, and therefore it is expected to report “SPR” in Data Field (14) Order type in the order report, even if the result is two forward trades. These orders should be reported as spark spreads in the same ways as presented in Annex II of the TRUM. Data Field (23) for Contract type should be populated with “FW” (in case the underlying contracts are forward contracts) in the order report and the resulting trade report for both legs.

Data Field (24) Energy commodity

No. Field Identifier Description
24 Energy commodity The classification of the energy commodity.
Description of Accepted Values Type Length Examples
  • NG=Gas
  • EL=Electricity
Text 2 NG

This field identifies the energy commodity of the product delivered; either natural gas or electricity. Other commodities such as emissions rights, coal, oil, etc. are out of scope of REMIT.

Spreads or spark spreads are not commodities. Clean and Dirty spark spreads involve one leg for the electricity trade and one leg for the gas trade, which have to be reported separately but should be linked together through Data Field (32) Linked Transaction ID. The emission leg (in the case of a Clean Spark Spread) will not be reported.

Where one or more elements of a spread is not gas or electricity, only the gas or electricity leg of the spread should be reported. For example, Clean and Dirty Dark Spreads, for a trade that involves electricity, coal and emissions should be reported as one leg for the electricity trade. Coal and emissions have not to be reported. In this case, the electricity trade does not need to be linked to other transactions through Data Field (32).

Data Field (25) Fixing index or reference price

No. Field Identifier Description
25 Fixing index or reference price Fixing index that sets the price for the contract or the reference price for derivatives.
Description of Accepted Values Type Length Examples
Up to 150 alphanumerical digits. Alphanumeric 150 XYZ abc day-ahead

This field identifies the name of the index used to fix the price of the traded contract as reported by the publisher or the reference price used to settle a derivative. If a fixing index or a reference price is reported in Data Field (25), then Data Field (35) shall be left empty.

Some contracts (both derivatives and non-derivatives) for physical delivery of gas or electricity are traded on the basis that the price will be fixed by an index value or reference price upon its publication.

Example: Party A trades a day-ahead gas/electricity contract on a broker platform at 11:00 am with fixing index ABCD day-ahead EU gas. The index price will be published later in the day by the ABCD publisher and that price will be used to settle the contract. Hence, the actual price is not known when the trade is agreed. The same logic applies for forward contracts with similar arrangements.

For derivatives, this field identifies the name or code (if available) of the underlying used for fixing the price of the traded contract. If a code is available, this field shall contain the code of the ultimate underlying instrument when reporting a transaction in a derivative. For example, a financial swap on two gas future contracts (e.g. two different delivery points) should have the name or the underlying code for the two futures.

As far as the Agency is aware, contracts that reference indexes which are used in order to determine settlement prices are available to the organised market places. In any case, since the Agency will not publish a list of indexes because these are publicly available, the Agency recommends that reporting parties use those indexes exactly as reported by the publisher.

If the index is not public, market participants should make best efforts to minimise any discrepancy between the two counterparties when reporting this information.

For derivatives that have not already been reported under EMIR, and therefore reported under REMIT, the following buyer and seller logic should apply: for example, in the case of a fix to floating derivative, if party X buys a swap, then party X pays a fixed price and party Y pays a floating price. This means that party X receives the floating leg and party Y receives the fixed leg. X will be identified as a buyer (B) and Y will be identified as a seller (S).

In the case of a floating to floating derivative, if party X buys a swap, party X pays the floating price of the first leg (or index) and party Y pays the floating price of the second leg (or second index). In this case, legs (indexes) should be sorted alphabetically. X will be identified as a buyer (B) and Y will be identified as a seller (S).

Reporting bilaterally agreed index trades in Table 1 and Table 2

Some contracts (both derivatives and non-derivatives) for physical delivery of gas or electricity (and/or their transportation) are traded on the basis that the price will be fixed by an index value or reference price upon its publication. When these types of contracts are traded bilaterally (i.e. non-standard contracts), market participants should consider the following in order to decide to report their trades with Table 1 or Table 2 of the REMIT Implementing Regulation.

When the price of an index trade is calculated, e.g. by using more than one index (i.e. combination of indices) or by applying a formula, the contract should be reported in Table 2 and the executions are reported in Table 1.

Example: A MP buys an electricity forward contract directly from a counterparty for delivery of 25MW in Country A for the month of August 2016. The contract does not have a fixed price, but uses the following formula/basket index:

50% ELECTRICITY DAILY INDEX BASE SPOT EXCHANGE X + 50% ELECTRICITY MONTH FUTURES BASE EXCHANGE X.

The MP should report the contract using Table 2, indicating the name of both indices via repeatable Data Field (25) and the price formula in Data Field (15). The related executions will be reported using Table 1.

On the other hand, if the index trade does not have a calculation, but uses only one index or a price differential from an index, Table 1 should be used for the reporting of the contract.

Example: A MP buys an electricity forward contract directly from a counterparty for delivery of 25MW in Country A for the month of August 2016. The contract does not have a fixed price, but uses the following formula index:

EUR 2 / MWh + ELECTRICITY DAILY INDEX BASE SPOT EXCHANGE X.

This means that the price for a Pricing Date will be that day's Specified Price per MWh of electric energy at constant power for delivery on the Delivery Date, stated in EUR, published by EXCHANGE X on the exchange’s website.

The contract should be reported using Table 1 and the value of EUR 2 shall be indicated in Data Field (36) for Index value and Data Field (37) Price currency.

Data Field (26) Settlement method

No. Field Identifier Description
26 Settlement method Whether the contract is settled physically, in cash, optional or other.
Description of Accepted Values Type Length Examples
  • P=Physical
  • C=Cash
  • O=Optional for counterparty
Text 1 P

This field identifies the type of settlement for the contract. “P” shall be indicated if the contract is settled physically and “C” shall be indicated if the contract is settled in cash. “O” shall be indicated if the contract can be physically settled or may be settled in cash at the option of one of the parties.

For contracts such as options on forwards, futures or swaps, as the option settles into the underlying forward, future or swap, this should be considered for physical delivery of the underlying contract and the value of “P” should be reported.

A majority of contracts traded under REMIT are for physical delivery, but there may also be derivative contracts that are not reported under EMIR and thus reported under REMIT. Consequently, different types of settlement methods can occur. For further clarification on derivatives not reported under EMIR but reportable under REMIT, please refer to section 3.3.3 of this guidance and also Annex III to the TRUM.

Data Field (27) Organised market place ID / OTC

No. Field Identifier Description
27 Organised market place ID / OTC In case the market participant uses an organised market place to execute the contract, this organised market place shall be identified by a unique code.
Description of Accepted Values Type Length Examples
  • LEI
  • MIC
  • ACER code
  • XBIL=Bilateral trade (off-market)
Alphanumeric
  • 20
  • 4
  • 12
  • 4
  • 1234567890abcdefrgf
  • MICX
  • C0643278W.EU
  • XBIL

This field identifies the organised market place of the execution of the transaction.

If the transaction was executed at an organised market place, the organised market place identification field must contain the Legal Entity Identifier (LEI) or, the Market Identifier Code (MIC) or the ACER code as assigned by the Agency at the time of the registration as organised market place.

If the transaction was bilaterally agreed between the two parties and executed off-organised market place, this field must report “XBIL”.

Data Field (28) Contract trading hours

No. Field Identifier Description
28 Contract trading hours The trading hours of the contract.
Description of Accepted Values Type Length Examples
ISO 8601 time format using UTC time format Time n/a 09:00Z/17:00Z

This field identifies the trading timeframe for the contract as set by the organised market place, indicating when a participant can submit orders and when trading can occur. All contract hours shall be reported using UTC time format.

In such case, trading hours are (in general) the opening and closing times of the specific contract along with any additional restrictions in trading times.

In case of continuous markets, exchanges or broker platforms shall report the trading hours in which their clients may place orders and trade in that market: e.g. 09:00Z to 17:00Z or 00:00Z to 24:00Z if no restrictions are imposed by the exchange.

In the case of auction markets, trading hours are in general 00:00Z to 24:00Z unless the exchange has some restrictions on the time from which bids and offers can be placed on a regular day to the date and time at which bids and offers can no longer be placed, i.e. the last trading date and time (Data Field (29)).

For bilateral trades that occur off-markets, 00:00Z to 24:00Z should be indicated by default.

For reporting executions in Table 1 under the framework of non-standard contracts, this field can be left blank.

Reporting contract trading hours with and without restrictions applied by organised market places

In the Agency’s view the “trading timeframe for the contract” should represent the hours within which the electronic orders are displayed in the screen, e.g. 09:00 to 17:00 if there are restrictions applied by the organised market place. If a voice brokered trade takes place outside the core trading hours, e.g. 9:00 to 17:00, the contract should be reported with the same hours, but flagged as “voice-brokered” in Data Field (34).

Data Field (29) Last trading date and time

No. Field Identifier Description
29 Last trading date and time The last trading date and time for the reported contract.
Description of Accepted Values Type Length Examples
ISO 8601 date and time format using UTC time format. Date and Time n/a 2014-01-29T16:30:00Z

This field identifies the last trading date and time for the contract. The last trading date and time is the last point in time when a participant to that market can submit orders and when trading can occur. The time shall be reported using UTC time format.

For auction markets, this is the gate closure. For exchange markets and brokers’ platforms, this is the last date and time when an order can be placed to trade the specific contract as identified in Data Field (21) Contract ID. If an organised market does not have such a time constraint, then this field should be left blank.

As regards bilateral trades which take place outside organised market places, this field should not be populated.

Updated: 
31/03/2022