Please insert at least 3 characters

TRUM – Section 4

Reporting of standard supply contracts

In this Chapter, the Agency provides information on how the data fields listed in Table 1 of the Annex to the Implementing Acts should be populated.

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. 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.

Please note that this guidance shows what has to be reported for a specific data field while the technical implementation, i.e. how to report the content of each data fields in XML format is not covered in this manual, but by the Agency’s Manual of Procedures on transaction and fundamental data reporting.  Market participants and other reporting parties should consult their Registered Reporting Mechanism (RRM) who reports on their behalf.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.1

Data fields related to the parties to the contract

This section includes the following fields:
1.      ID of the market participant or counterparty2.      Type of code used in field 13.      ID of the trader and/or of the market participant or counterparty as identified by the organised market place

4.      ID of the other market participant or counterparty

5.      Type of code used in field 4

6.      Reporting entity ID

7.      Type of code used in field 6

8.      Beneficiary ID

9.      Type of code used in field 8

10.    Trading capacity of the market participant or counterparty in field 1

11.    Buy/sell indicator

12.    Initiator/Aggressor

 

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 order to trade or the trade 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 a transaction, including the placing of orders, on a wholesale energy market. The other market participant is referred to as the “other counterparty” (see field 4). Counterparty and the other counterparty is therefore considered equivalent of market participant and the other market participant for the purpose of reporting under REMIT.

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

Registration of market participants with the relevant NRA will result in an ACER code. However, if an organised market place or other reporting 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 organised market place or other reporting 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.

From the Agency’s perspective, the ACER code is preferred, 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. If market participants prefer the LEI because it is already used for EMIR, they are free to use it as long as the LEI has been provided to the relevant NRAs in the registration process.

If a market participant is using an ACER code, this can be used to verify the identity of the other market participant from the European register of market participants published by the Agency and available on 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 trader and/or of the market participant or counterparty as identified by the organised market place

No. Field Identifier Description
3 ID of the trader and / or of the market participant or counterparty as identified by the organised market place The login username or trading account of the trader and / or the market participant or counterparty as specified by the technical system of the organised market place.

 

Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 1234567890abcdefghi

 

This field indicates the ID used by the organised market place or by the market participant to identify the user responsible for entering into the transaction that is reported. This is most likely an electronic ID for the trader/market participant’s account or a technical representation of that account. If populated from the perspective of the organised market place, this field shall represent how the market place identifies the trader or the market participant; if populated from the perspective of the market participant, then this field shall represent how the market participant identifies the trader.

For example, a trader called Joe Bloggs working at Company (A) trades on European Gas/Power Futures Exchange (EGPFE):

  • EGPFE identifies Joe Bloggs with ID = 123Abc
  • EGPFE identifies Company (A) with ID = CompA123
  • Company A identifies Joe Bloggs internally with ID = Abc12345

For trades at organised market places, Trader ID as identified by the organised market place should be reported as “123Abc” or if not available the Company ID as identified by the organised market place should be reported as “CompA123”

For bilateral contracts traded off-organised market places, Trader ID as identified by Company (A) should be reported as “Abc12345”.

Trader ID is a mandatory field in the sense that there must be an identifier of the person or the group of persons responsible for taking decisions or actions in executing or amending the transaction. That person or group of persons shall be identified by an ID.

A number or code does not disclose the identity of the person in the transaction reporting and market participants and organised market place may report a number (or code) in order to avoid the reporting of names.

As the same trader may have multiple IDs, the ID used for the execution of the transaction that is reported shall be used.

With regard to orders to trade placed by executing brokers at the organised market place, the trading ID of the broker’s client shall also be reported in this field if available to the organised market place. Alternatively, if the order report is reported through a third party on behalf of the executing broker, this should may be made available to the reporting party by the executing broker along with the Beneficiary ID (field 8) and reported to the Agency by the third party reporting on behalf of the broker.

 

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

No. Field Identifier Description
4 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. This field shall only be populated when reporting bilateral trades, including those bilateral trades that take place on broker platforms or any other organised market place which allows bilateral trades.

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 available on the Agency’s website.

If the trade takes place on an energy exchange and the other counterparty is a CCP, clearing house or a clearing member, this field shall be left blank.

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.

For orders on contracts that have to be cleared e.g. traded on a broker platform and then booked with the exchange, the ID of the exchange shall be reported here. In case the exchange does not have an ACER, LEI, BIC, EIC, or GLN/GS1 code, reporting parties can report the exchange‘s MIC code in the format XMIC00000.EU, where the first four characters represent the exchange’s MIC code, followed by 5 zeros, followed by “.EU” to replicate the ACER code format.

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

No. Field Identifier Description
5 Type of code used in field 4 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 4. For example, if an LEI code of the market participant is used in field 4 (e.g. 1a2b3c4d5e6f7g8e9f0h), the accepted value in field 2 is “LEI”. If an ACER code is used in field 4 (e.g. C0643278WY.EU), the accepted value is “ACE”. The same principle applies to BIC, EIC and GLN/GS1 codes.

 

Data Field No (6) Reporting entity ID

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

 

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

 

This field indicates the ID of the reporting entity that 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 case of bilateral trade. If the reporting party is a market participant, they shall use one of the unique codes registered with the NRA as REMIT market participant.

 

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

