4.1 Data fields related to the parties to the contract

4.1 Data fields related to the parties to the contract

This section includes the following fields: 

Field No. Field name Traded on OMP - Orders Traded on OMP - Trades Traded outside OMP - BILCONTRACT Traded outside OMP - EXECUTIONS
1 ID of the market participant or counterparty M M M M
2 Type of code used in field 1 M M M M
3 ID of the trader and/or of the market participant or counterpart or counterparty as identified by the organised market place M M M -
4 ID of the other market participant or counterparty - M* M M
5 Type of code used in field 4 - - M M
6 Reporting entity ID M M M M
7 Type of code used in field 6 M M M M
8 Beneficiary ID M* M* M* -
9 Type of code used in field 8 M* M* M* -
10 Trading capacity of the market participant or counterparty in field 1 M M M M
11 Buy/sell indicator M M M M
12 Initiator/Aggressor - M* M* -
M = mandatory; O = optional; - = does not apply; * = conditionally required; DV = default value specified in TRUM

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

No. Field Identifier Description
1 ID of the market participant or counterparty The market participant or counterparty on whose behalf the record of transaction is reported shall be identified by a unique code.
Description of Accepted Values Type Length Examples
  • ACER code 
  • LEI
  • BIC
  • EIC
  • GLN/GS1 code
Alphanumerical
  • 12
  • 20
  • 11
  • 16
  • 13
  • A0643278W.EU
  • 1a2b3c4d5e6f7g8e9f0h 
  • ACERSILJ500 
  • 21X000EUROPEU--8
  • a1b2c3d4e5f6g

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

As REMIT uses the term market participant and EMIR uses the term counterparty to identify the reporting party, both terms are used in this context for the purpose of reporting. The other market participant is referred to as the "other counterparty" (see Data Field (4)). Counterparty and the other counterparty is therefore considered equivalent of market participant and the other market participant for the purpose of reporting under REMIT.

The market participant shall be identified by the unique code registered with their NRA. If the market participant has several codes among those listed as accepted values for the population of Data Field (1), then all those codes have to be provided when registering with the NRA (i.e. should be recorded in their registration in CEREMP).

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

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

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

Guidance on reporting the ID of market participants, including its lifecycle

Data Field (1) ID of the market participant or counterparty, requires that the ID of the market participant or counterparty on whose behalf the record of transactions, including orders to trade, are reported shall be identified by a unique code. In the Agency’s view, this means that market participants that place orders have to be identified in the transaction report as responsible for the trading activity. This does not necessarily imply that they are the final beneficiary to the transaction, but that they are responsible for the reporting of the order or the trade. For example, when market participants place orders to trade on broker platforms on behalf of more than one legal entity, the organised market place should be informed by their clients on which market participant is placing the order for the reporting purpose and has to be reported in Data Field (1) and if there is a different beneficiary of the transaction to be reported in Data Field (8). For the population of Data Field (8) please refer to the guidance provided in the description of the relevant data field.

Reporting parties should be aware that it is not possible to modify (i.e. reporting lifecycle event with Action type ‘M’) the reported value in Data Field (1), as this is a key component for the identification of the uniqueness of the submitted report. For further information on how to report lifecycle event on Data Field (1), please refer to Annex VII to the TRUM.

If a market participant which is a financial entity chooses to use a BIC code for Data Field (1), it could be the case that the code is less than 11 characters long. In such a case, typically when an 8-digit code is given, the code has to be reported adding “XXX” at the end up to the 11-digit length.

Clarification on direct market access

Article 2 of REMIT identifies as market participants any person who enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets. Hence there is no distinction between entering into transactions in one or more wholesale energy markets directly or via a third entity.

ACER is aware that market participants might decide to conclude transactions on organised market places via a third party account by virtue of a Direct Market Access (DMA) agreement. In such a case, the member of the OMP (DMA provider) allows a client (DMA client) to enter into transactions on or through the OMP on its own account and under its contractual arrangements.

When dealing with DMA, it is ACER’s opinion that both the DMA provider and the DMA client fall under the definition of market participants under REMIT.

