Please insert at least 3 characters

TRUM – Section 7.3

Data fields for quantity and price reporting

This section includes the following fields:

15. Quantity
16. Measure unit
17. Currency
18. Total price
19. Fixed or floating reserve price
20. Reserve price
21. Premium price

 

Data Field No (15) Quantity

No. Field Identifier Description
15 Quantity Total number of units allocated with the transportation transaction as expressed in the measure unit.

 

Description of Accepted Values Type Length Examples
A decimal point value may be used to express values that are inferior to the defined unit of measurement.

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.

Numerical The maximum length of this information is 17 numeric characters (decimal mark included). All leading zeros are to be suppressed.

The number of decimal places identifying the fractional part of the quantity depends on local market rules.

20.5

 

This field is mandatory.

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

 

Data Field No (16) Measure unit

No. Field Identifier Description
16 Measure unit The unit of measurement used.

 

Description of Accepted Values Type Length Examples
Refer to EDIGAS Code list document for valid codes.
KW1 = Kilowatt – hour per hour (kWh/h)
KW2 = Kilowatt – hour per day (kWh/d)
HM1 = Million cubic meters per hour
HM2 = Million cubic meters per day
TQH = Thousand cubic meters per hour
TQD = Thousand cubic meters per day
MQ6 = Normal cubic meters per hour
MQ7 = Normal cubic meters per day
KWH = Kilowatt hour (KWh)
GWH= Gigawatt hour (GWh)
Alphanumeric Maximum 3 KW1

 

The unit of measurement used for all the quantities expressed within a time series.

This field is mandatory.

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

 

Data Field No (17) Currency

No. Field Identifier Description
17 Currency The currency in which the monetary amount is expressed.

 

Description of Accepted Values Type Length Examples
Refer to EDIGAS Code list document for valid codes. List of international ISO 4217 currency codes. Maximum 3 EUR

 

This field identifies the currency in which the monetary amount is expressed (currency of the price using the smallest denomination in the currency system). The schema only accepts one value for this field. The reported currency is always expressed in EUR.

This field is mandatory.

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

 

Data Field No (18) Total price

No. Field Identifier Description
18 Total price Reserve price at time of the auction plus auction premium or regulated tariff in case of other allocation mechanism than auction.

 

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 total price. Each TSO would reports one leg of bundled transaction. Those transactions are matched through data field no 5, i.e. transportation transaction identification.

This field is mandatory.

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

 

Data Field No (19) Fixed or floating reserve price

No. Field Identifier Description
19 Fixed or floating reserve price Identification of the type of the reserve price.

 

Description of Accepted Values Type Length Examples
Refer to EDIGAS Code list document for valid codes.
Z07 =  Fixed Price
Z08 = Floating Price
Alphanumeric Maximum 3 Z07

 

This field is mandatory if there is a reserve price (field 20).

This field corresponds to the field RESERVE_PRICE.TYPE in the schema.

 

Data Field No (20) Reserve price

No. Field Identifier Description
20 Reserve price The identification of the reserve price for the auction.

 

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 identifies the reserve price for the auction. Each TSO would report one leg of bundled transaction.

This field is mandatory for auctions.

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

 

Data Field No (21) Premium price

No. Field Identifier Description
21 Premium price The identification of the premium price for the auction.

 

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 additional amount on top of the reserve price as agreed between TSO and the market participant. Each TSO would report one leg of bundled transaction.

This field is mandatory for auctions.

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

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

Examples of transaction reporting

In order to facilitate transaction reporting and the understanding of how to populate the data fields in Table 4 of the Annex to the Implementing Acts, the Agency provides a number of examples of transaction reports. The examples can be found in ANNEX III 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.

The Agency will continue to work with relevant stakeholders on the reporting of gas transportation contracts and will provide more detailed information on this topic in subsequent editions of the TRUM, including additional trading scenarios in Annex II.

RSS_Icon Last update: 09/05/2016  

TRUM – Annex I

Data fields included in the draft Implementing Acts

.

Table 1

Reportable details of standard contracts for the supply of electricity and gas (Standard reporting form)

Field No. Field Identifier Description
Parties to the contract
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.
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).
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.
4 ID of the other market participant or counterparty Unique identifier for the other counterparty of the contract.
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).
6 Reporting entity ID ID of the reporting entity.
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).
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.
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).
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.
11 Buy/sell indicator Identifies whether the contract was a buy or sell for the market participant or counterparty identified in field 1.
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.
    Order details
13 Order ID The order shall be identified by using a unique code identifier provided by the market place or counterparties.
14 Order type The type of order as defined by the functionality offered by the organised market place.
15 Order condition A special condition for the order to execute.
16 Order status The status of the order, for example if order is active or deactivated.
17 Minimum execution volume Minimum Execution Volume – The quantity / volume of any defined minimum execution.
18 Price limit The defined price of the limit for the trigger or stop loss order.
19 Undisclosed volume The volume that is not disclosed to the market for the order.
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.
    Contract details
21 Contract  ID The contract shall be identified by using a unique code identifier provided by the market place or counterparties.
22 Contract name The name of the contract as identified by the organised market place.
23 Contract type The type of the contract.
24 Energy commodity The classification of the energy commodity.
25 Fixing index or reference price Fixing index that sets the price for the contract or the reference price for derivatives.
26 Settlement method Whether the contract is settled physically, in cash, optional or other.
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.
28 Contract trading hours The trading hours of the contract.
29 Last trading date and time The last trading date and time for the reported contract.
    Transaction details
30 Transaction timestamp The date and time of the contract execution or order submission, or their modification, cancellation or termination.
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.
32 Linked transaction ID The linked transaction identifier must identify the contract that is associated with the execution.
33 Linked order ID The linked order identifier must identify the order that is associated with the execution.
34 Voice-brokered Indicates whether the   transaction was voice brokered, “Y” if it was, left blank if it was not.
35 Price The price per unit.
36 Index value The value of the fixing index.
37 Price currency The manner in which the price is expressed.
38 Notional amount Value of the contract.
39 Notional currency The currency of the notional amount.
40 Quantity / Volume Total number of units included in the contract or order.
41 Total notional contract quantity The total number of units of the wholesale energy product.
42 Quantity unit for field 40 and 41 The unit of measurement used for fields 40 and 41.
43 Termination date Termination date of the reported contract. If not different from delivery end date, this field shall be left blank.
    Option details
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).
45 Option type Indicates whether the option is a call, put or other.
46 Option exercise date The date or dates when the option is exercised. If more than one, further fields may be used.
47 Option strike price The strike price of the option.
    Delivery profile
48 Delivery point or zone EIC code(s) for the delivery point(s) or market area(s).
49 Delivery start date Start date of delivery.
50 Delivery end date End date of delivery.
51 Duration The duration of the delivery period.
52 Load type Identification of the delivery profile (base load, peak load, off-peak, block of hours or other)
53 Days of the week The days of the week of the delivery
54 Load delivery Intervals Time interval for each block or shape.
55 Delivery capacity The number of units included in the transaction, per delivery time interval.
56 Quantity unit used in field 55 The unit of measurement used.
57 Price/time interval quantity If applicable price per quantity per delivery time interval.
    Lifecycle information
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 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 or order to trade, it will be identified as ‘cancel’;

.

Table 2

Reportable details of non-standard contracts for the supply of electricity and gas
(Non-standard reporting form)

Field No. Field Identifier Description
Parties to the contract
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.
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)
3 ID of the other market participant or counterparty Unique identifier for the other counterparty of the contract.
4 Type of code used in field 3 ACER registration code, Legal Entity Identifier (LEI),Bank Identifier Code (BIC), Energy Identification Code (EIC), Global Location Number (GLN/GS1)
5 Reporting entity ID ID of the reporting entity.
6 Type of code used in field 5 ACER registration code, Legal Entity Identifier (LEI),Bank Identifier Code (BIC), Energy Identification Code (EIC), Global Location Number (GLN/GS1)
7 Beneficiary ID If the beneficiary of the contract as referred in Article 8(1) of Regulation (EU) No 1227/2011 is counterparty to this contract the field is to be left blank.  If the beneficiary of the contract is not counterparty to this contract the reporting counterparty has to identify the beneficiary by a unique code.
8 Type of code used in field 7 ACER registration code, Legal Entity Identifier (LEI),Bank Identifier Code (BIC), Energy Identification Code (EIC), Global Location Number (GLN/GS1)
9 Trading capacity of the market participant or counterparty in field 1 Identifies whether the reporting counterparty has concluded the contract as principal on own account (on own behalf or behalf of a client) or as agent for the account of and on behalf of a client.
10 Buy/sell indicator Identifies whether the contract was a buy or sell for the market participant or counterparty identified in field 1.
    Contract details
11 Contract ID Unique identifier for the contract as assigned by the two market participants.
12 Contract date The date the contract was agreed or its modification, cancellation or termination.
13 Contract type The type of contract.
14 Energy commodity The classification of the energy commodity for the agreed contract.
15 Price or price formula Fixed price or price formula used in the contract.
16 Estimated notional amount Estimated notional amount of the contract (if applicable).
17 Notional currency The currency of the estimated notional amount.
18 Total notional contract quantity The estimated total number of units of the wholesale energy product. This is a calculated figure.
19 Volume optionality capacity The number of units included in the contract, per delivery time interval if available.
20 Notional quantity unit The unit of measurement used in fields 18 and 19.
21 Volume optionality The volume classification.
22 Volume optionality frequency The frequency of the volume optionality: e.g. daily, weekly, monthly, seasonal, annual or other, if available.
23 Volume optionality intervals Time interval for each volume optionality if available.
    Fixing index details
24  Type of index price Price classified as fixed, simple index (single underlying) or complex price formula (multiple underlying).
25 Fixing index List of indices determining the price in the contract. For each Index specify the name.  In case of a basket of indices for which no unique identifier exist the basket or the index shall be indicated.
26 Fixing index types Spot, forward , swap, spread, etc.
27 Fixing index sources For each index specify the publication source.
In case of basket of indices for which no unique identifier exist the basket or the index shall be indicated.
28 First fixing date First fixing date determined by the earliest date of all the fixings.
29 Last fixing date Last fixing date determined by the latest date of all the fixings.
30 Fixing frequency The frequency the fixing: e.g. daily, weekly, monthly, seasonal, annual or other.
31 Settlement method Whether the contract is settled physically, in cash, both, optional or other.
    Option details
32 Option style Indicates whether the option may be exercised at a fixed date (European and Asian style), a series of pre-defined dates (Bermudan) or at any time during the life of the contract (American).
33 Option type Indicates whether the option is a call, put or other.
34 Option first exercise date First exercise date determined by the earliest date of all the exercises.
35 Option last exercise date Last exercise date determined by the latest date of all the exercises.
36 Option exercise frequency The frequency of the Volume optionality: e.g. daily, weekly, monthly, seasonal, annual or other.
37 Option strike index For each Index specify the name.  In case of a basket of indices for which no unique identifier exist the basket or the index shall be indicated.
38 Option strike index type Spot, forward , swap, spread, etc.
39 Option strike index source For each index specify the fixing type. In case of a basket of indices for which no unique identifier exist the basket or the index shall be indicated.
40 Option strike price The strike price of the option.
    Delivery profile
41 Delivery point or zone EIC code(s) for the delivery point(s) or market area(s).
42 Delivery start date Start date and time of delivery. For physically delivered contracts this would be the delivery start date of the contract.
43 Delivery end date End date and time of delivery. For physically delivered contracts this would be the end delivery date of the contract.
44 Load type Identification of the delivery profile (base load, peak load, off-peak, block of hours or other).
    Life cycle information
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’.

 

Table 3

Reportable details of wholesale energy products in relation to the  transportation of electricity –
Primary allocation results and result of secondary market resale and transfer of long term transmission rights in electricity

Field no Field identifier Description
    Common data for total primary allocation results and secondary market resale and transfer rights and bid document
1. Document identification Unique identification of the document for which the time series data is being supplied.
2. Document version Version of the document being sent. A document may be sent several times, each transmission being identified by a different version number that starts at 1 and increases sequentially.
3. Document type The coded type of the document being sent.
4. Sender identification Identification of the party that is the sender of the document and is responsible for its content (EIC code).
5. Sender role Identification of the role that is played by the sender, e.g. TSO other reporting entity.
6. Receiver identification Identification of the party who is receiving the document.
7. Receiver role Identification of the role played by the receiver.
8. Creation date and time Date and time of the creation of the document, e.g. when the TSO or other reporting entity sends the transaction to the Agency.
9. Bid time interval/applicable time interval The beginning and ending date and time of the period covered by the document.
10 Domain The domain covered within the document.
11. Document status (if applicable) Identifies the status of the document.
    Capacity allocation time series (for primary allocation)