No. Field Identifier Description
7 Type of code used in field 6 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 6. For example, if an LEI code of the reporting entity is used in field 6 (e.g. a2b3c4d5e6f7g8e9f0h), the accepted value in field 7 is “LEI”. If an ACER code is used in field 6 (e.g. C0643278WY.EU), the accepted value is “ACE”. The same principle applies to BIC, EIC and GLN/GS1 codes.

 

Data Field No (8) Beneficiary ID

No. Field Identifier Description
8 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 the case that 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. if 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 in a wholesale energy market, 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.

If the beneficiary ID is available to the organised market places or to one of the two counterparties to the contract in the case of bilateral contracts traded off-organised markets, the beneficiary ID must be reported. This can also be reported as a lifecycle event after the trade takes place.

If the information on the beneficiary of the transaction is not available to the organised market place, this field shall be left blank. For example, the organised market place may only know the market participant (or the executing broker in case of exchange) that executed the transaction. Also when the trade is submitted for clearing, this information may be lost because the clearing house only executes transactions against its clearing members, and the market participant may (in the case of self‐clearing members) or may not be the ultimate beneficiary.

Some of the reported trades executed at organised market places will look like: A sells to B with beneficiary C. The Agency will in these cases receive two reported trades: A sells to B, B sells to C.

However, the trade may be even more complicated and it may involve more parties. For example, if a bilateral trade takes place off-market 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.

Bilateral and non-cleared transactions executed off-market may be of the form 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.

With regard to orders to trade placed by executing brokers at the organised market place, the Beneficiary ID of the broker’s client shall also be reported in this field if available to the organised market place. Alternatively, if the order report is reported through a third party on behalf of the executing broker, this should be made available to the reporting party by the executing broker along with trading ID (field 3) and reported to the Agency by the third party reporting on behalf of the broker.

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 any of their scenarios that are not represented in this manual.

 

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

No. Field Identifier Description
9 Type of code used in field 8 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 6. For example, if an LEI code of the reporting entity is used in field 8 (e.g. a2b3c4d5e6f7g8e9f0h), the accepted value in field 9 is “LEI”. If an ACER code is used in field 8 (e.g. C0643278WY.EU), the accepted value is “ACE”. The same principle applies to BIC, EIC and GLN/GS1 codes.

 

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

No. Field Identifier Description
10 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 8, this field may be populated with “A” for Agent.

The Agency understands that the terms Principal and Agent are  terms  commonly used in the financial markets and it depends upon whether 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 transactions:

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 (11) Buy/sell indicator

No. Field Identifier Description
11 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 from the perspective of the reporting market participant or, in the case of an agent (e.g. executing broker) transaction, from the perspective of the client.

For a trade transaction, this should indicate the side of the matched trade for the market participant as a buyer or a seller. For an order transaction, this should indicate whether the market participant indicated the intention 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 buy and 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 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, the 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 (12) Initiator/Aggressor

No. Field Identifier Description
12 Initiator/Aggressor When the trade is executed on an electronic or voice assisted broker platform, the initiator is the party who first placed the firm order in the market and the aggressor is the party that initiates the transaction.

 

Description of Accepted Values Type Length Examples
I=Initiator
A=Aggressor
S=Sleeve
Text 1 A

 

This field applies when the trade was executed as an electronic or voice assisted trade on broker platforms. “A” shall be indicated if the market participant was the originator of the transaction (aggressor) and “I” shall be indicated if the market participant was the passive participant (initiator), i.e. the one placing the order in the market first.

A buyer is identified as an aggressor if the market participant submits an order which matches with a sell order (initiator) that is already visible to the market place. A seller is identified as an aggressor if the market participant submits an order which matches with a buy order (initiator) that is already visible to the market place.

The Agency’s understanding of sleeve trade definition is the following: a market participant (A) would like to enter into a transaction with another market participant (B) which has advertised a price and quantity on the broker’s screen. However, because market participant A and B do not have an agreement to trade (or limited credit status), the broker may find a third market participant (C) who has an agreement to trade with both A and B and is willing to sleeve the trade (buy and sell the same contract simultaneously) for them.

There are two trades in this type of scenario: one trade between A and C (e.g. A buys from C) and another trade between C and B (e.g. C buys from B). The result of the sleeve trade is four legs to be reported to the Agency as follows:

A buys from C:

  • A reports the trade as buyer and as aggressor (A); and
  • C reports the trade as seller and as sleeve trade (S).

C buys from B:

  • C reports the trade as buyer and as sleeve trade (S); and
  • B reports the trade as seller and an initiator (I).

This field does not apply to orders to trade.

 

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.2

Data fields related to order details

This section includes the following fields:

13. Order ID
14. Order type
15. Order condition
16. Order status
17. Minimum execution volume
18. Price limit
19. Undisclosed  volume
20. Order duration

 

Data Field No (13) Order ID

No. Field Identifier Description
13 Order ID The order 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 100 alphanumerical digits. Alphanumerical 100 12345abcdef

 

This field identifies the unique order ID as specified by the organised market place (exchange or broker) to identify the order to trade.

When reporting an order ID from an organised market place, the ID should be unique for that contract and for that market place. The order ID shall be maintained throughout the lifecycle of the order. If an order is reported with an ID when it is reported as new, the same ID shall be used to identify the transaction throughout the remainder of its lifecycle.

 

