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 VI

Additional information on how to correctly report the Delivery point or zone

 

1  Background

The Agency has already provided its guidance in the Transaction Reporting User Manual (TRUM), in relation to Data Field No (48) Delivery point or zone (Table 1) and Data Field No (41) Delivery point or zone (Table 2) for electricity or gas supply and derivative contracts. The following is explained in the TRUM:

Data Fields No (48) Table 1 and No (41) Table 2 Delivery point or zone

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

 

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

 

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

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

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

Please note that this guidance will affect a very small number of transactions reported to the Agency as about 95% of reported transactions refer to valid Delivery point or zone codes.

 

2  Additional clarification to be provided to reporting parties

This guidance provides additional information on how to correctly report the Delivery point or zone.

Any contract related to the supply of electricity or gas, irrespective of whether the contract is a spot, a physical forward, a future or an option contract has a reference to a delivery point or zone. Also financial derivatives related to EU electricity or gas have a reference price or other attributes which relates to the delivery of the commodity.

The Agency has published the list of accepted EIC codes for REMIT transaction reporting purposes on the Agency’s REMIT portal attached to this Annex. No other codes should be reported unless listed on the Agency’s REMIT portal.

Additional codes that represent delivery points for REMIT transaction reporting purposes currently not listed should be notified to the Agency.

 

3  Electricity delivery point or zone

The delivery point or zone of a contract for the supply of electricity can be of two types:

1. Balancing zone: This is the zone for which the system operator is responsible to keep the electricity in balance. Market participants will deliver and take the delivery (transfer of ownership of the commodity) of the electricity through their nominations, e.g. the notification of the electricity delivered or withdrawn into or from the system to the System Operator;

2. Market area: This is the area that the specific contract refers to. It can be the same as the balancing area or it can encompass several balancing areas.

 

4  Gas delivery point

The delivery point or zone of a contract for the supply of gas can be of four types:

1. Balancing zone: This is the zone where the system operator is responsible to keep the gas in balance. Market participants will deliver and take the delivery (transfer of ownership of the commodity) of the gas through their nominations, e.g. the notification of the gas delivered or withdrawn into or from the system to the system operator;

2. Market area: This is the area that the specific contract refers to. It can be the same as the balancing area or it can encompass several balancing areas.

3. Interconnection or entry point (e.g. terminal):

a. The interconnection point is the point where gas is delivered and then transferred to the other side of the interconnection point by the system operator. This case applies to unbundled interconnection capacity only. E.g. Interconnection between area (A), managed by system operator (TSO_X), and area (B), managed by the neighbouring system operator (TSO_Y):

i. Market participant (MP1) delivers and balances its position at point (A) with TSO_X. Market participant (MP1) makes its nomination at point (A) with TSO_X;

ii. The system operators TSO_X and TSO_Y transfer the energy from point (A) to point (B);

iii. Market participant (MP2) delivers the gas and balances its position at point (B) with TSO_Y while the market participant (MP2) makes the nomination at point (B).