12. Time series identification The identification that uniquely identifies the time series.
13. Bid document identification The identification of the document in which the bids or resale references are contained.
14. Bid document version Version of the bid or resale document having been sent.
15. Bid identification The identification of the time series that was used in the original bid or resale.

This is the unique number that is assigned by the bidder when they made their original bid or resale. Left blank if not applicable.

16. Bidding party Identification of the market participant who bid for the capacity or resold capacity (EIC X Code).
17. Auction identification The identification linking the allocation to a set of specifications created by the auction operator.
18. Business type Identifies the nature of the time series.
19. In area The area where the energy is to be delivered (EIC Y Code).
20. Out area The area where the energy is coming from (EIC Y Code).
21. Contract type The contract type defines the conditions under which the capacity was allocated and handled, e.g. daily auction, weekly auction, monthly auction, yearly auction, long term contract, etc.
22. Contract identification The contract identification of the time series instance. This must be a unique number that is assigned by the auction operator and shall be used for all references to the allocation.
23. Measure unit quantity The unit of measure in which the quantity in the time series is expressed.
24. Currency (if applicable) The currency in which the monetary amount is expressed.
25. Measure unit price (if applicable) The unit of measure in which the price in the time series is expressed.
26. Curve type(if applicable) Describes the type of the curve that is being provided for the time series in question, e.g. variable sized block or fixed sized block or point.
27. Classification category (if applicable) The category of the product as defined by the market rules.
    No-Bid auction time series (for primary allocation)
28. Identification The identification of a time series instance.
29. Auction identification The identification of the auction where no bids have been received.
30. Classification category (if applicable) The category of the product as defined by the market rules.
    Secondary rights time series (for secondary rights)
31. Time series identification The identification of the time series instance. This must be a unique number that is assigned by the sender for each time series in the document.
32. Business type Identifies the nature of the time series, e.g. capacity rights, capacity transfer notification, etc.
33. In area The area where the energy is to be delivered (EIC Y Code).
34. Out area The area where the energy is coming from (EIC Y Code).
35. Rights holder Identification of the market participant who is owner of, or has the right to use, the transmission rights in question (EIC X Code).
36. Transferee party (if applicable) Identification of the market participant to whom the rights are being transferred or the interconnection trade responsible designated by the transferor (as designated in the rights holder attribute) to use the rights (EIC X code).
37. Contract identification The contract identification of the time series instance. This must be the number that has been assigned by the transmission capacity allocator e.g. TSO or auction operator, or allocation platform.
38. Contract type The contract type defines the conditions under which the rights were allocated and handled, e.g. daily auction, weekly auction, monthly auction, yearly auction, etc.
39. Previous contract identification (if applicable) The identification of a previous contract used to identify the transfer rights.
40. Measure unit quantity The unit of measure in which the quantity in the time series is expressed.
41. Auction identification (if  applicable)
42. Currency (if applicable) The currency in which the monetary amount is expressed.
43. Measure unit price (if applicable) The unit of measure in which the price in the time series is expressed.
44. Curve type (if applicable) Describes the type of the curve that is being provided for the time series in question, e.g. variable sized block or fixed sized block or point.
    Period for primary allocation and secondary processes
45. Time interval This information provides the date and time of the start and end of the reported period.
46. Resolution The resolution defining the number of periods that the time interval is divided (ISO 8601).
    Interval for primary allocation and secondary processes
47. Position The relative position of a period within an interval.
48. Quantity The quantity that has been allocated in the primary auction. The quantity that has been assigned to the nomination party for secondary rights.
49. Price amount (if applicable) The price expressed for each unit of quantity allocated through the primary allocation. The price expressed for each unit of quantity resold or transferred on the secondary market if applicable.
50. Bid quantity (if applicable) The quantity that was in the original bid document.
51. Bid price amount (if applicable) The original price expressed in the original bid or resale for each unit of quantity requested.
    Reason for primary allocation and secondary processes
52. Reason code (if applicable) A code providing the status of the allocation or the rights.
53. Reason text (if applicable) Textual explanation of the reason code.
    Bid header document and bid document fields for organised market places (applicable for secondary trading)
54. Subject party The market participant for whom the bid is being submitted (EIC code).
55. Subject role The role of the subject party.
56. Divisible An indication whether or not each element of the bid may be partially accepted or not.
57. Linked bids identification (if applicable) Unique identification associated with all linked bids.
58. Block bid An indication that the values in the period constitute a block bid and that they cannot be changed.

 

Table 4

Reportable details of wholesale energy products in relation to the transportation of gas – Primary and secondary capacity allocations for gas

Field no Field identifier Description
    Common data for primary and secondary allocation processes
1. Sender identification Identification of the party that is the owner of the document and is responsible of its content.
2. Organised market place identification Identification of organised market place.
3. Process identification The identification of the auction or other process as defined by the capacity allocating entity.
4. Type of gas Identifies the type of gas.
5. Transportation transaction identification A uniquely assigned identification number for the capacity allocation as assigned by the organized market place or TSO.
6. Creation date and time Creation date and time of the transaction.
7. Auction open date/time The date and time when an auction opens for bidding.
8. Auction end date/time The date and time when an auction closes.
9. Transportation transaction Type The type identifies the nature of transportation transaction to be reported in accordance with current applicable industry standards as specified by gas network code on Interoperability and data exchange.
10. Start date and time Date and time of the start of the transportation transaction runtime.
11. End date and time Date and time of the end of the transportation transaction runtime.
12. Offered capacity The quantity of capacity available in the auction expressed in the measure unit. Only relevant for bidding behaviour monitoring.
13. Capacity category Applicable capacity category
    Data for lifecycle reporting
14. Action type Status code of the report to be reported in accordance with current applicable industry standards as specified in gas network code on Interoperability and data exchange.
    Data for quantity and price reporting
15. Quantity Total number of units allocated with the transportation transaction as expressed in the measure unit.
16. Measure unit The unit of measurement used.
17. Currency The currency in which the monetary amount is expressed.
18. Total price Reserve price at time of the auction plus auction premium or regulated tariff in case of other allocation mechanism than auction.
19. Fixed or floating reserve price Identification of the type of the reserve price.
20. Reserve price The identification of the reserve price for the auction.
21. Premium price The identification of the premium price for the auction.
    Data for identification of location and market participant
22. Network point identification Within a network system according to the EIC code.
23. Bundling Specification of bundling.
24. Direction Specification of direction.
25. TSO 1 identification The identification of the TSO for which the data reporting is made.
26. TSO 2 identification The identification of the counter TSO.
27. Market participant identification The market participant to which the capacity is assigned.
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.
    Data applicable only for secondary allocations
29. Procedure applicable Specification of procedure applicable.
30. Maximum bid amount The maximum the transferee would be willing to offer, expressed in the currency per measure unit.
31. Minimum bid amount The minimum the transferor would be willing to offer, expressed in the currency per measure unit.
32. Maximum quantity The maximum the transferee/transferor would be willing to acquire/sell on creating the trade proposal.
33. Minimum quantity The minimum the transferee/transferor would be willing to acquire/sell on creating the trade proposal.
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.
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.
36. Transferor identification The market participant giving up the capacity.
37. Transferee identification The market participant receiving the capacity.
Data fields applicable only for orders placed at auctions for primary allocations
38. Bid ID Numerical identifier of the bid as assigned by the reporting entity.
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.
40. Bid price The price bid for each unit of capacity excluding the reserve price. Expressed in the currency and measure unit.
41. Bid quantity The quantity being bid for expressed in the measure unit.

[Download PDF]

RSS_Icon Last update: 08/01/2015  

TRUM – Annex II

Examples of Transaction Reporting

 

For actual examples, please download the PDF version of Annex II

 

Version history

Version Effective Date
Annex II Version 1.0 06 May 2015
Annex II Version 2.0 30 September 2015
Annex II Version 2.0*

*(with comments on non-standard contract examples)

16 November  2015
Annex II Version 2.1

(included additional non-standard contract examples an corrected a few typos in non-standard examples)

15 February 2016
Annex II Version 3.0

(included Electricity and Gas transportation contract examples)

23 March 2016

 

Introduction

Annex II to the TRUM presents examples of transaction reporting for both standard and non-standard contracts. The examples reported in this Annex show what has to be included in the transaction reports of wholesale energy products traded on auction and continuous markets, through broker platforms (both on screen and voice brokered) and through bilateral trades.

Please note that in case reporting entities consulting this document do not find relevant transaction reporting examples below, they should submit a query to the Agency, describing a trading scenario and their suggestion on what to report for each specific transaction. A template for the submission of additional trading examples, which will be added to this Annex, is available on ACER portal at https://www.acer-remit.eu/portal/data-submission and it can be sent to transaction.reporting@acer.europa.eu for discussion.

 

The structure of Annex II

Annex II is composed of three sections: Section (1), Section (2) and Section (3).

Section (1) relates to Table 1 of the REMIT Implementing Acts and Section (2) relates to Table 2 of the REMIT Implementing Acts as described below:

 

a) Section (1): reporting of orders and contracts with Table 1 of REMIT Implementing Acts Annex:

  1. Index of examples included in Section 1
  2. Example of transactions executed on auction markets
  3. Example of transactions executed on continuous markets
  4. Example of transactions executed through brokers (including voice brokered trades)
  5. Examples of bilateral transactions executed off-market
  6. Examples of delivery profiles for both gas and electricity transactions

 

b) Section (2): reporting of contracts with Table 2 of REMIT Implementing Acts Annex.

  1. Index of examples included in Section 2
  2. Example of non-standard contracts

 

c) Section (3) relates to Table 3 and Table 4 of the REMIT Implementing Acts as described below:

  1. Index of examples included in Section 3
  2. Example of Electricity Transportation Contracts
  3. Example of Gas Transportation Contracts

 

The different parts of Table 1 and Table 2

Table 1 of the REMIT Implementing Acts Annex is composed of seven sections:

  1. Parties to the contract
  2. Order details
  3. Contract details
  4. Transaction details
  5. Option details
  6. Delivery profile
  7. Lifecycle information

 

The six parts of Table 2

Table 2 of the REMIT Implementing Acts Annex is composed of six sections:

  1. Parties to the contract
  2. Contract details
  3. Fixing index details
  4. Option details
  5. Delivery profile
  6. Lifecycle information

 

Trading scenarios

The present Annex shows what has to be reported according to the REMIT Implementing Acts Annex Table 1 and Table 2.

Trading scenarios included in Annex II encompass orders to trade and contracts (both standard and non-standard contracts). Annex II shows what has to be reported for a specific trading scenario while the technical implementation, i.e. how to report a trading scenario is not covered in this Annex.

All the fields and their content reported in the examples below are mandatory for each type of transaction. Fields that are blank are not required to be reported for that type of transaction. If a transaction report includes additional or fewer fields than those reported in each trading scenario, that transaction needs to be covered by another example.

It is responsibility of the reporting parties to make sure their transaction reports comply with the examples reported in this Annex. If reporting parties cannot find trading examples representing their own transactions in this Annex, they should contact the Agency.

They can  submit their representation of the trading scenarios concerned using the form available at https://www.acer-remit.eu/portal/data-collection and sending it to transaction.reporting@acer.europa.eu

However, before reporting parties submit their queries they should make sure that there are not any examples in this Annex or any combinations of them which may already represent their reports. Reporting parties may combine, for example, the data fields from one section e.g. Contract details or Transaction details with data fields from Delivery profile from another scenarios.

For example: if a 15 minutes contract trading scenario is not represented in the examples of transactions executed on continuous markets, this should not prevent the reporting party from using the 15 minutes delivery profile details used in the examples of transactions executed on auction markets.

For complex delivery profile details the Agency will create additional trading scenarios in this Annex under the section “Examples of delivery profiles for both gas and electricity transactions” when necessary.

As the list of examples represented in this Annex will not be able to cover all possible trading scenarios, combining them should enable the majority of scenarios to be represented.
It is ultimate the responsibility of market participants and reporting parties to contact the Agency in case they have any doubt concerning what to include in their trading reports.

As regards the technical implementation of transaction reporting and the submission of the XML file, market participants and reporting parties should refer to the Manual of Procedure available at https://www.acer-remit.eu/portal/acer-documents.

Please read carefully

The fields reported in the trading examples below are mandatory for each type of transaction. Blank fields in the examples are not expected to be populated when reported for that type of transaction.

