Please insert at least 3 characters

TRUM – Section 5

Reporting of non-standard supply contracts

Reporting entities shall provide the details set out in Table 2 of the Annex to the Implementing Acts in relation to non-standard supply contracts. However, it is important to note that details of transactions executed within the framework of non-standard supply contracts specifying at least an outright volume and price shall be reported using Table 1 of the Annex to the Implementing Acts.

In this Chapter, the Agency provides information on how the data fields listed in Table 2 of the Annex to the Implementing Acts should be populated. In subsequent editions of the TRUM, the Agency may also provide further guidance on how to report non-standard supply contracts.

It is worth noting that not all the data fields are mandatory for all transactions. Data fields are expected to be populated when applicable according to this manual. However, additional information may be reported at the discretion of Market Participants. The Agency has prepared an extensive, but not exhaustive, list of trading scenarios, to show what is expected and applicable to each scenario. The trading scenarios are listed in ANNEX II.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 5.1

Data fields related to the parties to the contract

This section includes the following fields:

1. ID of the market participant or counterparty
2. Type of code used in field 1
3. ID of the other market participant or counterparty
4. Type of code used in field 3
5. Reporting entity ID
6. Type of code used in field 5
7. Beneficiary ID
8. Type of code used in field 7
9. Trading capacity of the market participant or counterparty in field 1
10. Buy/sell indicator

 

Data Field No (1) ID of the market participant or counterparty

No. Field Identifier Description
1 ID of the market participant or counterparty The market participant or counterparty on whose behalf the record of transaction is reported shall be identified by a unique code.

 

Description of Accepted Values Type Length Examples
ACER code
LEI
BIC
EIC
GLN/GS1 code
Alphanumerical 12
20
11
16
13
C0643278W.EU
1a2b3c4d5e6f7g8e9f0h
ACERSILJ500
10YCB-EUROPEU–8
a1b2c3d4e5f6g

 

This field aims to capture the ID of the market participant or counterparty on whose behalf the transaction is reported.

As REMIT uses the term market participant and EMIR uses the term counterparty to identify the reporting party, both terms are used in this context for the purpose of reporting. Thus, for the purpose of reporting, counterparty is considered equivalent to the market participant when entering into transaction on wholesale energy markets. The other market participant is referred to as the “other counterparty” (see field 4). Counterparty and the other counterparty are therefore considered equivalent of market participant and the other market participant for the purpose of reporting under REMIT.

Registration of market participants with the relevant NRA will result in an ACER code. However, if a third party is reporting on behalf of the market participant the ACER code may not be known. If the ACER code has not been provided by the market participant to the third party reporting on behalf of the market participant, one of the alternative codes listed above shall be used otherwise the report will be rejected as invalid.

The market participant or counterparty shall be identified by the unique code registered with their NRA. If the market participant has several or all the codes listed in field 1, all of them have to be provided when registering with the NRA.

From the Agency’s perspective, the ACER code is the preference but all the other codes may also be used. If a market participant is already using the LEI for EMIR reporting that market participant may use the LEI code also for REMIT reporting as long as the LEI has been provided to the NRAs in the registration process.

If a market participant is using an ACER code, the market participant/counterparty will be able to verify the identity of the other market participant from the European register of market participants published by the Agency and available at the Agency’s website.

 

Data Field No (2) Type of code used in field 1

No. Field Identifier Description
2 Type of code used in field 1 ACER registration code, Legal Entity Identifier (LEI),Bank Identifier Code (BIC), Energy Identification Code (EIC), Global Location Number (GLN/GS1)

 

Description of Accepted Values Type Length Examples
ACER code
LEI
BIC
EIC
GLN/GS1 code
Text 3
3
3
3
3
ACE
LEI
BIC
EIC
GLN

 

This field identifies the type of code used in field 1. For example, if an LEI code is used to identify the market participant in field 1 (e.g. 1a2b3c4d5e6f7g8e9f0h), the accepted value in field 2 is “LEI”. If an ACER code is used in field 1 (e.g. C0643278W.EU), the accepted value is “ACE”. The same principle applies to BIC, EIC and GLN/GS1 codes.

 

Data Field No (3) ID of the other market participant or counterparty

No. Field Identifier Description
3 ID of the other market participant or counterparty Unique identifier for the other counterparty of the contract.

 

