TRUM – Section 5.6

Data fields related to lifecycle information

This section includes the following fields:

45. Action type

 

Data Field No (45) Action type

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

 

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

 

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

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 7.4

Data fields for identification of location and market participant

This section includes the following fields:

22. Network point identification
23. Bundling
24. Direction
25. TSO 1 identification
26. TSO 2 identification
27. Market participant identification
28. Balancing group or portfolio code

 

Data Field No (22) Network point identification

No. Field Identifier Description
22 Network point identification Within a network system according to the EIC code.

 

Description of Accepted Values Type Length Examples
The codification scheme used for the coded identification is indicated by the coding scheme attribute and shall indicate the code “305” for an EIC measurement point code. Alphanumeric The maximum length of the connection point identification is 35 alphanumeric characters.

The maximum length of the coding scheme is 3 alphanumeric characters.

10Y0000123456789

 

Both the connection point identification and the coding scheme are mandatory.

This field corresponds to the field PROCESS_TRANSACTION.CONNECTIONPOINT.IDENTIFICATION – CODINGSCHEME in the schema.

 

Data Field No (23) Bundling

No. Field Identifier Description
23 Bundling Specification of bundling

 

Description of Accepted Values Type Length Examples
Refer to EDIGAS Code list document for valid codes.

ZEO for Bundled, ZEP  for Unbundled

Alphanumeric Maximum 3 ZEO

 

This field is represented in the Edigas schema as “CapacityType” and the code for “bundled” is “ZEO” and that for unbundled is “ZEP”.

This field is mandatory for auctions.

This field corresponds to the field PROCESS_TRANSACTION.CAPACITYTYPE.CODE in the schema.

 

Data Field No (24) Direction

No. Field Identifier Description
24 Direction Specification of direction.

 

Description of Accepted Values Type Length Examples
Refer to EDIGAS Code list document for valid codes.
Z02 = Input Quantity
Z03 = Output Quantity
Alphanumeric Maximum 3 Z02

 

This field specifies the direction of the transportation transaction. The TSO sells capacity with a direction in both bundled and unbundled capacity. For bundled capacity the direction is that of the reporting TSO’s side.

This field is mandatory.

This field corresponds to the field DIRECTION.CODE in the schema.

 

Data Field No (25) TSO 1 identification

No. Field Identifier Description
25 TSO 1 identification The identification of the TSO for which the data reporting is made.

 

Description of Accepted Values Type Length Examples
The codification scheme used for the coded identification is indicated by the coding scheme attribute and shall indicate the code “305” for an EIC party code. Alphanumeric The maximum length of a responsible TSO’s identification is 16 alphanumeric characters.

The maximum length of the coding scheme code is 3 alphanumeric characters.

10Y0000123456789

 

This field identifies the TSO for which the data reporting is made.

Both the identification and the coding scheme are mandatory.

This field corresponds to the field PROCESS_TRANSACTION.RESPONSIBLETSO_MARKETPARTICIPANT.IDENTIFICATION – CODINGSCHEME in the schema.

 

Data Field No (26) TSO 2 identification

No. Field Identifier Description
26 TSO 2 identification The identification of the counter TSO.

 

Description of Accepted Values Type Length Examples
The codification scheme used for the coded identification is indicated by the coding scheme attribute and shall indicate the code “305” for an EIC party code. Alphanumeric The maximum length of an adjacent TSO’s identification is 16 alphanumeric characters.

The maximum length of the coding scheme code is 3 alphanumeric characters.

10Y0000123456789

 

This field is mandatory if the field 23 is filled in with ZEO.

Both the identification and the coding scheme are dependent.

This field corresponds to the field PROCESS_TRANSACTION.ADJACENTTSO_MARKETPARTICIPANT.IDENTIFICATION – CODINGSCHEME in the schema.

 

Data Field No (27) Market participant identification

No. Field Identifier Description
27 Market participant identification The market participant to which the capacity is assigned.

 

Description of Accepted Values Type Length Examples
The codification scheme used for the coded identification is indicated by the coding scheme attribute and shall indicate the code “305” for an EIC party code. Alphanumeric The maximum length of a primary market participant’s identification is 16 alphanumeric characters.

The maximum length of the coding scheme code is 3 alphanumeric characters.

10X1001A1001A450

 

This field identifies the market participant the capacity is assigned.

This field is mandatory for primary allocations.

This field corresponds to the field PRIMARY_MARKETPARTICIPANT.IDENTIFICATION – CODINGSCHEME in the schema.

 

