FAQs on transaction reporting – Question II.3.2.11 [DELETED]

The question (in previous edition: Question 3.2.10) was deleted due to duplication.

RSS_Icon Last update: 20/07/2018  

FAQs on transaction reporting – Question II.3.2.12

Data field (28)

ANNEX II – Table 1 Examples 4.01-4.04 for Bilateral trades off-OMP versus Table 1 Examples 1.02-23.02 for Executions of non-standard trades

For the examples of Table 1 for Bilateral trades off-OMP, Field 28 has been populated with “00:00Z/24:00Z” which is in line with guidance in the TRUM.

However for examples of Table 1 for Execution trades, Field 28 has been left blank.

So that we can programme our systems in a consistent manner to populate this field for Table 1 under Phase 2, is it acceptable to always populate this field with “00:00Z/24:00Z”  regardless of whether the Table 1 is a bilateral or an execution trade?


Field 28 should be populated with “00:00Z/24:00Z” in line with the guidance in the TRUM. However, when Table 1 is used for the reporting of execution under the framework of non-standard contracts, Field (28) can be left blank as indicated in the examples available in Section II of Annex II to the TRUM.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.2.13

Data field (28) and (29)

In the fields “First fixing date” and “Last fixing date”, our understanding is to report the first and the last date of application of the price index within the contractual period, coherently with the example (e.g. If the XYZ index is used to calculate the price from the 1/03/16 to the 1/09/16, the 2 dates will be respectively the first and the last fixing dates). Furthermore, regarding field “Fixing frequency” our understanding is to report the frequency related to the publication of the index values from the provider. Is our interpretation correct?


As stated in the Transaction Reporting User Manual (TRUM), market participants have to use the “First fixing date” and “Last fixing date” fields to report the first date and last date, respectively, at which the price of the contract can be set using the index indicated in field 25 (fixing index).

If the contract has several indexes and each of them are used to set the contract price, then market participants shall report the first date at which the price of the contract can be fixed for each index reported in field 25 (fixing index). Same applies to “Last fixing date”.

With regard to “Fixing frequency” this field identifies the frequency of the fixing of the index for the contract price.  For example, a contract price can be set on the basis of an index that is used daily or on the basis of an index that it is used monthly.

RSS_Icon Last update: 16/02/2016  

FAQs on transaction reporting – Question II.3.2.14

Data field (30)

Reference to documents: TRUM, Annex 2, Table 15.02 – field 30 (non-standard contracts and transactions) All details of transaction executed within the framework of non-standard contracts specifying at least an outright volume and price are not necessarily available to both parties to the contract at the latest by the invoicing date (if we refer to the invoice issuance date). Indeed there may be a significant time gap (sometimes over 30 days) between the date where a producer issues its invoice and the date where the buyer actually receives it. Our below proposal aims at preventing from any breach of timely reporting due to a counterparty. We are requested by our NRA to check with ACER this would not create any operational issues.

For instance, a producer issues an invoice on 2nd February, however this invoice is only sent to the buyer on 28th February and received on 3rd March.

In that situation, the buyer will have all the details of the transaction only from 3rd March and will not therefore be able to use the invoice issuance date. The seller does not have any visibility of the date the invoice will be received and is not able to use the invoice reception date to populate the field.

We noted that ACER publicly stated at several times (in particular at the workshop of January 27th) that the reported transaction timestamps do not need to be the same for both parties.

Besides, during our meeting of January 8th, our NRA confirmed it does not use field 30 for reconciliation purposes unlike the fields related to the price, volume and delivery dates.

In this respect, as a buyer, we intend to populate field 30 with the invoicing reception date and expect sellers (producers) to populate this field with the date of issuance of the invoice.

Our NRA agrees with this methodology, but requested us to check with ACER this would not create any operational issues.


In the examples illustrated in Annex II to the TRUM it is indicated that the time and the date of the EXECUTIONS may be different between market participants. Market participants should report their EXECUTIONS concluded under the framework of non-standards contract within one month from when they know their price and quantity. In those circumstances where market participants do not know the price and volume until they receive the invoice from their counterparty, they should report their EXECUTION within one month from the receipt of the invoice.

RSS_Icon Last update: 26/04/2017  

FAQs on transaction reporting – Question II.3.2.15

Data field (42)

Reference is made to the lifecycle event for Non Standard contracts and in particular to amendment of long-term contracts where there is no delay in the start of the delivery. When a MODIFY for TAB2 is submitted which value for Field 42 (Delivery start date) should be used?

  1. Should the field be populated with the date since which the amendment is effective or;
  2. Should the field always maintain the same value (date) as the one that was reported for the NEW lifecycle event


Transaction Reporting User Manual (TRUM)

Practical Example:

In case ACER guidance is for 2) we highlight the risk that, since normally the long term contract’s formula (if contract price is one of the contractual sections affected by the amendment) becomes retroactively effective since the date of effectiveness of the amendment, maintaining in Field 15a also the previous info for such formula (that was valid previously) and the text describing the time switches, could soon saturate the 1000 characters currently allowed. Again, in option 2), could it be acceptable that Field 15a only reports the price formula valid due to the last amendment originating the MODIFY (with an explicit info stating the first day in which such formula is valid) and that also information in Fixing Indexes and Volume Optionality be reported with sole reference to the last amendment originating the MODIFY event?


In the Agency’s view, when an amendment of a long-term contract has to be reported, the modified record should be submitted with the Action type “M” (‘Modify’) and should include the same delivery start date in Field 42 and the new price formula in Field 15. The ‘explicit info stating the first day on which such formula is valid’ can also be reported in Field 15.

RSS_Icon Last update: 20/07/2018  

RSS_Icon Subscribe to this Category’s RSS