FAQs on transaction reporting – Question II.2.4.8

IAs:  Table 1, field #58.   TRUM:  We note that the TRUM v1.0 states the following on p.25:   “Lifecycle events that happen bilaterally between the counterparties with- out involving a broker, or an organised market, should be reported by the market participants through third parties.”

We kindly ask for the Agency’s opinion and clarification on the following, please:  Timeframe:

i) For OMP-traded deals: If MPs are to report subsequent bilateral lifecycle events of OMP-traded deals via third party RRMs (i.e. after the “new” execution has been reported by the relevant OMP), is the relevant start-date for the reporting of such purely bilateral lifecycle events Phase 1 or Phase 2?

ii) For OTC-traded deals: We expect the start-date for bi- lateral lifecycle events of OTC-traded deals to be in Phase 2.

Reporting Channel:

i) OMP: If OMPs would agree to offer the service of re- porting any bilateral non-OMP lifecycle events on be- half of the MPs, does ACER foresee that both MP counterparties would need to notify the broker/OMP of the bilateral lifecycle event?

ii) 3rd party RRM: If the OMP does not agree to report bi- lateral modifications, does this mean that MPs need to be prepared to report directly to a 3rd party RRM in Phase 1 (for instance, through the 3rd party RRM(s) that the MP envisions to use for OTC/bilateral trade reporting in Phase 2)?

Example:

A deal is concluded via two counterparties over a broker, and the broker submits a “new” transaction report in Phase 1. The two counterparties later agree to amend the deal bilaterally without the involvement or knowledge of the broker.

Our assumption is that such bilateral lifecycle modifications of OMP-traded deals need to be reported in Phase 1, even though no OMP is involved.


Answer:

If two counterparties enter into a trade concluded over a broker platform (Organised Market Place), the broker (subject to an agreement with the market participants) will submit a “new” transaction report on a T+1 basis in Phase 1.

If the two counterparties to the trade agree to amend the deal bilaterally without the involvement or knowledge of the broker, they are responsible for the reporting of such lifecycle events which have to be reported on a T+1 basis in Phase 1.

OTC transactions, are normally reportable on a T+30 basis in Phase 2. Please see the TRUM for additional clarifications.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.4.9

Clarification on reporting of transactions related to OTC clearing on standard contracts registered at the exchange. Should the exchange report these transactions even though the volume and price related to the registered cleared transaction could not be necessarily related to a unique transaction executed on broker platform?

1)  Market participant A executes on a broker platform a transaction with market participant B for a volume V1 and price P1 on day 15th of August.

2)  On 17 August market participant A execute another transaction on a broker platform with the same market participant B for a volume V2 and price P2.

3)  On 20 August Market participant A registers at exchange for clearing purpose a OTC transaction with market participant B for volume V=V1+V2 at price P (potentially different from P1 or P2).

We believe transactions registered at exchanges related to OTC clearing  should not be reported to ACER, as the clearing could be referred to cumulated volumes and a price chosen by market participants and hence do not provide useful elements for market monitoring. Furthermore, such reporting could lead to a double reporting of the same transactions from two different parties (i.e. broker platform and the exchange).


Answer:

From the above question, we understand that there are four separate transactions:

1) on 15 August volume V1 and price P1

2) on 17 August volume V2 and price P2

3) on 20 August the above transactions (V=V1+V2 at price P ) are terminated (this could also be split in two transactions)

4) and cleared at the exchange based on the new single transaction (V=V1+V2 at price P)

Please note that transaction (3) above, may be a termination or another transaction to offset transaction (1) and (2). There will not be any double counting.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.2.4.10

Lifecycle events reporting: For a reported trade, during the delivery period, the two parties agree to amend the price and the quantity. The two market participants report the trade modification and they have to report “Total Notional Contract Quantity” and “Notional Amount” in accordance with TRUM and “Open letter on REMIT transaction reporting data quality” (16 February 2017). Please let us know what is the proper way to calculate “Total Notional Contract Quantity” and “Notional Amount” in this case (trade modification).


Answer:

According to the Agency’s understanding, if for a reported trade, during the delivery period, the two parties agree to amend the price and the quantity, this is a new transaction. The early termination should be reported first and the new contract should be reported after. We do understand that market participants may treat this contract as the same contract. But we believe that while it is treated by the system as the same contract, this is in effect a new transaction executed at a different point in time, with different market information leading to different economics.

Example: MP1 and MP2 agree in September 2016 on a yearly supply (forward) contract for the delivery of 10MW at 30 EUR/MW. In the course of July 2017 (or any month during the delivery of such a contract) the two parties decide to change the price or quantity.  A termination “C” of the previous agreement should be reported, as well as a new transaction “N” with a new UTI with the new price and quantity (and delivery period left).