Data Field No (28) Balancing group or portfolio code

No. Field Identifier Description
28 Balancing group or portfolio code The balancing group (or balancing groups in case of bundled products) to which the shipper belongs or the portfolio code used by the shipper if a balancing group is not applicable.

 

Description of Accepted Values Type Length Examples
The codification scheme used for the coded identification is indicated by the coding scheme attribute and shall indicate the code “ZSO” for a TSO managed code or the code “305” for an EIC Account code. Alphanumeric The maximum length of an internal account’s identification is 35 alphanumeric characters.

The maximum length of the coding scheme code is 3 alphanumeric characters.

 

This field is mandatory and used only where balancing group portfolio or accounts apply. Internal account needs to be reported. “Internal account TSO” code is equivalent to TSO 1 Identification. Internal account is assigned by TSO 1 Identification.

This field corresponds to the field PRIMARY_MARKETPARTICIPANT.ACCOUNT.INTERNALACCOUNT in the schema.

RSS_Icon Last update: 09/05/2016  

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 5.7

Examples of transaction reporting

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 7.5

Data fields applicable only for secondary allocations

This section includes the following fields:

29. Procedure applicable
30. Maximum bid amount
31. Minimum bid amount
32. Maximum quantity
33. Minimum quantity
34. Price paid to TSO (underlying price)
35. Price the transferee pays to the transferor
36. Transferor identification
37. Transferee identification

 

Data Field No (29) Procedure applicable

No. Field Identifier Description
29 Procedure applicable Specification of procedure applicable.

 

Description of Accepted Values Type Length Examples
Refer to EDIGAS Code list document for valid codes.
A01 = CFO, call for orders
A02 = FCFS, first come first served
A03 = OTC, Over the counter
A04 = sublet
Alphanumeric Maximum 3 A01

 

This field is mandatory only in the case of secondary market allocations.

This field corresponds to the field PROCESS_TRANSACTION.SECONDARYMARKET_PROCEDURE.CODE in the schema.

 

Data Field No (30) Maximum bid amount

No. Field Identifier Description
30 Maximum bid amount The maximum the transferee would be willing to offer, expressed in the currency per measure unit.

 

Description of Accepted Values Type Length Examples
The maximum length of this information is 17 numeric characters (decimal mark included). All leading zeros are to be suppressed. Numeric

ISO 6093

17 1.8

 

This field is mandatory for “Call for orders” procedure. This attribute may be used only in the case of a secondary market transaction.

This field corresponds to the field MAXIMUMBID_PRICE.AMOUNT in the schema.

 

Data Field No (31) Minimum bid amount

No. Field Identifier Description
31 Minimum bid amount The minimum the transferor would be willing to offer, expressed in the currency per measure unit.

 

Description of Accepted Values Type Length Examples
The maximum length of this information is 17 numeric characters (decimal mark included). All leading zeros are to be suppressed. Numeric

ISO 6093

17 1.8

 

This field is mandatory for “Call for orders” procedure. This attribute may be used only in the case of a secondary market transaction.

This field corresponds to the field MINIMUMBID_PRICE.AMOUNT in the schema.

 

Data Field No (32) Maximum quantity

No. Field Identifier Description
32 Maximum quantity The maximum the transferee/transferor would be willing to acquire/sell on creating the trade proposal.

 

Description of Accepted Values Type Length Examples
The maximum length of this information is 17 numeric characters (decimal mark included). Numeric

ISO 6093

17 1.8

 

The decimal mark that separates the digits forming the integral part of a number from those forming the fractional part (ISO 6093) shall always be a period (“.”).

All quantities are unsigned values.

This field is mandatory for“Call for orders” procedure. The maximum quantity the transferee/transferor would be willing to acquire/sell. This attribute may be used only in the case of a secondary market transaction.

This field corresponds to the field MAXIMUMBID_QUANTITY.AMOUNT in the schema.

 

Data Field No (33) Minimum quantity

No. Field Identifier Description
33 Minimum quantity The minimum the transferee/transferor would be willing to acquire/sell on creating the trade proposal.

 

Description of Accepted Values Type Length Examples
The maximum length of this information is 17 numeric characters (decimal mark included). All leading zeros are to be suppressed. Numeric

ISO 6093

17 1.8

 

The decimal mark that separates the digits forming the integral part of a number from those forming the fractional part (ISO 6093) shall always be a period (“.”).

