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 2

Legal framework

In December 2011, the EU adopted a dedicated market integrity and transparency regulation for the gas and electricity wholesale markets with an EU-wide monitoring scheme: Regulation (EU) No 1227/2011 on wholesale energy market integrity and transparency (REMIT). REMIT introduces a sector-specific framework for the monitoring of European wholesale energy markets, with the objective of detecting and deterring market manipulation.

It defines prohibitions of market manipulation, attempted market manipulation and insider trading. It introduces obligations to disclose inside information and it provides for the monitoring of wholesale energy markets by the Agency in close cooperation with national regulatory authorities (‘NRAs’), the European Securities and Markets Authority (ESMA), financial authorities and other relevant authorities.

For the purpose of market monitoring, Article 8(1) of REMIT imposes an obligation on market participants, or third parties or authorities acting on their behalf, to provide the Agency with a record of wholesale energy market transactions, including orders to trade (‘trade data’). Furthermore, Article 8(5) of REMIT requires that market participants shall report to the Agency and NRAs information related to the capacity and use of facilities for production, storage, consumption or transmission of electricity or natural gas and use of LNG facilities, including planned or unplanned unavailability of these facilities (’fundamental data’).

REMIT also gives NRAs the option to monitor wholesale energy markets at national level and calls on Member States to provide them with appropriate investigatory and enforcement powers (see Article 13 of REMIT). REMIT also requires that the Agency shall establish a mechanism to share information it receives in accordance with Article 8 with NRAs and other relevant authorities (see Article 7(2) and 10 of REMIT).

According to Article 8(2) and 8(6) of REMIT, the European Commission shall, by means of Implementing Acts, adopt uniform rules on the reporting of records of transactions, including orders to trade (‘trade data’).

As regards the reporting of transactions, Article 8(2) of REMIT states that the Commission shall, by means of Implementing Acts:

a)    draw up a list of the contracts and derivatives, including orders to trade, which are to be reported in accordance with paragraph 1 and appropriate de minimis thresholds for the reporting of transactions where appropriate;

b)    adopt uniform rules on the reporting of information which is to be provided in accordance with paragraph 1;

c)    lay down the timing and form in which that information is to be reported.

As regards the reporting of fundamental data, Article 8(6) of REMIT states that the Commission shall, by means of Implementing Acts:

a)    adopt uniform rules on the reporting of information to be provided in accordance with paragraph 5 and on appropriate thresholds for such reporting where appropriate;

b)    lay down the timing and form in which that information is to be reported.

On 17 December 2014 the Commission adopted the Implementing Acts according to Article 8(2) and 8(6) of REMIT. According to Article 5(2) of the Implementing Acts, the Agency shall explain the details of the reportable information in relation to standard and non-standard contracts for the supply and transportation of electricity and gas in a user manual and after consulting relevant parties make it available to the public upon the entry into force of the Implementing Acts. On this basis, the Agency has developed this Transaction Reporting User Manual (TRUM), in which the details of the reportable information are explained.

On 31 March 2014, the Agency launched a first public consultation on the TRUM which was open until 5 May. The first public consultation document was prepared on the basis of the draft Implementing Acts presented by the Commission in October 2013 and also took into account the feedback received during the public consultation on Technical Standards in spring 2013.

Following the end of the first consultation, the Agency further elaborated the TRUM, taking into account the input received during the first consultation in spring 2014. On 22 July 2014, the Agency launched a second public consultation on the TRUM which was open until 2 September 2014. The second public consultation document was prepared on the basis of the draft Implementing Acts presented by the Commission in July 2014. In addition to the public consultations, the Agency organised a number of roundtable meetings and workshops with relevant stakeholders in order to consult on the topics of the TRUM.

An ACER staff working document version was published on 9 December 2014 and presented in a public workshop on 10 December 2014.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.5

Data fields related to option details

This section includes the following fields:

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

 

Data Field No (44) Option style

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

 

Description of Accepted Values Type Length Examples
A=American
B=Bermudan
E=European
S=Asian
O=Other
Text 1 B

 

This field identifies the option style, usually defined by the dates on which the option may be exercised: American, European, Bermudian, Asian or other style.

An American style option can be exercised anytime during its life allowing option holders to exercise the option at any time prior to and including its maturity date. A European style option can only be exercised at the maturity date. A Bermudian style option can only be exercised on specified dates indicated in field 46.

Reporting parties should refer to financial markets in order to identify the option style they are reporting. The reporting of exotic option styles such as binary, barrier, window options, etc., if traded at organised market places, should be reported with the value of “O”.

 

Data Field No (45) Option type

No. Field Identifier Description
45 Option type Indicates whether the option is a call, put or other.

 

Description of Accepted Values Type Length Examples
P=Put
C=Call
O=Other
Text 1 C

 

This field identifies the type of right the option holder owns, if it is a call option or a put option. “P” shall be indicated if the option is a put option and “C” shall be indicated if the option is a call option. If the option holder owns a type of right different from put or call, the value “O” for other shall be reported in this field.

Reporting parties should refer to financial markets in order to identify the option type they are reporting.

 

Data Field No (46) Option exercise date

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

 

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

 

This field identifies the date at which the option holder has the right, but not the obligation, to buy or sell the commodity or underlying instrument at a specified price on or before a specified date. In the case of an American, European or Asia option style, one exercise date is reported. In the case of a Bermudian option style, several dates may be reported.

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

 

Data Field No (47) Option strike price

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

 

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

 

This field identifies the price at which the owner of the option can buy (in the case of a call option) or sell (in the case of a put option) the energy commodity (gas or electricity) or the instrument as indicated in the option contract, e.g. future/forward/swap.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 6.4

Data fields related to secondary rights time series (for secondary rights)

This section includes the following fields:

31. Time series identification
32. Business type
33. In area
34. Out area
35. Rights holder
36. Transferee party
37. Contract identification
38. Contract type
39. Previous contract identification
40. Measure unit quantity
41. Auction identification
42. Currency
43. Measure unit price
44. Curve type

 

Data Field No (31) Time series identification

No. Field Identifier Description
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.

 

