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  

TRUM – Section 4.7

Data fields related to lifecycle information

This section includes the following fields:
58. Action type

 

Data Field No (58) Action type

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

 

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

 

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

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

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

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 6.6

Data fields related to interval for primary and secondary allocation processes

This section includes the following fields:

47. Position
48. Quantity
49. Price amount
50. Bid quantity
51. Bid price amount

 

Data Field No (47) Position

No. Field Identifier Description
47 Position The relative position of a period within an interval.

 

Description of Accepted Values Type Length Examples
The relative position must be expressed as a numeric integer value beginning with 1. All leading zeros must be suppressed. The maximum number of characters is 6.
1
2
3

999999
Integer Maximum 6 1

 

This information provides the relative position of a period within an interval.

This field is mandatory if available.

 

Data Field No (48) Quantity

No. Field Identifier Description
48 Quantity The quantity that has been allocated in the primary auction. The quantity that has been assigned to the nomination party for secondary rights.

 

Description of Accepted Values Type Length Examples
The maximum length of this information is 17 numeric characters (decimal mark included). The number of decimal places identifying the fractional part of the quantity depends on local market rules. Numeric Maximum 17 10.8

 

This information defines the quantity that has been assigned to the nomination party for the interval in question and that is expressed in the Measurement Unit. A decimal point value may be used to express values that are inferior to the defined unit of measurement. The decimal mark that separates the digits forming the integral part of a number from those forming the fractional part. (ISO 6093) shall always be a period (“.”). All quantities are non-signed values.

 

Data Field No (49) Price amount

No. Field Identifier Description
49 Price amount (if applicable) The price expressed for each unit of quantity allocated through the primary allocation. The price expressed for each unit of quantity resold or transferred on the secondary market if applicable.

 

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

ISO 6093

17 1.8

 

This field indicates the price expressed for each unit. The price indicated in a resale document equal to or above which the quantity may be sold.

This information defines the price expressed in the unit of measurement of Price per unit of quantity in compliance with the pricing scheme based on local market rules. The decimal mark that separates the digits forming the integral part of a number from those forming the fractional part (ISO 6093) shall always be a period (“.”).

This field is mandatory if available.

 

Data Field No (50) Bid quantity

No. Field Identifier Description
50 Bid quantity (if applicable) The quantity that was in the original bid document.

 

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

ISO 6093

17 1.8

 

This information defines the quantity that was requested for the interval in question and that is expressed in the Measurement Unit Quantity. A decimal point value may be used to express values that are inferior to the defined unit of measurement. The decimal mark that separates the digits forming the integral part of a number from those forming the fractional part. (ISO 6093) shall always be a period (“.”).All quantities are non-signed values. The number of decimal places identifying the fractional part of the quantity depends on local market rules.

This field is mandatory if available.

 

Data Field No (51) Bid price amount

No. Field Identifier Description
51 Bid Price Amount (if applicable) The original price expressed in the original bid for each unit of quantity requested.

 

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

ISO 6093

17 1.8

 

This information reproduces the price expressed in the unit of measurement of Price per unit of quantity requested in the original bid. The decimal mark that separates the digits forming the integral part of a number from those forming the fractional part (ISO 6093) shall always be a period (“.”).

This field is mandatory if available.

RSS_Icon Last update: 09/05/2016  

TRUM – Section 4.8

Examples of transaction reporting

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

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

RSS_Icon Last update: 09/05/2016  

TRUM – Section 6.7

Data fields related to reason for primary allocation and secondary processes

This section includes the following fields:

52. Reason code
53. Reason text

 

Data Field No (52) Reason code

No. Field Identifier Description
52 Reason code (if applicable) A code providing the status of the allocation or the rights.

 

Description of Accepted Values Type Length Examples
Refer to ETSO Code list document for valid codes.
A75: Rights status information
A71: Linked bid rejected due to associated bid unsuccessful
A72: Original bid divided to permit acceptance
A73: Bid accepted
A74: Auction Status
Alphanumeric Maximum 3 A75

 

This field provides the reason code provides the status of the rights identified. As many reason elements as necessary may be used. This information is at the time series level to provide related explanatory information.

This field is mandatory if available.

 

Data Field No (53) Reason text

No. Field Identifier Description
53 Reason text (if applicable) Textual explanation of the reason code.

 

Description of Accepted Values Type Length Examples
If the code does not provide all the information to clearly identify the justification of the allocation then the textual information may be provided. Alphanumeric Maximum 512

 

Used only if the reason code is insufficient to identify an error.

This field is mandatory if available.

RSS_Icon Last update: 09/05/2016  

RSS_Icon Subscribe to this Category’s RSS