iv. Delivery at interconnection points across two EU member states have to be reported only in case of unbundled capacity. In all other cases the balancing zone or market area should be reported (see point 3(a) above;

v. Delivery at interconnection points across a NON-EU and an EU member state with unbundled capacity has to be reported only in case of flow in the direction to the EU member state. Example: two counterparties have a gas contract for the delivery at interconnection point with unbundled capacity (also called at the border). If the gas flows from the NON-EU to the EU member state, the contract is reportable under REMIT as the counterparty (in the contract) receiving the gas is registered in the EU member state.

On the contrary if the gas flows from the EU to the NON-EU country, the contract is NOT reportable under REMIT as the counterparty receiving the gas is based in an NON-EU country.

b. The entry point (e.g. terminal) is the physical delivery point where the commodity changes hands at an entry point. For example this can be a terminal e.g. St. Fergus in Scotland (GB) where a seller delivers the gas to the buyer before the gas flows into the NBP hub (balancing zone).

4. Storage or LNG facility: This is the gas facility the contract refers to and it is a physical location.

 

5  How to read the spreadsheet

The “List of accepted EICs_Table_1_and_2” for REMIT transaction reporting purposes spreadsheet available on the Agency’s REMIT portal as an attachment to this Annex is formed of four sheets:

 

1. EIC Validity Check: this sheet has the following columns:

a. EICs: List of all Delivery point or zone EIC codes reported to the Agency with Table 1 and Table 2;

b. Country: The country the EIC refers to. This is a look-up from “Full List” sheet on the EIC listed in column “EICs”;

c. EL/NG: The type of energy commodity the EIC refers to;

d. Valid/Invalid: This column confirms the Agency understanding of the validity of the code.

e. EL Balancing Zone: The electricity balancing zone the EIC refers to. This is a look-up from “EL Codes” sheet (see below) on the EIC listed in column “EICs”;

f. EL Market Area: The electricity market area that the EIC code refers to. This is a look-up from “EL Codes” sheet (see below) on the EIC listed in column “EICs”;

g. NG Balancing Zone: The gas balancing zone that the EIC code refers to. This is a look-up from “NG Codes” sheet (see below) on the EIC listed in column “EICs”;

h. NG Market Area: The gas market area that the EIC code refers to. This is a look-up from “NG Codes” sheet (see below) on the EIC listed in column “EICs”;

i. Interconnection Points or entry point (e.g. terminal): The interconnection point or entry point that the EIC code refers to. This is a look-up from “Z Codes” sheet (which includes some Y codes too) on the EICs listed in column “EICs”;

j. LNG/Storage: The LNG/Storage facility that the EIC code refers to. This is a look-up from “W Codes” sheet on the EICs listed in column “EICs”;

k. ENTSO-E Website: When none of the above is applicable, the description of the EIC code refers to is checked with the one available on the ENTSO-E website;

l. Last digit check: When none of the above are applicable, the EIC code is checked for its integrity according to the EIC check logic. The tool is available on the ENTSO-E website (https://www.entsoe.eu/data/energy-identification-codes-eic/eic-code-lists/Pages/default.aspx)

2. List of Accepted EICs: This sheet lists:

  • EU’s electricity balancing zones and the electricity market areas the Agency is aware of. Each balancing zone or market area has one code.
  • EU’s gas balancing zones and the gas market areas the Agency is aware of. Each balancing zone or market area has one code.
  • EU’s interconnection points or entry points the Agency is aware of. Each interconnection or entry point has one code.
  • EU’s LNG/Storage facilities the Agency is aware of. Each LNG/Storage facility has one code and it will not be change in the future.

Should the Agency have not included any code mentioned in (2), (3) and (4), reporting parties should notify the code through the web form available at http://surveys.acer.europa.eu/eusurvey/runner/EICs_mapping

3. Invalid Codes: The list of invalid reported EIC codes identified by the Agency so far.

4. Full list: The list of Y-Z-W EIC codes available on ENTSO-E website at https://www.entsoe.eu/fileadmin/user_upload/edi/library/eic/EICRegistry.htm on 31 January 2017.

 

6  Actions to be taken by Organised Market Places and Market Participants

Reporting parties should take the following actions:

Valid: For EIC codes listed in column “EICs” of the sheet “EICs Validity Check” and flagged as “Valid” in column “Valid/Invalid” of the same sheet, in limited cases reporting parties may need to take corrective action (see below).

Where the EIC code is labelled as “Valid”, it is possible that reporting parties have submitted a code that belongs to another zone/area. For example: if a contract delivers gas at a balancing zone/market area in a specific country and the code for the electricity balancing zone/market area for the same country was reported instead, reporting parties should notify the Agency of such errors.

Invalid Code: For EIC codes listed in column “EICs” of the sheet “EICs Validity Check” and flagged as “Invalid” in column “Valid/Invalid” of the same sheet, reporting parties have to take action.

EICs listed in column “EICs” are labelled as “Invalid Code” when checked for their integrity according EIC checker available on the ENTSO-E website. As they are invalid they have to be corrected. In order to do so the online form should be used.

ENTSO-E: For EIC codes listed in column “EICs” of the sheet “EIC Validity Check” and flagged as “ENTSO-E” in column “Valid/Invalid” of the same sheet, reporting parties have to take action.

When EIC codes listed in column “EICs” do not have a match in the sheet “List of Accepted EICs” then the EIC is searched within the list of available codes published by ENTSO-E. Most of the codes published on the ENTSO-E website represent the same delivery point/area of those listed in “List of Accepted EICs”.

For example, the GB balancing zone is identified by the EIC code “10YGB———-A”. For the same balancing zone, reporting parties are also reporting “10Y1001A1001A58E” for Bidding Zone – Great Britain (APX) and “10Y1001A1001A57G” for Bidding Zone – Great Britain (N2EX). While this may be clear in the example above, there are thousands codes that may cause confusion to reporting parties.

Another example is when EIC codes are used to represent a market coupling area which does not specify the balancing zone where delivery takes place but the market coupling area. Example: if a market participant trades in country “A” and bids on a contract for delivery to “A” which is part of a market coupling area “A-B-C”, the EIC code for “A” should be reported.

Since it is not possible to identify the delivery area from these codes, and since different reporting parties may have interpreted these codes in a different way, reporting parties have to map these codes to existing codes available in “List of Accepted EICs” sheet. This will be a one-of time exercise.

In order to provide the mapping to the Agency reporting parties have to use the online form. The online form is self-explanatory and reporting parties have to fill in all the mandatory fields. No other communication channel will be made available.

Missing: For EIC codes listed in column “EICs” of the sheet “EIC Validity Check” and flagged as “Missing” in column “Valid/Invalid” of the same sheet, reporting parties have to take action.

When EICs listed in column “EICs” do not have a match in the sheet “List of Accepted EICs” then reporting parties have to map these codes to existing codes available in “List of Accepted EICs” sheet.

Missing codes, although may be valid codes issued by Local Issuing Office (LIO), may be interpreted, and reported in a different way and reporting parties have to map these codes to existing codes available in “List of Accepted EICs” sheet.

 

7  Corrective Action

In order to provide the mapping to the Agency, reporting parties have to use the online form. Reporting parties may also report new EIC codes not listed yet in the Agency’s list of accepted codes.

 

8  The way forward

As soon as possible reporting parties should use only EICs published in the Agency’s REMIT portal as attachment to this Annex.

As of 1 September 2017 a new validation rule will prevent the reporting of EICs not listed in the Agency’s list of accepted codes.

In case any new delivery point or zone has been created which will be relevant for REMIT transaction reporting purposes, reporting parties should notify them to the Agency using the on line form to update the ARIS validation rules with a least 10 working days’ notice.


[Download document]

RSS_Icon Last update: 14/11/2018  

Transaction Reporting User Manual (TRUM)

Contents


[Download document]

RSS_Icon Last update: 23/10/2017  

TRUM – Section 3.5

How to send a transaction report

Article 10(3) of the Implementing Acts stipulates that the Agency shall, after consulting relevant parties, establish procedures, standards and electronic formats based on established industry standards for reporting of, inter alia, trade data. These procedures, standards and electronic formats are described in the Agency’s Manual of Procedures on transaction and fundamental data reporting.

Furthermore, according to Article 11 of the Implementing Acts, the Agency shall develop technical and organisational requirements for submitting data. The requirements shall ensure efficient, effective and safe exchange and handling of information. They shall:

a) ensure the security, confidentiality and completeness of information;

b) enable the identification and correction of errors in data reports;