Data Field No (14) Order type

No. Field Identifier Description
14 Order type The type of order as defined by the functionality offered by the organised market place.

 

Description of Accepted Values Type Length Examples
BLO=Block
CON=Convertible
COM=Combination
EXC=Exclusive
FHR=Flexible Hour
IOI=Indication of Interest
LIM=Limit
LIN=Linked
LIS=Linear Step
MAR=Market
MTL=Market to Limit
SMA=Smart Order
SPR=Spread
STP=Step
VBL=Variable Block
OTH=Other
Text 3 MAR

 

This field identifies the type of order that is reported. Every order shall have a type as defined within the list below. Orders can have various characteristics.

BLO=Block: an order which is linked to one or more other orders for the purpose of trading (that must have the same price and the same quantity according to the trading venue’s rules) irrespective of whether the periods (e.g. half hours, hours) are contiguous.

CON=Convertible:  an order which under market conditions may be converted from a block order to a single hourly order.

COM=Combination:  an order which refers to two or more orders concerning different series and where the respective orders are executed simultaneously.

EXC=Exclusive:  a complex order type where the linked order is the exclusive order, i.e. only one of the orders can be transacted.

FHR=Flexible Hour:  a specific order that can trade at any hour provided that the price and volume are matched.

IOI=Indication of Interest:  quotations on trading venues such as Indication of Interest advertised on the screens of the organised market places.

LIM=Limit:  an order submitted with a specified limit price; the order executes either in part or in full at its limit price or better.

LIN=Linked:  an order where there is a dependency on/from another order for choosing to trade either one or the other or both orders.

LIS=Linear Step:  an order where the specified step range is matched linearly.

MAR=Market:  an unpriced order that will execute against the best priced orders.

MTL=Market to Limit:  a market order that executes at the best price, with any unexecuted portion stored in the book as a limit order.

SMA=Smart Order:  an order can be either against a financial or physical contract.

SPR=Spread:  an order where the order contains more than one contract e.g. taking either long or short position in different contracts.

STP=Step:  an order which defines a specific step range or step price.

VBL=Variable Block:  an order in which the block quantity can vary, i.e. different quantity at different hours.

OTH=Other:  an order that has not been identified by one of the existing order types.

 

Data Field No (15) Order condition

No. Field Identifier Description
15 Order condition A special condition for the order to execute.

 

Description of Accepted Values Type Length Examples
AON=All or None
FAF=Fill and Float
FAK=Fill and Kill
FOK=Fill or Kill
HVO=Hidden Volume
MEV=Minimum Execution Volume
OCO=One Cancels Other
PRE=Preference
PRI=Priority
PTR=Price Trigger
SLO=Stop Loss Order
OTH=Other
Text 3 FOK

 

This field identifies the conditions applied to the order at the time of the lifecycle event (new, modify, cancel, terminate) for the order, which indicates the special behaviours of the order types in combination with the order definition and the specific lifecycle event of the order.

AON=All or None: an order which must fill in full otherwise it will remain on the book until the entire volume has been matched.

FAF=Fill and Float: an order which will be killed immediately after matching with any available volume on the order book; if not filled at all, it stays in the market.

FAK=Fill and Kill: an order which must be filled as much as possible immediately upon entry; otherwise, it is removed from the order book.

FOK=Fill or Kill: an order which must fill immediately in full when it is entered into the book; otherwise, it will be removed without trading.

HVO=Hidden Volume: an order that has a hidden quantity, which is part of the total quantity of the order.

MEV=Minimum Execution Volume: an order which specifies a minimum volume of the order that has to be matched to allow trading.

OCO=One Cancels Other: an order which if triggered cancels another order.

PRE=Preference: an order which will trade with a specific participant or participants in preference of others.

PRI=Priority: an order which has a priority obligation for trading, i.e. it cannot trade with a participant within its own group.

PTR=Price Trigger: an order which will not be available for execution unless a specific trigger price is reached, similar to a Stop Loss, but may be triggered across product pricing, i.e. the price trigger may be based on a different contract or index.

SLO=Stop Loss Order : an order that is submitted to the market as a limit order or market order once a certain price condition of an instrument is met.

OTH=Other: an order that has not been identified by one of the existing order condition.

 

Data Field No (16) Order status

No. Field Identifier Description
16 Order status The status of the order, for example if order is active or deactivated.

 

Description of Accepted Values Type Length Examples
ACT=Active
COV=Converted
EXP=Expired
MAC=Matched
PMA=Partial Matched
REF=Refilled
SUS=Suspended
WIT=Withdrawn
OTH=Other
Text 3 ACT

 

This field identifies the status of the order that has been reported. Every order should have a status as defined by the list of order status reported above.

ACT=Active: the order has been activated by the system or participant and is visible in the active order book.

COV=Converted: converted a block order or variable block order which has been converted into a single order.

EXP=Expired: the order has expired as per its order duration or order conditions.

MAC=Matched: the order has been fully matched by another order transaction.

PMA=Partial Matched: the order has been partially matched by another order transaction.

REF=Refilled: the order has had the hidden or undisclosed quantity refilled to provide visible volume for the order to trade.

SUS=Suspended: an order which has been suspended from trading by the system.

WIT=Withdrawn: an order has been withdrawn from the market.