Description of Accepted Values Type Length Examples
Time series Unique Identification Alphanumeric Maximum 35 RS123446928
or 1432_137_42_40_559

 

This field provides a unique number that is assigned by the sender for each time series in the document.

This field is mandatory.

 

Data Field No (32) Business type

No. Field Identifier Description
32 Business type Identifies the nature of the time series, e.g. capacity rights, capacity transfer notification, etc.

 

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

A57 = Resale pricing

Alphanumeric 3 A57

 

This field indicates the nature of the time series concerning the rights.

This field is mandatory.

 

Data Field No (33) In area

No. Field Identifier Description
33 In area The area where the energy is to be delivered (EIC Y Code).

 

Description of Accepted Values Type Length Examples
EIC Alphanumeric The maximum length of this information is 16 characters 10Y0000123456789

 

This field identifies the area where the energy is going (10Y code of area where the energy is going).

This field is mandatory.

 

Data Field No (34) Out area

No. Field Identifier Description
34 Out area The area where the energy is coming from (EIC Y Code).

 

Description of Accepted Values Type Length Examples
EIC Alphanumeric The maximum length of this information is 16 characters 10Y0000123456789

 

This field identifies the area where the energy is coming from (10Y code of area where the energy is coming from).

This field is mandatory.

 

Data Field No (35) Rights holder

No. Field Identifier Description
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).

 

Description of Accepted Values Type Length Examples
EIC Alphanumeric The maximum length of this information is 16 characters 10Y0000123456789

 

This field identifies the Rights Holder by a unique coded identification. Whenever rights are transferred, the Rights Holder is the transferor of the rights.

This field is mandatory.

 

Data Field No (36) Transferee party

No. Field Identifier Description
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).

 

Description of Accepted Values Type Length Examples
EIC Alphanumeric The maximum length of this information is 16 characters 10Y0000123456789

 

This field identifies the Transferee party by a unique coded identification. In certain cases the transferee party also acts as Interconnection Trade Responsible.

This field is mandatory in case of transfers.

 

Data Field No (37) Contract identification

No. Field Identifier Description
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. the TSO or auction operator, or allocation platform.

 

Description of Accepted Values Type Length Examples
Capacity Agreement Identifications (CAI) Alphanumeric Maximum 35 3105105CY601

 

This field provides the number that has been assigned by the Transmission Capacity Allocator. This field provides identification that uniquely identifies the allocation.

This field is mandatory.

 

Data Field No (38) Contract type

No. Field Identifier Description
38 Contract type The contract type defines the conditions under which the rights was allocated and handled, e.g. daily auction, weekly auction, monthly auction, yearly auction, etc.

 

Description of Accepted Values Type Length Examples
Refer to ETSO Code list document for the valid list of codes.
A01 = Daily
A02 = Weekly
A03 = Monthly
A04 = Yearly
Alphanumeric 3 A01

 

This field defines the conditions under which the rights were allocated and handled. The significance of this type is dependent on the in area and out area specific coded working methods.

The Transmission Capacity Allocator responsible for the area in question auctions defines the contract type to be used, e.g.: daily auction, weekly auction, monthly auction, yearly auction, Long term contract, etc.

This field is mandatory.

 

Data Field No (39) Previous contract identification

No. Field Identifier Description
39 Previous contract identification (if applicable) The identification of a previous contract used to identify the transfer rights.

 

Description of Accepted Values Type Length Examples
Capacity Agreement Identifications (CAI) Alphanumeric Maximum 35 3105105CY601

 

This information identifies the previous identification that was used to identify the rights. This is only applicable if there was a change in Contract Identification information.

 

Data Field No (40) Measure unit quantity

No. Field Identifier Description
40 Measure unit quantity The unit of measure that is applied to the quantities in which the time series is expressed.

 

Description of Accepted Values Type Length Examples
Refer to ETSO Code list document for valid codes. Alphanumeric Maximum 3 MWH

 

This field indicates the unit if measurement used for the quantities expressed within the time series.

This field is mandatory.

 

Data Field No (41) Auction identification

No. Field Identifier Description
41 Auction identification (if applicable) The identification linking the capacity rights to a set of specifications created by the transmission capacity allocator, e.g. TSO or auction operator, or allocation platform.

 

Description of Accepted Values Type Length Examples
Unique Identification that clearly identifies the auction to which the bid is addressed. Alphanumeric Maximum 35 AT-CH-M-BASE——-140801-01

 

This field provides a unique identification of the set of specifications that clearly defines the auction to which the capacity rights submitted by the Capacity Trader are to be re-auctioned.

 

Data Field No (42) Currency

No. Field Identifier Description
42 Currency (if applicable) The currency in which the monetary amount is expressed.

 

Description of Accepted Values Type Length Examples
Refer to ETSO Code list document for valid codes. String Maximum 3
ISO 4217
EUR

 

This field indicates the currency used for the monetary amount expressed within the time series.

This information is mandatory if available.

 

Data Field No (43) Measure unit price

No. Field Identifier Description
43 Measure unit price (if applicable) The unit of measure in which the price in the time series is expressed.

 

Description of Accepted Values Type Length Examples
Refer to ETSO Code list document for valid codes. Alphanumeric Maximum 3 MWh

 

This field indicates the unit if measurement used for the price expressed within the time series (MW per unit, MWh per unit, etc.).

This information is mandatory.

 

Data Field No (44) Curve type

No. Field Identifier Description
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.

 

Description of Accepted Values Type Length Examples
Refer to ETSO Code list document for valid codes.
A01 – Sequential fixed size blocks
A02 – Points
A03 – Variable sized blocs
A04 – Overlapping breakpoints
A05 – Non-overlapping breakpoints
Alphanumeric Maximum 3 A01

 

This field represents the coded identification of the curve that is described in the Period and Interval class.

If the “Curve Type” element is omitted in the XML instance a default value of “sequential fixed sized blocks” shall be understood. Sequential fixed size blocks (A01) curve is made of successive Intervals of time (Blocks) of constant duration (size), where the size of Blocks is equal to the Resolution of the Period. The value of the Quantity remains constant within each block.

