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

Data Field (48)

Reference to documents: Annex Table 1 (details of reportable contracts) of Regulation (EU) No 1348/2014

Please be advised of the following data issue which has been identified by our company (OMP)

For pure financial products which never result in physical delivery, what should be filled in for field 48 (delivery point or zone).

Two examples

  1. Spread Dutch TT / Italian PSV
  2. German Power Financial

Please note that there is no consistency between the OMPs. For example for German Power. There are 4 different EIC codes used, but also not applicable and blank.

See https://www.acer-remit.eu/portal/standardised-contract

Because there is no physical delivery, the most logical approach is to make this field not applicable. To avoid misunderstanding (parties forgot to add a EIC code where applicable), it is advisable to use a fictive EIC code, for example 99X-NOT-APPLIC–


Answer:

It is our understanding that every contract related to the supply of electricity or gas, irrespective of if the contract is a spot, a physical forward, a future or an option contract has a reference to a delivery period and a delivery point. Also financial products that are settled in cash and never result in physical delivery have a reference price or other attributes which relate to the commodity. In this case, reporting parties should refer to the reference price or other attributes which relate to the electricity or gas and report its delivery point.

For contracts that involve more than one delivery point, all of them should be reported.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.2.3.10

Basis Swaps – defining who the buyer and seller are so counterparty fields can be correctly and consistently populated.

We trade products that are basis swaps. These are swaps where each leg is floating. Whereas for fixed-floating swaps we can use market convention to define the buyer, for floating-floating swaps there is no clear guidance on which leg the buyer is and which leg the seller is. For some jurisdictions we can report trades as generic so we don’t have to define buyer / seller for reporting purposes. Does ACER have any guidance?

We have our own convention in our internal systems for defining buyer / seller that we apply consistently.


Answer:

In the TRUM, under Field (25) for Table 1 “Fixing index or reference price” there is clear guidance on which leg the buyer is and which leg the seller is.

For derivatives that have not already been reported under EMIR, and which are 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, legs (indexes) should be sorted alphabetically. X will be identified as a buyer (B) and Y will be identified as a seller (S).

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.2.6.3

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.


Answer:

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.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.2.3.7

For Exchange Traded Commodity Derivatives only, executed by an Executing broker and cleared at a Clearing Broker. From the Executing Brokers point of view only:

  1. Can ACER confirm that if an underlying client is not a REMIT market participant, then we as the executing broker have no obligation to populate them as the beneficiary in field 8?
  2. Can ACER confirm that if an underlying client has registered as a REMIT market participant, however only executes cash settled derivatives, with no ability to make or take delivery and is not an exchange member, they would not be considered market participants for the purpose of reporting these trades only and therefore we as the executing broker have no obligation to populate them as the beneficiary in field 8?
  3. Can ACER confirm that if an executing broker knows they are giving up an executed transaction to an EMIR regulated clearing broker, or for a client who is required to report under EMIR, they can place reliance on the fact that the beneficiary will be reported under EMIR? Order details will still be reported as standard by us via the OMP.

Answer:

With regard to point (1) field (8) Beneficiary ID 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 an executing broker’s underlying client is not a REMIT market participant, then the executing broker may not populate the beneficiary in field (8).

With regard to point (2), if an executing broker underlying client has registered as a REMIT market participant (meaning that that person enters into transactions, including the placing of orders to trade, in one or more wholesale energy markets) even if only executes cash settled derivatives, with no ability to make or take delivery and is not an exchange member, that person would be considered market participant for the purpose of reporting all their trades and orders and therefore the executing broker may populate that market participant as the beneficiary in field (8).

If a person is a market participant that person has to report all their transactions in wholesale energy markets irrespective of where they take place. If field (8) is not populated, a back to back transaction between the executing broker and their underlying client should be reported, unless that transaction was already reported under EMIR.

With regard to point (3) above, according to the ANNEX III of the TRUM, under REMIT the executing broker (e.g. firm ABC) has to submit the order details only. This reporting must be done by delegation to the Organised Market Place or third party service provider. Firm ABC does not have to submit any trade report if the trade was reported under EMIR. Contract details reported by the clearing broker (Firm XYZ) and by the executing broker’s client (Client 123), under EMIR and, according to the Agency’s understanding, should make reference to the executing broker.

