Please insert at least 3 characters

FAQs on transaction reporting – Question II.1.1.29

The TSO in AAA, XXX, shows the occurred imbalances of previous periods and the active companies shall try to find a partner to offset the positions on bilaterally basis. If the companies cannot find offsetting volumes the TSO finally balances the accounts.

Could you please specify if pre-arranged contracts to offset the volumes are regarded as balancing contracts or as bilateral contracts which needs to be reported under REMIT?

In case they have to be reported, we would like to make ACER aware that the transaction timestamp is after the delivery start date which seems to be conflicting according to remarks in the letter to improve the data quality.

To our understanding only contracts with the TSO are defined as balancing contracts and the contracts needs to be reported as Table 2 contracts with monthly executions of the exchanged volumes to avoid balancing.


Answer:

Please refer to Question 3.1.50. 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 the Agency’s understanding that in “…day after markets”, and any other retro-deal market, 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.

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.1.1.30

Company deconsolidation from the group perimeter

The companies “XXX” and “YYY” are part of the same group and both registered MPs subject to REMIT. The companies “XXX” and “YYY” entered into transactions but accordingly to Article 4(1) of Commission Implementing Regulation (EU) No 1348/2014 they did not send on a regular basis any reporting related to the contracts.

On 1 July the company “XXX” is going to be deconsolidated from the consolidated financial statement of the company “YYY”. From a reporting point of view, should the contracts in place be reported to ACER? With which timetable? What is the contract date that should be used?

With reference to the reporting of the outstanding contracts, our interpretation is that they should not be reported because agreed out of normal market rules in an infra group context.

In case the Agency believes that those contracts have to be reported, our interpretation is that

  • the reporting should be done in T+1 month from the date of deconsolidation of company “XXX”
  • the contract date should be the same of T.

Answer:

As on 1 July the company “XXX” is going to be deconsolidated from the consolidated financial statement of the company “YYY” and it changes status, in the Agency’s view it is reasonable that company XXX should report all its contracts on T+1 month from its status change with the date of its status change.

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.1.1.31

As on 1 July the company “XXX” is going to be deconsolidated from the consolidated financial statement of the company “YYY” and it changes status, in the Agency’s view it is reasonable that company XXX should report all its contracts on T+1 month from its status change with the date of its status change.

1         Case1: TSO inserts buy offer for block contract 15:00 – 18:00 at 14:30 (in Balancing phase) with BAL parameter. Other market participant inserts sell offer for the same contract at 14:31 with price and volume which fully match the offer inserted by TSO. The trade match time is 14:40 (in balancing phase).

Which data should be reported in this case to ACER?

2         Case2: TSO inserts buy offer for block contract 15:00 – 18:00 at 14:30 (in Balancing phase) with BAL parameter. Other market participant inserts sell hourly offers 15-16, 16-17 and 17-18 (the same time period as block contract inserted by TSO) at 14:31 with price and volume which fully match the block offer inserted by TSO (cross trade enabled – matching of block contracts with hourly and quarterly contracts). The trade match time is 14:40.

Which data should be reported in this case to ACER?

3         Case3: TSO inserts buy offer for block contract 15:15 – 15:45 at 15:05 (in balancing phase) with BAL parameter. Other market participant inserts sell offer for the same contract at 15:06 with price and volume which fully match the offer inserted by TSO. The trade match time is 15:06 (in balancing phase).

Which data should be reported in this case to ACER?

1.  As is written in the TRUM, we are obliged to report offers and trades inserted/concluded outside the balancing phase. In this case, the block contract starts in the regular Intraday trading and ends in the Balancing phase.

Because we cannot divide the block contract into part of Intraday and part of Balancing phase we are planning to report both block offers and trades as is inserted/matched in the trading platform.

2.  In this case one block contract is matched with 3 hourly contracts and last hour of the block contract is in Balancing phase.

With the same reason as it mentioned on topic 1, we are planning to report all offers (block contract and 3 hourly contracts) and also all trades.

3.  Since offer and trade were submitted/concluded in a balancing phase it is our understanding that these market data will not be reported to ACER.


Answer:

We consider the interpretation provided above reasonable. Whenever a contract for balancing purposes cannot be separated from a contract for the supply, that contract should be reported as contract for the supply.

RSS_Icon Last update: 08/12/2017  