All quantities are unsigned values.

This field is mandatory for “Call for orders” procedure. The maximum quantity the transferee/transferor would be willing to acquire/sell. This attribute may be used only in the case of a secondary market transaction.

This field corresponds to the field MINIMUMBID_QUANTITY.AMOUNT in the schema.

 

Data Field No (34) Price paid to TSO (Underlying Price)

No. Field Identifier Description
34 Price paid to TSO (underlying price) Only applicable when there is an assignment expressed in the currency per measure unit which must be kWh/h.

 

Description of Accepted Values Type Length Examples
The maximum length of this information is 17 numeric characters (decimal mark included). All leading zeros are to be suppressed. Numeric

ISO 6093

17 1.8

 

This field indicates the price paid to the TSO.

This field is mandatory if the secondary market procedure (field 29) is CFO, FCFS or OTC.

This field corresponds to the field UNDERLYINGTSO_PRICE.AMOUNT in the schema.

 

Data Field No (35) Price the transferee pays to the transferor

No. Field Identifier Description
35 Price the transferee pays to the transferor Price the transferee pays to the transferor expressed in the currency per measure unit which must be kWh/h.

 

Description of Accepted Values Type Length Examples
The maximum length of this information is 17 numeric characters (decimal mark included). All leading zeros are to be suppressed. Numeric

ISO 6093

17 1.8

 

This field is mandatory for secondary market transactions.

This field corresponds to the field TRANSFER_PRICE.AMOUNT in the schema.

 

Data Field No (36) Transferor identification

No. Field Identifier Description
36 Transferor identification The market participant giving up the capacity.

 

Description of Accepted Values Type Length Examples
The codification scheme used for the coded identification is indicated by the coding scheme attribute and shall indicate the code “305” for an EIC party code. Alphanumeric The maximum length of a transferor market participant’s identification is 16 alphanumeric characters.

The maximum length of the coding scheme code is 3 alphanumeric characters.

10X1001A1001A450

 

This field is mandatory only in the case of secondary market reporting. The Edigas implementation guide only caters for EIC codes, it does not allow any other identification codes.

This field corresponds to the field TRANSFEROR_MARKETPARTICIPANT.IDENTIFICATION – CODINGSCHEME in the schema.

 

Data Field No (37) Transferee identification

No. Field Identifier Description
37 Transferee identification The market participant receiving the capacity.

 

Description of Accepted Values Type Length Examples
The codification scheme used for the coded identification is indicated by the coding scheme attribute and shall indicate the code “305” for an EIC party code. Alphanumeric The maximum length of a transferee market participant’s identification is 16 alphanumeric characters.

The maximum length of the coding scheme code is 3 alphanumeric characters.

10X1001A1001A450

 

This field is mandatory only in case of secondary market reporting.

This field corresponds to the field TRANSFEREE_MARKETPARTICIPANT.IDENTIFICATION – CODINGSCHEME in the schema.

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 6

Reporting of electricity transportation contracts

The reporting of electricity transportation contracts to ACER between two balancing zones within the European Union will be mandatory from 7 April 2016 onwards. In this Chapter, the Agency provides information on how the data fields listed in Table 3 of the Annex to the Implementing Acts should be populated. In subsequent editions of the TRUM, the Agency may also provide further guidance on how to report electricity transportation contracts. It should be noted that Table 3 of the Annex to the Implementing Acts shall be used for the reporting of both standard and non-standard electricity transportation contracts.

It is worth noting that not all the data fields are mandatory for all transactions. Data fields are expected to be populated when applicable according to this manual. The Agency has prepared a list of trading scenarios to show what is expected and applicable to each scenario. The trading scenarios are listed in ANNEX III.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 7.6

Data fields applicable only for orders placed at auctions for primary allocations

This section includes the following fields:

38. Bid ID
39. Auction round number
40. Bid price
41. Bid quantity

 

Data Field No (38) Bid ID

No. Field Identifier Description
38 Bid ID Numerical identifier of the bid as assigned by the reporting entity.

 

Description of Accepted Values Type Length Examples
The format and length of the identifier depends on the reporting entity. Alphanumeric Maximum 35 8552448

 

This field is mandatory. If there is no auction sequence there is no bid. The bid identification should only be present if auction round number is present.

This field corresponds to the IDENTIFICATION field in the schema.

 

Data Field No (39) Auction round number