In some circumstances reporting parties may provide additional information not required or described in the trading examples simply because it is easier to report what it is in their system rather than make a selection of it. This may be the case for the field Total notional amount in the order report. Reporting parties may decide to report this value in the order to trade report even if this field is not required At the condition that these do not violate the validation rules set by the Agency. Please contact your RRM to discuss this further. (sentences were rearranged)

In general the Agency will not reject the file because it contains additional information not required unless this is incompatible with the data validation rules available to the RRMs.

For phase one (starting on October 7 2015) of REMIT transaction reporting, as regards the technical implementation of transaction reporting, the submission of the XML files, market participants should liaise with the RRMs which will submit the reports on their behalf. For phase two (starting on April 7 2016) of REMIT transacting reporting, i.e. the submission of trades occurred outside organised markets, market participant may gain access to the technical standards if they decide to report their own transactions as an RRM.

 

Clarification of standard vs non-standard contract

 

(1) Trades not reported under EU financial legislations

(2) Contracts that are admitted to trade at Organised Market Places

(3) Details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price shall be reported using Table 1 of the Annex to the IAs.

 

Decision tree for the reporting of standard and not standard contracts and the use of Table 1 or Table 2

 

Reporting bilateral contracts traded outside organised market places, executions under non-standard contracts and back loading of standard contracts: Table 1.

In order to facilitate the reporting of bilateral contracts traded off-organised market places (standard and non-standard contracts with a defined price and quantity), back loading of standard contracts and execution under non-standard contracts the validation rules for these bilateral contracts are more relaxed than those for orders to trade and trades executed on organised market places.

Market participants and reporting parties reporting bilateral contracts traded off-organised market places, back loading of standard contracts and execution under non-standard contracts have to be reported with Table 1 of the Annex to the Implementing Acts. Market participants and reporting parties are expected to report the value of “BILCONTRACT”, “BACKLOADING” or “EXECUTION” in field 22 (Contract Name) according to the trading scenarios available in this ANNEX.

Please note that Article 5(1) of the Implementing Acts states that “Details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price shall be reported using Table 1 of the Annex”. This implies that even if a contract is considered a non-standard contract (reportable no later than 30 days from its execution ) but has an agreed price and quantity, the contract has to be reported using Table 1 of the Implementing Acts. See point 3.2.5 of the TRUM.

“BILCONTRACT”: should be reported in field 22 (Contract Name) of Table 1 to identify standard contracts and non-standard contracts (that have a defined price and quantity) that are traded outside the organised market places.

”BACKLOADING”: should be reported in field 22 (Contract Name) of Table 1 to identify the reporting of details of wholesale energy contracts which were concluded before the date on which the reporting obligation becomes applicable and remain outstanding on that date shall be reported to the Agency within 90 days after the reporting obligation becomes applicable for those contracts.

In the Agency’s view outstanding contracts are those contracts that have an outstanding physical or financial flow as defined by the contract and not by the settlement of invoice date. For futures and other derivatives, the Agency would expect to see the positions that are technically still “open” and that can be still trade out or to be settled. Please see also “Additional clarification on the back loading requirement” available in the TRUM (point 3.2.7).

“EXECUTION”: should be reported in field 22 (Contract Name) of Table 1 to identify the reporting of the details of transactions executed within the framework of non-standard contracts specifying that transactions can to be reported on a monthly basis. Executions under non-standard contracts are not subject to back loading reporting.

For the purpose of the reporting of the details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price, reportable with Table 1 of the Annex to the Implementing Acts, the Agency understands that these transactions should be reported according to the billing cycle industry standards as the invoicing date is the last point in time that price and quantity can be discovered.

The Agency understands that the billing cycle industry standards refer to calendar months and therefore twelve transactions per year (if the executions take place every month of the year) are expected to be reported no later than 30 days after the discovery of price and quantity. However, nothing prevents market participant from reporting the details of transactions executed within the framework of non-standard contracts on a more frequent basis even if the Agency would not expect it.

Reporting of non-standard contracts: Table 2

For the reporting of non-standard contracts and execution under non-standard contracts the Agency has widely consulted its stakeholders which have provided valuable input to this guidance. The Agency and the industry aligned their understanding of the reporting of non-standard contracts and execution under non-standard contracts and have created some basic rules for their reporting.

For the purpose of the reporting on non-standard contracts that do not have a defined price and quantity (at the time entering into the contract), non-standard contracts may have different characteristic base on:

a) volume scenarios;
b) price scenarios; and
c) delivery scenarios.

Each of the above scenarios has some variations; their descriptions can be found below. In the contract scenario descriptions below each volume scenario is represented by scenarios (V1) to (V5), each price scenario by scenarios (P1) to (P5) and each delivery scenario by scenarios (D1) to (D4).

a) Volume Scenarios

1. Fixed Flat Volume Scenario (V1): Supply to a customer in Europe for a term of one calendar year (e.g. 2015) with a fixed daily supply. No customer volume optionality.

2. Simple Nominated Volume Scenario (V2): The customer must nominate changes in offtake within a defined period prior to delivery period. In this example, the delivery is for calendar year 2015 and customer sends a monthly nomination three days before the start of the delivery month. Offtake nomination must be within a contract defined MIN /MAX range.

3. Cascade Nominated Volume Scenario (V3): The customer can choose to nominate changes in offtake using a time-cascade of deadlines. Customer could nominate next month delivery three days before the end of the month prior to delivery month or choose to nominate volume day ahead or could use a combination of both, nominating “certain” volume month ahead and refining that offtake with day ahead nominations. In this example delivery is for calendar year 2015. Offtake nomination must be within a contract defined MIN /MAX range.

4. Not Nominated (full supply) Volume Scenario (V4): Customer takes the volume required at the factory gate without giving any prior nomination of offtake. There will be an estimated profile provided before the contract deliveries begin but on any day offtake can be anywhere between zero and the capacity of the pipeline feeding the plant.

5. Fixed Shape Volume Scenario (V5): Customer contract defines the daily volume that will be delivered during the summer and a separate (different) daily volume that will be delivered during the winter. The customer has no flexibility to change the defined seasonal deliveries – daily delivered volume will be the same for every day of the season.

b) Price Scenarios

1. Fixed Price Scenario (P1): Supply customer for a term of one calendar year at a fixed price of Eur20 / unit for the year.

2. Trigger Price Scenario (P2): The customer can choose to fix the price of a future delivery period at the closing forward price (e.g. as published by Heren) for that forward period on the day the trigger is pulled. However if the price is not fixed, the contract price will default to a contract specified index, say day ahead.

3. Index Basket Scenario (P3): Contract price is determined by a basket of indexes where for the index basket there is a specified period (for calculation of average of closing prices), a specified period between the end of the calculation period and the beginning of the delivery period (the “lag”) and a specified delivery period that the calculated price applies to. This example would be a Calendar year 2015 delivery with calculation averaging over three months and delivery beginning immediately after end of averaging period and calculated price applied to three month period (3-0-3).

4. Index Switch Scenario (P4): Contract price is determined by one of two defined indexes where the customer can nominate 3 days prior to the pricing period which of the two indexes should be used for the calculation. For the chosen index there is a specified period (for calculation of average of closing prices), a specified period between the end of the calculation period and the beginning of the delivery period (the “lag”) and a specified delivery period that the calculated price applies to. This example would be a Calendar year 2015 delivery with calculation averaging over three months and delivery beginning immediately after end of averaging period and calculated price applied to three month period (3-0-3).

5. Simple Index Scenario (P5): Contract for calendar 2015 delivery Contract price for the month of delivery is calculated as the average closing price of the front month futures contract for the last calendar month of trading days prior to the month of delivery i.e. January 2015 delivery price is the average of the January 2015 Futures closing prices during the month of December 2014.

c) Delivery Scenarios

1. Fixed Delivery Scenario (D1): Delivery to a single identified delivery point, over one year period with same volume delivered every hour of every day.

2. Delivery Point Switching Scenario (D2): Customer can choose to be 100% supplied at one of two contract specified location’s (with two separate EIC codes) and must nominate choice 3 days before delivery starts for the next month and choice will remain until earlier of either end of contract or new nomination 3 days before new month when new choice will take effect.

3. Multiple Fixed Point Delivery Scenario (D3): Same as Fixed Delivery scenario but delivery is split using fixed percentages (that add up to 100%) between three different locations and the fixed percentages cannot change during the contract term.

4. Multiple Variable Point delivery Scenario (D4): Same as Multiple fixed point delivery scenario but the customer can change the percentage split (possible for up to two percentages to be 0% but total must add up to 100%) between three different locations and the customer must nominate choice 3 days before delivery starts for the next month and choice will remain until earlier of either end of contract or new nomination 3 days before new month when new choice will take effect.

Table 1: Volume: contract scenarios with some example values for relevant fields

V1 V2 V3 V4 V5
Field # Fixed Flat Simple Nominations Cascaded Nominations No-nominations

(Full Supply)

Fixed Shape
Short definition: If volume, shape and duration known them populate, otherwise blank
18 Total notional contract quantity volume x days blank blank blank (Winter daily vol. x days) + (Summer daily vol. x days)
Short definition: Indicate either agreed volume or maximum / minimum values, as stated in the contract, otherwise blank
19 Volume optionality capacity 100 0-2400 0-2400 blank 100,000 and 400,000
20 Notional quantity unit MW MW MW Therms MCM
Short definition: See definition in the TRUM: reflect type of volume optionality
21 Volume optionality F M M V F
Short definition: How often can customer exercise optionality
22 Volume optionality frequency blank M M,D blank blank
Short definition: The first date that a customer can exercise their optionality and also the last possible date in the contract term that optionality can be exercised.
23 Volume optionality intervals blank 29-12-2014 / 28-11-2015 29-12-2014 / 30-12-2015 blank blank

Please note that “blank” means empty field

 

Table 2: Price: contract scenarios with some example values for relevant fields

P1 P2 P3 P4 P5
Field #   Fixed Trigger Index Basket Index Switch Simple Index
15 Price or price Formula 20 Simplified Formula Simplified Formula Simplified Formula Simplified Formula
If volume, shape, price and duration are known on the contract date then populate, otherwise blank
16 Estimated notional amount Price x daily volume x days Blank Blank Blank (Price x Winter daily vol. x winter days) + (Price x summer daily vol. x summer days)
17 Notional currency EUR EUR EUR GBP EUR
If volume, shape, price and duration are known on the contract date then populate, otherwise blank
24  Type of index price F O C C I
List all indexes used in the formula (if there is one) otherwise blank
25 Fixing index Blank Blank GO FM mid,NG FM mid,  CPI UK GO FM mid or NG FM mid FM Close
Futures, Forward or other. Completed in sequence (field 24 to 30) for each index
26 Fixing index types Blank DAH FU, FW, OT FU or FW FU
Publication. Completed in sequence (field 24 to 30) for each index
27 Fixing index sources Blank Heren ICE, Heren, UK Stats ICE or Heren ICE
First date when the first price is included for the calculation of that index – e.g. For a front month index (average of closing prices for last month before expiry) then January’15 Front month will be the average of closing Jan Futures prices averaged from 1st December to 26th December so this field would be populated as 01-12-2014
28 First fixing date Blank 2014-12-01 2014-12-01 2014-12-01 2014-12-01
Similar to Field 28 but the last day. So if contract is calendar 2015 deliveries with front month pricing then last date would be the last pricing date of December ’15 futures contract, say, 27 November 2015, so populate field as 27-11-2015
29 Last fixing date Blank 2015-12-30 2015-09-30 2015-09-30 2015-11-27
How long is the closing price averaging period
30 Fixing frequency Blank O Q Q M

Please note that “blank” means empty field

 

Table 3: Delivery: contract scenarios with some example values for relevant fields

D1 D2 D3 D4
Field # Fixed Delivery switch Multiple points

 (Fix %)

Multiple points

(Variable %)

table 2 fields do not enable you to distinguish between switching between delivery points or adjusting the volume delivered at multiple points, so include all delivery points is it possible to deliver to (according to the contract)
41 Delivery point or zone 10YCB-EUROPEU–8 10YCB-EUROPEU–8
10YCB-EUROPEU-9
10YCB-EUROPEU–7
10YCB-EUROPEU–8
10YCB-EUROPEU-9
10YCB-EUROPEU–7
10YCB-EUROPEU–8
10YCB-EUROPEU-9
10YCB-EUROPEU–7
First delivery date according to contract
42 Delivery start date 2015-01-01 2015-01-01 2015-01-01 2015-01-01
Last possible date of delivery according to the contract
43 Delivery end date 2015-12-31 2015-12-31 2015-12-31 2015-12-31
Shape for natural gas is always GD
44 Load type GD GD GD GD

