5.2 Data fields related to contract details

5.2 Data fields related to contract details

This section includes the following fields:

Field No. Field name Non-standard contract
11 Contract ID M
12 Contract date M
13 Contract type M
14 Energy commodity M
15 Price or price formula M*
16 Estimated notional amount M*
17 Notional currency M*
18 Total notional contract quantity M*
19 Volume optionality capacity M*
20 Notional quantity unit M*
21 Volume optionality M*
22 Volume optionality frequency M*
23 Volume optionality intervals M*

M = mandatory; O = optional; - = does not apply; * = conditionally required

Data Field (11) Contract ID

No. Field Identifier Description
11 Contract ID Unique identifier for the contract as assigned by the two market participants.
Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumerical 100 AGHDN15832839

This field identifies the unique contract ID as assigned by the two market participants. For a detailed explanation of how to report the Contract ID market participants should refer to Annex IV which explains how to generate a unique transaction ID. This can also be used to generate a Contract ID. The Agency recommends that market participants use the ACER algorithm available in Annex IV of this manual, unless markets participants agree on their own method of generating a Contract ID.

Data Field (12) Contract date

No. Field Identifier Description
12 Contract date The date the contract was agreed or its modification, cancellation or termination.
Description of Accepted Values Type Length Examples
ISO 8601 date format Date n/a 2014-01-30

This field identifies the contract date on which the contract was agreed.

For the population of the field in case of modification of the contract, please refer to Annex VII.

This field must reflect the actual date as a string representation of the ISO 8601 date format.

Data Field (13) Contract type

No. Field Identifier Description
13 Contract type The type of contract.
Description of Accepted Values Type Length Examples
  • SO=Spot
  • 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

Applicable only for LNG (values not yet available in the REMITTable2 schema):

  • FW_DES = Forward on DES basis
  • FW_FOB = Forward on FOB basis
  • FU_DES = Future on DES basis
  • FU_FOB = Future on FOB basis
  • OP_DES = Option on DES basis
  • OP_FOB = Option on FOB basis
  • SP_DES = Spread on DES basis
  • SP_FOB = Spread on FOB basis
  • SW_DES = Swap on DES basis
  • SW_FOB = Swap on FOB basis

 

Applicable only PPAs (values not yet available in the REMITTable2 schema):

  • SO_PPA = Spot contract concluded under a PPA
  • FW_PPA = Forward contract concluded under a PPA
  • FU_PPA = Future contract concluded under a PPA
  • OP_PPA = Option contract concluded under a PPA
  • SP_PPA = Spread contract concluded under a PPA
  • SW_PPA = Swap contract concluded under a PPA
Text 2 FW

This field identifies the type of contract that is reported. For bilateral contracts 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.

Reporting spreads in Table 2 and in the Table 1 execution report

In case of trading a spread under the framework of a Table 2 non-standard contract, Data Field (13) Contract type is expected to be populated with ‘SP’ for ‘Spread’ for both legs (e.g. for the electricity and for the gas leg in case of a spark spread). In case of execution, the Table 1 report should indicate the contract type of the underlying contracts, e.g. ‘FW’ in case of forwards contracts.

Guidance on reporting the contract type information for LNG supply contracts

As described in Annex VIII of the TRUM, LNG supply contracts 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 shall be selected in field (23) with reference to the delivery terms relevant for that contract.

For more details, please consult Annex II and Annex VIII of the TRUM.

Note: Reporting parties should bear in mind that the above listed values which are applicable only for LNG in Data field (13) are currently not reportable in the REMITTable2 schema due to the ongoing technical implementation. During this period, reporting parties should populate field (13) with one of the currently available accepted values considered the most applicable for the LNG supply contract they intend to report.

Guidance on the reporting of Power Purchase Agreements (PPAs)

It is the Agency’s understanding that contracts under PPAs are considered as non-standard contracts to be reported in Table 2 and following the billing the Executions (specifying an outright volume and price) will have to be reported by no later than 30 days after the invoicing date, using Table 1 of the Annex to REMIT Implementing Regulation. Based on stakeholders’ feedback, PPAs are considered typically as forward contracts concluded between a buyer and a power producer or distributor for the supply of the production of a generation asset agreed bilaterally, usually for a long-term delivery period with predefined commercial conditions, including defined pricing, delivery point and billing and payments conditions.

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. 

Note: Reporting parties should bear in mind that the above listed values applicable which applicable only for contracts related to PPAs in Data field (13) are currently not reportable in the REMITTable2 schema due to the ongoing technical implementation. During this period, reporting parties should populate field (13) with one of the currently available accepted values considered the most applicable for the contract they intend to report.