No. Field Identifier Description
39 Auction round number An integer that increments every time an auction achieves no result and is re-run with different parameters starting at 1. To be left blank in case of auctions without binding rounds, e.g. day-ahead auctions.

 

Description of Accepted Values Type Length Examples
An integer value starting with 1.
1
2
3

999
Integer Maximum 3 1

 

This field identifies the specific order assigned by the System Operator for the capacity rights. In an ascending clock auction this is a sequential value starting from 1 that is assigned by the Auction Office. An integer is a number that is written without a fractional component (for example, 21, 4, and −2048 are integers; 9.75 and 5½ are not integers). In case of uniform price auctions (without biding rounds) the bidding round number should be 1. (e.g. day-ahead auction).

This field is mandatory.

This field corresponds to the SEQUENCE field in the schema.

 

Data Field No (40) Bid price

No. Field Identifier Description
40 Bid price The price bid for each unit of capacity excluding the reserve price. Expressed in the currency and measure unit.

 

Description of Accepted Values Type Length Examples
The maximum length of this information is 17 numeric characters (decimal mark included). All leading zeros are to be suppressed. Numeric

ISO 6093

17 1.8

 

This field indicates the Price Step in case of an auction.

This field is mandatory.

This field corresponds to the field BID_PRICE.AMOUNT in the schema.

 

Data Field No (41) Bid quantity

No. Field Identifier Description
41 Bid quantity The quantity being bid for expressed in the measure unit.

 

Description of Accepted Values Type Length Examples
The maximum length of this information is 17 numeric characters (decimal mark included). All leading zeros are to be suppressed. Numeric

ISO 6093

17 1.8

 

The decimal mark that separates the digits forming the integral part of a number from those forming the fractional part (ISO 6093) shall always be a period (“.”).The number of decimal places identifying the fractional part of the quantity depends on local market rules.

This field is mandatory.

This field corresponds to the field BID_QUANTITY.AMOUNT in the schema.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 1.1

Scope and purpose of the TRUM

The Agency has developed the TRUM to facilitate reporting to the Agency under Regulation (EU) No 1227/2011 (REMIT)[1] in order to ensure operational reliability according to Article 12(1) of REMIT.

Article 5(2) of Commission Implementing Regulation (EU) No 1348/2014[2] (hereafter referred to as ‘the Implementing Acts’) stipulates that the Agency shall explain the details of reportable information referred to in Article 5(1) of the Implementing Acts in a user manual and after consulting relevant parties make it available to the public upon entry into force of the Implementing Acts.

The TRUM is intended to provide market participants with guidance to make informed decisions about their transaction reporting obligations. The TRUM explains the details of the reportable trade data by providing guidance on how to populate the data fields included in the Implementing Acts, including the formats and standards that apply to reporting. The TRUM is not intended to be a replacement of the Implementing Acts.

Given that the Implementing Acts stipulate that only transactions, including orders to trade, in relation to wholesale energy products executed at organised market places will be reported in the first phase of reporting, the first edition of the TRUM focusses on explaining the details of the reportable information related to these contracts and orders to trade. The TRUM also covers the records of transactions in transportation contracts and non-standard supply contracts.

The TRUM and its Annexes will be updated in later editions on the basis of the experience gained by the Agency through the implementation of REMIT, including feedback from market participants and other stakeholders. The Agency anticipates that subsequent updates of the Annex II of TRUM will cover details and examples on reportable information for the second phase of transaction reporting not covered in detail by the first edition.

All subsequent editions of the TRUM will be made publicly available and consulted upon in due time, in accordance with Article 5(2) of the Implementing Acts which states that the Agency shall consult relevant parties on all material updates of the user manual. The Agency also intends to issue a REMIT Quarterly newsletter where inter alia relevant updates regarding transaction reporting obligations will be provided.

The technical and organisational requirements to be fulfilled by reporting entities in order to become a Registered Reporting Mechanism (RRM) will be defined in the Agency’s Requirements for the registration of Registered Reporting Mechanisms (RRM), including the Technical Specifications for RRMs.

Please note that the TRUM does not cover the reporting of fundamental data. For further information in that regard, please consult the Manual of Procedures on transaction and fundamental data reporting which, in accordance with Article 10(3) of the Implementing Acts, establishes procedures, standards and electronic formats for the reporting of transaction and fundamental data.


[1] OJ L 326, 8.12.2011, p.1.

[2] OJ L 363, 18.12.2014, p. 121.

 

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  

RSS_Icon Subscribe to this Category’s RSS