This information is mandatory if available.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 3.1

Market monitoring

The primary purpose of transaction reporting under REMIT is to enable the Agency and NRAs to efficiently and effectively monitor trading activity in wholesale energy products to detect and to prevent suspected market abuse (insider trading and market manipulation[1]) in order to fulfil the goal of increased integrity and transparency of wholesale energy markets[2]. This is important in order to ensure that final consumers and other market participants can have confidence in the integrity of electricity and gas markets, that prices set on wholesale energy markets reflect a fair and competitive interplay between supply and demand, and that no profits can be drawn from market abuse[3].

According to Article 7 of REMIT, the Agency shall monitor trading activity in wholesale energy products to detect and prevent market manipulation, attempted market manipulation and trading based on inside information. According to Article 16 of REMIT, NRAs shall cooperate at regional level and with the Agency in carrying out the monitoring of wholesale energy markets and ensure that the prohibitions of market manipulation, attempted market manipulation and insider trading are applied in accordance with Article 13 of REMIT.

The automated screening will form part of the Agency’s monitoring activities. Article 16(4) of REMIT also requires an initial assessment or analysis by the Agency prior to notifying a suspected breach of REMIT to the NRAs and prior to using the Agency’s powers under Article 16(4) of REMIT. The following figure illustrates the market monitoring approach envisaged by the Agency.

The Agency’s REMIT Information System (ARIS) is the Agency’s IT system for data collection, data sharing, and automatic screening and monitoring of trading activities in wholesale energy products. The high-level architecture of ARIS is illustrated below.

ARIS is based on four tiers:

  • Tier 1 of ARIS will support the collection of the reported trade and fundamental data. The scope and details for the data to be reported under Tier 1 is defined by the European Commission in the Implementing Acts.
  • Tier 2 of ARIS is the main database, where all the reported trade and fundamental data, as well as the registration data from market participants, will be stored.
  • Tier 3 of ARIS is the market monitoring system, which will screen and analyse the data collected and processed in Tier 1 and 2, with the aim to detect and deter market abuse in forms of insider trading and market manipulation, including attempted market manipulation. The market monitoring system will also be used for supporting investigations conducted by NRAs in coordination with the Agency.
  • Tier 4 of ARIS is the data sharing system. According to Article 10 of REMIT, the Agency shall establish mechanisms to share the information held in ARIS with NRAs, financial regulatory authorities, national competition authorities, the European Securities and Markets Authority (ESMA) and other relevant authorities. This tier may also be used for additional data analysis, reporting and archiving, and for the publication of certain aggregated information according to Article 12(2) of REMIT.

ARIS plays a key role in both the identification of suspicious transactions and the establishment of facts once suspected market abuse has been identified. However, the efficiency of both of these functions can be compromised by inaccurate transaction reporting and poor data quality. The Agency is required to identify any questionable transactions and establish their nature, timing and the parties involved.

Transaction reports are a key means of establishing this, enabling the Agency to discover possible instances of market abuse that call for further investigation and possible enforcement actions by NRAs. Similarly, transaction reports are very important as evidence when NRAs are bringing market abuse cases to court, as they provide an audit trail of the complete transaction.

The Agency also carries out wider market monitoring to detect any possible risks of market abuse due to market developments and new features of the markets. Transaction reports provide the Agency with useful information that can help with this kind of monitoring, e.g. statistics that show the rate of growth in the trading of certain wholesale energy products.

According to the requirements set out in Article 12 of REMIT, the Agency shall ensure the confidentiality, integrity and protection of the information collected under REMIT. Hence, ARIS must be operationally reliable.


[1] For definitions and explanations of the concept of insider trading and market manipulation, please refer to the ACER Guidance on the application of REMIT: http://www.acer.europa.eu/remit/Documents/REMIT%20ACER%20Guidance%203rd%20Edition_FINAL.pdf.

[2] See recital 2 of REMIT.

[3] See recital 1 of REMIT.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.6

Data fields related to delivery profile

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

 

Data Field No (48) Delivery point or zone

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

 

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

 

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

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

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

 

Data Field No (49) Delivery start date

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

 

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

 

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

 

Data Field No (50) Delivery end date

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

 

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

 

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

 

Data Field No (51) Duration

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

 

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

 

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

 

Data Field No (52) Load type

No. Field Identifier Description
52 Load type Identification of the delivery profile (base load, peak load, off-peak, block of hours or other)

 

Description of Accepted Values Type Length Examples
BL=Base load
PL=Peak load
OP=Off-Peak load
BH=Hour/Block Hours
SH =Shaped
GD=Gas Day
OT=Other
Text 2 BL

 

This field identifies the delivery profile (base load, peak load, off-peak, block of hours or other) of the contract. The load type should be defined as per the definition of the organised market place hosting the contract or, if available, as indicated in the contract in case of bilateral trade.

 

Data Field No (53) Days of the week

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

 

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

 

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

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

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

 

Data Field No (54) Load delivery intervals

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

 

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

 

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

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

 

Data Field No (55) Delivery capacity

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

 

Description of Accepted Values Type Length Examples
Up to 20 numerical digits in the format xxxxx.yyyyy with a maximum of 5 decimals. Number 20 10

 

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

 

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

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

 

Description of Accepted Values Type Length Examples
KW
KWh/h
KWh/d
MW
MWh/h
MWh/d
GW
GWh/h
GWh/d
Therm/d
KTherm/d
MTherm/d
cm/d
mcm/d
Btu/d
MMBtu/d
MJ/d
100MJ/d
MMJ/d
GJ/d
Text 2 to 8 MW

 

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

 

Data Field No (57) Price/time interval quantity

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

 

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

 

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 6.5

Data fields related to period for primary allocation and secondary processes

This section includes the following fields:

45. Time interval
46. Resolution

 

Data Field No (45) Time interval

No. Field Identifier Description
45 Time interval This information provides the date and time of the start and end of the reported period.

 

Description of Accepted Values Type Length Examples
ISO 8601 date format using UTC time format. Date and Time 41 2009-03-01T13:00:00Z/2010-05-11T15:30:00Z

 

