FAQs on transaction reporting – Question II.1.1.33

MP has concerns about reports in which one of his counterparties has changed ACER Code during the organization transition process.

Example:
There is a scenario in which there is a contract between party A and party B (ACER codes: ACER-A1 and ACER-B1 respectively) already reported, and at some point in time party A1 (as a result of organizational rebranding/division) receives a new ACER code (ACER-A2). How should such an event be reported to the Agency? In the form of a modification to the original contract or maybe a cancellation of the original one followed by reporting a new contract?


Answer:

In the Agency’s view, the change of the ACER code is a case of novation. As stated in Question 1.1.26 in the FAQ document, all open trades have to be novated with the name of the new legal entity in order to notify the change of the counterparty to the contract. In order to report a novation, an early termination with the old UTI (Action type “C”) and a new trade with a new UTI (Action type “N”) should be reported. This applies to both sides of the trade/contract.
This is also consistent with the ARIS validation rule available on the Agency’s REMIT portal. A change to Field No (1) ID of the market participant or counterparty is not possible, as this is a key component for the identification of the uniqueness of the submitted report. As a result, it is not allowed to report it as “M” (‘Modify’).

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.1.1.34

Reporting of novation and “novation like” activities.
There are different views in the industry about the reporting process that could require a “novation”. The old contract should terminate when the new contract starts or the new reporting should have the original date of the contract as starting date?


Answer:

In the Agency’s view, the new contract has to be reported with a new date (using Action type “N”), while the old contract has to be terminated (using Action type “C”). Please see also Question II.1.1.17, Question II.1.1.26, and Question II.3.5.6.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.1.13

Data Field (15)

Reference to documentation: REMIT Transaction Reporting User Manual

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

Example:

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

Because “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:

Orders have to be reported when they are visible to the market. This means that in some circumstances they may not be visible to the market and they are not reportable. Once triggered and visible to the market, these orders are reportable with the information that triggered and made them active in the market.

If a “Stop-loss” order is not activated and not visible in the order book of the Organised Market Place, it cannot be reported as active (ACT). Once the order is triggered, this will be reported with the following information:

Once the market order is triggered at 50 EUR and it is entered into the market

  Order details  
13 Order ID I4R9Q3Q6K3D2C1J5O0H8
14 Order type MAR
15 Order Condition SLO
16 Order Status ACT
17 Minimum Execution Volume
18 Price Limit
19 Undisclosed Volume
20 Order Duration GTC
58 Action type N

 

and in the XML file:

<triggerDetails>

<priceLimit>

<value>50</value>

<currency>EUR</currency>

</priceLimit>

</triggerDetails>

Or, if the order was a Price Limit order:

  Order details  
13 Order ID I4R9Q3Q6K3D2C1J5O0H8
14 Order type LIM
15 Order Condition SLO
16 Order Status ACT
17 Minimum Execution Volume
18 Price Limit 50
19 Undisclosed Volume
20 Order Duration GTC
58 Action type N

 

and in the XML file:

<triggerDetails>

<priceLimit>

<value>50</value>

<currency>EUR</currency>

</priceLimit>

</triggerDetails>

The Agency understands that there may be other combinations of order types and order conditions that may require additional guidance. This can be provided on an ad-hoc basis.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.2.1.29

Data Field (31)

In case of a cross-NEMO trade, how should OMPs report transactions that take place in the XBID platform for the coupled intraday continuous European market? For example:

OMP_1 reports trades matched within one zone/area,

OMP_2 reports trades matched within another zone/area.

What about cross border transactions between OMP_1 and OMP_2 zones? How should the UTIs of such transactions be reported?


Answer:

An example of how to report such transactions is available in the Annex II to the TRUM: Example 2.53 – Life cycle events for orders that match in intraday market coupled.

The only difference between this guidance and Example 2.53 available in Annex II to the TRUM is that in cross-NEMO trades, OMPs receive the same UTIs from the matching platform and therefore do not need to report two UTIs as in Example 2.53, but just one as described in the example below:

 

TRADE LIST OMP_1:

Transaction with UTI XBID_46752 will be reported by OMP_1.