When the account of the DMA provider is used for the order lifecycle and for executing trades, then the DMA provider (not the DMA client), despite acting solely on behalf of third entities, is responsible for all trading activity and compliance with REMIT, and shall be reported in Data Field (1). DMA clients shall instead be identified using Data Field (8) Beneficiary ID.

Further guidance on how to report DMA provider and DMA client is provided in the FAQs on transaction reporting.

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

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

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

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

No. Field Identifier Description
3 ID of the trader and / or of the market participant or counterparty as identified by the organised market place The login username or trading account of the trader and / or the market participant or counterparty as specified by the technical system of the organised market place.
Description of Accepted Values Type Length Examples
Up to 100 alphanumerical digits. Alphanumeric 100 1234567890abcdefghi

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

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

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

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

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

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

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

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

With regard to orders to trade placed by executing brokers at the organised market place (for the definition, please consult chapter 3.1.5 Definition of standard and non-standard contract, the trading ID of the executing broker’s client shall also be reported in this field if available to the organised market place. Alternatively, if the order or trade report is reported through a third party on behalf of the executing broker, this information should be made available to the reporting party by the executing broker along with the Beneficiary ID (Data Field (8)) and reported to the Agency.

TraderIdForOrganisedMarket and traderIdForMarketParticipant

Data Field (3) is represented by two fields in the electronic format: <traderIdForOrganisedMarket> 
and <traderIdForMarketParticipant>
. Whenever the transaction is executed or order placed at an OMP and the ACER XML file is generated by the OMP, the original data provided by the OMP should be reported, even if the market participant chooses to report via a third-party RRM. Since the market participant should report the trade/order report with the same information of the organised market place, in the electronic format the <traderIdForOrganisedMarket> 
(Data Field (3a)) should be reported, instead of <traderIdForMarketParticipant> 
(Data Field (3b)).

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

No. Field Identifier Description
4 ID of the other market participant or counterparty Unique identifier for the other counterparty of the contract.
Description of Accepted Values Type Length Examples
  • ACER code
  • LEI
  • BIC
  • EIC
  • GLN/GS1 code
Alphanumeric
  • 12
  • 20
  • 11
  • 16
  • 13
  • C0643278W.EU
  • 1a2b3c4d5e6f7g8e9f0h
  • ACERSILJ500
  • 10YCB-EUROPEU--8
  • a1b2c3d4e5f6g

This field indicates the ID of the other market participant or counterparty to the transaction that is reported. This field does not apply to orders to trade.

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

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

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

Populating the ID of the other market participant or counterparty in the order report for exchange traded contracts when orders are placed on a broker’s platform

Exchange traded contracts are typically traded anonymously, so that neither party to the trade knows who the other party is. If the trade takes place on an exchange with orders to trade placed on the broker OMP, this trade should be reported as any other trade that takes place on exchange, i.e. field 4 shall be left blank.

Trade with a market participant without an ACER code

When a REMIT market participant enters into a bilateral trade (e.g. a financial swap related to gas delivered in the EU) with a non-REMIT market participant (e.g. a firm that only trades OTC bilateral financial products related to the EU gas or electricity and never enters into a physical trade) or with a REMIT market participant without an ACER code (e.g. market participant is under registration), the REMIT market participant may need to populate Data Field (4) with a code to indicate that the counterparty to the trade does not have an ACER code. If this is the case, the REMIT market participant reporting bilateral trades should report the fictitious ACER code: ACERNONMP.EU in Data Field (4).

There could be a case where market participant MP1 reports a trade with MP2 which is identified by ACERNONMP.EU in MP1’s report and then a month later MP2 registers with the competent National Regulatory Authority (NRA), and receives an ACER code.

Because the previously reported trades by MP1 still identify MP2 with the generic ACER code (ACERNONMP.EU), MP1 should novate the trade as soon as the newly received ACER code of MP2 was communicated to MP1 by MP2. For further information on novation please refer to Annex VII to the TRUM.

MP2 will only be able to report trades identifying itself in Data Field (1) ID of the market participant or counterparty once it has been registered with the relevant NRA. At that point MP2 will be able to report all its transactions (past and future transactions) identifying itself in Data Field (1).

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

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

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

Data Field (6) Reporting entity ID

No. Field Identifier Description
6 Reporting entity ID ID of the reporting entity.
Description of Accepted Values Type Length Examples
  • ACER code
  • LEI
  • BIC
  • EIC
  • GLN/GS1 code
Text
  • 12
  • 20
  • 11
  • 16
  • 13
  • C0643278W.EU
  • 1a2b3c4d5e6f7g8e9f0h
  • ACERSILJ500
  • 10YCB-EUROPEU--8
  • a1b2c3d4e5f6g

This field indicates the ID of the reporting entity that submits the report to the Agency on behalf of the market participant as identified in Data Field (1). This entity is also known as a Registered Reporting Mechanism (RRM).

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

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

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

Data Field (8) Beneficiary ID

No. Field Identifier Description
8 Beneficiary ID If the beneficiary of the contract as referred in Article 8(1) of Regulation (EU) No 1227/2011 is counterparty to this contract the field is to be left blank. If the beneficiary of the contract is not counterparty to this contract the reporting counterparty has to identify the beneficiary by a unique code.
Description of Accepted Values Type Length Examples
  • ACER code
  • LEI
  • BIC
  • EIC
  • GLN/GS1 code
Alphanumeric
  • 12
  • 20
  • 11
  • 16
  • 13
  • C0643278W.EU
  • 1a2b3c4d5e6f7g8e9f0h
  • ACERSILJ500
  • 10YCB-EUROPEU--8
  • a1b2c3d4e5f6g

This field indicates the ID of the beneficiary of the transaction, i.e. the identification of the entity on whose behalf the trading activity was carried out. Data Field (8) has to be considered in case the trading activity is carried out by a third party on behalf of another market participant.

If the market participant reported in Data Field (1) coincides with the beneficiary of the transaction, then Data Field (8) field shall be left blank.

If the party reported in Data Field (1) is not the beneficiary of the transaction, the reporting market participant should identify the beneficiary in Data field (8) by a unique code registered in the European registry of market participants (CEREMP).

For example, if market participant A is trading on behalf of party B, then party B is the beneficiary and market participant A is acting on behalf of B as an Agent, as defined in Data Field (10). As market participant A enters into transactions on a wholesale energy market, party A is considered a market participant and has to be reported in Data Field (1).

If party A always acts as an Agent and does not enter into transaction in any EU wholesale energy markets on its own behalf, it is not considered a market participant according to REMIT. In such a case, the identification code of party B should be reported in Data Field (1) and Data Field (8) shall be left blank. In this case party A should not appear in the report as market participant, unless the agreement between party A and party B foresees that the responsibility of the trading activity and the execution of the potential trades still lies with party A.

If the beneficiary ID is provided by the market participant to the organised market places or to one of the two counterparties to the contract in the case of bilateral contracts, the beneficiary ID must be reported. This can also be reported as a lifecycle event after the trade takes place, according to the guidance provided in Annex VII to TRUM.

If the information on the beneficiary of the transaction is not available to the organised market place, this field shall be left blank. For example, the organised market place may only know the market participant (or the executing broker in case of exchange) that executed the transaction. Also when the trade is submitted for clearing, this information may be lost because the clearing house only executes transactions against its clearing members, and the market participant may (in the case of self‐clearing members) or may not be the ultimate beneficiary. It is expected that in such cases the organised market place where the trading activity occurs is informed by the market participants whenever they trade on behalf of a third party. In such a case, while Data Field (8) shall be left blank, Data Field (10) Trading capacity shall be populated with ‘A’ (Agent).

Some of the reported trades executed at organised market places will look like: A sells to B, where B is acting on behalf of C (beneficiary of the trade). The Agency shall in these cases receive two reported trades: A sells to B, B sells to C. However, the series of trades may be even more complex and it may involve more parties. For example, if a bilateral trade takes place off-market between A and B, there may be other trades between B and other parties (e.g. C and D) to represent how they split the value of the A and B trade.

Bilateral contracts concluded off organised market place may be of the form A sells to B with beneficiary C. In these cases, the Agency shall receive one reported trade: A sells to B with C identified in Data Field (8) as Beneficiary.

With regard to orders placed and trades concluded by executing brokers at the organised market place, the Beneficiary ID of the executing broker’s client shall also be reported in Data Field (8). The executing broker’s clients should make IDs required for reporting available to the organised market place or the third party RRM.

For lifecycle events related to Beneficiary ID in Data Field (8), please refer to Annex VII to the TRUM on reporting lifecycle events.

There may be situations where the beneficiary is not known. Market participants and reporting parties should contact the Agency to discuss any of their scenarios that are not represented in this manual.

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

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

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

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

No. Field Identifier Description
10 Trading capacity of the market participant or counterparty in field 1 Identifies whether the reporting counterparty has concluded the contract as principal on own account (on own behalf or behalf of a client) or as agent for the account of and on behalf of a client.
Description of Accepted Values Type Length Examples
  • P=Principal
  • A=Agent
Text 1 P

This field identifies the trading capacity of the market participant or counterparty in Data Field (1).

If the market participant is acting on its own behalf, this field shall be populated with “P” for Principal.

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

Nevertheless, if the market participant is acting on behalf of a third party as an agent and the OMP is aware that a transaction is concluded on behalf of a third party, Data Field (10) Trading capacity is expected to be populated with the value ‘A’ as ‘Agent’, irrespectively of whether the identification of the final beneficiary is known at the due time of the REMIT reporting.

The Agency understands that the terms Principal and Agent are commonly used in the financial markets and it depends upon whether an investment firm enters into a transaction as principal or agent.

Data Field (11) Buy/sell indicator

No. Field Identifier Description
11 Buy/sell indicator Identifies whether the contract was a buy or sell for the market participant or counterparty identified in field 1.
Description of Accepted Values Type Length Examples
  • B=Buy
  • S=Sell
  • C=Buy and Sell
Text 1 B

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

Since REMIT Implementing Regulation requires two-side reporting, each trade report should indicate the side of the trade for the reporting market participant as a buyer or a seller.

For orders, this should indicate whether the market participant indicated the intention to buy or sell the contract.

However, in some auction markets, there may be circumstances where an order is buy and sell. In such cases, this is identified by specifying a combined buy and sell indicator, i.e. “C”.

For derivatives that have not already been reported under EMIR, and therefore reported under REMIT, the following buyer and seller logic should apply:

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

Data Field (12) Initiator/Aggressor

No. Field Identifier Description
12 Initiator/Aggressor When the trade is executed on an electronic or voice assisted broker platform, the initiator is the party who first placed the firm order in the market and the aggressor is the party that initiates the transaction.
Description of Accepted Values Type Length Examples
  • I=Initiator
  • A=Aggressor
  • S=Sleeve
Text 1 A

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

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

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

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

A buys from C:

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

C buys from B:

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

This field does not apply to orders to trade.  

Guidance on linking transactions when trading in sleeve

When market participants enter into a sleeve trade, the resulting legs of the trade should be linked. By following the example of a sleeve trade provided above, the reporting should be done in the following way:

When A buys from C:

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

Market participants A and C shall report UTI 123 in Data Field (31) Unique Transaction ID.

When C buys from B:

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

Market participants B and C shall report UTI 456 in Data Field (31) Unique Transaction ID.

C in its sell sleeve report (reported with UTI 123) shall populate Data Field (32) Linked Transaction ID with UTI 456, and by following the same logic it shall populate the field for linked transaction ID with UTI 123 in its buy sleeve trade report.

For further examples on reporting sleeve trade, please consult Annex II to the TRUM.

Guidance on how to report the order of the Aggressor and Initiator for Click&Trade

In case of Click&Trade, the Agency shall receive two trade reports (buy and sell side) and only one order report. This relies on the fact that the order of the aggressor is not visible to other market participants and thus does not need to be reported to ACER.

The initiator shall report an order and a trade populating the Data Field (12) with “I”, while the aggressor, who aggresses the initiator’s order shall report the trade by populating the tag ‘clickAndTradeDetails’ in the electronic format with the information on the order of the initiator.

The Agency is aware that some trading systems automatically create the order for the Aggressor when a Click&Trade takes place. In this case, when reporting Click&Trade transactions, the reporting party can decide to report also the Aggressor’s order.

Updated: 
13/03/2024