Please note that this applies to Table 1 only when both price and quantity were already agreed on. For Table 2 it is reasonable to believe that the terms and conditions of these contracts may be modifiable and such modifications can be reported with “M” Modify type lifecycle event.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.4.11

How to report in REMIT report case where OMP XXX will remove a trade (standard contract) where a buy order was wrongly submitted and market participant has contacted us and asked for the trade to be removed? Other market participant which was a seller has been contacted and accepts the removal of the trade. In this case, where XXX makes the trade removal from the system, should the actionType be Error (cancellation of wrongly submitted report) or Cancel (a termination of an existing contract or order to trade)?

Practical example:

Market participant C has made an error while adding buy bid, bid was meant to be 45 MWh, but it went into trading system as of 450 MWh. There was already sell bid on the platform (Market Participant A 500 MWh), so bids were matched and trades made. Market participant C contacts us and tells there was a mistake and asks if we can remove the trade from the system. We contacted Market Participant A and told what has happened, and asked if the trade can be removed from the trading system. Market Participant A accepts that. There was also Market Participant B, who made buy bid of 50 MWh which was matched with market participant A’s sell bid. Figures below.

Orders:

  • Market Participant A: Sell bid 500 MWh à Order status: ACT – PMA (with 50 MWh) – MAC
  • Market Participant B: Buy bid 50 MWh à Order status: ACT – MAC
  • Market Participant C: Buy bid 450 MWh à Order: ACT – MAC

Trades:
1st trade

  • Market Participant A: Sell 50 MWh
  • Market Participant B: Buy 50 MWh

2nd trade

  • Market Participant A: Sell 450 MWh
  • Market Participant C: Buy 450 MWh

Both trades in trade 2 (450 MWh sell and 450 MWh buy) will be removed from the trading system by XXX, but orders remain as they are (those cannot be changed). How should this trade removal/cancellation be reported in REMIT report, especially Market Participant A´s order?

REMIT report correction:

For these Transaction timestamp: The time when trade has been removed and Action type: C (Cancel)

  • ORDER Market Participant C: Buy bid 450 MWh à
  • TRADE Market Participant A: Sell 450 MWh
  • TRADE Market Participant C: Buy 450 MWh

For this, does it need something for the correction?

  • Market Participant A: Sell bid 500 MWh à Order status: ACT – PMA (with 50 MWh) – MAC

Answer:

In the Agency’s view, when a trade is cancelled because ‘an order has been wrongly submitted to the trading system by a market participant’, the trade should be cancelled by using Action type “C”.

As the order is visible to the market, it should not be removed from the system and should be reported as an MAC or PMA order, even if it was erroneously submitted by a market participant. Then the trade will be first reported as New (Action type “N”) and then reported as Cancelled (Action type “C”).

For Action type “E” Error, in the TRUM it is explained that ‘when the report contains a cancellation of a wrongly submitted report, it will be identified as ‘error’. This means that Action type “E” for Error should be used when a transaction has been incorrectly sent to ARIS and needs to be removed from the database. Then, a new transaction should be submitted by using a different UTI.

However, the above question describes a case where the error occurs in the system of an OMP (as a result of their client’s mistake) and not in the reporting to ARIS, for example preparation of the file, extraction of data from the system, bugs etc.

Example:  if an OMP reports a trade with the price of 50 EUR instead of 50 GBP, that trade was incorrectly sent. The same applies if the real price is 50 and the OMP reports 35 (or any other price). Therefore, you would report an ‘Error’ transaction and resubmit is with the right price. This is not the case for your question.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.5.1

Back-loaded trades.  What indicator/field should we use for back loaded trades for historic contracts executed on Exchange?
We require an indicator because the validation for the back-loaded trades may be more relaxed than for the regular trades as the MP may not be able to supply all the details currently required by ACER.  The TRUM shows the use of “BACKLOADING” in the Contract Name field for off-market trades, but what about Exchange Traded trades?

Do we use the text “BACKLOADING” in the Contract Name field for Exchange-Traded trades or will there be a new action to indicate Back loading?  If not, can we agree with other RRMs to use the Linked Order ID field with the text “BACKLOADING” to indicate a back-loaded trade?


Answer:

The validation rules for the back loaded trades will be more relaxed than for the other trades as the market participants may not be able to supply all the details required for standard contracts. The TRUM shows the use of “BACKLOADING” in the Contract Name field for off-market trades as an example.

The TRUM also indicates that any information from examples of trades executed on continuous markets or auction markets can be applied to bilateral contracts and vice versa (for example profiles used in one trading example can be used to report a different trading example). The same logic applies to exchange traded contracts.

Please see example (2.19) “BACKLOADING” trade in Annex II to the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.5.2

XXX Futures EU and XXX Spot seek further clarification from ACER in relation to the back loading requirements for Exchange Traded Derivatives.

