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

Data Field (15)

Reference to documents: TRUM, Annex II, standard contracts – order conditions PTR & SLO (Data Field No 15)

XXXX Exchange (organized marketplace) offers order type named „stoploss”, where price trigger may either be related to the same instrument or to a different instrument (trader’s choice at the time order is entered). How should such orders be reported, are we correct to assume that such orders should always be reported with “order condition” = PTR (Price Trigger)?

Example:

1. order of XXXX Exchange type “stoploss” is entered at XXXX Exchange, in instrument X, with price trigger related to the same instrument X;

2. order of XXXX Exchange type “stoploss” is entered at XXXX Exchange, in instrument X, with price trigger related to a different instrument Y.

Reading description related to order conditions (Data Field No 15) in TRUM p. 43-44/150, are we correct to assume that we should report orders of XXXX Exchange type “stoploss” in the following manner:

Data Field No 15 (Order condition) – should have value „PTR” regardless of the fact whether actual price condition is related to the same instrument or is related to a different instrument.


Answer:

Data Field No 15 (Order condition) aims at capturing the condition for the order to execute.

A Stop Loss order (SLO) is submitted to the market as a limit order or market order once a certain price condition of an instrument is met (including profit taking). The price trigger refers to the same tradable instrument.

Price Trigger condition (PTR) applies to an order which will not be available for execution unless a specific trigger price is reached, similar to a Stop Loss, but may be triggered across product pricing, i.e. the price trigger may be based on a different contract or index.

With regard to the question above, the Agency understands that:

1. order of XXXX Exchange type “stoploss” is entered at XXXX Exchange, in instrument X, with a price trigger related to the same instrument X, which should be reported as SLO (stop loss); and

2. order of XXXX Exchange type “stoploss” is entered at XXXX Exchange, in instrument X, with a price trigger related to a different instrument Y, which should be reported as PTR (price trigger).

In both cases the orders have to be reported when visible to the market. This means that in some circumstances these orders are not visible to the market and they are not reportable. Once the non-visible orders are triggered and visible to the market, these orders become reportable with all the information that triggered and made them active in the market.

RSS_Icon Last update: 16/11/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.1.15

Data Field (21)

Would it be possible to extend the max length of the Contract ID?

We use this field as a reference and it is displayed in a number of lists and platforms (including XXXXX) together with the UTI, the Action and the parties to a transaction (unlike the Contract name, which is only available by searching the XML)

Our contract ID  includes the Instrument and the Period and immediately pinpoints potential issues with a given contract

Example:

Spread:

Germany_Baseload_vs_Germany_Baseload_NOMX_Futures_Sep_15


Answer:

The length of the Contract ID field is predefined in ACER’s XSD schema. At present there are no plans to change the schema. Schema REMITTable1_V1.xsd and REMITTable1_V2.xsd have been widely consulted with the industry. Any future amendments to the schemas will require a new consultation with the industry.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.1.16

Data Field (21)

The TRUM and its Annexes have been updated to state that for Backloading trades, you should set field 21 (contract ID) to NA and field 22 (name) to BACKLOADING.

Market participants reporting bilateral contracts traded off-organised market places, backloading and executions under the framework of non-standard contracts are not expected to submit a contract ID but only “NA” for not available.

Can I question the contract ID please, since in the XML file the contract ID is used to link the trade to the contract, and if it’s all set to NA then you cannot have more than one trade in a file as you cannot reference which contract the trade refers to.


Answer:

Market participants reporting backloading and executions under the framework of non-standard contracts should report “NA” in Field 21 (Contract ID) and “BACKLOADING” or “EXECUTION” in Field 22 (Contract Name). However, while reporting this information, market participants have to report details of the contracts in each Trade Report and not in the Contract List section of the XML file.

In order to use the Contract List section of the XML file, market participants can use any unique contract ID they prefer. There is no expectation that the other counterparty will report the same contract ID. The contract ID links Trade Reports to the contract in the Contract List section within the same XML file. For Example:

<contractList>

<contract>

<contractId>Contract1</contractId>

<contractName>BACKLOADING</contractName>

………

</contract>

<contract>

<contractId>Contract2</contractId>

<contractName>BACKLOADING</contractName>

………

</contract>

</contractList>

 

<TradeList>

……….

<contractInfo>

<contractId>Contract1</contractId>

</contractInfo>

</TradeList>

<TradeList>

……….

<contractInfo>

<contractId>Contract2</contractId>

</contractInfo>

</TradeList>

 

Or

 

<TradeList>

……….

<contract>

<contractId>NA</contractId>

<contractName>BACKLOADING</contractName>

</contract>

</TradeList>

<TradeList>

……….

<contract>

<contractId> NA </contractId>

<contractName>BACKLOADING</contractName>

</contract>

</TradeList>

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.1.28

Data Field (31)

Is it okay for us to flag the transaction on the AdditionalUtiInfo field, which means that:

If a trade is a cross border trade with the Swiss market then we integrate in the AdditionalUtiInfo field the EIC code of Swissgrid in the part of the trade that we will report, right?


Answer:

If a trade is a cross border trade between an EU market and the Swiss market (or any other non-EU market) then the Organised Market Place (OMP) may report the EIC Y code for the non-EU country delivery point.  The AdditionalUtiInfo field can be used to report the EIC Y code of the non-EU country.

Please note that the reporting of EIC Y code for the non-EU country delivery point is not a REMIT requirement. The Agency is aware that REMIT market participants reporting trades (executed on OMPs) through third parties may not possess this information and may therefore not be able to report the EIC Y code for the non-EU country delivery point.

RSS_Icon Last update: 16/11/2015  

FAQs on transaction reporting – Question II.2.1.46

Data Field (53)

As per the TRUM document, Days of the week allows the value ” ” which means “All days”.

But the specification in the ACER XSD says;

<xs:simpleType name=”daysOfTheWeekType”>

<xs:restriction base=”xs:string”>

<xs:pattern

value=”((SU|MO|TU|WE|TH|FR|SA)to(SU|MO|TU|WE|TH|FR|SA))|(SU|MO|TU|WE|TH|

FR|SA|XB|IB|WD|WN)”/>

</xs:restriction>

</xs:simpleType>

Due to this restriction, XML file fails validation wherever days of the week is ” “.

We would like to flag this to ACER. As a solution to this issue, should we have to display SUtoSA for All Days instead of “ “. Please advise.


Answer:

The symbol “ “ means blank and it means all days. Please note that the field is not mandatory.

RSS_Icon Last update: 16/11/2015  

RSS_Icon Subscribe to this Category’s RSS