RSS_Icon Last update: 14/12/2016  

FAQs on transaction reporting – Question II.2.3.8

For Exchange Traded Commodity Derivatives only, executed by an executing broker and cleared at a clearing broker. From the end client’s point of view only:

  1. Can ACER confirm that if an underlying client is not a REMIT market participant, then they themselves have no reporting obligation?
  2. Can ACER confirm that if an underlying client has registered as a REMIT market participant, however only executes cash settled derivatives, with no ability to make or take delivery and is not a direct exchange member, they would not be considered market participants for the purpose of reporting these trades only and themselves would not have a reporting obligation?
  3. Can ACER confirm that if a client is a REMIT market participant, which has a reporting obligation, but does not clear through an EMIR regulated clearing broker, or have any reporting obligations under EMIR, they can place reliance on the fact that the beneficiary will be reported by the Executing broker on their transaction report via the OMP?

Answer:

With regard to point (1) if the executing broker’s client is not a market participant there is no obligation to report REMIT transactions. The obligation to report REMIT transaction is on REMIT market participants. Please see Q&As on REMIT document, Questions II.4.2, II.4.43, and II.4.47

With regards to point (2) the question may apply to two different scenarios:

(a) if an underlying client has registered as a REMIT market participant, it means that they enter into transactions, including the placing of orders to trade, in one or more wholesale energy markets.

If the client executes cash settled derivatives, with no ability to make or take delivery and is not a direct exchange member, the client has to report all their transactions including cash settled derivatives because the client is a market participant in a first place.

(b) if an underlying client has registered as a REMIT market participant, but does NOT enter into transactions, including the placing of orders to trade, in one or more wholesale energy markets, that client should not have registered as REMIT market participant and therefore, as indicated in the TRUM ANNEX II: “a client of an exchange member that places orders to trade on the order book of the venue to trade EU gas or electricity derivatives for financial settlement or it is equivalent (e.g. trading on futures for the physical delivery without having arrangements to take or make the delivery of the commodity) should not be considered a market participant unless the client of the exchange member is itself a member of the exchange for the purpose of this trade.”

With regard to point (3) if a client is a REMIT market participant, which has a reporting obligation, but does not clear through an EMIR regulated clearing broker, or have any reporting obligations under EMIR, as indicated in the TRUM Annex III “market participants should report transactions under REMIT only if those transactions are not reported under EMIR …….”  they may place reliance on the executing broker reporting the client’s ID as beneficiary in filed (8) on executing broker’s transaction report reported by the OMP (or third party RRM), or alternatively report a back to back transaction between the client and the executing broker.

It is worth noting that there may be some ETDs traded on EU venues by non-EU counterparties that are not reported under EMIR (e.g. U.S. counterparties reporting under the Dodd Frank Act). The Agency understands that these trades have to be reported under REMIT and, if not reported under EMIR, have to be reported through the Organised Market Places or third party RRM reporting on their behalf.

RSS_Icon Last update: 14/12/2016  

FAQs on transaction reporting – Question II.2.3.9

For Exchange Traded Commodity Derivatives only, executed via Direct Market Access (DMA) and cleared at a Clearing broker.

From the End Client’s point of view only, can ACER confirm that if an underlying client is not a REMIT market participant, then they themselves have no reporting obligation?

Is the DMA provider a REMIT Market participant?

How DMAs’ clients that are market participant should report their trades without reporting a back to back transaction?


Answer:

If an underlying client is not a REMIT market participant, then they themselves have no reporting obligation.

When a Clearing Broker (e.g. DMACB) offers Direct Market Access (DMA) on an exchange to its client, although it is the DMACB’s client who trades, the trade is done via the DMACB‘s membership. Therefore, it is the Agency’s understanding that the DMA provider (DMACB) should be considered a REMIT market participant within the REMIT framework as it places the order on the exchange for its client.