Please note that “blank” means empty field

 

Combining the volume, price and delivery scenarios: examples

The combination of a volume scenario with a price scenario and a delivery scenario should be able to represent most of the non-standard contracts that have to be reported to the Agency. Based on the scenarios above, there are 100 (5 volume X 5 price X 4 delivery) possible scenarios that market participants and reporting parties should be able to represent.

Example 1: a market participant may want to report a contract with the following combinations:

a) Volume scenario: (V4) – Not Nominated (full supply)
b) Price scenario: (P5) – Simple Index Scenario
c) Delivery scenarios: (D1) – Fixed Delivery Scenario

Contract Description:

V4: Customer takes the volume required at the factory gate without giving any prior nomination of offtake. There will be an estimated profile provided before the contract deliveries begin but on any day offtake can be anywhere between zero and the capacity of the pipeline feeding the plant.

P5: Contract for calendar 2015 delivery. Contract price for the month of delivery is calculated as the average closing price of the front month futures contract for the last calendar month of trading days prior to the month of delivery i.e. January 2015 delivery price is the average of the January 2015 Futures closing prices during the month of December 2014.

D1: Delivery to a single identified delivery point, over one year period with same volume delivered every hour of every day.

 

Full Supply / Simple Index Price / Fixed Delivery Point   
N Field Identifier (buyer side) (seller side)
  Contract details    
11 Contract ID LTC0001 LTC0001
12 Contract date 2014-07-18 2014-07-18
13 Contract type FW FW
14 Energy commodity NG NG
15 Price or price formula FORMULA FORMULA
21 Volume optionality V V
  Fixing index details    
24 Type of index price I I
25 Fixing index Front Month Close Front Month Close
26 Fixing index types FU FU
27 Fixing index sources ICE ICE
28 First fixing date 2014-12-01 2014-12-01
29 Last fixing date 2015-11-27 2015-11-27
30 Fixing frequency M M
31 Settlement method P P
  Delivery profile    
41 Delivery point or zone 10YCB-EUROPEU–8 10YCB-EUROPEU–8
42 Delivery start date 2015-01-01 2015-01-01
43 Delivery end date 2015-12-31 2015-12-31
44 Load type GD GD

 

Example 2: a market participant may want to report a contract with the following combinations:

a) Volume scenario: (V3) – Cascade Nominated Volume Scenario
b) Price scenario: (P3) – Index Basket Scenario
c) Delivery scenarios: (D3) – Multiple Fixed Point Delivery Scenario

Contract Description:

V3: The customer can choose to nominate changes in offtake using a time-cascade of deadlines. Customer could nominate next month delivery three days before the end of the month prior to delivery month, or choose to nominate volume day ahead, or could use a combination of both, nominating “certain” volume month ahead and refining that offtake with day ahead nominations. In this example delivery is for calendar year 2015.

P3: Contract price is determined by a basket of indexes where for the index basket there is a specified period (for calculation of average of closing prices), a specified period between the end of the calculation period and the beginning of the delivery period (the “lag”) and a specified delivery period that the calculated price applies. This example would be a Calendar year 2015 delivery with calculation averaging over three months and delivery beginning immediately after the end of averaging period and calculated price applied to three month period (3-0-3).

D3: Same as Fixed Delivery scenario but delivery is split using fixed percentages (that add up to 100%) between three different locations and the fixed percentages cannot change during the contract term.

Cascaded Nom / Index Basket Price / Multiple Fixed Delivery Points 
N Field Identifier (buyer side) (seller side)
  Contract details    
11 Contract ID LTC0001 LTC0001
12 Contract date 2014-07-18 2014-07-18
13 Contract type FW FW
14 Energy commodity NG NG
15 Price or price formula FORMULA FORMULA
19 Volume optionality capacity 0-2400 0-2400
20 Notional quantity unit MW MW
21 Volume optionality M M
22 Volume optionality frequency M,D M,D
23 Volume optionality intervals 2014-12-29 / 2015-12-30 2014-12-29 / 2015-12-30
  Fixing index details    
24 Type of index price C C
25 Fixing index GO Front Month mid GO Front Month mid
26 Fixing index types FU FU
27 Fixing index sources ICE ICE
28 First fixing date 2014-12-01 2014-12-01
29 Last fixing date 2015-09-30 2015-09-30
30 Fixing frequency Q Q
24 Type of index price C C
25 Fixing index NG Fronth Month mid NG Fronth Month mid
26 Fixing index types FW FW
27 Fixing index sources Heren Heren
28 First fixing date 2014-12-01 2014-12-01
29 Last fixing date 2015-09-30 2015-09-30
30 Fixing frequency Q Q
31 Settlement method P P
  Delivery profile    
41 Delivery point or zone 10YCB-EUROPEU–8 10YCB-EUROPEU–8
41 Delivery point or zone 10YCB-EUROPEU-9 10YCB-EUROPEU-9
41 Delivery point or zone 10YCB-EUROPEU–7 10YCB-EUROPEU–7

 

Reporting of executions under non-standard contracts

The executions under non-standard contracts have to be reported with Table 1 of the Annex to the Implementing Acts. To see examples please download the PDF version of Annex II below.


Download documents:

ANNEX II – Examples of Transaction Reporting

Annex II Section 1 V1 XML Trade Examples

Annex II Section 2 V1 XML Trade Examples

RSS_Icon Last update: 24/03/2016  

TRUM – Annex III

Reporting of Energy Derivatives Contracts under REMIT and EMIR

 

Version history

Version Effective Date
Annex III Version 1.0 07 January 2015
Annex III Version 2.0 06 October 2015

 

This Annex aims at clarifying further the reporting path of the energy derivatives reported under REMIT and EMIR.

Following additional input received by the industry, the Agency has updated this guidance.

In order for a transaction/order in a derivative contract to be executed/placed on an organised market place, a chain of entities is involved. The Agency has developed this additional guidance in order to clarify further which entity (entities) in the chain is (are) considered to be “market participant(s)” under REMIT and therefore have to register with the national regulatory authority and on which party (parties) lie(s) the reporting obligation, what transactions have to be reported, what data have to be reported and who will do the actual reporting.

The Agency’s understanding of the reporting of energy derivatives contracts under REMIT is guided by the principle that uniform rules on the reporting of energy derivatives should not create unnecessary costs or administrative burdens for market participants and take account of reporting frameworks developed under EU financial market legislation. The scope of the reporting of energy derivatives under REMIT should therefore be aligned as much as possible with the scope of the reporting under EMIR and MiFID. The only exception to this is the reporting of matched and unmatched orders under REMIT to enable the Agency to fulfil its market monitoring task under REMIT.

Wholesales Energy Markets: physical vs financial markets [new]

Under REMIT, a market participant is any person who enters into transactions in one or more wholesale energy markets, where wholesale energy markets means any market within the Union on which wholesale energy products are traded. Wholesale energy products are contracts for the supply and transportation of gas and electricity in the EU and derivatives related to them irrespective of where and how they are traded.

In the Agency’s view a wholesale energy market is a market where the energy “commodity” or the “derivative” related to the commodity is physically traded (i.e. it physically changes hands/ownership) and not necessarily the venue where the transaction is agreed. Therefore it is important to clarify that:

  1. the energy exchanges, broker platforms and any other facilities where the commodity is negotiated (traded) are Organised Market Places in REMIT terms. These venues are used to arrange/negotiate the transactions (the contracts);
  2. for contracts for the supply (and transportation) of gas or electricity in the EU (including futures for the physical delivery) the wholesale energy market is the place where the energy commodity changes ownership (it is traded) e.g. a defined gas hub/electricity network where the gas or electricity changes hands; and
  3. for financial derivatives contracts related to EU wholesale gas and electricity products, the venue i.e. the organised market place that hosts that contract, with its clearing house and clearing members, is the wholesale energy market. In this case the wholesale energy market is the place where the derivative contract is traded, e.g. a specific venue with its own rules and arrangements (including clearing house and clearing members).

The Agency believes that any person entering into transactions in the physical markets of EU wholesale electricity or gas products, irrespective of where the transaction is agreed, that person is a REMIT market participant.

For derivatives related to EU wholesale gas or electricity products that are only for financial settlement, only the person entering into the transactions in the EU gas or electricity derivatives traded on venues, via its own trading membership, is the REMIT market participant for the purpose of reporting.

For example, a client of an exchange member that places orders to trade on the order book of the venue to trade EU gas or electricity derivatives for financial settlement or it is equivalent (e.g. trading on futures for the physical delivery without having arrangements to take or make the delivery of the commodity) should not be considered a market participant unless the client of the exchange member is itself a member of the exchange for the purpose of this trade.

However, if that person also enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets, e.g. enters on a physical trade (or its derivative) for the delivery (or transportation) of gas or electricity in the EU, that person is a market participant and has to report all the transactions on wholesale energy products including those trades that are only for financial settlement.

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

Exchange Traded Derivatives (ETDs) [amended]

ETDs traded on Regulated Markets (RMs) supervised by European financial regulators are subject to financial regulations. They are currently considered financial instruments to be reported under EMIR and under MiFID II/MiFIR from 2016.

As far as the Agency is aware, there are two categories of derivatives falling under the scope of REMIT and that have to be reported under EMIR/MiFIR:

  1. exchange traded derivatives (ETDs) traded at Regulated Markets supervised by European financial regulators;
  2. exchange traded derivatives (ETDs) traded at Regulated Markets supervised by European financial regulators;
  3. derivatives traded outside Regulated Markets supervised by European financial regulators e.g. traded on MTFs, OTF and bilaterally.

The Agency expects that market participants may enter into transactions by:

  1. acting on their own account and on their own behalf (pure principal transaction – i.e. on the decision of the firm);
  2. acting on their own account and on behalf of a client – i.e. on the order of other market participant; and/or
  3. acting for the account of and on behalf of a market participant (pure agency transaction).

The Agency understands that ETDs transactions involve several parties. Based on the input provided by the industry, the Agency understands that the following parties may be involved in a regular trade cycle for concluding a derivative transaction:

  • Exchange (Venue);
  • Clearing House (CH);
  • Exchange Members (EMs):
    • Executing Brokers (EBs) which have some discretion on the placing of orders to trade on the exchange; or
    • Firms providing Direct Market Access (“DMA”) to their clients.
  • Client (A) of the Executing Broker or of the firm that provide DMA, who is trading in its own discretion on behalf of itself or its clients;
  • Investment Manager (IM) which has investment discretion and is solely trading as agent on the account of clients through the Executing Broker;
  • Client (1) of the Investment Manager (IM) who is the beneficiary of the transaction executed by the (IM);
  • Clearing Broker (CB) of the Executing Broker (a clearing member of the Clearing House who is temporary clearing trades that an Executing Brokers executes on Exchange); and
  • Clearing Broker (CB) of the Client (a clearing member of the Clearing House providing clearing services to end-clients).

Please also see the exhibits at the end of this Annex.

  1. The reporting of wholesales energy derivatives transactions from the Executing Brokers’ prospective

The Agency understands that clearing brokers (CBs) and central counterparties (CCPs) are not considered “market participants” under REMIT as they do not enter into transactions in the meaning of REMIT. The Agency believes that this is in line with the meaning of entering into transaction according to Article 5 of MiFID I where the meaning of entering into transaction does not include actions related to option exercise, settlement or clearing. For further information on life cycle events, please refer to point 3.2.10 of the TRUM.

A far as the Agency understands, executing brokers may act as Principal before giving up the transaction for clearing and this seems to be the case for most of the transactions executed at Regulated Markets. As a consequence, executing brokers are considered as having placed orders to trade and having entered into transactions and, thus, they are REMIT market participants.

However, from the investment firm perspective, there are several possible scenarios, including:

  1. the investment firm is itself a counterparty trading on its own account on its own behalf;
  2. the investment firm is itself a counterparty trading on its own account on its own behalf and it is also clearing member;
  3. the investment firm is itself a counterparty trading on its own account on behalf of a client;
  4. investment firm is itself counterparty trading on its own account on behalf of a client and it is also clearing member;
  5. the investment firm is not itself a counterparty and is trading on the account of and on behalf of a client (agency transactions); and
  6. the investment firm is not itself a counterparty and is trading on the account of and on behalf of a client (agency transactions), but it is also clearing member.

A graphical representation of the above scenarios can be found in exhibits 1.1 to 1.6 at the end of this Annex. A few scenarios to represent what the Agency expects to receive from Trade Repositories receiving transactions under EMIR are represented in case 1 and case 2 below.