Description of Accepted Values Type Length Examples
ACER code
LEI
BIC
EIC
GLN/GS1 code
Alphanumeric 12
20
11
16
13
C0643278W.EU
1a2b3c4d5e6f7g8e9f0h
ACERSILJ500
10YCB-EUROPEU–8
a1b2c3d4e5f6g

 

This field indicates the ID of the other market participant or counterparty to the transaction that is reported.

 

Data Field No (4) Type of code used in field 3

No. Field Identifier Description
4 Type of code used in field 3 ACER registration code, Legal Entity Identifier (LEI),Bank Identifier Code (BIC), Energy Identification Code (EIC), Global Location Number (GLN/GS1)

 

Description of Accepted Values Type Length Examples
ACER code
LEI
BIC
EIC
GLN/GS1 code
Text 3
3
3
3
3
ACE
LEI
BIC
EIC
GLN

 

This field identifies the type of code used in field 3. For example, if an LEI code of the market participant is used in field 2 (e.g. 1a2b3c4d5e6f7g8e9f0h), the accepted value in field 3 is “LEI”. If an ACER code is used in field 2 (e.g. C0643278WY.EU), the accepted value is “ACE”. The same principle applies to BIC, EIC and GLN/GS1 codes.

 

Data Field No (5) Reporting entity ID

No. Field Identifier Description
5 Reporting entity ID ID of the reporting entity.

 

Description of Accepted Values Type Length Examples
ACER code
LEI
BIC
EIC
GLN/GS1 code
Alphanumeric 12
20
11
16
13
C0643278W.EU
1a2b3c4d5e6f7g8e9f0h
ACERSILJ500
10YCB-EUROPEU–8
a1b2c3d4e5f6g

 

This field indicates the ID of the reporting entity who submits the transaction report to the Agency on behalf of the market participant as identified in field 1. This entity is also known as a Registered Reporting Mechanism (RRM), which can be an energy exchange, a broker, a third party reporting on behalf of a market participant or the market participant itself in the case of a bilateral trade. If the reporting party is a market participant, then the ACER code or one of the unique codes that were registered with the NRA should be used.

 

Data Field No (6) Type of code used in field 5

No. Field Identifier Description
6 Type of code used in field 5 ACER registration code, Legal Entity Identifier (LEI),Bank Identifier Code (BIC), Energy Identification Code (EIC), Global Location Number (GLN/GS1)

 

Description of Accepted Values Type Length Examples
ACER code
LEI
BIC
EIC
GLN/GS1 code
Text 3
3
3
3
3
ACE
LEI
BIC
EIC
GLN

 

This field identifies the type of code used in field 5. For example, if an LEI code of the reporting entity is used in field 5 (e.g. a2b3c4d5e6f7g8e9f0h), the accepted value in field 6 is “LEI”. If an ACER code is used in field 5 (e.g. C0643278WY.EU), the accepted value is “ACE”. The same principle applies to BIC, EIC and GLN/GS1 codes.

 

Data Field No (7) Beneficiary ID

No. Field Identifier Description
7 Beneficiary ID If the beneficiary of the contract as referred in Article 8(1) of Regulation (EU) No 1227/2011 is counterparty to this contract the field is to be left blank. If the beneficiary of the contract is not counterparty to this contract the reporting counterparty has to identify the beneficiary by a unique code.

 

Description of Accepted Values Type Length Examples
ACER code
LEI
BIC
EIC
GLN/GS1 code
Alphanumeric 12
20
11
16
13
C0643278W.EU
1a2b3c4d5e6f7g8e9f0h
ACERSILJ500
10YCB-EUROPEU–8
a1b2c3d4e5f6g

 

This field indicates the ID of the beneficiary of the transaction in case the trade is executed by a third party on behalf of a market participant. If the beneficiary of the contract is the market participant entering into the transaction, this field is to be left blank. If the beneficiary of the contract is not counterparty to this contract, e.g. the market participant is acting on behalf of another market participant, the reporting counterparty has to identify the beneficiary by a unique code.

For example, if party B is trading on behalf of party C, then party C is the beneficiary and party B is acting on behalf of C. As party B enters into a transaction on wholesale energy products, or places an order to trade, party B is a market participant, unless party B always acts only as an agent. If party B always acts as an agent, in this case, it would not be a market participant according to REMIT and not appear in the report. If this is the case, the ID of C should be reported in field 1 and this field shall be left blank.

