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  

FAQs on transaction reporting – Question II.2.1.3

Data Field (3)

If an OMP produces an ACER XML file, but instead of loading the data through an RRM, the ACER XML file is provided to the market participant to load into their RRM of choice – will the validation of the Field 3 (Trader ID) data be based upon the OMP Trader Id (3a) or the Participant Trader Id (3b)?

OR

If an OMP produces an ACER XML file, but instead of loading the data through an RRM, the ACER XML file is provided to the market participant to load into their ETRM system and then report the trade to their RRM of choice – will the validation of the Field 3 (Trader ID) data be based upon the OMP Trader Id (3a) or the Participant Trader Id (3b)?

“traderIdForOrganisedMarket” (Field No. 3a)
“traderIdForMarketParticipant” (Field No. 3b)

  • MP A trades on OMP 1.
  • OMP 1 uses RRM 1.
  • MP A opts out of OMP 1 reporting, and requests the ACER XL data to lodge with their RRM of choice (RRM 2).
  • OMP 1 generates a daily ACER XML file for MP A.
  • MP A takes the file and loads it to RRM 2.

In this instance, does the ACER check on Field 3 (Trader Id) look at the OMP value (3a) as the data was sourced from an OMP or the participant value (3b as the data was loaded via a participant?
Suggest that in this instance, either value be allowed for reporting.


Answer:

Because the trade is executed at the Organised Market Place, the market participant should report the trade/order report with the same information of the Organised Market Place and therefore “traderIdForOrganisedMarket” (Field No. 3a) should be reported.

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.5

Data Field (4)

This question pertains to exchange contracts traded on a broker. These contracts are typically traded anonymously, so that neither party to the trade knows who the other party is. The question is what value should be supplied for TRUM field 4 for trades on such contracts. An example would be a XXX Germany Baseload contract traded on broker platform.

We believe the counterparty should be omitted. This would be consistent with the rule that exchange-traded contracts do not require a counterparty.


Answer:

If the trade takes place on an exchange with orders to trade placed on the broker’s screen or voice brokered, this trade should be reported as any other trade that takes place on exchange.

If traded on the broker’s screen, the orders should be reported as orders placed on the exchange’s contract. There is no expectation that the order report and the trade report are linked together as they were placed first and executed after on two different Organised Market Places.

When orders on futures traded on exchanges are placed on the broker platforms, e.g. Indication of Interest (IOI), Field (4) “ID of the of the market participant” should include the ID of the Exchange.

This can be reported in the form of the LEI, BIC, EIC, or ACER code. When only the Exchange’s MIC code is available to the reporting party, this can be reported (as a last resource) in the format XMIC0000.EU – where the 4 first digits represent the Exchange’s MIC code, followed by 5 zeros, followed by “.EU” to replicate an ACER code.

For the reporting of the trades and for the reporting of the orders, please see examples (2.17) and (3.21) respectively included in the Annex II to the TRUM.

RSS_Icon Last update: 08/09/2015  

RSS_Icon Subscribe to this Category’s RSS