5.1 Data fields related to the parties to the contract

This section includes the following fields:

_{M = mandatory; O = optional; - = does not apply; * = conditionally required}

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

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

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

Registration of market participants with the relevant NRA will result in an ACER code. However, if a third party is reporting on behalf of the market participant the ACER code may not be known. If the ACER code has not been provided by the market participant to the third 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.

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

From the Agency’s perspective, the ACER code is the preference 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 as long as the LEI has been provided to the NRAs in the registration process.

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

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

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”. If an ACER code is used in Data Field (1) (e.g. C0643278W.EU), the accepted value is “ACE”. The same principle applies to BIC, EIC and GLN/GS1 codes.

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

This field indicates the ID of the other market participant or counterparty to the transaction that is reported.

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

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

Data Field (5) Reporting entity ID

This field indicates the ID of the reporting entity who submits the transaction 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), which can be an energy exchange, a broker, a third party reporting on behalf of a market participant or the market participant itself in case of a bilateral trade. If the reporting party is a market participant, then the ACER code or one of the unique codes that were registered with the NRA should be used. 

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

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

Data Field (7) Beneficiary ID

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

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

Bilateral transactions with a beneficiary may look like as (A) sells to (B) with beneficiary (C). In these cases the Agency will receive one reported trade: (A) sells to (B) with (C) identified in Data Field (8) as Beneficiary.

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

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

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

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

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

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

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

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

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

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

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

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

Data Field (10) Buy/sell indicator

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 to display whether the transaction was a buy or a sell from the perspective of the reporting market participant or, in the case of an agent (e.g. executing broker) transaction, from the perspective of the client.

For derivatives that have not already been reported under EMIR, and therefore reported under REMIT, the following buyer and seller logic should apply: for example, in case of a fix to floating derivative, if party (A) buys a swap, then party (A) pays a fixed price and party (B) pays a floating price. This means that party (A) receives the floating leg and party (B) receives the fix leg. In case of a floating to floating derivative, if party (A) buys a swap, party (A) pays the floating price of the first leg (or index) and party (B) pays the floating price of the second leg (or second index). In this case the two legs (indexes) of the swap should be sorted alphabetically.

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