MarketParticipant PRICE QUANTITY LINKODERID UTI Transaction Time
MarketPaticipantOMP_11 21 50 OMP_1-MC-O-123454 XBID_12345 2018-04-18T19:50:32.000Z
MarketPaticipantOMP_12 21 50 OMP_1-MC-O-123456 XBID_12345 2018-04-18T19:50:32.000Z
MarketPaticipantOMP_13 20 100 OMP_1-MC-O-188593 XBID_46752 2018-04-18T19:40:32.000Z

 

TRADE LIST OMP_2:

Transaction with UTI XBID_46752 will be reported by OMP_2.

MarketParticipant PRICE QUANTITY LINKODERID UTI Transaction Time
MarketParticipantOMP_21 19 30 OMP_2-MC-123411 XBID_67891 2018-04-18T19:47:45.000Z
MarketParticipantOMP_22 19 30 OMP_2-MC-123422 XBID_67891 2018-04-18T19:47:45.000Z
MarketParticipantOMP_23 20 100 OMP_2-MC -123433 XBID_46752 2018-04-18T19:40:32.000Z

.

RSS_Icon Last update: 20/07/2018  

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  

FAQs on transaction reporting – Question II.2.4.11

How to report in REMIT report case where OMP XXX will remove a trade (standard contract) where a buy order was wrongly submitted and market participant has contacted us and asked for the trade to be removed? Other market participant which was a seller has been contacted and accepts the removal of the trade. In this case, where XXX makes the trade removal from the system, should the actionType be Error (cancellation of wrongly submitted report) or Cancel (a termination of an existing contract or order to trade)?

Practical example:

Market participant C has made an error while adding buy bid, bid was meant to be 45 MWh, but it went into trading system as of 450 MWh. There was already sell bid on the platform (Market Participant A 500 MWh), so bids were matched and trades made. Market participant C contacts us and tells there was a mistake and asks if we can remove the trade from the system. We contacted Market Participant A and told what has happened, and asked if the trade can be removed from the trading system. Market Participant A accepts that. There was also Market Participant B, who made buy bid of 50 MWh which was matched with market participant A’s sell bid. Figures below.

Orders:

  • Market Participant A: Sell bid 500 MWh à Order status: ACT – PMA (with 50 MWh) – MAC
  • Market Participant B: Buy bid 50 MWh à Order status: ACT – MAC
  • Market Participant C: Buy bid 450 MWh à Order: ACT – MAC

Trades:
1st trade

  • Market Participant A: Sell 50 MWh
  • Market Participant B: Buy 50 MWh

2nd trade

  • Market Participant A: Sell 450 MWh
  • Market Participant C: Buy 450 MWh

Both trades in trade 2 (450 MWh sell and 450 MWh buy) will be removed from the trading system by XXX, but orders remain as they are (those cannot be changed). How should this trade removal/cancellation be reported in REMIT report, especially Market Participant A´s order?

REMIT report correction:

For these Transaction timestamp: The time when trade has been removed and Action type: C (Cancel)

  • ORDER Market Participant C: Buy bid 450 MWh à
  • TRADE Market Participant A: Sell 450 MWh
  • TRADE Market Participant C: Buy 450 MWh

For this, does it need something for the correction?

  • Market Participant A: Sell bid 500 MWh à Order status: ACT – PMA (with 50 MWh) – MAC

Answer:

In the Agency’s view, when a trade is cancelled because ‘an order has been wrongly submitted to the trading system by a market participant’, the trade should be cancelled by using Action type “C”.

As the order is visible to the market, it should not be removed from the system and should be reported as an MAC or PMA order, even if it was erroneously submitted by a market participant. Then the trade will be first reported as New (Action type “N”) and then reported as Cancelled (Action type “C”).

For Action type “E” Error, in the TRUM it is explained that ‘when the report contains a cancellation of a wrongly submitted report, it will be identified as ‘error’. This means that Action type “E” for Error should be used when a transaction has been incorrectly sent to ARIS and needs to be removed from the database. Then, a new transaction should be submitted by using a different UTI.