FAQs on transaction reporting – Question II.1.1.32

We are having some issues with the submission of back loading transaction as they are rejected by a validation rule.  Could the Agency clarify further if back loading transactions can still be reported to the ARIS system?


Answer:

Commission Implementing Regulation (EU) No 1348/2014 clearly establishes that details of wholesale energy products in relation to the supply of electricity and gas executed at organised market places, including matched and unmatched orders, entered into application as of 7 October 2015 and for any other transactions as of 7 April 2016.

The Commission Implementing Regulation also establishes that details of wholesale energy contracts which were concluded before the date on which the reporting obligation becomes applicable and remain outstanding on that date shall be reported to the Agency within 90 days after the reporting obligation becomes applicable for those contracts. Please see also paragraph 3.4 “Start of reporting and reporting frequency” in the TRUM available in the REMIT portal.

This means that back-loading of transactions concluded at organised market places was due by no later than 90 days after 7 October 2015 and 90 days after 7 April 2016 for any other transactions.

The Agency’s system was set to allow back loading of historical data skipping several validation rules. This was done through the submission of an XML file with a date in the filename prior (<) to the date of 5 Oct 2015 00:00:00Z. In this case most of the validation rules were ignored.

This was done to allow market participants to report their back-loading transactions even in those cases where they did not have the full set of information as required by Commission Implementing Regulation (EU) No 1348/2014 for reportable records of transactions, including orders to trade, entered into as 7 October 2015 and 7 April 2016.

However, the Agency had left open the back-loading channel for more than one year in addition to the deadlines set by the Commission Implementing Regulation: 90 days after 7 October 2015 and 90 days after 7 April 2016.

The Agency would like to take this opportunity to reiterate that any transaction executed at an organised market place has to be reported on T+1 day basis and any other transaction on a T+1 month basis and that any transaction reported 90 days after 7 October 2015 and 90 days after 7 April 2016 cannot and will not be considered back-loading, but rather late reporting.

In cases of late reporting, market participants and organised market places should liaise with their RRM as these regularly receive instructions on this topic from the Agency.

The Agency would like to remind that late reporting may constitute a breach of Article 8(1) of REMIT.

RSS_Icon Last update: 08/12/2017  

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

Data Field (1) and (8)

Some market participants place orders on screen on behalf of more than one legal entity.

For example, a trading house may has a US head office and a European subsidiary and they enter into master agreements with various trading counterparties with either the US head office or the European registered entity, depending upon the preference of the counterparty. US entities would for example contract with the US parent for example to be governed by US law whereas European entities would typically contract with the European based subsidiary.

A trader at one of these “double headed” companies places a single order onto the market. For every counterparty that has good credit with them the number appears tradable, but the resulting trade can end up as being between one of several entities. So a single order can result in a trade with a different “principal” depending on who the counterparty name is. The order is in effect placed on behalf of two (or more) legal entities. I can’t see a way in the schema of representing this.

Example – trader at DoubleCo that has 2 entities – Usco and EUco.

With counterparty A they have a master agreement between A and USco.

With counterparty B they have a master agreement between A and EUco.

DoubleCo initiates an order onto the market, and depending on whether it is aggressed by A or B determines whether there is a trade between USCo and A, or EUCo and B.

The difficulty is how to represent the single order that is on behalf of more than one entity.

USCo is not acting as an agent for EUCo, both USCo and EUCo would be principals to the trade. Company A would report a trade with USCo and company B would report a trade with EUco.

The suggestion would be that ACER accepts that for certain participants, that the idOfMarketParticipant reported for the order may not match the idOfMarketParticipant reported on the linked trade.

An alternative would be to update the schema to allow more than one participant ID on an order (but not on a trade, since we know the correct legal entity at this point).


Answer:

When market participants place orders to trade on broker platforms on behalf of more than one legal entity the Organised Market Place should decide or/and agree with their clients which market participant is placing the order for the reporting purpose. By placing an order the legal entity is a market participant even if it will not be a counterparty to the trade.

Data Field (1) ID of the market participant or counterparty, requires that the ID of the market participant or counterparty on whose behalf the record of transaction is reported shall be identified by a unique code.

In the Agency’s view, this means that market participants that place orders on the screen of the brokers or exchanges 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.