c) enable authentication of the source of information;

d) ensure business continuity.

The Agency shall assess whether reporting parties comply with the requirements. Reporting parties who comply with the requirements shall be registered by the Agency.

Reporting entities complying with the RRM requirements defined by the Agency shall be registered by the Agency as such.

The transaction reporting will be done through the Agency’s REMIT Information System (ARIS)[1].


[1] See Section 3.1.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 5.6

Data fields related to lifecycle information

This section includes the following fields:

45. Action type

 

Data Field No (45) Action type

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

 

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

 

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

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 7.4

Data fields for identification of location and market participant

This section includes the following fields:

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

 

Data Field No (22) Network point identification

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

 

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

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

10Y0000123456789

 

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

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

 

Data Field No (23) Bundling

No. Field Identifier Description
23 Bundling Specification of bundling

 

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

ZEO for Bundled, ZEP  for Unbundled

Alphanumeric Maximum 3 ZEO

 

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

This field is mandatory for auctions.

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

 

Data Field No (24) Direction

No. Field Identifier Description
24 Direction Specification of direction.

 

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

 

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

This field is mandatory.

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

 

Data Field No (25) TSO 1 identification

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

 

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

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

10Y0000123456789

 

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

Both the identification and the coding scheme are mandatory.

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

 

Data Field No (26) TSO 2 identification

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

 

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

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

