ACER Registration Code within the REMIT Regulation compliance system means a numerical (alphanumeric, 12 values, example: 1234567890ab) wholesale energy market participant unique identifier assigned by the European Agency for the Cooperation of Energy Regulators (ACER) during the market participant registration process with the EU Member State National Energy Regulator (NRA).
ACER Registration Code is used for REMIT transactions and orders reporting purposes. It is also necessary in the process of the application for the EIC Code (The Energy Identification Coding Scheme (EIC) Reference Manual, ENTSO-E, 2016.02.15, p. 10).
REMIT Implementing Regulation No 1348/2014
When reporting information referred in Articles 6, 8 and 9 including inside information, the market participant shall identify itself or shall be identified by the third party reporting on its behalf using the ACER registration code which the market participant received or the unique market participant code which the market participant provided while registering in accordance with Article 9 of Regulation (EU) No 1227/2011.
Considering the variety of identifiers used (examples: Legal Entity Identifier (LEI), Bank Identifier Code (BIC), Energy Identification Code (EIC), Global Location Number (GLN/GS1)), it is important to note, only registration of market participant with the relevant NRA will result in an ACER code assignment.
The ACER's Trade Reporting User Manual (TRUM) mentions, from the Agency's perspective, the ACER code is the "preference", but all the other above codes may also be used.
Let's add - if these other codes were included in the registration information submitted by the market participant to CEREMP.
The specific - but as practice may prove - default scenario may occur in the situation where an organised market place (OMP) is reporting on behalf of the market participant.
In this case the ACER code may not be known (note that contracts concluded outside an organised market place represent the only instance where trade data are to be reported by market participants themselves).
If the ACER code has not been provided by the market participant to the organised market place reporting on behalf of the market participant, ACER indicates one of the alternative codes listed above should be used, otherwise the report will be rejected as invalid.
ACER's Frequently Asked Questions (FAQs) on REMIT transactions reporting
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".
As regards the LEI code, TRUM observes that if a market participant is already using the LEI for EMIR reporting that market participant could 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 NRAs in the registration process.
If a market participant is using an ACER Registration 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 ACER and available at the ACER's website.
It is also useful to note, the ID of the other market participant or counterparty to the transaction needs to be reported only when reporting bilateral trades, including those bilateral trades that take place on broker platforms.
If, in turn, the trade takes place on an energy exchange and the other counterparty is a CCP, clearing house or a clearing member, the relevant field of the reporting form be left blank.
ACER's Questions & Answers on REMIT explain how market participants that play several roles (e.g. a TSO that has also a capacity trading platform) should be identified and whether it is allowed that one organisation has several ACER codes.
The ACER clarification is the ACER code does not distinguish by roles, but aims at uniquely identifying market participants.
A market participant with several roles will therefore still be identified by one unique ACER code.
It is interesting that the ACER envisions situations where reporting for bilateral trades is made with the use of a fictitious ACER Code.
This relates to trades concluded with non-REMIT market participants, REMIT market participant not registered with any NRA yet or a non-EU market players.
Such a designation takes the form of "ACERNONMP.EU" (see box).
If, however, a market participant designated with the trade report with "ACERNONMP.EU" subsequently registers with the competent NRA and informs the counterparty of its ACER code (or any other reportable code) there is a requirement to send a modification report to update the code in previous reports.
ACER Code is populated in field 121 of the REMIT Registration Format.
It is noteworthy, in the Functioning and Usefulness of the European Register of Market Participants, ACER's Public Consultation Paper PC_2016_R_01, 18 March 2016 the need to ensure the traceability of relevant changes in the registration records has been raised.
Consequently, it has been proposed to supplement, in addition to field 121 (ACER code'), two new fields to the REMIT Registration Format:
- one indicating previously used ACER codes; and
- another identifying the relationship with the previous codes.
The identification of the relationship between ACER codes could be provided by selecting the following types:
- same person previously registered in another Member State;
- incorporation of a registered market participant;
- spin-off from a registered market participant;
Indeed, the implementation of the above improvement could have a merit for the proper identification of wholesale energy market participants.
Frequently Asked Questions (FAQs) on REMIT transaction reporting
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.
Another important aspect in the aforementioned ACER Report of 18 March 2016 forms the issue that some counterparties and organised market places (OMPs) voluntarily require market participants to be registered in the European register of market participants before they can trade with them/in their platforms.
The Report rises to the forefront the introduction of this as a legal requirement to benefit the integrity and transparency of the wholesale energy markets and opens the discussion on the pros and cons of introducing this potential new legal obligation.
ACER's Frequently Asked Questions (FAQs) on REMIT transaction reporting
Related documents: FAQs, Q 1.1.17: Two companies are subject to REMIT transaction reporting and both registered parties with ACER. Both companies are currently reporting their trades under their separate ACER Code.
On July 1 these companies will merge to one company and will use one ACER Code in the future.
We will therefore rename the new joint company and use the ACER code of one of the previous companies and delete the code of the other.
Do we need to cancel trades already reported as one of the former companies and resend them as new submissions under the merged company and new name with new UTI?
We would like to get guidance on how to proceed for our REMIT reporting!
Example: Company number 1 as a MP is currently reporting trades under REMIT under its own ACER code. On July 1 Company number 1 will be novated and become a new company which will have the ACER Code of Company number 2. What are the implications for trades reported under Company number 1?
Our current interpretation is to cancel all trades reported under Company number 1 and resend them under the name of the new joint company.
Is this correct and will the counterparty be obliged to do the same?
As presented in Q 1.1.17 of the FAQs on Transaction Reporting, in order to report a novation, an early termination with the old UTI and a new trade with a new UTI should be reported. Both Companies number 1 and 2 will have to submit an early termination report with Action Type “C” for Cancel the old trade and a new submission with Action Type “N” for the new trades of the Company number 1.
We started to report form April the 7th, 2016 and we reported all our standing contracts in backload and added, as it happened, execution of them. All the transactions were accepted.
Now one of our supplier, a company, from outside the EU, asked us to report for it as well. And here is where we have a problem. When we reported our contracts (3) in backload with this supplier he didn’t have an ACER code then and we reported that contract, and later execution, using the ACERNONMP.EU code. Now our supplier informs us that he has his ACER code now and asks us to report for him as well. All contracts were reported and accepted as well as all execution.
We have reported again those contracts and transactions with correct ACER code, and we would like to delete the ones with the ACERNONMP.EU code. My question is how we should do that: report it as error or report denouement?
As specified in the FAQ 2.6.2. a modification report with the updated ACER code should have been reported. It is necessary to modify the original report with the updated ACER code.
Reference to documents:
- REMIT-EU 1227/2011, Article 9, paragraph 1
- Guidance on the application of REMIT, 3rd Edition, Updated 3-June-2015, Section 3.5
- FAQs on REMIT transaction reporting, item II.2.6
- ARIS Data Validation v2.1 , section 6.3.2.
- ARIS Data Validation Rules configuration V3.1 (Rule AT2F15R1 has been disabled on both Testing Framework and Production)
How field (4) of Table 2 “ID of the other market participant or counterparty” in a bilateral transaction should be populated when the other counterparty (non-EU member) does not have an ACER code but is a REMIT participant.
Example: In a reportable Bilateral Contract the “other Market Participant” (counterparty) is a non-EU member but refuses to register for obtaining an ACER code.
Given that according to:
1. FAQs on REMIT transaction reporting, item II.2.6, the fictitious ACER code ACERNONMP.EU is used for cases that the counterparty is a non-REMIT market participant
2. ARIS Data Validation Rules configuration V3.1, the Rule AT2F15R1 has been disabled on both Testing Framework and Production
There are 2 possible solutions:
1. To populate field 4 with any of the codes (EIC/BIC/ LEI/GLN/GS1) if available OR
2. To populate field 4 with a fictitious code similar to the abovementioned but to clearly indicate that is a non EU non-registered REMIT participant, e.g. ACERNONEU.MP (this approach covers the (rare) case the said participant does not have any of the EIC/BIC/ LEI/GLN/GS1 codes).
Field (4) of Table 2 “ID of the other market participant or counterparty” in a bilateral transaction should be populated with one of the allowed codes if the other counterparty to the contract is a REMIT registered market participant otherwise ACERNONMP.EU to indicate the counterparty to the contract is not a registered market participant.
Frequently Asked Questions (FAQs) on REMIT transaction reporting