For all transactions executed at organised market places, including Regulated Markets where ETDs are traded, a market participant cannot report directly to the Agency, but must report their transactions through the Organised Market Place, trade matching or trade reporting system.

For illustration purposes, the Agency’s understanding of the two most frequent trading scenarios on ETDs is as follows:

Case 1: Investment Firm (ABC) acts as executing broker on behalf of its Client (123) and gives up a trade for clearing to Investment Firm (XYZ) as clearing broker.  The Agency understands that:

Under EMIR:

  1. firm ABC, acting as executing broker, does not have to report the transaction if the trade is given up to Firm XYZ within T+1 (and there has not been any change to the economic terms of the original trade);
  2. firm XYZ, acting as clearing broker, has to report the cleared transaction which includes the Client 123 identifier as counterparty to the contract and the Firm ABC identifier as executing broker; and
  3. client 123, as the originator of the order to trade and counterparty to the contract, has to report the cleared transaction which includes Firm XYZ identifier as counterparty to the contract and Firm ABC identifier as executing broker

The above representation is provided in ESMA’s Q&A on EMIR available under http://www.esma.europa.eu/content/EMIR-QA. Please see Scenario 2 taken from the ESMA’s Q&A and Exhibit (III.1) below for the Agency’s understanding of the EMIR/REMIT overlap.

Under REMIT:

  • Firm ABC has to submit the order details only.  This reporting must be done by delegation to the Organised Market Place or third party service provider. Firm ABC does not have to submit any trade report.

Under this scenario, the Agency will have access to:

  1. order(s) details reported  by Firm ABC, the executing broker, under REMIT;
  2. contract details reported by Firm XYZ, the clearing broker, under EMIR; and
  3. contract details reported by Client 123, under EMIR.

Case 2: In the case where Firm ABC acts as both executing broker and clearing broker for a trade executed at the Organised Market Place:

Under EMIR:

  • firm ABC, acting as executing broker, does not have to report the contract because, under EMIR where an entity is fulfilling more than one of these roles (for example, where the investment firm is also the clearing member), then it does not have to report separately for each role and should submit one report identifying all the applicable roles in the relevant fields; and
  • firm ABC, acting as clearing broker, has to report the cleared transaction which includes the Client 123 identifier as counterparty to the contract and Firm ABC identifier as executing broker.

Please see ESMA’s Q&A on EMIR available under http://www.esma.europa.eu/content/EMIR-QA and exhibit (III.2) below for the Agency’s understanding of the EMIR/REMIT overlap.

Under REMIT:

  • firm ABC, acting as executing broker, does have to report for its role and must report order details via delegation to an OMP or third party service provider. Firm ABC does not have to report data related to the contract;
  • firm ABC, acting as clearing broker, does not have to report in its role because, in that capacity, it is not considered to have entered into a transaction;

Under this scenario, ACER will have access to:

  • order(s) details reported  by Firm ABC as executing broker under REMIT;
  • transaction details reported by Firm ABC as clearing broker under EMIR; and
  • transaction details reported by Client 123, under EMIR.

Market participants that have to comply with EMIR should focus on EMIR requirements rather than on the REMIT ones. Parties involved in the execution of an ETD contract will have to report their transactions under EMIR. If they do so, they are complying with REMIT too. However, the obligation to report orders to trade to the Agency is still with the market participants.

There is no need for separate guidance on reporting of ETD contracts and their life cycle events (such as exercise of an option or those actions that are not visible to the market) even though they are reportable under EMIR.

Market participants should report transactions under REMIT only if those transactions are not reported under EMIR. In fact, it is worth noting that there may be some ETDs traded on EU venues by non-EU counterparties that are not reported under EMIR (e.g. U.S. counterparties reporting under the Dodd Frank Act). The Agency understands that these trades have to be reported under REMIT and, if not reported under EMIR, have to be reported through the Organised Market Places or third parties with Table 1 of the Implementing Acts and according to the TRUM.

B. The reporting of wholesales energy derivatives transactions from the venues’ perspective

From the venues’ perspective, the Agency considers a few scenarios which are also represented in exhibits (2.1) to (2.6) at the end of this Annex.

Please note

The Agency explains below its understanding of the arrangements between exchanges, exchange members, their clients and other market players on the basis of input received by the Agency’s stakeholders. Although the Agency has put its best effort in representing possible cases/scenarios, it cannot guarantee that all cases are covered in this document.

There may be cases where arrangements between exchanges, exchange members, their clients and other market players are different than those presented below. If so, these should be assessed on a case by case basis to verify if those arrangements would make a market player to be a REMIT market participant.

Please contact transaction.reporting@acer.europa.eu if you have any questions.

 

In order to represent the possible scenarios (from the venues’ perspective), there are a few points that it is worth clarifying and that are applicable to the cases illustrated below:

About Client (A):

  1. client (A) has its own membership of the exchange, but uses the trading systems of an Exchange Member (EM) to trade on the Central Limit Order Book (CLOB). In this particular case, the Agency believes that Client (A) is a market participant and has the obligation to report its transactions; and
  2. client (A) is NOT a member of the venue, but uses the trading systems of an Exchange Member (EM) to trade on the Central Limit Order Book (CLOB). In this particular case, the Agency believes that Client (A) is currently not considereda REMIT market participant entering into transactions which are required to be reported to the Agency in accordance with Article 8(1) of REMIT, unless it enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets (e.g. any other wholesale energy market). In this case the Exchange Member (EM) is the Market Participant and the (EM) shall report the transactions.

About the reporting of Field (1) ID of the market participant or counterparty, and Field (10) Trading capacity of the market participant or counterparty in field (1):

  1. if Client (A) has been set-up in the Venue’s system (see point [a] above) , Field (1) should report the Client (A)’s ID and Field (8) should report “P” for Principal; and
  2. if Client (A) has NOT been set-up in the Venue’s system (see point [b] above), Field (1) should report the Exchange Member (EM)’s ID and Field (8) should report “P” for Principal or “A” for Agent if the Exchange knows this is an Agent transaction.

About the reporting of Field (3), ID of the trader and / or of the market participant or counterparty as identified by the organised market place. This field should identify the user responsible for entering into the transaction that is reported:

  1. If Client (A) has been set-up in the Venue’s system (see point [a] above), client (A) is responsible for the trading and responsible for entering into the transaction, and Field (3) should report Client (A) trader’s ID. This is most likely an electronic ID which identifies Client (A)’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 that ID.
  2. If Client (A) has NOT been set-up in the Venue’s system (see point [b] above), Client (A) trader’s ID may not be available to the Venue. However, since Client (A) is responsible for taking decisions or actions in executing or amending the transaction, where an identifier of the person or the group of persons responsible for taking decisions on behalf of Client (A) is available, this should be reported in Field (3): ID of the trader and/or of the market participant or counterparty as identified by the organised market place.

The Agency understands that there should be an ID (in some format) in the Venue’s system that differentiates the orders to trade submitted by one (EM)’s Client from another (EM)’s Client, e.g. Client (A) and Client (B).

This is most likely an electronic ID which identifies Client (A)’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 that ID.

If such ID is not available, the Venue may report the Trader ID (or an account number) of the Exchange Member that provides DMA to Client (A).

For the purpose of REMIT reporting, the exchange will be able to report information about the orders to trade placed by the market participants (or information about the trades if not reported under EMIR) as follows:

Case (1) and (2): the Clearing Member (CM) and the Exchange Member (EM) are the same firm which also provides DMA to their clients.

Case 1: Client (A) holds a clearing account with Clearing Member (CM) which also provides (A) with DMA to the Exchange. Client (A) uses the trading systems of its Clearer (CM/EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) has its own membership of the exchange and it is a REMIT Market Participant.

_____

Order report details
Field Description Examples
1 ID of the market participant or counterparty Client(A)’s ACER code

(or other code)

2 Type of code used in field 1 ACE  (or other type)
3 ID of the trader and / or of the market participant Client (A)’s Trader ID
8 Beneficiary ID
9 Type of code used in field 8
10 Trading capacity of the market participant or counterparty in field 1 P (Principal)

 

Case 2: Client (A) holds a clearing account with Clearing Member (CM) which also provides (A) with DMA to the Exchange. Client (A) uses the trading systems of its Clearing Member (CM/EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) is not a member of the exchange and is currently not considered a REMIT market participant entering into transactions which are required to be reported to the Agency in accordance with Article 8(1) of REMIT, unless it enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets (e.g. somewhere else).

_____

Order report details
Field Description Examples
1 ID of the market participant or counterparty Exchange Member’s ACER code (or other code)
2 Type of code used in field 1 ACE  (or other type)
3 ID of the trader and / or of the market participant or counterparty as identified by the organised market place Exchange Member’s Trader ID (or Client (A)’s Trader ID if available)
8 Beneficiary ID
9 Type of code used in field 8
10 Trading capacity of the market participant or counterparty in field 1 P (Principal)

______

Case (3) and (4): the Clearing Member (CB) and the Exchange Member (EM) are not the same firm. DMA is provided by the Exchange Member.

Case 3: Client (A) holds an account with the Exchange Member (EM) which provides (A) with DMA to the Exchange. Client (A) uses the trading systems of (EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) has its own membership of the exchange and it is a REMIT Market Participant.

_____

Order report details
Field Description Examples
1 ID of the market participant or counterparty Client(A)’s ACER code

(or other code)

2 Type of code used in field 1 ACE  (or other type)
3 ID of the trader and / or of the market participant or counterparty as identified by the organised market place Client (A)’s Trader ID
8 Beneficiary ID
9 Type of code used in field 8
10 Trading capacity of the market participant or counterparty in field 1 P (Principal)

 

Case 4: Client (A) holds an account with the Exchange Member (EM) which provides (A) with DMA to the Exchange. Client (A) uses the trading systems of (EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) s not a member of the exchange and it is currently not considered a REMIT market participant entering into transactions which are required to be reported to the Agency in accordance with Article 8(1) of REMIT, unless it enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets.

_____

Order report details
Field Description Examples
1 ID of the market participant or counterparty Exchange Member’s  ACER code (or other code)
2 Type of code used in field 1 ACE  (or other type)
3 ID of the trader and / or of the market participant or counterparty as identified by the organised market place Exchange Member’s Trader ID (or Client (A)’s Trader ID if available)
8 Beneficiary ID
9 Type of code used in field 8
10 Trading capacity of the market participant or counterparty in field 1 P (Principal)

_____

Case (5) and (6): the Clearing Member (CB) and the Exchange Member (EM) are not the same firm. DMA to the exchange is provide by the Exchange Member (EM) which only acts as Agent.

Case 5: Client (A) holds an account with the Exchange Member (EM) which provides (A) with DMA to the Exchange. Client (A) also holds an account with the Clearing Member (CM). Client (A) uses the trading systems of (EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) also has its own membership of the exchange and it is a REMIT Market Participant.

_____

Order report details
Field Description Examples
1 ID of the market participant or counterparty Client(A)’s ACER code

(or other code)

2 Type of code used in field 1 ACE  (or other type)
3 ID of the trader and / or of the market participant or counterparty as identified by the organised market place Client (A)’s Trader ID
8 Beneficiary ID
9 Type of code used in field 8
10 Trading capacity of the market participant or counterparty in field 1 P (Principal)

_____

Case 6: Client (A) holds an account with the Exchange Member (EM) which provides (A) with DMA to the Exchange. Client (A) also holds an account with the Clearing Member (CM). Client (A) uses the trading systems of (EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) is not a member of the exchange and it is currently not considered a REMIT market participant entering into transactions which are required to be reported to the Agency in accordance with Article 8(1) of REMIT, unless it enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets.

_____

Order report details
Field Description Examples
1 ID of the market participant or counterparty Exchange Member’s  ACER code (or other code)
2 Type of code used in field 1 ACE  (or other type)
3 ID of the trader and / or of the market participant or counterparty as identified by the organised market place Exchange Member’s Trader ID (or Client (A)’s Trader ID if available)
8 Beneficiary ID
9 Type of code used in field 8
10 Trading capacity of the market participant or counterparty in field 1 P (Principal) or A (Agent)

 

C. The reporting of wholesales energy derivatives transactions from the Investment Manager and their Client’s perspective [new]

From the Investment Manager and their Client’s perspective, the Agency considers a few scenarios which are also represented in exhibits (3.1) to (3.4) and the end of this Annex.

Case 1: The Investment Manager (IM) has investment discretion with respect to the account of Client (1) and is acting solely as agent on behalf and on the account of its Client (1). The Investment Manager (IM) places an order to trade with the Executing Broker (EB), who trades on the Venue. Client (1) holds a clearing account with Clearing Member (CM). The Executing Broker (EB) and Clearing Member (CM) are the same legal entity. The Executing Broker gives up the trade to the Clearing Member. All parties involved are FCs/NFCs for purposes of EMIR.