10Y0000123456789

 

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

Both the identification and the coding scheme are dependent.

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

 

Data Field No (27) Market participant identification

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

 

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

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

10X1001A1001A450

 

This field identifies the market participant the capacity is assigned.

This field is mandatory for primary allocations.

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

 

Data Field No (28) Balancing group or portfolio code

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

 

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

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

 

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4

Reporting of standard supply contracts

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

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 5.7

Examples of transaction reporting

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 7.5

Data fields applicable only for secondary allocations

This section includes the following fields:

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

 

Data Field No (29) Procedure applicable

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

 

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

 

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

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

 

Data Field No (30) Maximum bid amount

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

 

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

ISO 6093

17 1.8

 

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

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

 

Data Field No (31) Minimum bid amount

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

 

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

ISO 6093

17 1.8

 

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

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

 

Data Field No (32) Maximum quantity

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

 

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

ISO 6093

17 1.8

 

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

All quantities are unsigned values.

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

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

 

Data Field No (33) Minimum quantity

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

 

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

ISO 6093

17 1.8

 

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

All quantities are unsigned values.

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

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

 

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

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

 

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

ISO 6093

17 1.8

 

This field indicates the price paid to the TSO.

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

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

 

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

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

 

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

ISO 6093

17 1.8

 

This field is mandatory for secondary market transactions.

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

 

Data Field No (36) Transferor identification

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

 

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

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

10X1001A1001A450

 

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

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

 

Data Field No (37) Transferee identification

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

 

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

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

10X1001A1001A450

 

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.1

Data fields related to the parties to the contract

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

4.      ID of the other market participant or counterparty

5.      Type of code used in field 4

6.      Reporting entity ID

7.      Type of code used in field 6

8.      Beneficiary ID

9.      Type of code used in field 8

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

11.    Buy/sell indicator

12.    Initiator/Aggressor

 

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

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

 

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

 

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

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

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

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

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

If a market participant is using an ACER code, this can be used to verify the identity of the other market participant from the European register of market participants published by the Agency and available on the Agency’s website.

 

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

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

 

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

 

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

 

Data Field No (3) ID of the trader and/or of the market participant or counterparty as identified by the organised market place

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

 

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

 

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

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

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

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

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

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

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

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

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

 

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

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

 

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

 

This field indicates the ID of the other market participant or counterparty to the transaction that is reported. This field shall only be populated when reporting bilateral trades, including those bilateral trades that take place on broker platforms or any other organised market place which allows bilateral trades.

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

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

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

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

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

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

 

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

 

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

 

Data Field No (6) Reporting entity ID

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

 

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

 

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

 

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

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

 

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

 

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

 

Data Field No (8) Beneficiary ID

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

 

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

 

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

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

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

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

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

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

Bilateral and non-cleared transactions executed off-market may be of the form A sells to B with beneficiary C. In these cases, the Agency will receive one reported trade: A sells to B with C identified in field 8 as Beneficiary.

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

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

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

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

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

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

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

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

 

Data Field No (11) Buy/sell indicator

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

 

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

 

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

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

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

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

 

Data Field No (12) Initiator/Aggressor

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

 

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

 

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

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

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

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

A buys from C:

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

C buys from B:

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

This field does not apply to orders to trade.

 

RSS_Icon Last update: 09/05/2016  

RSS_Icon Subscribe to this Category’s RSS