OTH=Other: an order that has not been identified by one of the existing order status.

 

Data Field No (17) Minimum execution volume

No. Field Identifier Description
17 Minimum execution volume Minimum Execution Volume – The quantity / volume of any defined minimum execution.

 

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 100

 

This field identifies the minimum execution volume of the order which has to be matched for the order to be executed. This field shall only be populated if the order condition field 15 is Minimum Execution Volume “MEV”.

 

Data Field No (18) Price limit

No. Field Identifier Description
18 Price limit The defined price of the limit for the trigger or stop loss order.
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 58.6

 

This field identifies the defined price limit for a trigger or stop loss order that causes the order to either enter into the order book or to be withdrawn from the order book. This field shall only be populated if the order condition is Price Trigger “PTR” or Stop Loss “SLO”.

 

Data Field No (19) Undisclosed volume

No. Field Identifier Description
19 Undisclosed volume The volume that is not disclosed to the market for the order.

 

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 1000

 

This field identifies the “undisclosed” or “hidden” volume of the order as provided to the organised market place. The volume entered in this field is the volume of the order which is not visible to the market place. This field applies to those orders that have an order condition Hidden Volume “HVO” (e.g. Iceberg Orders).

 

Data Field No (20) Order duration

No. Field Identifier Description
20 Order duration The order duration is the time for which the order exists within the system until it is removed / cancelled unless it is executed.
Description of Accepted Values Type Length Examples
DAY=Day
GTC=Good Till Cancelled
GTD=Good Till Date
GTT=Good Till Time
SES=Session
OTH=Other
Text 3 SES

 

This field identifies the duration of the order, i.e. the time for which the order exists within the system until it is removed or cancelled unless it is executed. For example, an order can be active during the trading session for the day or until it is cancelled.

DAY=Day: an order which persists for the current day only.

GTC=Good Till Cancelled: an order which persists until the user cancels the order or it reaches the system maximum duration.

GTD=Good Till Date: an order which persists until a specified date.

GTT=Good Till Time: order which persists until a specified time and date.

SES=Session: an order which persists only within the current trading session or until gate closure

OTH=Other: an order duration that has not been identified by one of the existing order duration types.

RSS_Icon Last update: 09/05/2016  

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  

TRUM – Section 4.4

Data fields related to transaction details

This section includes the following fields:

30. Transaction timestamp
31. Unique transaction ID
32. Linked transaction ID
33. Linked order ID
34. Voice-brokered
35. Price
36. Index value
37. Price currency
38. Notional amount
39. Notional currency
40. Quantity/Volume
41. Total notional contract quantity
42. Quantity unit for field 40 and 41
43. Termination date

 

Data Field No (30) Transaction timestamp

No. Field Identifier Description
30 Transaction timestamp The date and time of the contract execution or order submission, or their modification, cancellation or termination.

 

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

 

This field identifies the transaction timestamp, meaning the time at which the reported event occurred. This field must reflect the actual time as a string representation of the ISO 8601 date and time format. The timestamp will always be represented in UTC time format. Transactions that occur in a different time zone have to be converted and represented in UTC time format.

For orders in continuous markets, the transaction timestamp is the time at which the orders were placed into the market or at which any subsequent modifications or cancellations of the order transaction occurred.

For orders in auction markets, the transaction timestamp is the time at which the orders were placed into the market and considered for the auction.

For trades in continuous markets, the transaction timestamp is the time at which the orders were matched and trades were created in the market or at which any subsequent modifications or cancellations of the trade transaction occurred.

For trades in auction markets, the transaction timestamp is the time of the announcement of the auction results or any subsequent modifications or cancellations of the trade transaction.

For bilateral trades, the actual trading time (the time at which the trade was agreed by the two traders) shall be reported rounded to the nearest minute in the UTC format, e.g. 2014-01-29T10:35Z. However, where reporting market participants are unable to meet the requirement to populate the trading time field with the actual trading time and instead give the time at which the trade is entered into their system (when this is not materially different from the actual trading time), market participants should make best efforts to minimise any discrepancy between the trading time and the booking time.

With regards to the statement “materially different from the actual trading time”, this has to be assessed on a case-by-case basis.

Where the trading time is not made available (e.g. for back-to-back transactions or when market participants do not have direct access to the markets and the trading time is not available or the trading time is not forwarded by the broker/trading firm) the default time of 00:01:00 UTC time must be used. A default time should only be used as a last resort and market participants should take reasonable steps to report the actual time that the transaction was executed. Using this default time will ensure that these transaction reports are included in the Agency’s monitoring of trading before a price-sensitive announcement.

 

Data Field No (31) Unique transaction ID

No. Field Identifier Description
31 Unique transaction ID Unique identifier for a transaction as assigned by the organised market place of execution, or by the two market participants in case of bilateral contracts to match the two sides of a transaction.

 

Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 1234567890abcdefrgf

 

This field is populated with a unique identifier assigned by the organised market place where execution takes place in order to match the two sides of a transaction or by the two market participants in the case of off-organised market place bilateral contracts.

Unique transaction ID: generation, dissemination and usage

The Agency appreciates that the UTI reporting requirements under REMIT may be slightly different than requirements set by transaction reporting regimes under other European legislations. The Agency encourages market participants to follow the guidelines set out in this manual for a correct interpretation of how to report the trade UTI under the REMIT transaction reporting regime.