In the Agency’s view, a person that place an order in the exchange is a market participant even if it will not be a counterparty to the trade. Market participants that place orders on the screen of the exchange have to be identified in the trade report as responsible for the reporting of the report. This does not imply that they are counterparty to the contract, but that they are responsible for the reporting of the order or the trade. Please also see FAQs document on transaction reporting Q. II.2.1

As indicated in the TRUM Annex III “market participants should report transactions under REMIT only if those transactions are not reported under EMIR …….

As a REMIT market participant, DMACB is required to report orders and transactions (if DMACB is counterparty to the trade and not reported under EMIR) in wholesale energy derivative contracts to the Agency. It is possible that DMACB’s clients are also market participants under REMIT. This can be the case when clients have own memberships on other REMIT energy exchanges, or when they trade bilaterally any REMIT physical products.

When the exchange reports trades (not orders) on behalf of DMACB, the exchange may report the ID of the DMACB’s client as end beneficiary in field (8) Beneficiary ID. Please note that for orders there is no need to report the Beneficiary ID.

In addition, the Agency understands that DMACB ‘s clients may trade on the exchange under (1) Locally Managed Accounts (LMA) or (2) System Managed Accounts (SMA).

  1. In case of the LMA set-up, the exchange does not see the information concerning the end-user (DMACB’s client) and would report DMACB as a market participant, which means that the end beneficiary field would not be filled in. DMACB and the exchange may agree to report the DMACB’s client ID in the beneficiary field (8) if this is a market participants but only for trades not reported under EMIR and not for orders.
  2. In case of the SMA set-up, even if the exchange is able to see the identity of DMACB’s client (via an ACER code), the exchange should NOT report the ID of the DMACB’s client as market participant but as beneficiary in Field (8) Beneficiary ID if the exchange receives that assignment by the DMACB if the trade has not been reported under EMIR.

The Agency’s view is that the correct reporting should not depend on the two different set-ups (i.e. LMA or SMA), but on the definition of market participant of REMIT. Therefore when an order is placed on the DMACB’s membership the exchange should not report the ID of the DMACB’s client as a Market Participant in field (1).

Therefore when a trade is executed on the DMACB’s membership the exchange should not report the ID of the DMACB’s client as a Market Participant in field (1) but the ID of DMACB and the DMACB’s client ID in Field (8) Beneficiary ID if agreed with the DMACB and if the trade was not reported under EMIR.

Please note that for orders there is no need to report the Beneficiary ID as this applies to transaction only if not reported under EMIR.

RSS_Icon Last update: 14/12/2016  

FAQs on transaction reporting – Question II.2.1.4

Data Field (3)

Reference to documents: Annex IV to Transaction Reporting User Manual

Is it mandatory for OTC contracts, to fill Table 1, Field 3? In the examples provided by ACER, such fields are filled only for standard contracts and examples 15.2-18.2. What features of examples 15.2-18.2 are triggers for reporting this field? What is the understanding of the person concluding the contract in case of OTC market? Is it a person whose signature appears on the contract?

In our opinion, this field should not be required for contracts concluded OTC.


Answer:

Data Field (3) ID of Trader is required to be populated for any contract executed at organised market places and bilaterally as already indicated in the TRUM. For executions executed under the framework of non-standard contracts, examples are available in Section (2) of Annex II to the TRUM. The Agency would not expect this filed to be reported in line with the examples provided in Annex II to the TRUM.

RSS_Icon Last update: 26/09/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  

FAQs on transaction reporting – Question II.2.1.30

Data Field (35) and (38)

Reporting negative prices & resulting negative notionals

We wish to get clarification on how to report the following scenario under REMIT from 7th April 2016 onwards:

In some cases a trade may be for a “”negative”” price. This is not the same as the trade being the “”other way around””, i.e. a “”buy”” instead of a “”sell””.

Is it permissible to report negative prices in the various fields, i.e. fields 35 or 57 of table 1, or field 15 of table 2?

The same question would apply to resulting notionals.


Answer:

If the Price of the trade is negative, this should be reported with a negative number. For notional values, these should always be reported in absolute value.

RSS_Icon Last update: 24/03/2016  

RSS_Icon Subscribe to this Category’s RSS