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

If an OMP reports a trade to ACER, and subsequently errors that trade out – is the market participant still required to provide a Beneficiary Id?

An OMP make a new trade submission to ACER – but the Beneficiary Id is not provided, as this would normally be populated as a lifecycle event (Action Type = M) by the market participant.

However, the trade is cancelled out by the OMP (Action Type = C).

In this instance, the market participant would not be able to submit the lifecycle event (Action Type = M) to notify ACER of the Beneficiary ID, as the trade is in a Cancelled state and cannot be modified.

Suggest that in these instances, there is no beneficiary, as there is no trade and hence no position.

Therefore, ACER will see a new trade submission, and a subsequent lifecycle event cancelling that trade.

ACER will not receive any subsequent lifecycle events for cancelled trades – so in instances where market participants are updating the Beneficiary Id in a two stage process (using Action Type = M), the Beneficiary Id may remain null.


Answer:

If two orders match and result in a transaction that is then cancelled, we would expect one of the following scenarios to be reported:

1) one or two active order reports (the second order may never been on the screen) + two matched order reports (or one or more partially matched orders) + two new trade reports + two cancelled trade reports;

2)  two active order reports (the second order may never been on the screen) + two matched order reports (or one or more partially matched orders) + two cancelled matched orders reports (please see example 3.55 in the 30 July webinar document);

or if the Organised Market Place uses a click and trade system:

3) one active order report + one matched order reports (or one or more partially matched orders) + two new trade reports (one will be a click and trade) + two cancelled trade reports.

They all indicate the same thing. There is no need to report the Beneficiary ID.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.4.2

The reporting of expired orders. In TRUM it seems like the event when an order expires should be reported (with Order status EXP – Expired).

For practical reasons we have some problems with reporting these at T+1. The expirations of orders take place in the night batch and usually around 4 in the morning (sometime before the next trading day opens). For practical reasons we must prepare the REMIT data to be reported before that time. So if we are to report these “as is” we would report expirations on T+2

It seems really unnecessary to report when an order expires and will lead to heavily increased volumes. All the information for expiration this is already in the previous events (Order duration).

For trades that expire on maturity date cancelations should not be sent, so it does not seem logical to have different reporting logic on expiration for trades and orders.

Since there is no gain in reporting expired orders my suggestion is that it should not be reported.


Answer:

There is no need to report the order report for Order status EXP (Expired) if this can be derived from Field (20) Order duration and expirationDateTime available in the schema. Field (20) Order duration has seven accepted values:

Order Duration  
DAY=Day No need to report Order status EXP
GTC=Good Till Cancelled No need to report Order status EXP
GTD=Good Till Date No need to report Order status EXP  if Expiration Date Time is be reported in the XML report
GTT=Good Till Time No need to report Order status EXP  if Expiration Date Time is be reported in the XML report
SES=Session No need to report Order status EXP
OTH=Other No need to report Order status EXP  if Expiration Date Time is be reported in the XML report

 

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.4.3

The market participant can change the lifecycle of the ”OrderReport”  and “TradeReport” via the field “ActionType”. The possible values are: New, Modify, Error and Cancel.

But if the market participant wants to report the change of the contract, he doesn’t have the possibility to report the change. The contract type doesn’t have the field “ActionType”.

Is it not allowed to change or cancel the contract?

For details see xml tags:  “contractList”  and “annexTable1ContractType”.


Answer:

If reporting parties erroneously report the contract ID or details of the contract in the Contract List section of the XML file, they have to resubmit all the transactions related to that contract. To do so, the reporting parties have to:

1) submit a trade error report in order to cancel the previous transactions; and

2) re-submit them with the correct contract ID/details.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.4.4

Article 5 of the Implementing Regulation and TRUM Section 3.2.10

It has been mentioned at an industry meeting that a lifecycle even that needs to be reported is when the trader for a still active trade leaves the company, or moves to another department, and therefore is no longer responsible for taking decisions or actions in executing or amending the transaction. The suggestion is that in this case a modification to the trade report needs to be made identifying the person who is now responsible for taking decisions or actions in executing or amending the transaction. For example:

John Smith enters into a trade for Summer 2016 Baseload on 17/5/2015.