Market participants should bear in mind that it is their obligation to comply with REMIT and it is their obligation to make sure that the Agency receives the correct UTI in the correct format for their transactions as required by the Implementing Acts. This should be the unique identifier for a transaction (UTI) as assigned by the organised market place of execution or by the two market participants in the case of bilateral contracts to match the two sides of a transaction.

Regardless of whether the trade takes place in a continuous market, through brokers or bilaterally, the buyer and the seller of a trade must report the same UTI for the matched trade.

In a matched trade, there should always be two sides of the trade (reported separately) irrespective of being one-to-one, one-to-many or many-to-many matches. As far the Agency is aware, there are not two sides for each matched trade in auction markets. All transactions have one price and this is set by the auction algorithm for all the counterparties at the same time. In these particular markets, all transactions shall have a different ID to distinguish them from each other.

It is crucial that market participants use the UTI generated by the organised market place as indicated in the legislation to avoid reporting trades that cannot be matched in the Agency’s system and therefore labelled as incorrect.

The Agency believes that there are a few UTI generation and dissemination scenarios which need to be considered, namely:

 

The trade is executed: The UTI should be generated by The trade/order report is sent to ACER by Need for MPs generating the UTI Lifecycle events reported by
At OMP The OMP The OMP No Third parties

(or OMP if this offers the service)

Third parties No Third parties
Bilaterally Market participants or third parties on their behalf Market participants Yes Market participants or third parties
Third parties Yes Market participants or third parties

 

As far as the Agency is aware, most of the organised market places where wholesale energy products are admitted to trade already have a system in place to generate a UTI which conforms to the REMIT Implementing Acts’ requirements, i.e. a unique transaction ID to identify the two sides of the trade.

However, if there are organised markets that do not have such a system, they should put one in place by the time the reporting obligation starts. Article 6(1) of the Implementing Acts states that “….The organised market place where the wholesale energy product was executed or the order was placed shall at the request of the market participant offer a data reporting agreement”. In reporting the transaction on behalf of a market participant, the organised market shall provide the Agency with a UTI compliant with the requirements in the Implementing Acts and in this user manual.

In summary:

1. for auction markets, each transaction shall have a different ID generated by the exchange;

2. for continuous markets in energy and derivative exchanges, transactions shall identify the buy side and the sell side with the same UTI generated by the exchange, e.g. :

    • (A) matches a trade with (B), both (A) and (B)’s trade reports shall have the same UTI (e.g. 123);
    • (A) matches a trade with (B) and (C), if (A)’s trade report is considered just one execution, then (A), (B) and (C)’s trade reports shall have the same UTI (e.g. 123). If A’s trade with (B) and (C) is split into two trades, then (A) and (B) trade reports shall have the same UTI (e.g. 123) and (A) and (C) shall have the same UTI (e.g. 567) which is different from the (A) and (B) trade report UTI (123);

3. for brokers’ platforms including voice-brokered transactions (bilateral trades), the UTI shall identify the buy side and the sell side with the same UTI (e.g. 123) generated by the broker’s platform;

4. for bilateral trades that take place outside an organised market place, the two market participants shall assign the same UTI to their trade reports.

The Agency is aware of a few situations where the UTI generation, dissemination and its usage may not be harmonised across organised market places and/or market participants.

If an organised market place does not generate or/and disseminate, for any reasons, the UTI to the market participant or the broker client or exchange’s member market participants may follow the guidance below.

Generation and usage of the UTI for bilateral trades that take place outside an organised market place may be more complicated than for trades taking place on organised market places. The Agency has developed and made public an ACER algorithm which would enable market participants to generate the same UTI from the economic terms of the bilateral trade without any communication between the two market participants. Please see ANNEX IV.

The ACER algorithm is based on the concatenation of economic terms included in the contract and their anonymisation. The Agency recommends using the ACER algorithm unless market participants agree to submit a UTI which is generated by a system/guidance which is publicly available or they agree to use one of the two parties’ UTI generation methods and agree on its dissemination and usage.

Therefore, for bilateral trades that take place outside an organised market place, the Agency recommends that market participants shall use the ACER algorithm available in ANNEX IV of this manual, unless:

 

    1. markets participant agree to submit a UTI which is generated by a publicly-available system/guidance.  Please refer to ANNEX IV for the most update-to-date list with the web address of the organisations providing such a system/guidance. In this case, market participants should bear in mind that it is their responsibility to agree on the division of tasks and their timing and submit the same UTI to the Agency; or
    2. market participants may agree on how to generate their UTI: for example, they may agree to accept one of the two parties’ UTI generation methods and agree on its dissemination and usage. This is entirely at their discretion how they opt to do it. In this case, market participants should bear in mind that it is their responsibility to agree on the division of tasks and their timing and submit the same UTI to the Agency.

 

Data Field No (32) Linked transaction ID

No. Field Identifier Description
32 Linked transaction ID The linked transaction identifier must identify the contract that is associated with the execution.

 

Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 1234567890abcdefrgf

 

This field indicates if two or more transactions are linked to each other or transactions executed within the framework of non-standard contracts linked to the non-standard contract. The value populated in this field is the unique ID as defined by the field 31 for standard contracts or field 11 of Table 2 for non-standard contracts. The linked trade ID shall be used in the following scenarios:

1. When a trade occurs across multiple products due to the nature of the product, e.g. a product which is a spread of two or more products falling under the scope of REMIT. The trade for each product is to be reported and the different trades are to be linked to each other when they are executed simultaneously on the organised market place.

Examples:

a. Clean and Dirty Spark Spreads for a trade that involves electricity and gas: the two contracts are reported separately, with one leg for the electricity and one leg for the gas trade. The two legs, i.e. gas and electricity trades, should be linked together through this field.

b. Physical Swaps for a trade that involves two gas or electricity trades: a geographical physical swap involves two trades, e.g. selling gas in a particular delivery point and buying it at another delivery point. Both trades have to be reported separately and linked together through this field if they are traded simultaneously.

2. When a transaction is executed within the framework of a non-standard contract, the details of the transaction specifying at least an outright volume and price will be reported and linked to the non-standard Contract ID (Data Field No 11 of table 2).

 

Data Field No (33) Linked order ID

No. Field Identifier Description
33 Linked order ID The linked order identifier must identify the order that is associated with the execution.

 

Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 1234567890abcdefrgf

 

This field identifies a transaction which is the result of an executed order. The linked order ID shall be used in the following scenarios:

  • when an order is executed, the trade report or results report (for auctions) should contain the field “Linked Order ID” to identify the order that triggered the trade to occur; and
  • when an order has a special condition that links the order to another order, e.g. the order type is a block or exclusive order.

 

Data Field No (34) Voice-brokered

No. Field Identifier Description
34 Voice-brokered Indicates whether the transaction was voice brokered, “Y” if it was, left blank if it was not.

 

Description of Accepted Values Type Length Examples
Y=YES Text 1 Y

 

This field identifies if the transaction was voice brokered. If the transaction was voice brokered, this field shall be populated with “Y”. If the transaction was not voice-brokered, this field should be left blank.

 

Data Field No (35) Price

No. Field Identifier Description
35 Price The price per unit.

 

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 53.45

 

This field identifies the agreed price per unit of energy as expressed in field 40. In the case of options, this field represents the premium while, in the case of orders, this field represents the bid or offer price for that order.

If a price/time interval is specified in field 57, this field should be left blank. The trading examples in ANNEX II explain in which circumstances this field should not be reported.

 

Data Field No (36) Index value

No. Field Identifier Description
36 Index value The value of the fixing index.

 

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 +/- 0.02

 

This field identifies the value of the fixing index indicated in field 25. The index value represents the value of the index at the time the contract was traded.

When an index value is not known when the contract is traded, the market participant should report a null value as “0” (zero). Market participants often enter into transactions and agree on a difference (+/-) from the fixing index price that will be published after the trade occurs, e.g. by the end of the day or a few weeks or months after. The agreed difference (+/-) from the fixing index value may be expressed in currency (e.g. +/- EUR 0.05) or in percentage terms (e.g. +/- 0.1 %). If the price differential is reported in percentage terms, then the value “PCT” shall be used in the currency field 37. If there is no deviation from the value of the fixing index, the value should be 0.

 

Data Field No (37) Price currency

No. Field Identifier Description
37 Price currency The manner in which the price is expressed.

 

Description of Accepted Values Type Length Examples
ISO 4217 Currency Code, 3 alphabetical 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 forint
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 35.

If the transaction is priced as a percent of the value of the fixing index (e.g. +/- 0.1 %), this field should be reported as “PCT” which is one of the accepted values.

If fields 35 and 36 are blank, this field should be left blank.

 

Data Field No (38) Notional amount

No. Field Identifier Description
38 Notional amount Value of the contract.
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 53450.00

 

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

Notional Amount = Price x Volume x Number of periods, where:

  • Price is the defined as the price of the volume as per field 35
  • Volume is the quantity of energy as per field 40
  • Number of periods is the number of times that quantity is delivered / received (as derived from the delivery profile)

This can also be calculated using the following formula:

Notional Amount = Price x Total notional contract quantity where:

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

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

€50 x 100(MW) x 24(h) = €120,000

or for a monthly contract:

€50 x 100(MW) x 24(h/day) x 30(days) = €3,600,000

Index trades may not have a value for the contract as this type of contract may not have a fixed price available at the time of the reporting. These index trades may have +/- EUR (or any other currency) 0.05 or +/- 0.1% differential from the published index value which is not available to the organised market place.

The index value may be published after the trading hours or in some cases days/weeks/months after the trade, e.g. a month forward on an index where market participant A enters into a contract for the delivery of gas three months ahead from the trading date (a physical forward). The price of that physical forward will be set the day before the delivery starts based on the front month average price of the month before the delivery takes place. For example, a trade occurs in April for the delivery in July; the average front month (July) price in June is calculated on 30 June and the delivery starts on 1 July at the price of the average front month (July) price in June.

This field should be left blank for trades 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 in April 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 notional amount calculation should use the option strike price and not the option premium.

For orders and their lifecycle events, this field shall not be reported.

 

Data Field No (39) Notional currency

No. Field Identifier Description
39 Notional currency The currency of the notional amount.

 

Description of Accepted Values Type Length Examples
ISO 4217 Currency Code, 3 alphabetical 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 forint
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 38. The notional currency shall be provided in unit as stored in the system of the reporting party.

