Please insert at least 3 characters

TRUM – Section 4.1

Data fields related to the parties to the contract

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

4.      ID of the other market participant or counterparty

5.      Type of code used in field 4

6.      Reporting entity ID

7.      Type of code used in field 6

8.      Beneficiary ID

9.      Type of code used in field 8

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

11.    Buy/sell indicator

12.    Initiator/Aggressor

 

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

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

 

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

 

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

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

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

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

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

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

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

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

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

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

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

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

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

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

 

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

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

 

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

 

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

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

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

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

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

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

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

 

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

 

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

 

Data Field No (6) Reporting entity ID

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

 

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

 

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

 

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

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

 

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

 

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

 

Data Field No (8) Beneficiary ID

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

 

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

 

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

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

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

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

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

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

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

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

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

 

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

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

 

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

 

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

 

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

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

 

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

 

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

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

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

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

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

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

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

 

Data Field No (11) Buy/sell indicator

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

 

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

 

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

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

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

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

 

Data Field No (12) Initiator/Aggressor

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

 

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

 

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

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

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

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

A buys from C:

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

C buys from B:

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

This field does not apply to orders to trade.

 

Last update: 09/05/2016   RSS_Icon Subscribe to this Page’s RSS