When a single order can result in a trade with a different “principal” depending on who the counterparty name is and the order is still placed on behalf of two (or more) legal entities, there is no need to indicate in the order report who is the beneficiary if and only if the beneficiary may be either the USco and EUco (as for the example above).

With regard to the trade, once it is clear to the Organised Market Place (and the market participant who placed the order) who is the beneficiary of the trade, this can be added in field (8) “Beneficiary ID” if this is different than the market participant reported in Field (1) “ID of the market participant or counterparty” in the order report. Please see the example below.

Firms Placing the order

(any of the three legal entities e.g. EUCo)

Matched orders Other side of the trade
EUCo EUCo and MP 1 MP 1
USCo EUco USCo and MP 2 MP 2
JPCo JPCo and MP 3 MP 3

 

The trade report should look like:

 Field # Case 1

EUCo and MP1

Case 2

EUCo and MP1

(alternative to case 1)

Case 3

USCo and MP2

Case 4

JPCo and MP3

#1 (ID MP) EUCo EUCo EUCo EUCo
# 4 (ID Other MP) MP 1 MP 1 MP 2 MP 3
# 8 (Beneficiary ID) EUCo USCo JPCo
#10 (Capacity) P A A A

 

RSS_Icon Last update: 08/09/2015  

FAQs on transaction reporting – Question II.2.1.2

Data Field (2)

Allowable format of BIC Codes.

The TRUM and XSD schema both show the BIC as being an 11 character field.

However, in the marketplace the BIC code is actually an 8 character reference, with an optional 3. And in ACER’s list of Participant’s

We suggest that the XSD be modified to allow BIC submission with a minLength of 8.

<xs:simpleTypename=”bic“>

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

<xs:maxLength value=”11“/>

<xs:minLength value=”118“/>

<xs:pattern value=[A-Za-z0-9_]+“/>

</xs:restriction>

As background, the BIC is made up by;

  • Business Party Prefix (4 Characters)
  • Country Code (2 Characters)
  • Business Party Suffix (2 Characters)
  • Optional Branch Identifier (3 Characters)

Numerous instances of 8 character BIC codes in the marketplace.  A small selection below for reference:

KRONDK22

NDEAFIHH

DABAFIHH

RABONL2U

OKOYFIHH

BREXPLPW

TATRSKBX

BAWAATW

Suggestion is that in order to successfully use BIC within the ACER XML schema, the validation on BIC should allow for a minimum of 8 characters (currently 11) and a maximum of 11.


Answer:

Our understanding is that the SWIFT code is 8 or 11 characters long. According to ISO 9362:2009 (dated 2009-10-01).

The SWIFT code is 8 or 11 characters long, made up of:

  • 4 letters: Institution Code or bank code.
  • 2 letters: ISO 3166-1 alpha-2 country code
  • 2 letters or digits: location code

If the second character is “0”, then it is typically a test BIC as opposed to a BIC used on the live network.

If the second character is “1”, then it denotes a passive participant in the SWIFT network

If the second character is “2”, then it typically indicates a reverse billing BIC, where the recipient pays for the message as opposed to the more usual mode whereby the sender pays for the message.

3 letters or digits: branch code, optional (‘XXX’ for primary office)

Where an 8-digit code is given, it may be assumed that it refers to the primary office and therefore should be reported as:

<bic>12345678XXX</bic>

RSS_Icon Last update: 08/09/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.4

Data Field (3)

Reference to documents: Annex IV to Transaction Reporting User Manual

Is it mandatory for OTC contracts, to fill Table 1, Field 3? In the examples provided by ACER, such fields are filled only for standard contracts and examples 15.2-18.2. What features of examples 15.2-18.2 are triggers for reporting this field? What is the understanding of the person concluding the contract in case of OTC market? Is it a person whose signature appears on the contract?

In our opinion, this field should not be required for contracts concluded OTC.


Answer:

Data Field (3) ID of Trader is required to be populated for any contract executed at organised market places and bilaterally as already indicated in the TRUM. For executions executed under the framework of non-standard contracts, examples are available in Section (2) of Annex II to the TRUM. The Agency would not expect this filed to be reported in line with the examples provided in Annex II to the TRUM.

RSS_Icon Last update: 26/09/2016  

RSS_Icon Subscribe to this Category’s RSS