Please insert at least 3 characters

TRUM – Section 4.3

Data fields related to contract details

This section includes the following fields:

21. Contract  ID
22. Contract name
23. Contract type
24. Energy commodity
25. Fixing index or reference price
26. Settlement method
27. Organised market place ID/OTC
28. Contract trading hours
29. Last trading date and time

 

Data Field No (21) Contract ID

No. Field Identifier Description
21 Contract ID The contract shall be identified by using a unique code identifier provided by the market place or counterparties.

 

Description of Accepted Values Type Length Examples
Up to 50 alphanumerical digits. Alphanumerical 50 AGHDN15832839

 

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

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

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

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

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

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

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

 

Data Field No (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 may or may not be a venue-specific name. The contract name should be unique for a particular organised market place, but the same name can also be used by other organised market places.

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

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

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

Data Field No (23) Contract type

No. Field Identifier Description
23 Contract type The type of the contract.

 

Description of Accepted Values Type Length Examples
AU=Auction
CO=Continuous
FW=Forward style contract
FU=Future style contract
OP=Option style contract
OP_FW=Option on a forward
OP_FU=Option on a future
OP_SW=Option on a swap
SP=Spread
SW=Swap
OT=Other
Text Up to 5 FW

 

This field identifies the type of contract that is reported.

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

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

Physical swaps or dark spreads are usually executed under two master agreements/contracts 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.

Data Field No (24) Energy commodity

No. Field Identifier Description
24 Energy commodity The classification of the energy commodity.

 

Description of Accepted Values Type Length Examples
NG=Gas
EL=Electricity
Text 2 NG

 

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

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

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

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

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

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

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

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

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

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

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

Data Field No (26) Settlement method

No. Field Identifier Description
26 Settlement method Whether the contract is settled physically, in cash, optional or other.

 

Description of Accepted Values Type Length Examples
P=Physical
C=Cash
O=Optional for counterparty
Text 1 P

 

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

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

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

Data Field No (27) Organised market place ID / OTC

No. Field Identifier Description
27 Organised market place ID / OTC In case the market participant uses an organised market place to execute the contract, this organised market place shall be identified by a unique code.

 

Description of Accepted Values Type Length Examples
LEI
MIC
ACER code
XBIL=Bilateral trade (off-market)
Alphanumeric 20
4
12
4
1234567890abcdefrgf
MICX
C0643278W.EU
XBIL

 

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

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

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

Data Field No (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 case of continuous markets, exchanges or broker platforms shall report the trading hours in which their clients may place orders and trade in that market: e.g. 09:00Z to 17:00Z or 00:00Z to 24:00Z if no restrictions are imposed by the exchange.

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

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

Data Field No (29) Last trading date and time

No. Field Identifier Description
29 Last trading date and time The last trading date and time for the reported contract.

 

Description of Accepted Values Type Length Examples
ISO 8601 date and time format using UTC time format. Date and Time n/a 2014-01-29T16:30:00Z

 

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

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

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

RSS_Icon Last update: 09/05/2016  

RSS_Icon Subscribe to this Category’s RSS