The Agency believes that the Executing Broker (EB) is considered to be a “Market Participant” under REMIT. The Investment Manager (IM) is considered a market participant if it is itself a member of the exchange and Client (1) is currently not considered to be Market Participant unless Client (1) enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets. If Client (1) is a Market Participant and the trade is reported to a Trade Repository under EMIR, its REMIT reporting obligation will have been met.

Case 2: The Investment Manager (IM) has investment discretion with respect to the account of Client (1) and is acting solely as agent on behalf and on the account of its Client (1). Client (1) holds a clearing account with Clearing Member (CM). The Executing Broker (EB) and Clearing Member (CM) are not the same legal entity. The Executing Broker gives up the trade to Clearing Member (CM). All parties involved are FCs/NFCs for purposes of EMIR. If Client (1) is a Market Participant and the trade is reported to a Trade Repository under EMIR, its REMIT reporting obligation will have been met.

Same as for Case 1 above, The Agency believes that the Executing Broker (EB) is considered to be a “Market Participant” under REMIT. The Investment Manager (IM) is considered a market participant if it is itself a member of the exchange and Client (1) is currently not considered to be Market Participant unless Client (1) enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets.

Also in this case, if Client (1) is a Market Participant and the trade is reported to a Trade Repository under EMIR, its REMIT reporting obligation will have been met.

Case 3: The Investment Manager (IM) has investment discretion with respect to the accounts of Client (1) and Client (2), and is acting solely as agent on behalf and on the account of its clients. Client (1) holds a clearing account with Clearing Member (CM1) and Client (2) holds a clearing account with Clearing Member (CM2). After executing the trade, the Executing Broker (EB) gives up part of the trade to Clearing Member (CM1) and the other part to Clearing Member (CM2). Each Clearing Member will establish a back-to-back trade vis-à-vis the initial trade with Client (1) and Client (2) respectively. All parties involved are FCs/NFCs for purposes of EMIR with the exception of Client (2).

Same as for Case 1 above, the (EB) is considered to be a “Market Participant” under REMIT. The Investment Manager (IM) is considered a market participant if it is itself a member of the exchange and Client (1) and Client (2) are currently not considered to be Market Participant unless Client (1) or (2) enter into transactions, including the placing of orders to trade, in one or more wholesale energy markets. If they are market participants, then they have to report the back to back transaction with the (CB).

Case 4: The Investment Manager has investment discretion with respect to the account of Client (1) and is solely trading as agent on behalf and on the account of its client. Client (1) is not an FC/NFC for EMIR purposes and holds a clearing account with a Clearing Broker (CB) who is also not an FC/NFC for EMIR purposes. The Executing Broker (EB) will give-up the trade to Clearing Member (CM) (who is an FC/NFC for EMIR purposes). Clearing Member (CM) establishes a trade between itself and the Clearing Broker (CB) who is clearing the trade vis-à-vis Client (1).

Market participants shall make sure that supply contracts and derivatives reportable solely under REMIT (e.g. energy derivatives not traded on Regulated Markets or MTFs) are reported to the Agency and not to EMIR Trade Repositories.

For example, if a market participant reports all its transactions to a Trade Repository, including spot and physical forward transactions not captured by EMIR, the market participant is not complying with REMIT unless the Trade Repository is a Registered Reporting Mechanism under REMIT and the market participant has given precise instructions to the Trade Repository to report its transaction to the Agency.

 

Scenario 1: the investment firm is itself a counterparty trading on its own account (either on its own behalf or on behalf of a client), the following reports should be submitted:

 

 

Report Who has the reporting obligation12? Trade ID13 Transaction reference number13 Counterparty

ID (2)

ID of the other counterparty (3)

 

Broker ID (8) Clearing member ID (10) Beneficiary ID (11) Trading capacity (12)14 Counterparty side (13) Venue of execution CCP
1 Clearing member UTI001 TRN1 Clearing member CCP Clearing Member Clearing member ‘P’ ‘B’ MIC CCP
2 CCP UTI001 TRN1 CCP Clearing member Clearing member CCP ‘P’ ‘S’ MIC CCP
3 Investment firm UTI002 TRN1 Investment firm Clearing member Investment firm Clearing member Investment firm ‘P’ ‘B’ MIC CCP
4 Clearing member UTI002 TRN1 Clearing member Investment firm Investment firm Clearing member Clearing member ‘P’ ‘S’ MIC CCP
5 Client UTI003 TRN1 Client Investment firm Investment firm Clearing member Client ‘P’ ‘B’ MIC CCP
6 Investment firm UTI003 TRN1 Investment firm Client Investment firm Clearing member Investment firm ‘P’ ‘S’ MIC CCP

12 This column was inserted to clarify reporting obligations; it is not part of the reportable fields under Article 1(1) of Commission Delegated regulation (EU) No 148/2013.
13 See ETD reporting question 5.
14 This field refers to the trading capacity of the counterparty with the reporting obligation.

Source ESMA’s website available at http://www.esma.europa.eu/content/EMIR-QA

_____

Scenario 2: the investment firm is not itself a counterparty and is trading on the account of and on behalf of a client, the following reports should be submitted:

Report Who has the reporting obligation? 15 UTI

 

 

Transaction reference number Counterparty ID (2) ID of the other counterparty (3)

 

Broker ID (8) Clearing member ID (10) Beneficiary ID (11) Trading capacity (12) 16 Counterparty side (13) Venue of execution CCP ID
1 Clearing member UTI001

 

TRN1 Clearing member CCP Clearing member Clearing member ‘P’ ‘B’ MIC CCP
2 CCP UTI001 TRN1 CCP Clearing member Clearing member CCP ‘P’ ‘S’ MIC CCP
3 Client UTI002 TRN1 Client Clearing member Investment firm Clearing member Client ‘P’ ‘B’ MIC CCP
4 Clearing member UTI002 TRN1 Clearing member Client Investment firm Clearing member Clearing member ‘P’ ‘S’ MIC CCP

15 This column was inserted to clarify reporting obligations; it is not part of the reportable fields under Article 1(1) of Commission Delegated regulation (EU) No 148/2013.
16 These fields refer to the trading capacity of the counterparty with the reporting obligation.

Source ESMA’s website available at http://www.esma.europa.eu/content/EMIR-QA

 

Exhibit (A): Exchange traded derivatives

 

 

Exhibit (B): Exchange traded derivatives, simplified view

 

Exhibit (1.1): the investment firm is itself counterparty trading on its own account on its own behalf.

 

Exhibit (1.2): the investment firm is itself counterparty trading on its own account on its own behalf and it is also clearing member.

 

Exhibit (1.3): the investment firm is itself counterparty trading on its own account on behalf of a client.

 

Exhibit (1.4): investment firm is itself counterparty trading on its own account on behalf of a client and it is also clearing member

 

Exhibit (1.5): the investment firm is not itself counterparty and is trading on the account of and on behalf of a client (agency transactions). This case also applies when the investment firm gives up the trade for clearing to the clearing broker.

 

Exhibit (1.6): the investment firm is not itself a counterparty and is trading on the account of and on behalf of a client (agency transactions and trades given up for clearing), but it is also clearing member.

 

Exhibit (2.1): Client (A) holds a clearing account with Clearing Member (CM) which also provides (A) with DMA to the Exchange. Client (A) uses the trading systems of its Clearer (CM/EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) has its own membership of the exchange and it is a REMIT Market Participant.

 

Exhibit (2.2): Client (A) holds a clearing account with Clearing Member (CM) which also provides (A) with DMA to the Exchange. Client (A) uses the trading systems of its Clearing Member (CM/EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) is not a member of the exchange and is currently not considered a REMIT market participant entering into transactions which are required to be reported to the Agency in accordance with Article 8(1) of REMIT, unless it enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets (e.g. somewhere else).

 

Exhibit (2.3): Client (A) holds an account with the Exchange Member (EM) which provides (A) with DMA to the Exchange. Client (A) uses the trading systems of (EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) has its own membership of the exchange and it is a REMIT Market Participant.

 

Exhibit (2.4): Client (A) holds an account with the Exchange Member (EM) which provides (A) with DMA to the Exchange. Client (A) uses the trading systems of (EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) s not a member of the exchange and it is currently not considered a REMIT market participant entering into transactions which are required to be reported to the Agency in accordance with Article 8(1) of REMIT, unless it enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets.

 

Exhibit (2.5): Client (A) holds an account with the Exchange Member (EM) which provides (A) with DMA to the Exchange. Client (A) also holds an account with the Clearing Member (CM). Client (A) uses the trading systems of (EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) also has its own membership of the exchange and it is a REMIT Market Participant.

 

Exhibit (2.6): Client (A) holds an account with the Exchange Member (EM) which provides (A) with DMA to the Exchange. Client (A) also holds an account with the Clearing Member (CM). Client (A) uses the trading systems of (EM) and is trading on a proprietary basis (with no clients). Client (A) is trading on the Central Limit Order Book (CLOB) of the Venue. Client (A) is not a member of the exchange and it is currently not considered a REMIT market participant entering into transactions which are required to be reported to the Agency in accordance with Article 8(1) of REMIT, unless it enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets.

 

Exhibit (3.1): The Investment Manager (IM) has investment discretion with respect to the account of Client (1) and is acting solely as agent on behalf and on the account of its Client (1). The Investment Manager (IM) places an order to trade with the Executing Broker (EB), who trades on the Venue. Client (1) holds a clearing account with Clearing Member (CM). The Executing Broker (EB) and Clearing Member (CM) are the same legal entity. The Executing Broker gives up the trade to the Clearing Member. All parties involved are FCs/NFCs for purposes of EMIR.

 

Exhibit (3.2): The Investment Manager (IM) has investment discretion with respect to the account of Client (1) and is acting solely as agent on behalf and on the account of its Client (1). Client (1) holds a clearing account with Clearing Member (CM). The Executing Broker (EB) and Clearing Member (CM) are not the same legal entity. The Executing Broker gives up the trade to Clearing Member (CM). All parties involved are FCs/NFCs for purposes of EMIR.

 

Exhibit (3.3): The Investment Manager (IM) has investment discretion with respect to the accounts of Client (1) and Client (2), and is acting solely as agent on behalf and on the account of its clients. Client (1) holds a clearing account with Clearing Member (CM1) and Client (2) holds a clearing account with Clearing Member (CM2). After executing the trade, the Executing Broker (EB) gives up part of the trade to Clearing Member (CM1) and the other part to Clearing Member (CM2). Each Clearing Member will establish a back-to-back trade vis-à-vis the initial trade with Client (1) and Client (2) respectively. All parties involved are FCs/NFCs for purposes of EMIR with the exception of Client (2).

 

Exhibit (3.4): The Investment Manager has investment discretion with respect to the account of Client (1) and is solely trading as agent on behalf and on the account of its client. Client (1) is not an FC/NFC for EMIR purposes and holds a clearing account with a Clearing Broker (CB) who is also not an FC/NFC for EMIR purposes. The Executing Broker (EB) will give-up the trade to Clearing Member (CM) (who is an FC/NFC for EMIR purposes). Clearing Member (CM) establishes a trade between itself and the Clearing Broker (CB) who is clearing the trade vis-à-vis Client (1).


[Download document]

RSS_Icon Last update: 06/10/2015  

TRUM – Annex IV

Guidance on the Unique Transaction ID (UTI)

Please read carefully

The Agency developed the Guidance on the Unique Transaction ID (UTI) and the excel file for the UTI generation in conjunction with its stakeholders following an intense consultation of the industry.

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 Commission Implementing Regulation (EU) No 1348/2014. 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.

Whilst for executions at organised market places, the UTI is already defined by the organised market place, market participants have to agree which form of a UTI they will use before reporting any bilateral contract. This therefore includes determining the approach that they will use to define which entity generates the UTI.

Accordingly, the generation and usage of an agreed UTI for bilateral trades that take place outside an organised market place may be needed. The Agency has already made available guidance on the UTI in its Transaction Reporting User Manual (TRUM), but would like to facilitate the UTI generation for bilateral contracts as much as possible for the benefit of market participants. This is why 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 note that it is not mandatory to use the Agency’s UTI generator. It only aims at providing another possibility for the UTI generation for bilateral contracts.