For more information on how to report PPAs under REMIT, please consult Annex II of the TRUM.

Data Field (14) Energy commodity

No. Field Identifier Description
14 Energy commodity The classification of the energy commodity for the agreed contract.
Description of Accepted Values Type Length Examples
  • NG=Gas
  • LG = Liquified natural gas (not yet available in the REMITTable2 schema)
  • EL=Electricity
Text 2 NG

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

Spreads are not commodities. Clean and Dirty Spark Spreads, for trades that involve both electricity and gas have to be reported separately unless the contract itself includes both commodities in which case both, gas and electricity, should be reported in this field.

Clean and Dirty Dark Spreads, for a trade that involves electricity, coal and emissions should be reported as an electricity contract. Coal and emissions have not to be reported.

Reporting accepted value ‘LG’ in Data field (14)

Note: Reporting parties should note that the above listed value ‘LG’ is currently not reportable in the REMITTable2 schema for Data field (14) due to the ongoing technical implementation. During this period, reporting parties should populate field (14) with ‘NG’ when reporting LNG supply contracts.

Data Field (15) Price or price formula

No. Field Identifier Description
15 Price or price formula Fixed price or price formula used in the contract.
Description of Accepted Values Type Length Examples
  • For Price Up to 20 numerical digits in the format xxxxx.yyyyy with a maximum of 5 decimals.
  • For Formula Up to 1000 alphanumerical digits.
Number Alphanumeric
  • 20
  • 1000
  • 35.00
  • HGSG/HBS*+578HSH

This field identifies the agreed price per unit of energy as expressed in Data Field (20). In case of options, this field represents the premium. If the contract includes a price formula this shall be reported in this field.

If the price is set by an index reported in Data Field (25) without any formula, then Data Field (15) shall be left blank.

The Agency understands that a price formula may be very complex and may not be represented in the same way in the systems of the two counterparties to the contract. When the price formula is very complex, market participants should report a simplified version of the formula. Nevertheless, a clear reference to the used indices is expected to be indicated here by specifying the fixed and variable components with reference to the index or indices reported in field (25).

Data Field (16) Estimated notional amount

No. Field Identifier Description
16 Estimated notional amount Estimated notional amount of the contract (if applicable).
Description of Accepted Values Type Length Examples
Up to 20 numerical digits in the format xxxx.yyyyy with a maximum of 5 decimals. Number 20 53450.00

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

Estimated notional amount = Price x Total notional contract quantity where:

  • Price is defined as the price of the volume as per Data Field (15)
  • Total notional contract quantity is the quantity of energy as per Data Field (18)

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

50 EUR/MWh x 100 MW x 8 h = EUR 40,000

or for a monthly contract:

50 EUR/MWh x 100 MW x 8 h/day x 30 days = EUR 1,200,000

This field should be left blank for contracts that do not have a known (fixed) 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 today 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 option strike price should be used, and not the option premium.

The Agency understands that without a fixed price and/or quantity, market participants will only be able to provide an estimated notional amount.

Where Data Field (18) Total notional contract quantity is not known, this field shall be left blank.

Data Field (17) Notional currency

No. Field Identifier Description
17 Notional currency The currency of the estimated notional amount.
Description of Accepted Values Type Length Examples

ISO 4217 Currency Code, 3 text digits:

  • BGN=Bulgarian lev
  • CHF=Swiss franc
  • CZK=Czech koruna
  • DKK=Danish krone
  • EUR=Euro
  • EUX=Euro cent
  • GBX=Penny sterling
  • GBP=Pound sterling
  • HUF=Hungarian forintI
  • 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 (15) (price) and/or (16) (estimated notional amount). The notional currency shall be provided in the major unit, e.g. EURO rather than EURO cent and GBP rather than GB pence.

The reason for reporting the major unit is, 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 and it may be more appropriate to have GBP 1,000,000 rather than GBX. 100,000,000.

If Data Field (15) (Price) and (16)(Estimated notional amount) is blank, this field should be left blank.

Data Field (18) Total notional contract quantity

No. Field Identifier Description
18 Total notional contract quantity The estimated 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 xxxx.yyyyy with a maximum of 5 decimals. Number 20 1000

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

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

  • Volume is the quantity of energy as per Data Field (19) volume optionality capacity (if available)
  • Number of periods is the number of times that quantity is delivered / received

For example, a contract traded for a volume of 100 MW delivered for 8 hours would have the following total notional contract quantity:

