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 | Order duration | 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 on which the contract is traded. The contract ID is organised market place-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 contract. The contract identifier must be unique and shall not be 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 records of transactions, including orders to trade placed on organised market places, then reporting parties should ensure accuracy of the reported data by checking the consistency with the parameters originally provided by the organised market place.
Sometimes the contract name and the contract ID may be the same. In this case, both fields should be populated with the same value.
|
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 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. “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 |
Applicable for EFPs and EFSs
Applicable only for LNG
Applicable only for PPAs
|
Text | Up to 5 | FW |
This field identifies the type of contract.
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 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 trade period, contract or product spreads, it is considered that the transaction refers to two different master agreements. The order placed should be reported as a spread order (indicated as “SPR” for ‘Spread’ in Data Field (14) Order type). In addition, Data Field (23) for Contract type should be populated with “FW” (in case the underlying contracts are forward contracts). The order may result in a trade, which needs to be linked to the spread order and reported in two trade legs. It is ACER’s understanding that when dealing spread contracts financially settled, transactions are typically represented by one legal agreement. In such a case, Data Field (23) Contract type is expected to be populated with “SP” (‘Spread’). For details please consult Annex II of the TRUM. Guidance on the reporting of Exchange for Physical (EFP) and Exchange for Swaps (EFS) It is ACER’s understanding that exchanges may offer to its clients the possibility to use trade types as Exchange for Physical (EFP) and Exchange for Swap (EFS), standing for:
Such trades are published on the screen with volume and price. The trade type flag identifies that a trade is a block-, an EFP- or an EFS trade, in order to allow the market to understand the differences in the trade types. Transactions related to EFP or EFS shall be flagged in field (23) as FU_EFP, FW_EFP, FU_EFS or FW_EFS respectively. Guidance on reporting the contract type information for LNG supply contracts As described in Annex VIII of the TRUM, LNG supply contracts/transactions can be concluded based on two distinct delivery terms, i.e. on the basis of DES (‘Delivery-ex-ship’) or FOB (‘Free-on-board’). Therefore, the contract type of the reportable LNG contract/ transaction shall be selected in field (23) with reference to the delivery terms applicable to that contract/transaction. For more details, please consult Annex II and Annex VIII of the TRUM. Guidance on the reporting of Power Purchase Agreements (PPAs) When reporting a non-standard contract concluded under a PPA in Table 2, reporting parties shall populate Data field (13) Contract type with one of the values only applicable for PPAs, e.g. FW_PPA, in order to flag in the report that the contract refers to a PPA. When reporting Executions concluded under the non-standard contracts in Table 1, the same information shall be populated in Data Field (23) in Table 1 on the contract type as indicated in the Table 2 report. For more information on how to report PPAs, please see the extra guidance box in Data field (13) Contract type of Table 2 and also the reporting examples provided in Annex II of the TRUM. |
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 |
|
Text | 2 | NG |
This field identifies the energy commodity of the product reported which may be liquefied natural gas or electricity. Other commodities such as emissions rights, coal, oil, etc. are out of scope of REMIT.
Spark spreads involve one leg for the electricity trade and one leg for the gas trade, which has to be reported separately but should be linked by using Data Field (32) Linked Transaction ID. In case of a clean spark spread, the emission leg shall 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, for clean and dirty dark spreads, coal and emissions legs should not be reported. In this case, the electricity trade does not need to be linked to other transactions using 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) Price should be left empty.
Some contracts 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.
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. Since the Agency does not publish a list of publicly available indexes, the Agency recommends that reporting parties use indexes exactly as reported by the publisher.
If the index is not publicly available, 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 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 is based on a formula, e.g. by using a combination of indices and fixed parameters, the contract should be reported in Table 2 and the related actual executions should be reported in Table 1. Example: A market participant buys an electricity forward contract from a counterparty. The contract price is expressed by the following formula/basket index: 50% ELECTRICITY DAILY INDEX BASE SPOT EXCHANGE X + 50% ELECTRICITY MONTH FUTURES BASE EXCHANGE X. The market participant 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 price formula should mimic the index reported and provide information as accurately as possible. The related executions shall be reported using Table 1, indicating a numerical value for price and actual quantities. On the other hand, if the index trade is not subject to a formula, 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 market participant buys an electricity forward contract from a counterparty. The contract does not have a fixed price, but uses the following formula index: EUR 2 / MWh + ELECTRICITY DAILY INDEX BASE SPOT EXCHANGE X. The market participant should report the contract 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. Additional clarifications on the population of Fixing index or reference price in the Table 1 schema In REMITTable1_V3 schema the element “indexName” is present in the contract, order, and trade sections. Any fixing index adopted for fixing the price of a contract has to be indicated in the contract section of the schema. The purpose of the “indexName” element in the order and trade parts of the schema is to specify to which fixing index the values in the “indexCurrValue” element group refer in cases where more than one fixing index is used for fixing the price of the traded contract. It is not mandatory to populate the “indexName” in the order and trade parts of the schema when there is only one fixing index used to fix the price of the contract. |
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 |
|
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/swaps, the option settles into the underlying forward/future/swap. Since the underlying contract is considered for physical delivery the value of “P” should be reported.
Contracts reportable under REMIT are normally for physical delivery in the EU, but there may also be derivative contracts that are not reported under EMIR and 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.2.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 |
|
Alphanumeric |
|
|
This field identifies the organised market place on which the order was placed and the trade concluded.
If the order was placed or the trade concluded 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 concluded off-organised market place, the trade report should indicate “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 the case of continuous trading, trading hours are (in general) the opening and closing times of the specific contract along with any additional restrictions in trading times. In such a case, organised market places shall indicate 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 organised market place.
In the case of exchange traded auction markets, trading hours are in general 00:00Z to 24:00Z unless the exchange has some restrictions on the time from which orders can be placed on a regular day to the date and time at which orders can no longer be placed, i.e. the last trading date and time (Data Field (29)).
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 using 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 those trading hours, 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 market participant can submit orders and when trading can occur. The time shall be reported using UTC time format, thus indicating Z or a time zone offset.
For auction markets (e.g. Day-Ahead or Intraday electricity auctions), specific gate closure times shall be reported. 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 place does not apply a time constraint, this field should be left blank.
As regards bilateral trades which take place outside organised market places, this field shall be left blank.