For a few complex contracts this guidance and the UTI generator tool may need to be updated in the future. Where market participants feel that this guidance and the UTI generator tool provided by the Agency may not fully satisfy their needs, they should generate and agree on a UTI as indicated in the TRUM. It is important to stress that it is ultimately the market participants’ responsibility to make sure that the Agency receives the correct UTI in the correct format for their transactions as required by Commission Implementing Regulation (EU) No 1348/2014.

The Agency aims at continuing its cooperation with the industry to update this guidance and the UTI generator tool as required.

If you have any question related to this document, please use the REMIT query form https://support.acer-remit.eu/forms/remit-query-form

 

ACER’s UTI generator tool

Unique Transaction Identifiers (UTIs) can be created in different ways; to help provide some consistency in the generation of UTIs, the Agency has tested a solution and believes it is simple and usable by the vast majority of reporting parties.

The generation is based on using a hash function (BASE 64 SHA256) which allows the creation of exactly the same UTI value if the reporting parties use the same input data.

Please note that some market participants, while testing the UTI generator, have experienced an issue due to missing VBA functionality under Windows 10.

Please note that the UTI generator is functioning under Windows 10 after activating .NET Framework 3.5 (includes .NET 2.0 and 3.0).

 

It is important that the reporting parties use the terms agreed at the time of trade execution/contract agreement rather than those that are stored in the market participants’ trade/contract capture systems. However, some normalisations have been introduced in the version 2 of the UTI generator tool to cope with some mismatches observed.

The Agency is offering one solution only and it is up to market participants to assure the REMIT compliance with regard to UTI and implement this guidance according to their IT needs. The Agency’s UTI generator is based on an excel spreadsheet which is available on the Agency’s REMIT portal at https://documents.acer-remit.eu/category/remit-reporting-user-package/transaction-reporting-user-manual-trum.

The ACER algorithm is based on the concatenation of economic terms included in the trade/contract and standardised to 45 characters. The UTI generation works in the following steps:

  1. The relevant information is entered into a spreadsheet or any other application capable of running the required task, e.g. web GUI, java etc.;
  2. The entered data is normalised where applicable as agreed with the industry.
  3. The relevant information is concatenated first, then “hashed” and thus an UTI is generated.

This process works identically for both reporting parties if the reporting parties use the same input data and it may make sense for market participants’ IT departments to build the UTI generator into their local trading system enabling the UTI generation whenever they enter a trade; but this decision should be taken by each market participant.

The input text comprises the data elements taken from the REMIT Table 1 example below:

Field name Value (example)
Buyer’s ACER code C0643778W.EU
Seller’s ACER code C06AG978W.EU
Contract Type SP
Commodity EL
Settlement O
Date of the Trade 2014-11-21
Price 5.35
Currency EUX
Quantity/Volume (Field 40) 24000
Quantity Unit for field 40 KWh/d
Delivery Point or zone 10YCB-EUROPEU–8
Delivery Start Date 2015-01-01
Delivery End Date 2015-01-31

 

When data fields are formatted, normalised and concatenated in the right order as a string, the result is the following:

C0643778W.EUC06AG978W.EUFWELP2014-11-210.00223EUR1.0000000000MW10YCB-EUROPEU–82015-01-012015-01-31

Please note that the concatenated value contains normalised values (characters highlighted in yellow) following the instructions described in sections below and are not just a copy of the input.

Once the input has been hashed, the result is the following:

YwBycOVBTzf2d1nWsAF3CSNz1nbeF4TBNOKz0tHM26wC

The output value of the hash function would be the following UTI:

YwBycOVBTzf2d1nWsAF3CSNz1nbeF4TBNOKz0tHM26001

This is independent of the party (buyer or seller) generating the UTI values since both parties using the same data and the same algorithm will generate matching UTIs without the need for exchanging data. It must be remembered that if only a minor modification is made to the input data by one party, the output value will be completely different.

It may be that some fields will not be available (e.g. the price for index trades) and they cannot be included in the UTI generation. However, two market participants that generate a UTI/Contract ID using the data listed in the relevant tables below would nevertheless be able to create exactly the same identifier by following this guidance.

General remarks:

  • All fields are treated as text fields, even though some of them are of different original formats (e.g. Contract date, Price, Quantity/Volume and Progressive Number).
  • Spaces (blanks) are not permitted since a blank character is also a character that has an effect in the UTI generation.
  • Reporting parties should use the terms agreed at the time of the trade execution/contract agreement rather than those that are stored in the market participants’ individual systems.

Normalisation scope

Certain fields are subject to automated format change and/or normalisation prior to concatenating, and this is why certain values within the Concatenated value will differ from the input values; these are explained in more detail within Section (1).

Field No Field Name Condition
23 Contract Type Certain values should not be used for entry data, other values will be automatically changed under certain conditions in the Concatenated value. See details in

Item #3 below.

26 Settlement Method The accepted entry value of “O” will be replaced by “P” in the Concatenated value. See details in Item #5 below.
35 Price There are several assessments applied to this field:

–      The entered price will be automatically changed to reflect the price with five (5) decimal places, by either adding zeros, or rounding the value;

–      Where the price is entered in the minor unit of a currency (either EUX or GBX), the price value will be converted within the Concatenated value to reflect the price in the major unit of the relevant currency;

–      Price will be also normalised to price per standard energy unit in the Concatenated value.

See details in Item #7 below.

37 Price currency Where a minor unit of currency is used, i.e. EUX or GBX, this will be normalised to the major unit of the relevant currency i.e. EUR or GBP only. See details in Item #8 below.
40 Quantity/volume The quantity/volume will be normalised to a standard unit with 10 decimal places.

See details in Item #9 below.

42 Quantity Unit Standard units are agreed to be: MWh/h (MW), Therm/d, cm/day, Btu/d and MJ/d.

See details in Item #10 below.

 

Section (1) Relevant fields to be taken into account for the generation of the UTI for the reporting of transactions with the REMIT Table 1 of the REMIT Implementing Regulation. Please see the Transaction Reporting User Manual (TRUM) for further details.

Table 1

# Field No in TRUM Field name in the Table 1 UTI Generator Values in the Table 1 UTI Generator (example)
1 1 Buyer’s ACER code C0643778W.EU
2 4 Seller’s ACER code C06AG978W.EU
3 23 Contract Type SP
4 24 Commodity EL
5 26 Settlement method O
6 30 Date of the Trade (without time) 2014-11-21
7 35 Price 5.35000
8 37 Price currency EUX
9 40 Quantity/Volume 24000.00000
10 42 Quantity Unit for field 40 kWh/d
11 48 Delivery Point or zone 10YCB-EUROPEU–8
12 49 Delivery Start Date 2015-01-01
13 50 Delivery End Date 2015-01-31
14 n/a Progressive Number

(for equal trades on the same date)

1
15 n/a Concatenated values C0643778W.EUC06AG978W.EUFWELP2014-11-210.00223EUR1.0000000000MW10YCB-EUROPEU–82015-01-012015-01-31
16 n/a Hash of the concatenated values YwBycOVBTzf2d1nWsAF3CSNz1nbeF4TBNOKz0tHM26wC
17 31 Unique transaction ID YwBycOVBTzf2d1nWsAF3CSNz1nbeF4TBNOKz0tHM26001

 

The Fields highlighted in yellow are subject to formatting and/or normalisation; e.g. Contract Type=SP, “SP” will be normalised. The yellow Value string is the normalised Concatenated value; e.g. “SP” is normalised in the Concatenated values string to “FW”.

Items #1 & #2: Field (1) Buyer’s ACER code and Field (4) Seller’s ACER code:

The Agency would like to avoid any inconsistent interpretations or views which may arise from an individual market participants’ perspective in terms of who is a buyer or who is the seller.

Each trade has unambiguously defined a buyer (the one who accepts a commodity or an instrument) and a seller (the one who gives up a commodity or an instrument). Therefore, Field (1) always requires the buyer’s ACER code whereas Field (2) always requires the seller’s ACER code irrespective of who (buyer or seller) is reporting. Please note that the code has to be an ACER code and no other code (such as an EIC, LEI or BIC) is allowed.

The buyer/seller logic is available in the TRUM; please see Field No (11). Note that in the case of a floating to floating derivative, if party (A) buys a swap, party (A) pays the floating price of the first leg (or index) and party (B) pays the floating price of the second leg (or second index). In this case the two legs (indexes) of the swap should be sorted alphabetically.

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

Any deviations from the above will result in the generation of different UTIs which would therefore be invalid.

Item #3: Field (23) Contract Type:

The range of accepted values for the Contract Type is available in the TRUM. However, the value “OT” (Other) should never be used and it is not allowed to be used in the UTI generator tool.

In addition, the Agency’s UTI algorithm always replaces the following contract types:

  • if contract type is “SW” and Settlement method is “P” or “O”, then its value is replaced with “FW”;
  • if contract type is “SP” and Settlement method is “P” or “O”, then its value is replaced with “FW”;
  • if contract type is “SP” and Settlement method is set to “C”, then its value is replaced with “SW”;
  • if contract type is “OP_FW” or “OP_SW””, then its value is replaced with “OP”;
  • Please note that “AU”, “CO”, “FU” or “OP_FU” are not allowed to be used in the UTI generator tool. In the example provided within the Table 1 above the combination of the Contract type “SP” and Settlement method “O” resulted in the “FW” within the Concatenated value.

Item #4: Field (24) Commodity:

The range of accepted values for the Commodity is available in the TRUM.

Item #5: Field (26) Settlement method:

The range of accepted values for the Settlement method is available in the TRUM. However, if the Settlement method is “O” (Optional for counterparty) then its value is replaced with “P” in the Concatenated value.

This is also the case in the example provided within Table 1 where Settlement method “O” was entered by reporting party but has been replaced with “P” in the Concatenated value.

Item #6: Field (30) Date of the trade (without time):

This field should be populated in ISO 8601 standard, i.e. YYYY-MM-DD. There should be no representation of time (hours, minutes, seconds etc.) used; the field is strictly a date type field.

Item #7: Field (35) Price:

When the price of a trade/contract is known at the time of execution the value should be used for the UTI generation. Reporting parties should use the price agreed at the time of the trade execution rather than the one that is stored in the market participants’ individual systems.

The field Price has been dealt within the UTI generator tool as follows:

At first, if a price is entered that has less than five decimal places after the decimal point, the “UTI generator” will convert the price format such that there will be five decimal places used in the price field; for example ‘25.5’ will become ‘25.50000’.

If a price has more than five decimal places, the ‘round half up’ rule will apply and the price format will be converted to five decimal places before being used in the concatenation; for example entry ‘48.123455’ will be rounded to ‘48.12346’, whereas ‘48.123454’ will be rounded to ‘48.12345’.

Please use decimal point (.) as the separator.

In a second step, a value from price field will be converted to the major unit (valid for the GBX to GBP and EUX to EUR currencies only) and normalised in the price per 1 standard unit of energy family group, e.g. 1 MW (see also the conversion of Quantity to a standard unit of the family group, Item #9 below).

Price in the concatenated value is always converted to price/1unit (e.g.  EUR/1 MW). This is needed to reduce the risk that for the same trade are entered different values that have the same meaning and resulting in different UTIs.

When the price of a trade is not known at the time of the UTI generation (e.g. due to a price index), the ‘Price’ field along with the ‘Price currency’ field should be left blank. The UTI generator tool will create a value of ‘0.00000’ to represent the price within the concatenation.

Please note that index price differentials are reported in Field (36) Index Value, not in Field (35) Price and they should not be used in the UTI generator.

For transactions having multiple prices then the price for the 1st time interval should be used.

All the trades below have the same price (EUR) per MW but are edited differently – different combination of the price currency and quantity unit are entered in the following fields:

# Price Currency Quantity Unit
1 53.50000 EUR 1.00000 MWh/h
2 1284.00000 EUR 24.00000 MWh/d
3 53.50000 EUR 1000.00000 KWh/h
4 1284.00000 EUR 24000.00000 KWh/d
5 5,350.00000 EUX 1.00000 MWh/h
6 128400.00000 EUX 24.00000 MWh/d
7 5,350.00000 EUX 1000.00000 KWh/h
8 128400.00000 EUX 24000.00000 KWh/d

 

All the above trades will have a price converted to EUR 53.5000 and the quantity will be converted to 1 MW (see Item # 9 below) in the Concatenated value.

In the example provided within the Table 1 of this document that would mean that the value for the price within the Concatenated value is calculated in the following steps:

  • the price from EU cents (i.e. EUX) converted to EUR (5.35 EUX -> 0.05350 EUR) valid for the KWh/d unit;
  • the conversion of the quantity volume KWh/d to the standard unit MWh/h i.e. MW is: (24000 KWh/d)/24= 1000 KWh/h which is 1 MWh/h i.e. 1MW);
  • the price/1unit calculation (0.05350/24) = 0.00223 EUR per standard unit and that unit being 1 MW).

