How should we populate field (4) “ID of the other market participant or counterparty” in a bilateral transaction when the other counterparty to the contract may not be a REMIT market participant, a REMIT market participant not registered with any NRA yet or a non-EU market player?
As indicated in Annex III to the TRUM, under “Wholesales Energy Markets: physical vs financial markets” section on page 1, there are circumstances where market players trading wholesale energy products may not be REMIT market participants.
When a market player is a REMIT market participant and enters into a bilateral transaction (e.g. a financial swap related to gas delivered in the EU) with a non-REMIT market participant (a firm that only trades OTC bilateral financial products related to the EU gas or electricity and never enters into a physical trade), the REMIT market participant may need to populate field (4) with a code to indicate that the counterparty to the trade is not a REMIT market participant. If this is the case market participants reporting bilateral trades concluded with non-REMIT market participants should report a fictitious ACER code as follows:
- ACERNONMP.EU – when the reporting party knows that the counterparty is a non-REMIT market participant
Please note that the above is only valid for field (4) “ID of the other market participant or counterparty”.
Last update: 16/02/2016
Frequently Asked Questions (FAQs) on REMIT transaction reporting – II.2.6 Questions related to bilateral trades Question 2.6.1
The question asks how to report where one of the market participants may be not a REMIT market participant. The answer recommends that a generic ACER Code ACERNONMP.EU is used so that the obligation to report can be fulfilled.
Market Participant A reports a transaction with Market Participant B who is not registered with any National Regulatory Authority (NRA) and does not have an ACER code and hence is identified using ACERNONMP.EU. A month later Market Participant B is registered with an NRA and get their ACER code and uses this for reporting all transaction post receipt of the ACER code. All previous transactions reported still identify Market Participant B with the generic ACER code ACERNONMP.EU.
Market participant (MP) (A) reports a transaction with MP (B) which is identified using ACERNONMP.EU in MP (A)’s report. A month later when MP (B) is registered with the competent NRA and informs MP (A) of its ACER code (or any other reportable code) will be able to report all its transaction post registration with the NRA.
Because previously reported transactions by MP (A) still identify MP (B) with the generic ACER code (ACERNONMP.EU), MP (A) should send a modification report to update the code of MP (B) in MP (A)’s reports.
MP (B) will only be able to report transactions identifying itself in Field 1 (ID of the market participant or counterparty) once it has been registered with the National Regulatory Authority (NRA). At that point MP (B) will be able to report all its transactions (past and future transactions) identifying itself in Field 1.
Last update: 24/03/2016
Reference to documents: ACER TRUM 2.0
4.3 Data fields related to contract details
28. Contract Trading Hours
29. Last trading date and time
How should the fields 28 and 29 be filled when a bilateral contract was entered during an tender at a specific time.
Example: We organise weekly tenders for grid losses (No OMP) with typical products (e.g. Base Year 2017) every week on the same weekday at a specific time (e.g.10:00-10:30).
The TRUM is not clear in this specific case. For bilateral trades that occur off-markets, 00:00Z to 24:00Z should be indicated by default and field 29 should not be populated. This trades where closed on a tender during an specific time. It is not possible for this products to send bids at a different time. In my interpretation I would fill in the time where the gate of the auction is open in field 28 and the gate closure time in field 29.
Data Field (28) “Contract Trading Hours” and data Field (29) “Last trading date and time” are required to be populated for transactions executed at Organised Market Places (OMPs). For any bilateral contract, including those that are the result of a tender, data Field (28) “Contract Trading Hours” should be populated with 00:00Z to 24:00Z by default; data Field (29) “Last trading date and time” should not be populated.
Last update: 26/04/2017