This field identifies the start and end date and time of the time interval of the period in question. The time of the start and end of the period is expressed in UTC.

There may be several period classes for a time series. The overall time interval covered by the period shall be within the complete rights time interval. The number of periods within a time series as characterised by the resolution must completely cover the period’s time interval. If a time series is suppressed then the interval quantities are all zeroed out.

This field is mandatory.

 

Data Field No (46) Resolution

No. Field Identifier Description
46 Resolution The resolution defining the number of periods that the time interval is divided (ISO 8601).

 

Description of Accepted Values Type Length Examples
The resolution is expressed in compliance with ISO 8601.
For example PT15M expresses a 15 minute resolution.
Date and Time PnYnMnDTnHnMnS PT15M

 

This field identifies the number of periods that the time interval is divided. Where nY expresses a number of years, nM a number of months, nD a number of days. The letter “T” separates the date expression from the time expression and after it nH identifies a number of hours, nM a number of minutes and nS a number of seconds.

This information defines the resolution of a single period. The time interval must contain a whole number of periods as expressed by the resolution.

This field is mandatory.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 3.2

What to report?

According to Article 8(1) of REMIT, market participants, or a person or authority acting on their behalf, shall provide the Agency with a record of wholesale energy market transactions, including orders to trade. Article 8 of REMIT also stipulates that the Commission, by means of Implementing Acts, shall define the list of contracts to be reported, the timing and form for reporting and who should report transactions.

The Implementing Acts also provide a context for the reporting of fundamental data. For further information in this regard, please consult the Manual of Procedures on transaction and fundamental data reporting.

The list of contracts to be reported is defined in Article 3 of the Implementing Acts. An overview of the reportable contracts is provided below.

1. Supply contracts

According to Article 3(1)(a) of the Implementing Acts, the following wholesale energy products in relation to the supply of electricity or natural gas with delivery in the Union shall be reported:

(i) intraday or within-day contracts for the supply of electricity or natural gas where delivery is in the Union irrespective of where and how they are traded, in particular regardless of whether they are auctioned or continuously traded;

(ii) day-ahead contracts for the supply of electricity or natural gas where delivery is in the Union irrespective of where and how they are traded, in particular regardless of whether they are auctioned or continuously traded;

(iii) two-days-ahead contracts for the supply of electricity or natural gas where delivery is in the Union irrespective of where and how they are traded, in particular regardless of whether they are auctioned or continuously traded;

(iv) week-end contracts for the supply of electricity or natural gas where delivery is in the Union irrespective of where and how they are traded, in particular regardless of whether they auctioned or continuously traded;

(v) after-day contracts for the supply of electricity or natural gas where delivery is in the Union irrespective of where and how they are traded, in particular regardless of whether they auctioned or continuously traded;

(vi) other contracts for the supply of electricity or natural gas with a delivery period longer than two days where delivery is in the Union irrespective of where and how they are traded, in particular regardless of whether they are auctioned or continuously traded;

(vii) contracts for the supply of electricity or natural gas to a single consumption unit with a technical capability to consume 600 GWh/year or more.

2. Transportation contracts

According to Article 3(1)(b) of the Implementing Acts, the following wholesale energy products in relation to the transportation of electricity or natural gas in the Union shall be reported:

(i) Contracts relating to the transportation of electricity or natural gas in the Union between two or more locations or bidding zones concluded as a result of a primary explicit capacity allocation by or on behalf of the TSO, specifying physical or financial capacity rights or obligations.

(ii) Contracts relating to the transportation of electricity or natural gas in the Union between two or more locations or bidding zones concluded between market participants on secondary markets, specifying physical or financial capacity rights or obligations, including resale and transfer of such contracts.

3. Derivatives of energy supply and transportation contracts

Article 3(1)(a) and (b) of the Implementing Acts stipulate the reporting of the following derivatives contracts:

a) options, futures, swaps and any other derivatives of contracts relating to electricity or natural gas produced, traded or delivered in the Union (Article 3(1)(a)(8));

b) options, futures, swaps and any other derivatives of contracts relating to the transportation of electricity or natural gas in the Union (Article 3(1)(b)(3)).

4. Contracts reportable on request of the Agency

Article 4(1) of the Implementing Acts also establishes a list of contracts reportable only upon reasoned request of the Agency and on an ad-hoc basis. This includes:

a) intragroup contracts;

b) contracts for the physical delivery of electricity produced by a single production unit with a capacity equal to or less than 10 MW or by production units with a combined capacity equal to or less than 10 MW;

c) contracts for the physical delivery of natural gas produced by a single natural gas production facility with a production capacity equal to or less than 20 MW;

d) contracts for balancing services in electricity and natural gas.

As regards the contracts listed in Article 4(1) of the Implementing Acts, for the time being the Agency does not intend to request information on those contracts. For further information, please consult the non-action letter issued by the Agency on 7 January 2015. The Agency will consult in due time before establishing RRM requirements applicable to the reporting of contracts covered by Article 4(1) of the Implementing Acts.

However, if the contracts listed above are concluded at an organised market place, then they shall be reported even in the absence of a request from the Agency.

5. Definition of standard and non-standard contract

According to Article 2 of the Implementing Acts:

a) ‘standard contract’ means a contract concerning a wholesale energy product admitted to trading at an organised market place, irrespective of whether or not the transaction actually takes place on that market place;

b) ‘non-standard contract’ means a contract concerning any wholesale energy product that is not a standard contract;

c) ‘organised market place’ or ‘organised market’ means:

a) a multilateral system, which brings together or facilitates the bringing together of multiple third party buying and selling interests in wholesale energy products in a way that results in a contract;

b) any other system or facility in which multiple third-party buying and selling interests in wholesale energy products are able to interact in a way that results in a contract.
These include electricity and gas exchanges, brokers and other persons professionally arranging transactions, and trading venues as defined in Article 4 Directive 2014/65/EU.

Definition of organised market place

Any multilateral system, which brings together or facilitates the bringing together of “multiple third party” buying and selling interests in wholesale energy products is considered an organised market under REMIT.