Bilateral transactions with a beneficiary may look like as (A) sells to (B) with beneficiary (C). In these cases the Agency will receive one reported trade: (A) sells to (B) with (C) identified in field 8 as Beneficiary.

However, the trade may be even more complicated and it may involve more parties. For example if a bilateral trade takes place between (A) and (B) there may be other trades between (B) and (C) and (D) to represent how they split the value of the (A) and (B) trade.

There may be many situations where the beneficiary may or may not be known and there are many possible scenarios. Market participants and reporting parties should bear in mind that it is their responsibility to contact the Agency to discuss their scenarios not represented in this manual.

 

Data Field No (8) Type of code used in field 7

No. Field Identifier Description
8 Type of code used in field 7 ACER registration code, Legal Entity Identifier (LEI),Bank Identifier Code (BIC), Energy Identification Code (EIC), Global Location Number (GLN/GS1)

 

Description of Accepted Values Type Length Examples
ACER code
LEI
BIC
EIC
GLN/GS1 code
Text 3
3
3
3
3
ACE
LEI
BIC
EIC
GLN

 

This field identifies the type of code used in field 7. For example, if an LEI code of the reporting entity is used in field 7 (e.g. a2b3c4d5e6f7g8e9f0h), the accepted value in field 8 is “LEI”. If an ACER code is used in field 7 (e.g. C0643278WY.EU), the accepted value is “ACE”. The same principle applies to BIC, EIC and GLN/GS1 codes.

 

Data Field No (9) Trading capacity of the market participant or counterparty in field 1

No. Field Identifier Description
9 Trading capacity of the market participant or counterparty in field 1 Identifies whether the reporting counterparty has concluded the contract as principal on own account (on own behalf or behalf of a client) or as agent for the account of and on behalf of a client.

 

Description of Accepted Values Type Length Examples
P=Principal
A=Agent
Text 1 P

 

This field identifies the trading capacity of the market participant or counterparty in field 1. Unless the market participant is acting on behalf of a third party as an agent, this field shall be populated with “P” for Principal.

If the market participant is acting on behalf of a third party as an agent and the beneficiary identification is known and reported in field 76, this field may be populated with “A” for Agent.

The Agency understands that the terms Principal and Agent is a term commonly used in the financial markets and it depends if an investment firm enters into a transaction as principal or agent (depending on their business model). The Agency expects that market participants may enter into transaction:

a. acting on their own account and on their own behalf (pure principal transaction – i.e. on the decision of the firm);

b. acting on their own account and on behalf of a client – i.e. on the order of other market participant; and/or

c. acting for the account and on behalf of a market participant (pure agency transaction).

Market participants should bear in mind that the meaning of entering into a transaction under EMIR is different to the meaning of entering into a transaction under REMIT, where the latter refers to entering into a transaction in “wholesale energy markets” and not being counterparty to the contract, such as CCPs or clearing members.

 

Data Field No (10) Buy/sell indicator

No. Field Identifier Description
10 Buy/sell indicator Identifies whether the contract was a buy or sell for the market participant or counterparty identified in field 1.

 

Description of Accepted Values Type Length Examples
B=Buy
S=Sell
C=Buy and Sell
Text 1 B

 

The Buy/sell indicator indicates whether the market participant is reporting a transaction for the buying or selling of a contract. “B” shall be indicated for buy and “S” shall be indicated for sell to display whether the transaction was a buy or a sell from the perspective of the reporting market participant or, in the case of an agent (e.g. executing broker) transaction, of the client.

For a trade transaction this should indicate the side of the matched trade for the market participant; a buyer or a seller. For an order transaction, this should indicate whether the market participant indicated to buy or sell the contract that the order transaction was placed on. However, in some auction markets there may be circumstances where an order is either buy or sell. In such a case, this is identified by specifying a combined buy and sell indicator, i.e. “C”.

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 case of a fix to floating derivative, if party (A) buys a swap, then party (A) pays a fixed price and party (B) pays a floating price. This means that party (A) receives the floating leg and party (B) receives the fix leg. In case of a floating to floating derivative, if party (A) buys a swap, party (A) pays the floating price of the first leg (or index) and party (B) pays the floating price of the second leg (or second index). In this case the two legs (indexes) of the swap should be sorted alphabetically.