Item #8: Field (37) Price currency:

The range of accepted values for the Currency is available in the TRUM. Reporting parties should use the currency as at the time of the trade execution rather than the one that is stored in the market participants’ individual information systems.

However, in circumstances where the price is reflected in the minor unit (for example UK natural gas is traded in ‘pence per therm’), the UTI generator will convert the currency to the major unit and normalise the price to reflect this change; for example ‘51.00 GBX’ will be normalised to ‘0.51000 GBP’. This is limited to GBX-GBP and EUX-EUR currencies only.

If there is no price available as described in Item #7, then the ‘Price currency’ field should be left blank; there will not be any representation for the currency within the concatenation.

Item #9: Field (40) Quantity/Volume:

When the Quantity/Volume (capacity) of a trade/contract is known at the time of execution the value should be used for the UTI generation. Reporting parties should use the quantity/volume agreed at the time of the trade execution rather than the one that is stored in the market participants’ individual systems.

The UTI generator tool converts Quantity to a standard unit of the family group. For example:

  • KW, KWh/h, KWh/d, MWh/h, MWh/d, GW, GWh/h and GWh/d are converted to MWh/h (MW);
  • KTherm/d and MTherm/d are converted to Therm/d;
  • mcm/d is converted to cm/day;
  • MMBtu/d is converted to Btu/d;
  • 100MJ/d, MMJ/d, GJ/d are converted to MJ/d;

The field Quantity has been dealt within the UTI generator tool as follows:

If a quantity/volume is entered as a value with less than five decimal places after the decimal point, the “UTI generator” will convert it in such a way that there will be five decimal places used in the Quantity volume field.

If a value in the quantity/volume field has more than 5 decimal places, the ‘round half up’ rule will apply and the value will be normalised to 5 decimal places before using in the concatenation.

Please use decimal point (.) as the separator.

In the concatenation value, all quantity will be converted to 1 energy unit, e.g. 1 MW (see also the conversion of Quantity to a standard unit of the family group).

This is needed to reduce the risk that for the same trade are entered different values that have the same meaning. All the trades below have quantity (1 MW) but represented differently:

# Price Currency Quantity Unit
1 53.50000 EUR 1.00000 MWh/h
2 1284.00000 EUR 24.00000 MWh/d
3 53.50000 EUR 1000.00000 KWh/h
4 1284.00000 EUR 24000.00000 KWh/d
5 5,350.00000 EUX 1.00000 MWh/h
6 128400.00000 EUX 24.00000 MWh/d
7 5,350.00000 EUX 1000.00000 KWh/h
8 128400.00000 EUX 24000.00000 KWh/d

 

All the above trades will have a quantity converted to 1 MW in the concatenated value and the prices will be converted accordingly (see Item # 7 above).

For trades that do not have a fixed volume for the entire delivery period of the trade/contract, the volume for the first non-zero delivery period should be used for the UTI generation.

In the example provided within the Table 1 of this document that would mean that the quantity volume of 24000 KWh/d is converted to the standard unit MWh/h i.e. 1 MWh/h. Within the Concatenated value the quantity/volume is replaced by the quantity volume in the format 1.0000000000 MW.

Item #10: Field (42) Quantity Unit for field 40:

The range of accepted values for the Quantity (capacity) Unit is available in the TRUM. However, it is important to stress that both market participants should use exactly the same Quantity Unit as at the time of the trade execution rather than the one that is stored in the market participants’ individual systems.

For example, if two market participants trade UK NBP gas, they most like trade in Therms. In this case the quantity unit to be used is Therm/d and not MWh/h or any other units. Or, if two market participants trade German electricity, they most likely trade it in MWh/h; again no other unit should be used.

Only a Field (42) value contained in the list of accepted values for field 40 detailed in the TRUM can be used in the UTI generator tool and these must be entered in the same format

i.e. ‘MWh/h’ and NOT ‘mwh/h’.

Standard units for which the price/1unit is calculated (e.g. X EUR per 1 MWh/h) within the Concatenated value are agreed to be MWh/h (MW), Therm/d, cm/day, Btu/d and MJ/d.

Item #11: Field (48) Delivery Point or zone:

Only EIC codes published in the “List of Accepted Codes” in ANNEX VI of the TRUM on the REMIT portal must be used. There is no automatic (built-in) normalization in the UTI generation.

This field should be populated with the EIC Y, EIC W or EIC Z for the delivery point or zone of the trade. In cases where there are more than one delivery points or zones relevant to the trade, the market participants should use the first EIC code in alphanumeric order (i.e. 0-9, A-Z) in the UTI generator tool. For example if:

  • 10YCB-EUROPEU—18 and 16YCB-EUROPEU—9 are in the contract then 10YCB-EUROPEU—18 will be used for the UTI generator; or
  • 22YCB-EUROPEU—18 and 11YCB-EUROPEU—9 are in the contract then 11YCB-EUROPEU—18 will be used for the UTI generator.

Items #12 and #13: Field (49) and (50) Delivery Start Date and Delivery End Date:

In the same way as item #6, items #12 and #13 should be populated in the ISO 8601 standard, i.e. YYYY-MM-DD. There should be no representation of time (hours, minutes, seconds etc.) used; the fields are strictly date type fields.

Item #14: Progressive Number for equal trades on the same date:

For trades/contracts executed on the same day with exactly the same trade terms (i.e. items from 1 to 19) the progressive number will be used to differentiate each UTI that will be generated. This is a function of the UTI generator tool and does not need to be populated by the market participant.

It does not matter which trade obtains which progressive number for the UTI, as the UTI generator tool will increment the progressive number by one for each trade with the same terms.

Section (2) Relevant fields to be taken into account for the generation of the Contract ID for the reporting of transactions with Table 2 of the REMIT Implementing Regulation. Please see the Transaction Reporting User Manual (TRUM) for further details.

Table 2

# Field No in TRUM Field name  in the Table 2 Contract ID Generator Value in the Table 2 Contract ID Generator (example)
1 1 Buyer’s ACER code C0643778W.EU
2 3 Seller’s ACER code C06AG978W.EU
3 13 Contract Type FW
4 14 Commodity EL
5 31 Settlement P
6 12 Contract Date (without time) 2014-11-21
7 n/a n/a n/a
8 n/a n/a n/a
9 n/a n/a n/a
10 n/a n/a n/a
11 41 Delivery Point or zone 10YCB-EUROPEU–4
12 42 Delivery Start Date 2015-01-01
13 53 Delivery End Date 2015-01-31
14 n/a Progressive Number

(for equal contract on the same date)

1
15 n/a Concatenated values C0643778W.EUC06AG978W.EUFWELP2014-11-2110YCB-EUROPEU–42015-01-012015-01-31
16 n/a Hash of the concatenated values qZ9uPVrjPK6Bzl2xNCUNkOn5rUXB9svJdxMjcg3hY9oC
17 11 Contract ID qZ9uPVrjPK6Bzl2xNCUNkOn5rUXB9svJdxMjcg3hY9001

 

Items #1 & #2: Field (1) Buyer’s ACER code and Field (3) Seller’s ACER code:

The Agency would like to avoid any inconsistent interpretations or views which may arise from an individual market participants’ perspective in terms of who is a buyer or who is a seller.

Each contract has unambiguously defined a buyer (the one who accepts a commodity or an instrument) and a seller (the one who gives up a commodity or an instrument). Therefore field 1 always requires the buyer’s ACER code whereas field 2 always requires the seller’s ACER code irrespective of who  (buyer or seller) is reporting. Please note that the code has to be an ACER code and no other code (such as an EIC, LEI or BIC) is allowed.

Where a contract allows either party to buy or sell then the buyer should be defined as the market participant that is first alphabetically, with the other market participant being defined as the seller.

Any deviations from the above will result in the generation of different Contract IDs which would therefore be invalid.

Item #3: Field (13) Contract Type:

The range of accepted values for the Contract Type is available in the TRUM. However, the value “OT” (Other) should never be used and it is not allowed to be used in the UTI generator tool.

In addition, the Agency’s UTI algorithm always replaces the following contract types:

  • if contract type is “SW” and Settlement method is “P” or “O”, then its value is replaced with “FW”;
  • if contract type is “SP” and Settlement method is “P” or “O”, then its value is replaced with “FW”;
  • if contract type is “SP” and Settlement method is set to “C”, then its value is replaced with “SW”;
  • if contract type is “OP_FW” or “OP_SW””, then its value is replaced with “OP”;
  • Please note that “AU”, “CO”, “FU” or “OP_FU” are not allowed to be used in the UTI generator tool.

Item #4: Field (14) Commodity:

The range of accepted values for the Commodity is available in the TRUM.

Item #5: Field (31) Settlement:

The range of accepted values for the Settlement is available in the TRUM. However, if Settlement method is “O” (Optional for counterparty) then its values is replaced with “P” in the Concatenated value.

Item #6: Field (12) Contract date (without time):

This field should be populated in ISO 8601 standard, i.e. YYYY-MM-DD. There should be no representation of time (hours, minutes, seconds etc.) used; the field is strictly a date type field.

Items #7 to #10:

Not used in the UTI generation process for the REMIT Table 2 contracts.

Item #11: Field (41) Delivery Point or zone:

Only EIC codes published in the “List of Accepted Codes” in ANNEX VI of the TRUM on the REMIT portal must be used.

There is no automatic (built-in) normalization in the UTI generation.

This field should be populated with the EIC Y, EIC W or EIC Z for the delivery point or zone of the trade. In cases where there are more than one delivery points or zones relevant to the trade, the market participants should use the first EIC code in alphanumeric order (i.e. 0-9, A-Z) in the UTI generator tool.

Items #12 and #13: Field (42) and (43) Delivery Start Date and Delivery End Date:

In the same way as item #6, items #12 and #13 should be populated respecting the ISO 8601 standard, i.e. YYYY-MM-DD. There should be no representation of time (hours, minutes, seconds etc.) used; the fields are strictly date type fields.

Item #14: Progressive Number for equal contracts on the same date:

For contracts executed on the same day with exactly the same contract terms (i.e. items from 1 to 13) the progressive number will be used to differentiate each Contract ID that will be generated. This is a function of the UTI Generator tool and does not need to be populated by the market participant.

It does not matter which contract obtains which progressive number for the Contract ID, as the UTI generator tool will increment the progressive number by one for each contract with the same terms.

Section (3) Technical note on the BASE64SHA256 function

  1. Transform the text to be hashed in a buffer of byte.
  2. Apply the sha256 function (the sha256 function produces a buffer of 256 bits, normally every 8bits corresponds to 1 ASCII character, but if HEXADECIMAL code is used, 4 bits corresponds to a character).
  3. Encode the result in BASE64 (in BASE64 every 6bit corresponds to a character so using 256/6 will result in 42 characters, with the remaining three characters being used to manage duplications).

The APIs used are the ones provided by .NET framework.


[Download document + UTI Generator]

RSS_Icon Last update: 07/01/2019  

TRUM – Annex V

Abbreviations

 

ACER/ the Agency Agency for the Cooperation of Energy Regulators
ARIS Agency’s REMIT Information System
CCP Central Counterparty
CEREMP Centralised European Registry of wholesale Energy Market Participants
EIC Energy Identification Code
EMIR European Market Infrastructure Regulation
ENTSO-E European Network of Transmission System Operators for Electricity
ENTSOG European Network of Transmission System Operators for Gas
ESMA European Securities and Markets Authority
GLN/GS1 Global Notification Number
LEI Legal Entity Identifier
LNG Liquefied Natural Gas
LSO LNG System Operator
MAD Market Abuse Directive
MAR Market Abuse Regulation
MIC Market Identifier Code
MiFID Markets in Financial Instruments Directive
MiFIR Markets in Financial Instruments Regulation
MoU Memorandum of Understanding
MP Market Participant
MS Member State
NRA National Regulatory Authority
OMP Organised Market Place
OTC Over the Counter
OTF Organised Trading Facility
PPAT Person Professionally Arranging Transactions
REMIT Regulation on wholesale Energy Market Integrity and Transparency
RRM Registered Reporting Mechanisms
SSO Storage System Operator
TSO Transmission System Operator
UMM Urgent Market Message
UTC Coordinated Universal Time
UTI Unique Transaction Identifier
VTP Virtual trading point
VWAP Volume-weighted Average Price

[Download PDF]

RSS_Icon Last update: 08/01/2015  

RSS_Icon Subscribe to this Category’s RSS