The Agency believes that the notion of “multiple third party” plays a key role in determining what constitutes an organised market place; a many-to-many trading possibility must exist in order to consider it an organised market place.

Energy and derivative exchanges, MTFs, OTFs and brokers, are examples of organised market places where many-to-many trading can occur.

In the Agency’s view, multilateral systems that procure or sell energy on behalf of TSOs only for balancing purposes should not be considered organised market places if those systems act solely on behalf of the TSOs.

It is the Agency’s understanding that such a system facilitates a one-to-many trading opportunity at each imbalance period, e.g. in an electricity market, per each half hour/hour balancing period the system procures or sells energy for the TSOs.

However, if the multilateral system brings together or facilitates the bringing together of “multiple third parties” procuring and selling energy, the system facilitates a many-to-many trading opportunity, e.g. if participants can trade with each other and the TSO in a within day gas market to adjust their positions, that system should be considered an organised market place.

Likewise, if the multilateral system brings together or facilitates the bringing together of “multiple third party” buying and selling of capacity, e.g. on a capacity secondary market, that system should be considered an organised market place if that system allows many-to-many trading.

 

The Implementing Acts suggest that any contract admitted to trading at an organised market place is a standard contract. Furthermore, if the same contract is traded outside the organised market place, this shall still be considered a standard contract.

An example of a contract admitted to trading at an organised market place is a future contract on gas or electricity. This future contract is a wholesale energy product that may also be traded bilaterally or through a broker outside the exchange, via its Central Counterparty (CCP) and clearing members. In this case, the contract that is admitted to trading at the organised market place and traded outside the exchange shall be considered a standard contract. The same applies to any wholesale energy product.

Transactions that take place on broker platforms, including those that are voice brokered, are often based on bilateral general agreements, e.g. a master agreement which sets the rules for trading activity of the two counterparties to the contract. As the conclusion of such contracts take place on the broker’s platform (including voice brokered), these contracts are standard contracts. Another example is a spot or forward contract for the physical delivery of electricity concluded on a broker’s platform under a general/master agreement. This is a standard contract irrespective of its profile and complexity, e.g. a shaped (profile) contract traded through a broker (including voice brokered) shall be considered a standard contract.

Two parties may also trade and conclude the same contract under a general/master agreement bilaterally outside the organised market place. If the two parties bilaterally trade a contract which is admitted to trading at an organised market place, that contract shall be considered a standard contract, e.g. a spot or forward contract for the physical delivery of gas or electricity. However, when a shaped (profile) contract is traded outside the market place, that contract should not be considered a standard contract .

When a contract for the delivery of gas or electricity at a specific delivery point/area is not traded at an organised market place, but only bilaterally between the two parties, that contract should not be considered a standard contract even if a similar contract for the delivery of gas or electricity at a different delivery point/area is traded at an organised market place. For example, if a physical forward for the delivery of gas in country (A) in the month of July is traded on a broker platform, but a contract with the same characteristics for the delivery of gas in country (B) in the month of July is not traded on an organised market, the latter should not be considered a standard contract.

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 the contract is considered non-standard contract but has an agreed price and quantity, the contract has to be reported using Table 1 of the Implementing Acts. However, it is important to note that under the non-standard contract reporting requirement such a contract would be reportable no later than 30 days from its execution rather than within the time limit for standard contracts of no later than the following business day.

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) Non-Standard Contracts with defined price and quantity and 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 REMIT Implementing Regulation

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

This guidance aims to clarify the Agency’s understanding of the difference between a standard contract and a non-standard contract based on Article 2 of Commission Implementing Regulation (EU) No 1348/2014 which states:

(2) ‘standard contract’  means a contract concerning a wholesale energy product admitted to trading at an organised market place, irrespective of whether or not the transaction actually takes place on that market place;

(3) ‘non-standard contract’ means a contract concerning any wholesale energy product that is not a standard contract.

In the Agency’s view it is essential to further clarify the meaning of “admitted to trading” at an organised market place.
A contract admitted to trading at an organised market place is a contract that is visible to the market and available for trading to market participants.

Exchange traded contracts

For exchange traded contracts it is clear what “a contract admitted to trading” means. In this case a contract that is listed on the exchange is a tradable instrument and it can be registered at the exchange when two parties agree on the price off-screen.

Broker platform traded contracts

For a contract admitted to trading on brokers’ platforms it is worth to further clarify the meaning of “admitted to trading”.
Brokers, in the context of Article 2(4) of Commission Implementing Regulation (EU) No 1348/2014, advertise tradable contracts on their platforms. These contracts have certain specifications such as clip size (contract size), delivery point of the energy commodity, delivery start and end date, hours of the delivery and any other specification to identify the contract. These contracts, e.g. within day or day ahead contract as well as any forward contract, are tradable multiple times until their “expiration date and time” (last trading date and time) is reached.
Once a contract is admitted to trading on the Broker’s platform (visible on their screen) it can usually be traded several times either on the screen or voice brokered by both by both buyers and sellers until the date and time the contract is tradable. For example:

1. hourly electricity product: this can be traded for several days before the gate closure;

2. day-ahead gas or electricity product: this can be traded for several hours during the day before the delivery of the gas/electricity starts; and

3. a monthly/quarterly/seasonal forward product: this can be traded every day for several months before the delivery starts.

In the Agency’s view these contracts have to be considered standard contracts admitted to trading at an organised market place. As a consequence the organised market place where these wholesale energy products were executed or the order was placed shall, at the request of the market participant, offer a data reporting agreement in line with Article 6(1) of Commission Implementing Regulation (EU) No 1348/2014.

Voice-brokered contracts

In general, the above considerations apply the same way for broker platform traded contracts and voice-brokered contracts. In this context, the references in the TRUM to “including voice brokered” should be understood as referring to those situations where the contracts:

1) are admitted to trading at organised market places;

2) an order is visible on the screen; and

3) a voice brokered order matches the order on the screen. That trade is considered a voice brokered trade.

Specificities of voice-brokered shaped/profile contracts