100 MW x 8h = 800 MWh

or for a monthly contract:

100 MW x 8h x 30days = 240,000 MWh

In case the above mentioned two elements of the formula are defined/known by the contract (especially if the volume classification of the capacity is indicated as ‘F’ for ‘Fix’ in Data Field (21) Volume optionality), reporting parties are expected to perform the calculation of the TNCQ of the contract and report it in Data Field (18).

The Agency understands that without a defined quantity market participants will be only able to provide an estimated notional contract quantity, e.g. in case when the volume optionality is indicated as Min/Max in Data Field (21).  

Where the total notional contract quantity is not known, this field may be left blank. This scenario may be applicable primary when the volume optionality is indicated as Complex or Variable in Data Field (21). Nevertheless, providing an estimated TNCQ also in these scenarios always gives an added value to the transaction report.

Data Field (19) Volume optionality capacity

No. Field Identifier Description
19 Volume optionality capacity The number of units included in the contract, per delivery time interval if available.
Description of Accepted Values Type Length Examples
Up to 20 alphanumerical digits. Alphanumeric 20 100/200

This field identifies the number of units included in the contract per delivery time interval if available.

For example, if the non-standard contract has optionality identifying the capacity per time interval, this should be reported in this field. Please see examples available in Annex II. 

Data Field (20) Notional quantity unit

No. Field Identifier Description
20 Notional quantity unit The unit of measurement used in fields 18 and 19.
Description of Accepted Values Type Length Examples

For field 18:

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

For field 19:

  • 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
Text 2 to 8 MWh

This field must identify the unit used for the reported quantity in Data Field (18) (total notional contract quantity) and Data Field (19) (volume optionality capacity). Where the units for Data Field (18) and Data Field (19) differ, the two different quantity units should be provided.

Data Field (21) Volume optionality

No. Field Identifier Description
21 Volume optionality The volume classification.
Description of Accepted Values Type Length Examples
  • V=Variable
  • F=Fix
  • M=Min/Max
  • C=Complex
  • O=Other
Text 1 F

This field identifies the type of volume classification of the capacity indicated in Data Field (19). This is a representation of the flexibility of the contract capacity.

For example, it refers to the volume classification such as variable “V” (e.g. unbound variable capacity), fix “F” (e.g. 100), min/max “M” (e.g. 100 to 200), complex “C” (e.g. 0 [zero] or 100 to 200) or other “O” (e.g. 0 or 200). Please see the examples in Annex II.

When Data Field (21) is populated with “V”, “M”, “C” and “O”, then Data Field (22) is expected to be populated.

Volume optionality: Complex

In the Agency’s point of view, “C” for Complex should in general cover all the cases where the volume optionality cannot be classified as one of the non-complex options (i.e. Variable, Fix or Min/Max).

Data Field (22) Volume optionality frequency

No. Field Identifier Description
22 Volume optionality frequency The frequency of the volume optionality: e.g. daily, weekly, monthly, seasonal, annual or other, if available.
Description of Accepted Values Type Length Examples
  • X=Half hourly
  • H=Hourly
  • D=Daily
  • W=Weekly
  • M=Monthly
  • Q=Quarterly
  • S=Season
  • A=Annual
  • O=Other
Text 1 Q

This field identifies the frequency of the volume optionality as indicated in Data Field (19). This is a representation of how frequently the capacity of the non-standard contract can be “flexed”.

For example, it refers to the hourly, daily, weekly, monthly, seasonal, annual or other volume optionality frequency as specified in the table above. It does not specify the exact dates and times when the contract capacity can be changed, but only the frequency that the capacity can be adjusted.  

Data Field (23) Volume optionality intervals

No. Field Identifier Description
23 Volume optionality intervals Time interval for each volume optionality if available.
Description of Accepted Values Type Length Examples
ISO 8601 date format Date n/a 2014-01-01 / 2014-03-31

This field identifies the time interval for each volume optionality, as indicated in Data Field (19), that the market participant of the non-standard contract can adjust the volume capacity.

Reporting volume optionality intervals

Whenever field (19) Volume optionality capacity must be reported, then field (23) becomes mandatory and both fields (19) and (23) have to be reported within the <volumeOptionalityIntervals> element in the schema.

Field (23) consists of <startDate> and <endDate>  fields in the schema. If for some reasons, the startDate and endDate is not applicable (not known), then 1900-01-01 should be used for both fields to indicate that no volume optionality intervals are available. /li>

Updated: 
13/03/2024