Please insert at least 3 characters

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  

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  

RSS_Icon Subscribe to this Category’s RSS