When a shaped/profile contract is voice brokered without being advertised on the screen of the broker (e.g. a broker’s client asks the broker to find a counterparty to a shaped/profile contract), it would be traded only once and would then expire and not be tradable any more (as opposed to those contracts that are traded on the screen and that can be traded multiple times). In the Agency’s view such a contract, although traded through a broker, is not to be considered “admitted” (advertised on the broker’s screen) to trading at an organised market place and it should not be considered a standard contract. Therefore, and in line with Article 7(4) of Commission Implementing Regulation (EU) No 1348/2014 these contracts shall be reported no later than one month following their conclusion, modification or termination.
Since these contracts are voice brokered and executed at an organised market place, in the Agency’s view, the broker (in the context of Article 2(4) of the Commission Implementing Regulation)  shall at the request of the market participant offer a data reporting agreement in line with Article 6(1) of the Commission Implementing Regulation (EU) No 1348/2014.
Some organised market places may allow their clients to upload on the screen (and therefore be visible to the market) complex shaped/profile contracts for the trading on that organised market place and those contracts which are subject to bids or offers.
Although these contracts might not be traded several times (they may be, or may not be, removed once they are matched) they are still admitted to trading on the screen of the broker and therefore, in the Agency’s view, they have to be considered admitted to trading at an organised market place. When this is the case, no matter the contract’s complexity, as long as the contract is visible to the market it is considered admitted to trading at the organised market place and it should be considered a standard contract.
The Agency understands that the reporting of complex contracts on a T+1 day basis may bring up some difficulties for the organised market place and/or the reporting party; however, they should make their best effort to report complex shaped/profile contracts (considered standard contracts according to REMIT) as soon as possible.

Consequences of the criterion “admitted to trading” for the transaction reporting obligation

Transactions related to products admitted to trading at the organised market place are subject to the reporting obligations for standard contracts and reportable on a T+ 1 day basis, irrespective of whether they are traded on screen or voice brokered.
Transactions related to any other products that is not a standard contract are subject to the reporting obligations for non-standard contracts and reportable on a T+1 month basis.

 

6. Information to be reported

Market participants, other reporting entities or third parties reporting on their behalf, are obliged to ensure that the submitted transaction reports are complete and accurate.
The information to be reported shall include:

a) in relation to standard contracts for the supply of electricity or natural gas, the details set out in Table 1 of the Annex to the Implementing Acts;

b) in relation to non-standard contracts for the supply of electricity or natural gas, the details set out in Table 2 of the Annex to the Implementing Acts;

c) in relation to standard and non-standard contracts for the transportation of electricity, the details set out in Table 3 of the Annex to the Implementing Acts;

d) in relation to standard and non-standard contracts for the transportation of natural gas, the details set out in Table 4 of the Annex to the Implementing Acts.

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

Clarification of outright volume and price and reporting frequency for transactions executed within the framework of non-standard contracts

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

With regard to “specifying at least an outright volume and price”, the Agency understands that once the volume and the price of the transaction is known to the two parties (which can occur after the delivery of the commodity), the transaction is complete.

There is little difference between a physical spot/forward contract traded at an organised market place with a price settled against an index and an execution under non-standard contract framework which settles days after the delivery of the energy commodity ends. In fact, both of these two contracts may not have a fixed price or volume before the delivery of the energy commodity starts and, most likely, both of them will be completely settled after the delivery period ends.

However, while the physical spot/forward contract traded on an organised market place is reported with the contracted volume and the fixing index (which most likely is publicly available), the transaction executed under the framework of a non-standard contract has to be reported once the delivered quantity and the price are known, but still using Table 1 of the Annex to the Implementing Acts.

As far the Agency is aware, details of transactions executed within the framework of non-standard contracts specifying at least an outright volume and price are available to both parties to the contract by the invoicing date at the latest. On that basis, those executions under the framework of non-standard contract are reportable no later than 30 days after the invoicing date using Table 1 of the Annex of the Implementing Acts.

 

The data fields included in the Implementing Acts are listed in ANNEX I of this manual.

To achieve complete and accurate transaction reporting, market participants, other entities with reporting responsibilities and third parties reporting on their behalf must have appropriate systems and controls in place. For further information on this matter, please consult the Requirements for the registration of RRMs[1].

7. Back-loading requirement

According to Article 7(6) of the Implementing Acts, 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.

The reportable details shall only include data which can be extracted from market participants’ existing records. They shall at least comprise of data referred in Article 44(2) of Directive 2009/73/EC of the European Parliament and of the Council and in Article 40(2) of Directive 2009/72/EC of the European Parliament and of the Council[2] (record keeping obligations).

Additional clarification on the back loading requirement

Article 40(1) of Directive 2009/72/EC and Article 44(1) of Directive 2009/73/EC stipulate record keeping obligations of at least five years for the relevant data relating to all transactions in electricity and gas supply contracts and electricity and gas derivatives.

According to Article 40(2) of the Directive 2009/72/EC, “The data shall include details on the characteristics of the relevant transactions such as duration, delivery and settlement rules, the quantity, the dates and times of execution and the transaction prices and means of identifying the wholesale customer concerned, as well as specified details of all unsettled electricity supply contracts and electricity derivatives”.

According to Article 44(2) Directive 2009/73/EC “The data shall include details on the characteristics of the relevant transactions such as duration, delivery and settlement rules, the quantity, the dates and times of execution and the transaction prices and means of identifying the wholesale customer concerned, as well as specified details of all unsettled gas supply contracts and gas derivatives”.

Market participants should consider that the above Directives set the minimum requirement for the reporting of contracts which were concluded before the date on which the reporting obligation becomes applicable and remain outstanding on that date. Where other information which is required to be reported under REMIT can be extracted from market participants’ existing records, market participants shall also report that information.

In order for the Agency and the NRAs to know each market participant’s open positions at the time when the reporting obligation becomes applicable, market participants shall report contracts which were concluded before the date on which the reporting obligation becomes applicable and remain outstanding on that date. This information will enable the Agency and the NRAs to rationalise and understand subsequent trading activity. This contract shall be reported at transaction level and not at position level.