On 21/10/2015 John Smith leaves the company and is therefore no longer responsible for the trade in any way. Would that need to be reported and if so how?


Answer:

The trader leaving the market participant does not in itself constitute a life cycle event. Any subsequent modifications or amendments to the trade are considered a life cycle event. If a different trade changes the terms of the contract, then the Trader ID can be amended by a life cycle event with a trade report containing the following information:

Field (3) Traded ID: the ID of the trader who has made the modification

Any field that was amended: new value as a result of the modification (including new time stamp).

Field (58) Action Type “M” for Modify (or ”C” for Cancel if the trade is cancelled).

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.4.5

We found a problem with the forthcoming new intraday order. The order type is ICEBERG and can be created as non-active then it can be activated then deactivated and then activated again etc. The question is how to change Order Type and Action Type in the report according to the deactivation. Once the order is deactivated, no one can see it on screen. We prepared the following example:

Action Order

ID

Version Orders Status Action Type Time
New order, non-active 45635 1 no report 2015-08-18T10:58:44.000
Activation 45635 2 ACT N 2015-08-18T11:25:00.000
Deactivation 45635 3 WIT M 2015-08-18T13:02:34.000
Activation 45635 4 ACT M 2015-08-18T13:58:23.000
Cancellation by MP 45635 5 WIT C 2015-08-18T15:01:03.000
or        
Cancellation by system 45635 5 SUS C 2015-08-18T15:01:03.000

 

We think that the new order that has been created but not activated shouldn’t be reported. So, the first report should be done at time of activation with action type “N”. Then, deactivation should be marked with the status “WIT”=Withdrawn, because the order won’t be displayed on the screen. We think that if we used status “OTH”=Other instead of “WIT”=Withdrawn, it would be interpreted as a special order but still active in the system that can be matched. That’s why we used status.


Answer:

An order that has been created but not activated should not be reported. The first report should always start with a new (“N”) report. The deactivation should be marked with the status “WIT”=Withdrawn and Action Type “M”=Modify if the order is not visible on the screen and it can be reactivated.

If the order is withdrawn permanently, this should be marked with the status “WIT”=Withdrawn and Action Type “C”= Cancel or “SUS”=Suspended and Action Type “C”= Cancel. In this case the order cannot be reactivated.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.4.6

What order status should be given when reporting “Stop-loss” when it is not activated?

The TRUM does not contain any examples of reporting “Stop-loss” orders whereas it is quite commonly used by market participants.

Because a “Stop-loss” order before its activation is not visible in the order book of the organised market place it cannot be reported as ACT (active). Should it be reported in the field “Order status” as SUS (Suspended) or OTH (Other)?


Answer:

Since a “Stop-loss” order is not visible in the order book of the Organized Market Place before it is activated, it should not be reported. An order with Stop-loss or any other trigger (e.g. profit-taking) should be reported if already Active in the order book.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.4.7

Who has the reporting obligation for lifecycle change in case of standard contracts reported by OMPs? This question is significant for broker contracts.

In our view, the MP has the obligation for reporting all data – ‘new’ Orders, Contracts and Trades as well as any changes to the original report that arise from reporting errors or changes to the underlying data due to lifecycle events. However MPs can delegate reporting to OMPs but the OMP may not have sight of lifecycle events for trades that occur after the reporting day, say a partial novation of a trade. In this case any change to the originally reported information submitted as part of the reporting of a ‘new’ trade, will have to be reported by the MP (via an RRM), or possibly uploaded to the originating OMP and reported by them, should they offer such a service.


Answer:

The obligation and responsibility of correct reporting lies with the market participant. Market participants should ensure that they can make changes to existing reports in an appropriate way. The Organised Market Place should offer a data reporting agreement for trades executed on their platforms. Such a reporting agreement may or may not include the possibility to update lifecycle events that occur outside the venue.

Market participants should be able to provide the Agency with information about any changes to the underlying data due to lifecycle events. They shall do so through third party Registered Reporting Mechanisms. The list of Registered Reporting Mechanisms is available on the REMIT portal.

RSS_Icon Last update: 16/11/2015  

RSS_Icon Subscribe to this Category’s RSS