However, the above question describes a case where the error occurs in the system of an OMP (as a result of their client’s mistake) and not in the reporting to ARIS, for example preparation of the file, extraction of data from the system, bugs etc.

Example:  if an OMP reports a trade with the price of 50 EUR instead of 50 GBP, that trade was incorrectly sent. The same applies if the real price is 50 and the OMP reports 35 (or any other price). Therefore, you would report an ‘Error’ transaction and resubmit is with the right price. This is not the case for your question.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.1.50

There is a type of transaction that occurs in the UK (and perhaps elsewhere) referred to Gas-Retro-Deals. These are physical trades executed after the gas day at beach terminals. Shippers are incentivised to enter into such deals on occasion to reduce transportation costs or imbalances. These are done after delivery but before settlement. Therefore, they would have a timestamp after the delivery start date.

We do not believe an example is required here but if it necessary, please let me know.

We believe that Gas-Retro-Deals fall within the scope of ‘…day after markets.’ We believe this is a common understanding amongst industry participants who trade such contracts. We would appreciate confirmation from ACER on this interpretation. In addition, any other guidance ACER would like to provide at the same time on the reporting of such contracts would also be helpful.


Answer:

[UPDATED] based on additional input provided by the Agency’s stakeholders

In the Agency’s view, a balancing trade is a contract between a party and a System Operator (SO), in most cases TSO, who is in charge of keeping the energy in the network/system (either gas or electricity) in balance.

It is our understanding that in “…day after markets”, and any other retro-deal market, [added] where an SO or TSO is not involved, market participants balance/adjust their positions with other market participants. If this is the case, these contracts should be reported by both parties as wholesale energy products.

In the Agency’s view, balancing trades are well defined in Articles (2)9 to (2)11 of COMMISSION IMPLEMENTING REGULATION (EU) No 1348/2014, in the sense that they are related to balancing energy and services:

(9) ‘balancing energy’ means energy used by TSOs to perform balancing;

(10) ‘balancing capacity (reserves)’ means the contracted reserve capacity;

(11) ‘balancing services’ means

  • for electricity: either or both balancing capacity and balancing energy;
  • for natural gas: a service provided to a TSO via a contract for gas required to meet short term fluctuations in gas demand or supply.

In addition, whenever market participants (MP) may have any doubts about the delivery point, we would recommend (MP A) to report the transaction in any case, even if the other counterparty (MP B) would not agree with (MP A). In this case (MP A) would not take the risk of not reporting a reportable contract according to REMIT. The EIC for the destination delivery point can be reported in this case.

We also recommend market participants to read Questions 3.1.21, 3.1.22, 3.1.23 and 3.1.24 of the FAQs on transaction reporting document which, in the Agency’s view, would help to understand the scope of LNG contracts under REMIT.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.1.51

Does technical delivery of natural gas for gasification purposes or emergency delivery has to be reported under REMIT?

A “service company” has been asked by TSO or DSO to provide natural gas in case of network failure/damage. This action can take up to 2-3 days of delivery realized for a relatively small group of final consumers within specific area of the network, where regular delivery is not possible due to supply failure. Sometimes such delivery is not direct, but one service company sells natural gas to another service company. Does such contract have to be reported under REMIT?

As volumes are very small, transaction has no influence on the market and this delivery has semi-balancing purpose, it does not have to be reported.

A “service company” is a firm which repairs a transmission or distribution network in case of its damage. Let’s say that there is a small village supplied with gas by a single pipe. This pipe has been damaged due to some construction works. A service company has been called to repair the pipe. The repair work has been scheduled for two business days. During this time the village is without gas supply. To avoid such gas supply interruption (especially during the winter), the service company provides gas to the village, usually using LNG cistern and small regasification station (short time emergency delivery).

In such situation a service company does not sell gas to the final customers, it just provides gas to the network and sells it to the operator (in our understanding this is for balancing purposes). Sometimes there are two service companies due to technical specifics of repair works and it happens that one service company (main contractor of repair works) sells gas to another service company (subcontractor of repair works).

Our question is whether such contracts should be subject to REMIT reporting. In our view this is balancing (or filling the network) so it is not subject to REMIT reporting.