The Agency understands that only market participants know precisely their outstanding positions, e.g. delivery end date is after or equal to the date that the reporting obligation becomes effective. For example, where a trade on a contract that is bilaterally settled takes place, executed with or without the help of a broker, only the two counterparties to the contract have knowledge of subsequent lifecycle events; no visibility on outstanding positions is available to third parties, including the broker who facilitated that transaction.

Since there are multiple organised market places trading identical products, market participants can open a position and at a later date close it at different organised market or it could even be closed out by direct agreement of the two market participants outside of an organised market place.

Having this in mind, the reporting of details of contracts in wholesale energy products 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 by market participants unless the organised market places are willing to assist the market participants with the back loading reporting.

Market participants should bear in mind that the organised market places’ willingness to assist market participants with the back loading reporting is entirely at the discretion of the organised market places as there is no obligation under REMIT for them offering that service.

 

8. Identifying reference data to be collected from organised market places for the list of standard contracts and the list organised market places

According to Article 3(2) of the Implementing Acts, the Agency shall, in order to facilitate reporting, draw up and maintain a public list of standard contracts upon entry into force of the Implementing Acts and update that list in a timely manner.

In order to assist the Agency in complying with its obligations, organised market places shall submit identifying reference data to the Agency for each wholesale energy product they admit to trading. This information shall be submitted in a format defined by the Agency before trading commences in that particular contract. Organised market places shall submit updates of the information as changes occur. The list of standard contracts will cover both physical and financial contracts traded at organised market places.

The purpose of the list of organised market places is to publish the exchanges, brokers and other persons professionally arranging transactions which will fall under Article 6(1), especially the contracts traded at organised market places that are covered under the first phase transaction reporting, nine months following the entry into force of the Implementing Acts . The Agency will consult on the list prior to its publication. The list of organised market places will be published for the first time upon the entry into force of the Implementing Acts.

The purpose of the list of standard contracts is to specify the supply contract types for which Table 1 of the Annex to the Implementing Acts (the standard reporting form) is applicable. The creation of the list of standard contracts is not intended to assign unique identifiers to the contracts listed, nor will the information collected be used for matching against the transaction reports. The only purpose of the public list of standard contracts is to display the characteristics of each contract type for which the standard reporting form is applicable.

The Agency currently considers that the identifying reference data, to be submitted by organised market places, shall contain the following information[3]:

a) Contract name

b) Delivery zone

c) Energy commodity type

d) Contract type

e) Load type

f) Organised market place ID

g) Full name of the market place

h) Type of organised market place

The list of standard contracts will be published in due time before the start of the second phase of transaction reporting, covering contracts traded outside organised market places in order to fulfil the purpose to facilitate reporting and identification of contacts traded outside organised market places as standard or non-standard contracts.

9. Distinctions between product, contract and transaction for standard contracts

The Agency recognises that, given the terminology used in the REMIT and in the Implementing Acts, there is a need to clarify the following terms used in the TRUM:

a) Product

b) Contract

c) Transaction

d) Order report

e) Trade report

The product is the subject of the contract. A market participant enters into a transaction to close a deal (a contract), which is the right/obligation to receive/deliver the commodity (the product) in exchange of a payment.

a) Product

REMIT and the Implementing Acts use the term “wholesale energy product” when referring to contracts for the supply and transportation of gas and electricity within the European Union. In the TRUM, “product” refers to the energy commodity. A product is a physically deliverable item, and can be identified by a set of characteristics that represent the commodity profile:

(i) Commodity Type = Electricity

(ii) Delivery / Bidding Zone = France

(iii) Delivery Profile / Period = 1 Hour / 2 Hours / 1 Month / Quarter / Season / 2pm to 3pm, etc. or for example from 01/01/2015 to 31/01/2015 from 7:00am to 7:00pm

This could be represented as: [Commodity Type][EIC Code][Delivery Profile]. All products, regardless of how or where they are traded are physically identical, in that they are the same commodity delivered to the same zone with the same profile. A product is the subject of a wholesale energy contract.

b) Contract

A contract is a specific tradable instrument that allows a market participant to trade the product, i.e. the actual traded commodity, on a specific market place. Orders and trades can only occur against a contract. There can be multiple contracts against a single product. The contract has the following characteristics:

a) Product = as defined in the product definition above

b) Contract Type = Day-ahead / Forward

c) Market Identification = Legal Entity Identification (LEI) or Market Identification Code (MIC)

d) Market Contract Name = Electricity French Base load

This could be represented as: [Product][Contract Type][MIC][Contract Name]. The product is the subject of the contract. Whilst the contract is specific to one organised market place, the product can be traded at other organised market places, or bilaterally, as well. Additional information relating to a contract, which varies between venues, includes:

(i) Delivery capacity = 25 MW

(ii) Trading Times = 12pm (auction) or 09:00 to 17:00 (continuous market)

(iii) Traded Currency = EUR

Contracts traded at different organised market places are different from each other as different terms and conditions apply, even though they are related to the same energy commodity. For each individual contract, there is a specific order book.

c) Transaction

Transactions can only occur for a specific contract. Market participants submit orders (bids and offers) to the organised market place as an indication of their willingness to trade the contract for the delivery of the product. An order, either in an auction or on a continuous market, is always considered as a bid or offer for the purchase or sale of the contract for the delivery of the product.

The rules of the organised market place determine whether the market participant’s submission of orders results in a trade. In the case of a continuous market, an order placed by a market participant will result in a sequenced set of events that may produce a trade. In the case of an auction market, the organised market place will produce all trade results at the close of the auction period.

d) Order report

An order report is a representation of orders submitted by a market participant or by an execution venue on behalf of a market participant and represents the willingness to trade a contract with a determinable price and volume.

e) Trade report

A trade report is a representation of any contract where there is a match between two or more orders to trade within an organised market place or an agreement on a bilateral trade which takes place off-market.

The trade report always shows a single side of the transaction, representing the matched values for the market participant. When a trade occurs, the market participant must produce a report for each trade.

In the following subchapters, the Agency provides information on how the data fields listed in Table 1 of the Annex to the Implementing Acts should be populated when sending transaction reports to the Agency.

