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  

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

Reference:

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?


Answer:

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  

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.


Answer:

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

Data field (24) to (30)

Reference to documents: TRUM – Table 2 Reporting – Fixing Index Details (Fields 24-30)

Are FX indexes reportable under this section of Table 2?

If we have transaction to deliver physical gas, with the GBP or EUR price payable linked to a complex formula of USD Oil, the formula will contain a FX conversion index such as Bank Of England reference rate. Is that FX index also reportable as a fixing index under this section of Table 2?

Example 9.01 in Annex II would seem to suggest the answer is no.

Based on Example 9.01, our interpretation is that the answer is No. Could ACER confirm this explicitly as we would like to understand why FX indexes are treated differently from oil commodity indexes, and therefore if there is anything else that is not reportable under this section?


Answer:

In the FAQs document the Agency has already indicated that there is no need to report an FX index in the fixing index details session (fields 24 to 30 of Table 2). If any FX index has to be reported, it can be reported in the formula. Only indexes related to the energy commodity should be reported in the fields from 24 to 30 of Table 2. This would include also oil and coal or any other energy commodity to fix the price of gas or electricity.

Examples of non-standard contracts reportable with Table 2 and available in Annex II to the TRUM, such as 9.01-13.01-14.01-25.01, were provided to the Agency by market participants. These examples clearly indicate that, in the industry’s view, Oil Index and Coal Index should be reported.

RSS_Icon Last update: 26/09/2016  

FAQs on transaction reporting – Question II.3.2.8

Data field (24)

Reference to documents: Transaction Reporting User Manual, page 91

Is it mandatory, to fill Table 2, Field 24? If not, what are the features of the contract that release the obligation to report this information? TRUM shows a list of possible values to fill – it allows “Other”, suggesting that this field covers any situation that may occur in practice. Moreover, description does not include any exceptions concerning reporting obligation, which took place in many other fields (in such cases ACER stipulated, that the data are not required if certain conditions are met). On the other hand, i.e. example 2.01 (p. 182 of Annex II to TRUM) field is left blank, indicating existence of specific features of the contract, for which the field may be left blank. We expect the field to be obligatory, despite missing values in provided examples.


Answer:

Table 2 field 24 is NOT a mandatory field in the XSD schema and it should be used according to the examples provided in Annex II to the TRUM.

RSS_Icon Last update: 26/09/2016  

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?


Answer:

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

Data field (24) to (31)

Table 2 Fields 24 to 31 – Data fields related to fixing index details

For non-standard trades with the delivery price linked to a formula, if the formula includes an FX index used to convert the currency of the fixing into the currency of settlement, does that FX index need to be reported in this section.

Annex II: Example 9.01 – Oil Index Gas Physical Formula Deal.

The above example in the TRUM would imply the answer to this question is NO – i.e. you do not have to report FX indexes in this section.

Could ACER explicitly confirm this and detail any other types of indexes or fixings that would NOT need to be reported in this section (if any)?


Answer:

There is no need to report an FX index in the fixing index details session (fields 24 to 30 of Table 2). If any FX index has to be reported, it can be reported in the formula. Only indexes related to the energy commodity should be reported in the fields from 24 to 30 of Table 2.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.2.7

Data field (21)

Table 2 Field 21 – Volume optionality

How do we differentiate between “C” for Complex and “O” for Other?

Especially as there are no examples in the TRUM that use “O”.


Answer:

From the Agency’s point of view, “C” for Complex should cover all the cases where the volume optionality cannot be classified as one of the non-Complex options (i.e. Variable, Fix or Min/Max). We are currently not aware of any possible use of “Other”.

RSS_Icon Last update: 24/03/2016  

FAQs on transaction reporting – Question II.3.2.2

Data field (11)

Frequently Asked Questions (FAQs) on REMIT transaction reporting – II.2. Questions related to standard contracts Question 2.1.26

The question addresses the issue of assigning a UTI for back loaded standard contracts and states that as the field is mandatory that a UTI is required, but that this doesn’t have to match with the other market participant.

Under the obligation to report non-standard contracts, there is the same issue with regards to the Contract ID for contracts that are subject to back loading; as such the same logic should apply.

Party A and Party B have to report a non-standard contract that is subject to the back loading requirement. As this contract was in existence prior to the obligation to report, a Contract ID will not have been allocated to the contract.


Answer:

Non-standard contracts that are subject to the back loading requirement under REMIT should be reported with a Contract ID, but there would be no expectation that the Contract ID used will match between the two market participants for back loaded contracts.

The Contract ID is required because otherwise the market participant will not be able to link the executions to the contract. The Contract ID can be anything the market participant would like to submit as long as it is unique to the market participant and does not need to match the Contract ID of the other market participant.

RSS_Icon Last update: 24/03/2016  

RSS_Icon Subscribe to this Category’s RSS