On page 19 of the TRUM, ACER states that: “In order for the agency and the NRAs to know each market participant’s open positions at the time the reporting obligation becomes applicable, market participants shall report contracts which were concluded before the date on which the reporting obligation becomes applicable and remain outstanding in that date.”

Please could ACER clarify if and how the back loading requirement covers Exchange Traded Derivatives (“ETDs”)? Whilst the TRUM states that organised market places’ willingness to assist market participants with the back loading reporting is entirely at the discretion of the OMP, there is a potential reporting burden placed on Market Participants for which they may need the assistance of the OMP.

Example: When an ETD such as a futures contract is traded top day, the contract is concluded that day leaving an “End of Day” position at the exchange level. The positions in these ETD contracts do not remain outstanding and the positions are not technically “open” in that the transaction has been concluded. The futures position can however be subsequently traded out if the position holder decides; this would result in new trades.  Effectively, unless the position has not been assigned correctly, prior to the 07 October 2015, then there are technically no trades that have yet to be concluded to report.

The back loading requirement does not cover ETDs   (futures and options) given that they are no contracts which were concluded before the date on which the reporting obligation becomes applicable (07 October 2015) and remain outstanding on that date.


Answer:

In our view, outstanding contracts are those contracts that have an outstanding physical or financial flow as defined by the contract and not by the settlement of the invoice date. For futures we would expect to see the positions that are technically still “open” and that can be still trade out (or closed) or to be settled. Please see also “Additional clarification on the back loading requirement” available in the TRUM.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.5.3

With respect to the reporting of transactions on wholesale energy contracts that were concluded prior to the date on which the reporting obligation becomes applicable and remains outstanding on that date (back-loading), it is unclear whether this includes or excludes trades that have expired on that date, but remain unsettled.
Please confirm whether wholesale energy transactions to be back-loaded include trades that haven’t settled, although expired on or before the date on which the reporting obligation becomes applicable.

Trade expires on 07/10/2015, but settles a day or two later – In scope for back-loading?

  • Trades expires prior to 07/10/2015, but settles on 07/10/2015 – Out of scope for back-loading
  • Trade expires and settles prior to 07/10/2015 – Out of scope for back-loading
  • Anything that hasn’t settled on the date the reporting obligation becomes applicable has not “concluded” and therefore is in-scope for back-loading of data to the ACER?

Answer:

The Agency considers outstanding contracts those contracts that have an outstanding physical or financial flow as defined by the contract and not by the settlement of the invoice date. For futures the Agency would expect to see the positions that are technically still “open” and that can be still traded out (or closed) or settled. Please see also “Additional clarification on the back loading requirement” available in the TRUM.

With regard to the above question:

  • Trade expires on 07/10/2015, but settles a day or two later is in scope for back loading
  • Trade expires prior to 07/10/2015, but settles on 07/10/2015, is in scope for back loading
  • Trade expires and settles prior to 07/10/2015, is out of scope for back loading

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.5.4

Articles 40(1), 40(2) and 44(2) make clear the backloading requirements that Market Participants should consider the minimum requirement for the reporting of contracts which were concluded before the date on which the reporting obligation becomes applicable and remain outstanding on that date i.e. 7th April 2016.

Where other information which is required to be reported under REMIT can be extracted from market participants’ existing records, market participants shall also report that information.

But could ACER please provide some clarity as to whether trades would need to be backload reported if trades have a delivery and settlement date prior to the 7th April 2016 but where there may be some scenarios whereby there will be some cash flows/payments that will not be able to be made until after this date but will not impact the trade or the delivery.

An example of this may be the result of the way that a trade is priced e.g. the trade is agreed and concluded pre- 7th April 2016 but priced as an average over all of April 2016 hence the price will not be known until it is calculated after 7th April 2016.

On the basis that all aspects of the trade will be concluded/ settled/delivered prior to the 7th April 2016, XXXX would like to confirm ACERs view that these would be out of scope for the backloading requirement based on:

–   the agreement and conclusion of the trade and/or any delivery will have taken place prior to the 7th April 2016 and that the outstanding cash flow is not material in the context of REMIT transparency or in relation to market manipulation;

–   in the spirit of what REMIT is trying to achieve, reporting these trades to ACER would add little apparent value in terms of transparency, market manipulation or market impact and that

–   the TRUM seems to hint (although not explicit) that the delivery of the contracts is the key factor for reporting requirement generally (3.2.1 point (iv)).


Answer:

Since the contract and all its aspects have been concluded/ settled/delivered prior to 7 April 2016 the obligation to report backloaded contracts does not apply for the above-mentioned scenario.

RSS_Icon Last update: 10/07/2017  

FAQs on transaction reporting – Question II.2.6.1

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?


Answer:

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”.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.2.6.2

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.


Answer:

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.

RSS_Icon Last update: 24/03/2016  

RSS_Icon Subscribe to this Category’s RSS