For example, if party (A) and party (B) enter into a swap transaction where the financial settlement is the difference between two floating indexes “XYZ Index” and “ABC Index”, (A) is the buyer of the swap if (A) pays the floating price of ABC Index and receives the floating price of XYZ Index while (B) is the seller of the swap as (B) receives the floating price of ABC Index and pays the floating price of XYZ Index.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 5.2

Data fields related to contract details

This section includes the following fields:

1. Contract  ID
2. Contract date
3. Contract type
4. Energy commodity
5. Price or price formula
6. Estimated notional amount
7. Notional currency
8. Total notional contract quantity
9. Volume optionality capacity
10. Notional quantity unit
11. Volume optionality
12. Volume optionality frequency
13. Volume optionality intervals

 

Data Field No (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 No (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. This field must reflect the actual date as a string representation of the ISO 8601 date format.

 

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

 

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

 

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

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.

 

Data Field No (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:

Notional Amount = Price x Total notional contract quantity where:

 

  • Price is defined as the price of the volume as per field 15
  • Total notional contract quantity is the quantity of energy as per field 18

 

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

€50 x 100(MW) x 8(h) = €40,000
or for a monthly contract:
€50 x 100(MW) x 8(h/day) x 30(days) = €1,200,000

This field should be left blank for contracts 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 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 defined price and quantity, market participants will only be able to provide an estimated notional amount that may differ between the two counterparties.

 

Data Field No (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
HRK=Croatian kuna
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 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 GBp. 100,000,000.

If field 15 (price) and 16 (estimated notional amount) is blank, this field should be left blank.

 

Data Field No (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 = Volume x number of periods, where:

  • Volume is the quantity of energy as per 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

The Agency understands that without a defined quantity market participants will be only able to provide an estimated notional contract quantity that may differ from between the market participants.

Where the total notional contract quantity is not known this field shall be left blank.

 

Data Field No (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 No (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 field 18 (total notional contract quantity) and field 19 (volume optionality capacity). Where the units for field 18 and field 19 differ, the two different quantity units should be provided.

 

Data Field No (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 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”. Please see the examples in Annex II.

 

Data Field No (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 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 No (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 field 19, that the market participant of the non-standard contract can adjust the volume capacity.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 5.3

Data fields related to fixing index details

This section includes the following fields:

24. Type of index price
25. Fixing index
26. Fixing index types
27. Fixing index sources
28. First fixing date
29. Last fixing date
30. Fixing frequency
31. Settlement method

 

Data Field No (24) Type of index price

No. Field Identifier Description
24 Type of index price Price classified as fixed, simple index (single underlying) or complex price formula (multiple underlying).

 

Description of Accepted Values Type Length Examples
F=Fixed
I=Simple Index
C=Complex Price Formula
O=Other
Text 1 C

 

This field identifies the type of index or reference price used to sett the price of the contract. Some contracts, both derivatives and non- derivatives, related to the 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. The price can be classified as fixed “F” when the contract has a fix price (e.g. EUR 50.60), simple index “I” (e.g. a single underlying) or complex price formula (multiple underlyings used in a formula). In case none of the above applies, other “O” shall be used.

 

Data Field No (25) Fixing index

No. Field Identifier Description
25 Fixing index List of indices determining the price in the contract. For each Index specify the name. In case of a basket of indices for which no unique identifier exist the basket or the index shall be indicated.

 

Description of Accepted Values Type Length Examples
Up to 150 alphanumerical digits. Alphanumeric 150 EUGAS day-ahead Publisher Name

 

This field identifies the name of the fixing index used to set the price of the transactions executed under the contract. Market participants shall report the name of the fixing index in this field and where the contract has several fixing indexes each of them should be reported in this field.

As the Agency does not intend to publish a list of indexes because most of them are publicly available and can be readily accessed, the Agency recommends that reporting parties use those indexes exactly as advertised by the publisher.

If the index is not public, then market participants should make best efforts to minimise any discrepancy with the other market participant when reporting this information.

 

Data Field No (26) Fixing index types

No. Field Identifier Description
26 Fixing index types Spot, forward , swap, spread, etc.

 

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
Text Up to 5 FW

 

This field identifies the type of fixing index indicated in field 25 used in the contract that is being reported. Where the contract has several type of fixing index each of them should be reported in this field.

For example, if the index is a spot price published by an exchange the “SO” value shall be reported. If the index is published by a price reporting agency or other publisher and it represents the delivery of the energy commodity during the course of a specific day, week, weekend, month etc., then the “FW” value shall be reported. If the index is a future price published by an exchange the “FU” value shall be reported.

 

Data Field No (27) Fixing index sources

No. Field Identifier Description
27 Fixing index sources For each index specify the publication source. In case of basket of indices for which no unique identifier exist the basket or the index shall be indicated.

 

Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 Index Source Name

 

This field identifies the source of the fixing index/indexes used in field 25 (fixing index). Where the contract has several sources for the fixing indexes each source should be reported in this field.

For each index reported in field 25 (fixing index), market participants shall specify the publication source of each index. In the case of a basket of indices for which no unique publisher exists, market participants shall report all sources of the basket of indices.

For example, if in field 25 the index “EU-GAS-CALENDAR-YEAR-2015-PUB-NAME” is reported, the market participants shall report the source of the publication of the index, e.g. the EU-GAS-PRICES-PUB-NAME and the publisher name e.g. PUB-NAME, needed to identify where the index is published. This applies to each individual index reported in field 25.

For example, if in field 25 is reported the “EU-GAS-CALENDAR-YEAR-2015-PUB-NAME-ABC” index and “EU-GAS-CALENDAR-YEAR-2015-PUB-NAME-123” index, market participants shall report the source of the publication for both i.e. “PUB-NAME-ABC” and PUB-NAME-123”.

 

Data Field No (28) First fixing date

No. Field Identifier Description
28 First fixing date First fixing date determined by the earliest date of all the fixings.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format Date n/a 2024-01-29

 

This field identifies the first date at which the price of the contract can be set using the index indicated in field 25 (fixing index).

If the contract has several indexes and each of them may be used to set the contract price, market participants shall report the first date at which the price of the contract can be fixed for each index reported in field 25 (fixing index).

For example:

1. index ABC may be used to fix the contract price from 01/01/2015 to 31/12/2017;

2. index 123 may be used to fix the contract price from 01/04/2015 to 31/03/2018; and

3. index XYZ may be used to fix the contract price from 01/04/2016 to 31/03/2019.

In this case market participants shall report 01/01/2015, 01/04/2015 and 01/04/2016 for this field.

 

Data Field No (29) Last fixing date

No. Field Identifier Description
29 Last fixing date Last fixing date determined by the latest date of all the fixings.
Description of Accepted Values Type Length Examples
ISO 8601 date format Date n/a 2034-01-29

 

This field identifies the last date at which the price of the contract can be fixed using the index indicated in field 25 (fixing index).

In the contract has several indexes and each of them may be used to set the contract price, market participants shall report the last date at which the price of the contract can be fixed for each index reported in field 25 (fixing index).

For example:

4. index ABC may be used to fix the contract price from 01/01/2015 to 31/12/2017;

5. index 123 may be used to fix the contract price from 01/04/2015 to 31/03/2018; and

6. index XYZ may be used to fix the contract price from 01/04/2016 to 31/03/2019.

In this case 31/12/2017, 31/03/2018 and 31/03/2019 shall be reported for in this field.

 

Data Field No (30) Fixing frequency

No. Field Identifier Description
30 Fixing frequency The frequency the fixing: e.g. daily, weekly, monthly, seasonal, annual or other.

 

Description of Accepted Values Type Length Examples
X=Half hourly
H=Hourly
D=Daily
W=Weekly
M=Monthly
Q=Quarterly
S=Seasonal
A=Annual
O=Other
Text 1 W

 

This field identifies the frequency of the fixing of the index for the contract price.

For example, it refers to the daily, weekly, monthly, seasonal, annual or other frequency as specified in the table above. It does not specify the exact dates and times when the fixing occurs but its frequency.

For example, a contract price can be set on the basis of an index that is used daily or a contract price can be set on the basis of an index that it is used monthly.

 

Data Field No (31) Settlement method

No. Field Identifier Description
31 Settlement method Whether the contract is settled physically, in cash, both, 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 contract such as option on futures or swaps, as they settle into the underlying 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 point 3.3.3 of this document.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 5.4

Data fields related to option details

This section includes the following fields:

32. Option style
33. Option type
34. Option first exercise date
35. Option last exercise date
36. Option exercise frequency
37. Option strike index
38. Option strike index type
39. Option strike index source
40. Option strike price

 

Data Field No (32) Option style

No. Field Identifier Description
32 Option style Indicates whether the option may be exercised at a fixed date (European and Asian style), a series of pre-defined dates (Bermudan) or at any time during the life of the contract (American).

 

Description of Accepted Values Type Length Examples
A=American
B=Bermudan
E=European
S=Asian
O=Other
Text 1 B

 

This field identifies the option style, usually defined by the dates on which the option may be exercised: American, European, Bermudian, Asian or other style.

An American style option can be exercised anytime during its life allowing option holders to exercise the option at any time prior to and including its maturity date. A European style option can only be exercised at the maturity date. A Bermudian style option can only be exercised on specified dates indicated in the contract.

Reporting parties should refer to financial markets in order to identify the option style they are reporting. The reporting of exotic option styles such as binary, barrier, window options, etc., it should be reported with the value of “O”.

 

Data Field No (33) Option type

No. Field Identifier Description
33 Option type Indicates whether the option is a call, put or other.

 

Description of Accepted Values Type Length Examples
P=Put
C=Call
O=Other
Text 1 C

 

This field identifies the type of right the option holder owns, if it is a call option or a put option. “P” shall be indicated if the option is a put option and “C” shall be indicated if the option is a call option. If the option holder owns a type of right different from a put or a call, the value “O” for other shall be reported in this field.

Reporting parties should refer to financial markets in order to identify the option style they are reporting.

 

Data Field No (34) Option first exercise date

No. Field Identifier Description
34 Option first exercise date First exercise date determined by the earliest date of all the exercises.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format Date n/a 2014-01-29

 

This field identifies the first date at which the option holder has the right, but not the obligation, to buy or sell the commodity or underlying instrument at a specified price using the index indicated in field 37 (option strike index) or the price as reported in field 40 (Option strike price).

For example, the counterparty to the contract that holds the option may exercise against the option strike index indicated in field 37, the right to buy or sell the energy commodity from 01/01/2015 to 31/12/2017 (on specific dates or at specific intervals), the market participant shall report 01/01/2015 in this field.
Where the contract has several indexes and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report the first date at which the option can be exercised per each index reported field 37 (option strike index). For example:

1. index ABC may be used to exercise the option from 01/01/2015 to 31/12/2017;

2. index 123 may be used to exercise the option from 01/04/2015 to 31/03/2018; and

3. index XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019.

In this case 01/01/2015, 01/04/2015 and 01/04/2016 shall be reported in this field.

 

Data Field No (35) Option last exercise date

No. Field Identifier Description
35 Option last exercise date Last exercise date determined by the latest date of all the exercises.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format Date n/a 2024-01-29

 

This field identifies the last date at which the option holder has the right, but not the obligation, to buy or sell the commodity or underlying instrument at a specified price using the index indicated in field 37 (option strike index) or the price as reported in field 40 (Option strike price).

For example, a counterparty to the contract that holds the option may exercise, against the option strike index indicated in field 37, the right to buy or sell the energy commodity from 01/01/2015 to 31/12/2017 (on specific dates or at specific intervals), the market participant shall report 31/12/2017 in this field.

Where the contract has several indexes and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report the last date at which the option can be exercised per each index reported field 37 (option strike index). For example:

1. index ABC may be used to exercise the option from 01/01/2015 to 31/12/2017;

2. index 123 may be used to exercise the option from 01/04/2015 to 31/03/2018; and

3. index XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019.

In this case 31/12/2017, 31/03/2018 and 31/03/2019 shall be reported in this field.

 

Data Field No (36) Option exercise frequency

No. Field Identifier Description
36 Option exercise frequency The frequency of the Volume optionality: e.g. daily, weekly, monthly, seasonal, annual or other.

 

Description of Accepted Values Type Length Examples
D=Daily
W=Weekly
M=Monthly
S=Seasonal
A=Annual
O=Other
Text 1 W

 

This field identifies the frequency at which  the option holder has the right, but not the obligation, to buy or sell the commodity or underlying instrument at a specified price using the index indicated in field 37 (option strike index) or the price as reported in field 40 (Option strike price).

For example, a counterparty to the contract that holds the option may exercise, against the option strike index indicated in field 37, the right to buy or sell the energy commodity on monthly basis, the market participant shall report “M” in this field. Same applies to the other type of frequencies.

Where the contract has several indexes and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report frequency at which the option can be exercised per each index reported field 37 (option strike index). For example:

1. index ABC may be used to exercise the option from 01/01/2015 to 31/12/2017 on a daily basis;

2. index 123 may be used to exercise the option from 01/04/2015 to 31/03/2018 on a monthly basis; and

3. index XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019 on a weekly basis.

In this case “D”, “M” and “W” shall be reported in this field

 

Data Field No (37) Option strike index

No. Field Identifier Description
37 Option strike index For each Index specify the name. In case of a basket of indices for which no unique identifier exist the basket or the index shall be indicated.

 

Description of Accepted Values Type Length Examples
Up to 150 alphanumerical digits. Alphanumeric 150 Index Name

 

This field identifies the name of the strike index used in the index option embedded in the contract. Market participants shall report the name of the index in this field.

An index option is a call or put option contract in which the underlying asset is an index of any sort. For example, in a call, a market participant may buy the right to an index on or before the expiration date at a certain strike index.

Some options, both derivatives and non-derivatives, related to physical delivery of gas or electricity are traded on the basis that the option may be exercised against an index or reference price upon its publication.

As the Agency does not intend to publish a list of indexes because most of them are publicly available and can be readily accessed, the Agency recommends that reporting parties use those indexes exactly as advertised by the publisher.

If the index is not public, than market participants should make best efforts to minimise any discrepancy with the other market participant when reporting this information. Market participants may consider using the following convention:

[commodity]-[delivery area]-[delivery period]-[index name]-[publisher name]

1. GAS-NBP-DAYAHEAD-INDEX-PUBLISHERNAME

2. GAS-EU- FRONTMONTH-AVERAGEPRICE-PUBLISHERNAME

3. ELECTRICITY-GERMANY-FRONTMONTH-FUTURE-EXCHANGENAME

 

Data Field No (38) Option strike index type

No. Field Identifier Description
38 Option strike index type Spot, forward , swap, spread, etc.

 

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
Text 2 FW

 

This field identifies the type of strike index of the option used in the contract as reported in field 37.  For each index, market participants shall specify the type of index.

For example, if the index is a spot price published by an exchange the “SO” value shall be reported.
If the index is published by a price reporting agency or other publisher and it represents the delivery of the energy commodity during the course of a specific day, week, weekend, month etc., than the “FW” value shall be reported. If the index is a future price published by an exchange the “FU” value shall be reported.

Where the contract has several indexes and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report the type of index used against which the option can be exercised per each index reported field 37 (option strike index). For example:

1. the spot price published by Exchange ABC may be used to exercise the option from 01/01/2015 to 31/12/2017;

2. the index value for a forward contract published by Publisher 123 may be used to exercise the option from 01/04/2015 to 31/03/2018; and

3. future price published by Exchange XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019.

In this case “SO”, “FW” and “FU” shall be reported in this field.

 

Data Field No (39) Option strike index source

No. Field Identifier Description
39 Option strike index source For each index specify the fixing type. In case of a basket of indices for which no unique identifier exist the basket or the index shall be indicated.

 

Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 Index Source Name

 

This field identifies the source of strike index of the option used in the contract as reported in field 37 (option strike index).  For each index, market participants shall specify the source of index.

For example, if the index is a spot price published by Exchange ABC, the name of the exchange shall be reported. If the index is published by a price reporting agency or other publisher, then the name of the publisher shall be reported.

Where the contract has several indexes and where each of them may be used to exercise the option, market participants shall report the source of each index reported in field 37 (option strike index) against which the option can be exercised. For example:

1. the spot price published daily by the Exchange ABC may be used to exercise the option from 01/01/2015 to 31/12/2017;

2. the index value for a forward contract published by Publisher 123 may be used to exercise the option from 01/04/2015 to 31/03/2018; and

3. future price published by the Exchange XYZ may be used to exercise the option from 01/04/2016 to 31/03/2019.

In this case “Exchange ABC”, “Publisher 123” and “Exchange XYZ” shall be reported in this field.

 

Data Field No (40) Option strike price

No. Field Identifier Description
40 Option strike price The strike price of the option.

 

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 125.98

 

This field identifies the price at which the owner of the option can buy (in the case of a call option), or sell (in the case of a put option), the energy commodity (gas or electricity) or the instrument as indicated in the option contract, e.g. future/forward/swap.

This field shall be reported only if the strike price is available. In the case of an option strike index where the strike price is not available this field should not be blank.

Where the option has several strike prices and where each of them may be used to exercise the right to buy or sell the energy commodity, market participants shall report all the strike prices at which the option can be exercised.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 5.5

Data fields related to delivery profile

This section includes the following fields:

41. Delivery point or zone
42. Delivery start date
43. Delivery end date
44. Load type

 

Data Field No (41) Delivery point or zone

No. Field Identifier Description
41 Delivery point or zone EIC code(s) for the delivery point(s) or market area(s).

 

Description of Accepted Values Type Length Examples
EIC Y code, 16 character alphanumeric code. Alphanumeric 16 10YCB-EUROPEU–8

 

This field identifies the commodity delivery point or zone. This field shall report the EIC Y code (or an alternative code to be agreed with the Agency if the EIC is not available) to identify the delivery and/or balancing point for the contract.

Example: A contract for the supply of gas at the NBP hub (GB market) will report the EIC Y code to identify that balancing area. A contract for the supply of electricity in the German-Austrian area shall be reported using the EIC Y code to identify the balancing area where the supplier/consumer is located which in this case can be either in Germany or Austria.

However, because gas can also be delivered at the interconnection point, then the EIC-Z Code for that interconnector maybe used.

 

Data Field No (42) Delivery start date

No. Field Identifier Description
42 Delivery start date Start date and time of delivery. For physically delivered contracts this would be the delivery start date of the contract.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format Date n/a 2014-01-29

 

This field identifies the date that delivery of the commodity under the reported contract starts.

 

Data Field No (43) Delivery end date

No. Field Identifier Description
43 Delivery end date End date and time of delivery. For physically delivered contracts this would be the end delivery date of the contract.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format Date n/a 2014-01-29

 

This field identifies the end date of delivery of the commodity under the reported contract.

 

Data Field No (44) Load type

No. Field Identifier Description
44 Load type Identification of the delivery profile (base load, peak load, off-peak, block of hours or other).

 

Description of Accepted Values Type Length Examples
BL=Base load
PL=Peak load
OP=Off-Peak load
BH=Hour/Block Hours
SH =Shaped
GD=Gas Day
OT=Other
Text 2 BL

 

This field identifies the delivery profile (base load, peak load, off-peak, block of hours or other) of the contract. The load type should be identified as defined in the contract if available. If a delivery profile is not defined in the contract, market participants shall report “OT” for other.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 5.6

Data fields related to lifecycle information

This section includes the following fields:

45. Action type

 

Data Field No (45) Action type

No. Field Identifier Description
45 Action type When the report contains:
– a contract reported for the first time, it will be identified as ‘new’;
– a modification of details of a previously reported contract, it will be identified as ‘modify’;
– a cancellation of a wrongly submitted report, it will be identified as ‘error’;
– a termination of an existing contract, it will be identified as ‘cancel’.

 

Description of Accepted Values Type Length Examples
N=New
M=Modify
E=Error
C=Cancel
Text 1 N

 

This field identifies the type of action regarding the event that is being reported.

The first submission of a transaction to the Agency of a bilateral contract is an event which will be identified as “new”. Any modification of this report has to be notified to the Agency and reported as “modify”. An example of a report modification is when two parties agree to amend one or more terms of the original agreement (e.g. price, quantity or any other value previously reported). When a cancellation of a wrongly submitted report is needed, a report shall be submitted to the Agency and reported as “error” for its cancellation.

At any time during the term of a contract, the parties may agree or be forced to terminate the contract (i.e. they end the trade earlier than its natural maturity date). This early termination of an existing contract should be identified as “cancel”.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 5.7

Examples of transaction reporting

In order to facilitate transaction reporting and the understanding of how to populate the data fields in Table 2 of the Annex to the Implementing Acts, the Agency provides a number of examples of transaction reports. The examples can be found in ANNEX II of this document.

It is worth noting that not all the data fields are mandatory for all transactions. The data fields are expected to be reported only when it is applicable according to this manual. The Agency has prepared an extensive list of trading scenarios to show what is expected and applicable to each scenario. However, the Agency is aware of the fact that, given the characteristics of some transactions, not all the possible trading scenarios have been covered in this manual.

RSS_Icon Last update: 09/05/2016  

RSS_Icon Subscribe to this Category’s RSS