However, reporting parties may want to report in a major unit e.g. EUR rather than EUX for euro cent and GBP rather than GBX for penny sterling. The reason for reporting the major unit is to avoid unnecessarily large values. 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 so it may be more appropriate to have GBP 1,000,000 rather than GBX 100,000,000.

If field 38 is blank, this field should be left blank.

Data Field No (40) Quantity/Volume

No. Field Identifier Description
40 Quantity / Volume Total number of units included in the contract or order.

 

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 100

This field identifies the quantity or energy volume (delivery capacity) for the contract, i.e. the contract size or clip size. The value that shall be reported in this field is the volume per time unit, e.g. the number of MWh/h or therm/day.

For example, consider the two scenarios: market participant A enters into a contract and sells 10 MW (MWh/h) of electricity (or gas) at €50/MWh on the day-ahead market whilst market participant B enters into a contract and sells 10 therms (therm/day) of gas at €50/therm on the day-ahead market. In both scenarios, the value of 10 should be reported in this field.

The same applies if the contract is an hourly or monthly delivery contract.

If delivery capacity is specified in field 55, this field should be left blank. Please refer to the trading scenarios in ANNEX II.

Data Field No (41) Total notional contract quantity

No. Field Identifier Description
41 Total notional contract quantity The total number of units of the wholesale energy product.

 

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 1000

This field identifies the total quantity or energy volume of the transaction (total contract volume). The total notional contract quantity is the overall quantity/volume of energy included in the transaction. 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 40
  • Number of periods is the number of times that quantity is delivered / received (as derived from the delivery profile)

For example, a contract traded for a volume of 50 MW delivered for 24 hours would have the following notional contract quantity:

50 MW x 24h = 1,200 MWh

or for a monthly contract:

50 MW x 24h/day x 30 days = 36,000 MWh

Continuing this example, if the above contract was for delivery for 10 hours, the Notional Contract Quantity would be 500 MWh (50 MW x 10h), however if the contract for delivery was for 10 hours for 30 days, then the notional  quantity would be 15,000 MWh (50 MW x 10 h/day x 30 days).
For orders and their lifecycle events, this field shall not be reported.

Data Field No (42) Quantity unit for fields 40 and 41

No. Field Identifier Description
42 Quantity unit for field 40 and 41 The unit of measurement used for fields 40 and 41.

 

Description of Accepted Values Type Length Examples

For field 40:

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

<For field 41:

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

Text 2 to 8 MW

This field identifies the unit used for the reported quantity in field 40 and field 41 as specified in the contract. Since the units for field 40 and field 41 differ, the two different quantity units should be provided according to the above list.

Data Field No (43) Termination date

No. Field Identifier Description
43 Termination date Termination date of the reported contract. If not different from delivery end date, this field shall be left blank.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format. Date 10 2014-01-29

This field identifies the termination date of the contract, where the contract is terminated before the end of the previously reported delivery period. In this case, a cancellation report has to be submitted with the termination date of the contract in this field.

Example: market participant (A) and market participant (B) trade a monthly physical forward for the month of July. During the course of the month of July, (A) and (B) agree to terminate the contract on 25 July instead of the original delivery end date of 31 July. In this case, the date of 25 July should be reported as termination date in this field and the cancelled report should also include the time and date of such the termination agreement in the transaction timestamp (field 30).

 

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.5

Data fields related to option details

This section includes the following fields:

44. Option style
45. Option type
46. Option exercise date
47. Option strike price

 

Data Field No (44) Option style

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

 

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 field 46.

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., if traded at organised market places, should be reported with the value of “O”.

 

Data Field No (45) Option type

No. Field Identifier Description
45 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 put or 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 type they are reporting.

 

Data Field No (46) Option exercise date

No. Field Identifier Description
46 Option exercise date The date or dates when the option is exercised. If more than one, further fields may be used.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format. Multiple rows if needed. Date 10 2014-01-29

 

This field identifies the 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 on or before a specified date. In the case of an American, European or Asia option style, one exercise date is reported. In the case of a Bermudian option style, several dates may be reported.

Reporting parties should refer to financial markets in order to report correctly the exercise date/dates.

 

Data Field No (47) Option strike price

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

 

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 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.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.6

Data fields related to delivery profile

This section includes the following fields:
48. Delivery point or zone
49. Delivery start date
50. Delivery end date
51. Duration
52. Load type
53. Days of the week
54. Load delivery intervals
55. Delivery capacity
56. Quantity Unit in field 55
57. Price/time interval quantity

 

Data Field No (48) Delivery point or zone

No. Field Identifier Description
48 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. Alphanumerical 16 10YCB-EUROPEU–8

 

This field identifies the commodity delivery point or zone. This field reports 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, since gas can also be delivered at the interconnection point, then the EIC-Z Code for that interconnector may be used.

 

Data Field No (49) Delivery start date

No. Field Identifier Description
49 Delivery start date Start date of delivery.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format Date 10 2014-01-01

 

This field identifies the date at which the delivery of the commodity starts as specified in the contract.

 

Data Field No (50) Delivery end date

No. Field Identifier Description
50 Delivery end date End date of delivery.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format Date 10 2014-03-31

 

This field identifies the date at which the delivery of the commodity ends as specified in the contract.

 

Data Field No (51) Duration

No. Field Identifier Description
51 Duration The duration of the delivery period.

 