Answer:

In the Agency’s view, based on the information provided above, this contract seems to be a contract for the supply of gas for a period of maintenance, and not for a balancing service.

In the Agency’s view, balancing trades are well defined in Articles (2)9 to (2)11 of COMMISSION IMPLEMENTING REGULATION (EU) No 1348/2014, in the sense that they are related to balancing energy and services:

(9) ‘balancing energy’ means energy used by TSOs to perform balancing;

(10) ‘balancing capacity (reserves)’ means the contracted reserve capacity;

(11) ‘balancing services’ means,

  • for electricity: either or both balancing capacity and balancing energy;
  • for natural gas: a service provided to a TSO via a contract for gas required to meet short term fluctuations in gas demand or supply.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.1.52

There are different views within the industry about the reporting of purchase seller agreement when transactions consist of different parts. For example:

  • Company A can sell electricity to Company B in accordance with the terms and conditions of their purchase seller agreement; but also
  • Company B can sell electricity to Company A in accordance with the terms and conditions of their purchase seller agreement

How should such a contract be reported?

  1. Some market participants believe that the contract should be split in two different reporting streams: one contract for the sold quantity and one contract for the bought quantity
  2. Other market participants suggested to report one contact using C as buy/sell indicator

This different views may result in the reporting of the same contract with different formats:

  1. Company A reports a Table 2 with a “C” as buy/sell indicator;
  2. Company B report two separate Table 2, one for the sold quantity and one contract for the bought quantity
    What is the right way to report such purchase seller agreement transaction?

Answer:

In the Agency’s view, purchase-seller agreements should be reported with Table 2, as per the examples available in Annex II to the TRUM provided by the Agency’s stakeholders.

With regard to the reporting of a transaction under a purchase-seller agreement with Table 2, if market participants have different views on the reporting of such contracts, they can report their purchase-seller agreement with Table 2 either as one contract with a “C” as buy/sell indicator, or two separate contracts, one as “B” for Buy and one as “S” for Sell, provided that the meaning of the reports is the same.

As a result, any EXECUTION under that framework agreement should be reported with Table 1. Please see examples in Annex II to the TRUM.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.2.1

Data field (4)

Reference to documents:

  • REMIT-EU 1227/2011, Article 9, paragraph 1
  • Guidance on the application of REMIT, 3rd Edition, Updated 3-June-2015, Section 3.5
  • FAQs on REMIT transaction reporting, item II.2.6
  • ARIS Data Validation v2.1 , section 6.3.2.
  • ARIS Data Validation Rules configuration V3.1 (Rule AT2F15R1 has been disabled on both Testing Framework and Production)

How field (4) of Table 2 “ID of the other market participant or counterparty” in a bilateral transaction should be populated when the other counterparty (non-EU member) does not have an ACER code but is a REMIT participant.

Example: In a reportable Bilateral Contract the “other Market Participant” (counterparty) is a non-EU member but refuses to register for obtaining an ACER code.

Given that according to:

1. FAQs on REMIT transaction reporting, item II.2.6, the fictitious ACER code ACERNONMP.EU is used for cases that the counterparty is a non-REMIT market participant

2. ARIS Data Validation Rules configuration V3.1, the Rule AT2F15R1 has been disabled on both Testing Framework and Production

There are 2 possible solutions:

1. To populate field 4 with any of the codes (EIC/BIC/ LEI/GLN/GS1) if available

OR

2. To populate field 4 with a fictitious code similar to the abovementioned but to clearly indicate that is a non EU non-registered REMIT participant, e.g. ACERNONEU.MP  (this approach covers the (rare) case the said participant does not have any of the EIC/BIC/ LEI/GLN/GS1 codes).


Answer:

Field (4) of Table 2 “ID of the other market participant or counterparty” in a bilateral transaction should be populated with one of the allowed codes if the other counterparty to the contract is a REMIT registered market participant otherwise ACERNONMP.EU  to indicate the counterparty to the contract is not a registered market participant.

RSS_Icon Last update: 20/07/2018  

RSS_Icon Subscribe to this Category’s RSS