Orders to trade

The reporting of orders to trade is an important requirement that enables the Agency and the NRAs to detect possible cases of market manipulation. The Agency understands that, under the REMIT transaction reporting regime, all orders that are visible to market participants on organised markets shall be reported to the Agency.

The financial market legislations suggest that the notion of order for the purpose of Article 25 MiFIR includes quotations on trading venues. This is consistent with the approach taken in Article 17(2) MiFID. In particular ‘order’ includes quotations on RFQs (Request for Quotes) and voice broking systems operated by a trading venue where such quotations are advertised through the trading venue’s system.

Therefore, the Agency is of the understanding that the reference to orders includes quotations on trading venues such as Indication of Interest (IOI) advertised on the screens of the organised market places, while according to Article 7(3) of the REMIT Implementing Acts, orders placed in brokers’ voice operated services are not reportable, unless they appear on electronic screen or other devices used by the trading venue. These orders shall thus only be reported at request of the Agency.

With regard to orders to trade in auction markets, Article 7(2) of the REMIT Implementing Acts states that “In the case of auction markets where orders are not made publicly visible, only concluded contracts and final orders shall be reported. They shall be reported no later than on the working day following the auction.” This indicates that only orders that are admitted to the final auction have to be reported. For example, in the situation where an order is placed in an auction platform and then modified, the initial order is not a reportable order but the latter order is, if it is valid when the actual auction takes place.
Orders on spreads

Orders on spreads are orders that are placed by market participants on the screen of the organised market place with the intention to enter into a transaction made up of more than one contract (leg) at the same time. An example of such orders is those placed on the broker platforms to trade a dirty spark spread. Only orders on spreads that consist of wholesale energy products are reportable under REMIT.

As the REMIT reporting obligation encompasses both gas and electricity contracts, any spread trade which includes an underlying which is outside the scope of the REMIT reporting obligations (e.g. coal, oil, carbon emissions) falls outside the scope of orders on spreads reportable under the REMIT reporting regime. If a market participant places an order on a spread different than the dirty spark spread (electricity and gas), that order should not be reported to the Agency. In this case, only the individual transactions falling under the scope of REMIT will be reported to the Agency.

Furthermore, organised market places or trade matching systems may advertise spread trade opportunities for their clients on their screens. These types of advertised spreads such as    spark, dark, inter period, inter product, ratios, cleared vs. non-cleared spreads should not be considered orders to trade as these are not placed by their client, the market participant. Trades which results from such spread are not different from trades that are executed manually by the market participant and should be reported as two or more separate transactions.

 

10. Lifecycle events

According to Article 7(1) of the Implementing Act “Any modification or the termination of the concluded contract or order to trade shall be reported as soon as possible but no later than the working day following the modification or termination“. Table 1 and Table 2 of the Annex to the Implementing Acts requires market participants to report details for contracts, trades, orders to trade and their lifecycle events to the Agency.

The REMIT transaction reporting lifecycle events include:

a) the submission of a contract or an order to trade (trade or order report) for the first time which will be identified as ‘new’;

b) the modification of details of a previous trade or order report, which will be identified as ‘modify’;

c) the cancellation of a wrongly submitted trade or order report, which will be identified as ‘error’; and

d) the termination of an existing contract or order to trade, which will be identified as ‘cancel’.

Trading scenarios incorporating the above lifecycle events and how to report them are available in ANNEX II which should help market participants to understand lifecycle events under the REMIT transaction reporting regime.

Market participants should note that reporting of lifecycle events under REMIT may differ from lifecycle events reported under other EU legislations. In fact, the following are not expected to be reported under REMIT as they are not activities related to the execution or modification of a transaction entered into a wholesale energy market: confirmation, compression, settlement (pre-settlement, excluding early termination, and/or post-settlement activities), notional increase/decrease (relative to commodity index transactions including derivatives), clearing or option exercise.

There are two categories of lifecycle events reported under REMIT:

a) lifecycle event related to trades;

b) lifecycle event related to orders to trade.

a) Lifecycle event for trades (trade report)

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

The early termination of an existing contract should be identified as “cancel”. At any time during the term of a contract, the parties may agree to terminate the contract (i.e. they end the trade earlier than its natural maturity date). In situations where the two counterparties to the contract may decide, or be forced, for an early termination of a contract prior to their natural maturity, a  trade report shall be reported to indicate the agreed early termination date. This trade report shall be identified as “cancel”.

In the bilateral and broker trade environment, contracts may sometimes be amended after initial execution, e.g. counterparties may agree to increase the volume or to amend the price. If counterparties agree, through the broker, to increase the volume or to change the price of the contract, this must be reported by the broker. The same applies to any other organised market place. Lifecycle events that happen bilaterally between the counterparties without involving a broker, or an organised market, should be reported by the market participants through third parties.

If the contract was traded bilaterally outside the broker platform, market participants may report lifecycle events directly to the Agency if registered as reporting entity.

b) Lifecycle event for orders to trade (order report)

The submission to the Agency of an order at an organised market place for the first time will be identified as “new”. Any modification of this order report has to be notified to the Agency and reported as “modify”. Sometimes it may happen that a cancellation of a wrongly submitted order is needed. When this happens, a report with reference to the previous one will be submitted to the Agency and reported as “error” for its cancellation. A non-exhaustive list of examples for types of order modification can be found in ANNEX II of this document.


[1] For information concerning the Agency’s RRM Requirements, please see https://www.acer-remit.eu/portal/public-documentation.

[2] Directive 2009/72/EC of the European Parliament and of the Council of 13 July 2009 concerning common rules for the internal market in electricity and repealing Directive 2003/54/EC (OJ L 211, 14.8.2009, p. 55) and Directive 2009/73/EC of the European Parliament and of the Council of 13 July 2009 concerning common rules for the internal market in natural gas and repealing Directive 2003/55/EC.

[3] ANNEX II of this document provides a table outlining the identifying reference data to be submitted by organised market places.

RSS_Icon Last update: 09/05/2016  

RSS_Icon Subscribe to this Category’s RSS