Description of Accepted Values Type Length Examples
N=Minutes
H= Hour
D= Day
W= Week
M =Month
Q = Quarter
S= Season
Y= Annual
O=Other
Text 1 M

 

This field identifies the duration of the delivery period. This is a generic representation of the contract, i.e. it does not specify the exact dates and times of the contract, but the common usage terms of the delivery period. For example, it refers to the contract as a month contract or any other duration as specified in the table reported above without specifying the exact start and end date and time of a month contract.

 

Data Field No (52) Load type

No. Field Identifier Description
52 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 defined as per the definition of the organised market place hosting the contract or, if available, as indicated in the contract in case of bilateral trade.

 

Data Field No (53) Days of the week

No. Field Identifier Description
53 Days of the week The days of the week of the delivery

 

Description of Accepted Values Type Length Examples
” “=All days
MO=Monday
TU=Tuesday
WE=Wednesday
TH=Thursday
FR=Friday
SA=Saturday
SU-Sunday
XB=Excluding bank holidays
IB=Including bank holidays
WD=Week days
WN=Weekend
Text 2 to 6 MO
Or any combination like:
MOtoFR
Or
WN

 

This field identifies the days of the week that the commodity (gas or electricity) is delivered. This field does not apply to hourly or daily delivery contracts. This field applies to contracts for the delivery of the product when the delivery is repeated over a number of set days.

A monthly peak electricity forward contract must indicate that the delivery takes place from Monday to Friday during the month of the delivery.  A monthly off-peak electricity forward contract must indicate that the delivery takes place Monday to Sunday on off-peak hours during the month of the delivery.

An hourly, block of hours or a day-ahead base load contract will not require reporting of this field, unless for delivery over a number of set days.

 

Data Field No (54) Load delivery intervals

No. Field Identifier Description
54 Load delivery Intervals Time interval for each block or shape.

 

Description of Accepted Values Type Length Examples
Time interval expressed in local time of the delivery point/area in the format of HH:MM Time n/a 10:00/11:00

 

This field identifies the load intervals for the delivery of the product (gas or electricity) and shall be expressed in local time at the delivery point/area.

If the delivery intervals are the same for the entire duration of the contracts, e.g. an electricity peak load contract for delivery 07:00 to 19:00 or an electricity off-peak contract for delivery 00:00 to 07:00 and 19:00 to 00:00, the delivery intervals for each single day of the delivery will not be reported as these will be the same for the entire duration of the contract.

 

Data Field No (55) Delivery capacity

No. Field Identifier Description
55 Delivery capacity The number of units included in the transaction, per delivery time interval.

 

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 10

 

This field identifies the delivery capacity for each delivery interval if the delivery capacity is different for each delivery interval reported in field 54. If the delivery capacity is the same for each delivery interval then this field should be left blank and the delivery capacity should be reported in field 40.

 

Data Field No (56) Quantity unit used in field 55

No. Field Identifier Description
56 Quantity unit used in field 55 The unit of measurement used.

 

Description of Accepted Values Type Length Examples
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 MW

 

This field identifies the unit used for the reported quantity in field 55.

 

Data Field No (57) Price/time interval quantity

No. Field Identifier Description
57 Price/time interval quantity If applicable price per quantity per delivery time interval.

 

Description of Accepted Values Type Length Examples
Up to 20 numerical digits in the format xxxx.yyyyy with a maximun of 5 decimals. Number 20 50.25

 

This field identifies the price for the quantity at each time interval if the price is different for each delivery interval reported in field 54. If the price is the same for each delivery interval then this field should be left blank and the price should be reported in field 35.

For example, if field 54 indicates two delivery intervals: 9:00 to 12:00 and 12:00 to 15:00 and field 55 indicates two capacities, e.g. 10 MW (for delivery 9:00 to 12:00) and 20 MW (for delivery 12:00 to15:00), then field 57 shall be used for reporting different price per MW per each block, for example, EUR 50/MW (for delivery 9:00 to 12:00) and EUR 55/MW (for delivery 12:00 to 15:00). If the price per MW for the two blocks is the same, then the price should be reported in field 35 and not in this field.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.7

Data fields related to lifecycle information

This section includes the following fields:
58. Action type

 

Data Field No (58) Action type

No. Field Identifier Description
58 Action type When the report contains:
– a contract or an order to trade for the first time, it will be identified as ‘new’;
– a modification of details of a previous report, 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 or order to trade, 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 for the event that is being reported.

The first transaction of an order or contract should be a reported as “new”. Within a single trading day, there should only ever be one “new” action for a transaction. All subsequent transactions for that order or contract should either be reported as “modify”, “cancel” or “error”.

“Modify” should be used for any changes to the transaction made by the market participant or the execution venue on their behalf.

“Cancel” should be used to identify when the market participant or the execution venue has removed the order transaction from trading or should be used when a contract is terminated prior to the original end date.

“Error” should be used where a transaction has been incorrectly sent and needs to be removed from the database. A new transaction would then be submitted using a different UTI.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.8

Examples of transaction reporting

In order to facilitate transaction reporting and the understanding of how to populate the data fields in Table 1 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. Data fields are expected to be reported only when they are 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 may have been covered in this manual.

RSS_Icon Last update: 09/05/2016  

RSS_Icon Subscribe to this Category’s RSS