Transaction Reporting User Manual (TRUM)
Guidance on reporting lifecycle events
The Agency developed guidance on reporting lifecycle events as Annex VII to the Transaction Reporting User Manual (TRUM). The instructions herein provided are based on the available documentation, such as the TRUM, FAQs on REMIT transaction reporting, Q&As on REMIT, the Agency’s own data analysis, as well as on numerous consolidated instructions provided as answers to questions received from MPs, RRMs and OMPs.
The Agency aims with this Annex to consolidate and clarify further lifecycle reporting requirements.
The current version of the guidance (v1.0) covers the reporting of lifecycle events for gas and electricity supply contracts and it may be amended in the future to provide guidance on transportation contracts.
Market participants and organised market places should bear in mind that it is their obligation to comply with REMIT ensuring that the Agency receives all data on REMIT transactions that should be reported in the correct format and compliant with the requirements stipulated by Commission Implementing Regulation (EU) No 1348/2014 and the TRUM.
The correct and timely reporting including lifecycle events is the obligation and responsibility of the market participant. 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 also the possibility to update initially reported records in case of lifecycle events that occur outside the venue. Market participants should be able to provide to the Agency all information about any changes in the reported data due to lifecycle events.
All REMIT reportable transaction events, from the start through all stages of the transaction lifetime up to the final act of the execution or cancellation of the transaction should be reported with the same diligence in order to provide timely and accurate details concerning the content and chronology of events.
- Transaction Reporting User Manual and Annex II
- ACER REMIT Information System Data Validation Document
- ARIS Data Validation Rules Configuration Document
1 Scope and purpose
The primary purpose of transaction reporting under REMIT is to enable the Agency and the NRAs to efficiently and effectively monitor trading activity in the EU wholesale energy market to detect and prevent suspected market abuse in order to fulfil the goal of increased integrity and transparency of wholesale energy markets. This is important in order to ensure confidence in the integrity of electricity and gas markets by the means that prices set on those markets reflect a fair and competitive interplay between commodity supply and demand, and that no profits can be drawn from market abuse.
It is important to stress that within the REMIT context, the subject of the specific trading activity is a contract that is underpinning any trading activity. A contract is a specific tradable instrument allowing market participants to trade a product under a specific condition on the specific market place or bilaterally at a defined time. Orders and trades can only occur against the contract. To a certain extent orders, trades and contracts traded bilaterally (if not specified, hereinafter referred as ‘transactions’) are exposed to changes due to their nature, business decisions of market participants or business events affecting them (company merges, bankruptcy etc.), market rules or events of the specific market places, (non)availability of certain information to be reported at the moment REMIT obligation to report is due etc. The need of changing initially reported transactions can also happen as a result of technical or other submission errors made in the reporting to the Agency’s REMIT Information System (ARIS). As a consequence of a change or a set of changes the reporting of a lifecycle of a transaction is triggered.
Given the diverse and vivid energy markets which involve variety of products and contract types, trading procedures and conditions, it is essential to have a common understanding on how the lifecycle event of such trading activities and scenarios shall be reported. As trading activities are based on several algorithms and performed at diverse IT systems, the Agency noticed that some patterns streaming from those IT system features can be observed in the REMIT reporting and might not be in line with the REMIT obligation and REMIT reporting instructions and guidance provided.
In short, all changes in a transaction that are reported to ARIS should resonate with the trading activities and trading circumstances and should accurately and coherently, from the chronological and content perspective, represent events triggered by business decisions or other underlying root causes.
In the future, the Agency plans to extend this guidance also to the reporting of lifecycle events of transportation contracts related to electricity and natural gas.
Annex VII to the TRUM aims to further complement the information provided in the TRUM on reporting lifecycle events and, thus these two guidance documents should be consulted together. Practical examples of frequently reported lifecycle events are provided in Annex II to TRUM.
2 Timeliness and exceptions to Table 1 and Table 2 lifecycle reporting
Timely reporting of the lifecycle events
Article 7 of the REMIT Implementing Regulation stipulates that any modification or termination of the concluded energy supply contract including orders to trade shall be reported to the Agency as soon as possible. With regards to the timeliness of the lifecycle reporting, if a new REMIT transaction is due to be reported one working day following the transaction, also all lifecycle events related to that transaction have to be reported on the same time basis, i.e. one working day following the modification or cancellation of standard supply contracts, trades or orders to trade. If the reporting is due to be reported after one month (e.g. non-standard contracts or executions), also the related lifecycle events have to be reported in the same time frame.
Exceptions in the reporting of lifecycle events
Market participants should note that reporting of lifecycle events under REMIT may differ from lifecycle events reported under other EU legislations. The following situations are not expected to be reported under REMIT as they are not considered activities related to the modification or cancelation of a transaction entered into a wholesale energy market: confirmation, compression, settlement (pre-settlement excluding early termination, and/or post-settlement activities such as also invoicing/payment transactions), notional increase/decrease (relative to commodity index transactions including derivatives), clearing or option exercise (for latter please consult clarifications in TRUM).
Also, even though a force majeure event is not a reportable event per se, if the terms of the contract are amended due to this event, or the contract is cancelled, then a lifecycle event reflecting that event should be reported.
Changing the Registered Reporting Mechanism (hereinafter: RRM,) which reports on behalf of the market participant, should not be regarded as a lifecycle event. Please note that there are no technical restrictions in regard to the reporting of a new record or the lifecycle events of the previously reported records to ARIS by a new RRM.
3 Introduction to Table 1 and Table 2 lifecycle reporting
Each REMIT reportable transaction should have a valid and active record (i.e. successful reported record) in the ARIS data base with the Action type N for ‘New’ as the first reported event in the sequence of the particular transaction events.
If any reportable change of the initially reported transaction happens, it represents a subsequent lifecycle event of that transaction and it is essential to bear in mind that the record which was previously sent has to be appropriately “recognized” and “complemented” with information by submitting a record reflecting a complete updated information (within this document such records are referred to as “corresponding records”). The Agency’s REMIT Information System Data Validation Document contains a description of the data validation rules used by ACER to ensure the basic validation of the reported transactions and their lifecycle events. Herein the intention is to summarize the fundamental rules and key data fields important for the lifecycle reporting.
The TRUM data fields that constitute a key which uniquely identifies a record reported in Table 1 (for all uses: orders, trades, bilateral contracts, executions), besides Field No (58) Action type, are: Field No (1) ID of the market participant; Field No (11) Buy/sell indicator; Field No (31) Unique transaction ID/Field No (13) Order ID; Field No (21) Contract ID; Field No (27) Organised Market Place ID/OTC and Field No (33) Linked order ID
For Table 2 the TRUM data fields constituting the key that uniquely identifies the record, besides Field No (45) Action type, are the following: Field No (1) ID of the market participant; Field No (3) ID of other market participant; Field No (10) Buy/sell indicator; Field No (11) Contract ID.
In general, to be able to report the lifecycle event of a previously reported transaction, the abovementioned relevant data fields (the key) should exactly match in the corresponding records (i.e. the content in the original record and the one intended to report the next lifecycle event should be the same) and it is not allowed to update (modify) these fields as lifecycle event
The possible Action types for lifecycle events reportable under Field No (58) for REMIT Table 1 and Field No (45) for REMIT Table 2 transactions are:
a) Action type N (new) should be used to report any new transaction;
Action type N (new) always indicates the first event in any transaction lifecycle.
Corresponding record with any other action type can be accepted in ARIS only if a record with Action type N (new) had been successfully reported previously.
c) Action type E (error) shall be used if the reporting party needs to indicate that the previously submitted record was erroneously reported, e.g. the previously reported record was wrong. Any correction to the already reported information using Action type E will result in a logical deletion (i.e. error-out or invalidation,) of the corresponding record which was successfully reported previously, but not in the removal of the previously reported record from the ARIS database. Reporting an event with Action type E cannot be the result of a business decision, for example to change the economic values such as price or quantity in the previously reported transaction record.
d) Action type M (modify) should be used in case reporting parties report a modification reflecting a business decision/business event affecting the transaction.
Reporting with the Action type M (modify) is triggered by a business decision or it is a result of a business event. For example, Action type M shall be used to modify an outstanding contract (e.g. modification of the delivery profile within the same Contract ID) or changing the status of an order to trade (e.g. modification of the order status and quantity after order has been partially matched).
Action type M (modify) indicates the corresponding transaction has been modified due to a business decision or as a result of a business event.
Action type M (modify) should NOT be used for correcting wrongly submitted information but Action type E (error) should be used for that purpose instead.
e) Action type C (cancel) should be used in case reporting parties intentionally report a business event that represents the early termination of an existing trade, bilateral contract or cancellation of an order, representing the end of the transaction lifecycle.
The Action type C (cancel) is also triggered by a business decision or it is a result of a business event. A record with Action type C represents the last event in the transaction sequence.
Examples for when to report Action type C (cancel):
- Permanent withdrawal of an order from the order book;
- Termination of an existing contract due to a novation.
Reporting of Action types entails prerequisites and rules which are important to follow in order to correctly report the sequence of records representing the transaction lifecycle, as presented in the summary below:
|Action type||Prerequisites||Meaning/sequencing||Transaction time / Unique transaction identifiers / XML content|
REMIT reportable event i.e. a new transaction.
Record with Action type N (new) is always the first reported record of any transaction and it is a prerequisite for reporting any other subsequent lifecycle event of a transaction (M, C or E).
If the uniquely identified transaction with Action type N is the only successfully reported record, it represents the current valid status of the transaction.
Table 1: Transaction timestamp in Data field No (30) should reflect the exact date and time of the transaction i.e. REMIT reportable event, e.g. exact date and time of the order activation.
Table 2: Contract date in Data field No (12) should reflect the exact date the contract was agreed.
Unique transaction identifiers
Unique transaction identifiers are in Table 1: Field No (13) Order ID, Field No (21) Contract ID, Field No (31) Unique transaction ID; in Table 2: Field No (11) Contract ID.
The unique identifier shall be unique as defined in TRUM and used through all reported lifecycle events of the transaction.
1. REMIT reportable business event related to the transaction, and
2. Existence of the valid and active corresponding record with either Action type N or M
Record with Action type M (modify) indicates the modification of the information provided in the corresponding record in the relevant fields reflecting the business decision.
If the uniquely identified transaction with Action type M is the last successfully reported lifecycle event, it represents the present valid state of the transaction. Record with Action type N or M can be further modified with a corresponding record with Action type M.
Table 1: Transaction timestamp in Data field No (30) should reflect the exact date and time of the business decision/event causing a need for the modification of the record, e.g. exact date and time of the matching order should be reported.
Table 2: Contract date in Data field No (12) should reflect the exact date when the modification of the contract was agreed.
In general, transaction time of the modified transaction as a result of a business event should be the same as or later than the transaction time reported in the corresponding valid record reported previous (with Action type N or M).
It is crucial to distinguish how to report transaction time in case of providing only additional information (e.g. Beneficiary ID when trading capacity of market participant is “A” and the Beneficiary ID was not previously known), and not reporting a new business event. Such an amendment should be reported with Action type M, but the transaction time should remain the same as provided within the previous corresponding valid record, and should not reflect the time when the missing information (e.g. Beneficiary ID) became available.
Unique identifiers of transaction
Unique transaction identifiers are in Table 1: Field No (13) Order ID, Field No (21) Contract ID, Field No (31) Unique transaction ID; in Table 2: Field No (11) Contract ID.
The unique identifier shall be unique as defined in TRUM and used through all reported lifecycle events of the transaction and in general cannot be modified by “M”. Exception to use “M” in order to modify UTI in Table 1: There is one exception in UTI modifications for bilateral trades (OMP=XBIL) referring to reporting within Table 1 with the timeline of T+1 day: If previousUniqueTransactionIdentifier (or additionalUTIInfo) is not empty, the UTI can be changed with M and different UTI would be used through further lifecycle event reporting. See FAQ 3.1.17
1. Business event that represents the cancelation of the transaction and
2.Existence of the valid and active corresponding record with either Action type N or M
Record with Action type C (cancel) indicates the business event of a cancelation or termination of transaction which can include reporting additional data such as the termination date of contract, if relevant.
If a uniquely identified transaction with Action type C is the last successfully reported lifecycle event, it represents the valid state of the transaction indicating that the transaction in question has completed its lifecycle.
Record with Action type C cannot be modified with Action type M or cancelled by another record with Action type C.
Table 1: Transaction timestamp (Data field No (30)) should reflect the exact date and time of the cancelation e.g. exact date and time of the order permanent withdrawal or expiration should be reported.
Table 2: Contract date (Data field No (12)) should reflect the exact date the contract cancelation was agreed.
The transaction time of the cancelled transaction should be the same or later then the transaction time reported within the previous corresponding valid record.
Unique identifiers of transaction (Table 1: Field No (13) Order ID, Field No (21) Contract ID; Field No (31) Unique transaction ID; Table 2: Field No (11) Contract ID)
As the transaction has completed its lifecycle, the unique identifier should not be re-used for identifying other transaction.
1.Detected wrongly submitted data to ARIS and
2. Existence of the valid and active corresponding record with either Action type N or M or C
Record with Action type E (error) indicates the invalidation of the corresponding record with the same transaction time. If the corresponding record with the earlier (different) transaction time exists and is not subsequently invalidated, it represents the present valid state of the transaction.
Scenarios for sequencing:
A. Record with Action type N followed by a record with Action type M which has the same transaction time
If the initial transaction with Action type N was modified by the record with Action type M having the same transaction time as N and then followed by the record with Action type E and the same transaction time, both records will be invalidated.
B. Record with Action type N followed by a record (or records) with Action type M which has a different transaction time
If the initial transaction with Action type N was modified by the record with Action type M having different transaction time than N and then followed by the record with Action type E having the same transaction time as M, only the record with Action type M will be invalidated. In this case the record with Action type N remains valid and further actions type can follow (see instructions for N above).
If both transactions – one with Action type N and one with Action type M are to be invalidated, two records with Action type E with two transaction times as provided in N and M records have to be sent.
Invalidating only the N record, while not invalidating the M record is not allowed and must be avoided.
The record with action type E needs to have the same Transaction time value (Table 1: Data field No (30) Transaction timestamp; Table 2: Data field No (12) Contract date) as the corresponding record that is to be invalidated.
Unique identifier transaction
After the invalidation with Action type E, when reporting a corrected record representing the same transaction (with action type N) the unique identifier (Table 1: Field No (13) Order ID, Field No (21) Contract ID; Field No (31) Unique transaction ID; Table 2: Field No (11) Contract ID) of the invalidated record can be re-used.
If to be reported, the corrected transaction with Action type N (re-using the unique identifier of the transaction and indicating the transaction time of the event) should be submitted in the same XML file as the record with Action type E.
The same principle of sending invalidation record (with Action type E) and subsequent corrected record (with Action type M or Action type C) within the same XML file applies.
4 Lifecycle events related to orders to trade
As stated in the TRUM an order record is a representation of an order to trade (bid or offer) submitted by a market participant or by an execution venue on behalf of a market participant and represents the willingness (commitment) to trade a specific contract under certain conditions.
How to report specific order lifecycle events
Data Field No (13) Order ID
Order ID should be unique for the contract and for the market place at which it was placed and should be consistently used through the reporting of all lifecycle events of the order. Once the lifecycle order has been reported with Action type C (cancel), the same Order ID can no longer be adopted for any further lifecycle event of that order and cannot be re-used for other order placed on the same OMP for the same Contract ID.
It is also required that trades resulting from matched orders refer to the corresponding Order ID by populating Data field No (33) Linked order ID in the TRUM. This is important also for the appropriate understanding of the trading cycle and lifecycle events.
Data Field No (30) Transaction timestamp
The timestamps of the lifecycle events with Action type N (new) should reflect the time when an order is activated by the system (this includes also implied orders) or by market participant and is visible to the market.
For the lifecycle events with Action type M (modify) the timestamp should reflect the time of the business decision/event, e.g. time of change due to refilling a volume or matching an order. If the order is partially matched in several consecutive steps, this should also be visible from the different timestamps of the order lifecycle records with Order status ‘PMA’ (for partially matched) in Data field (No) 16 and Action type M.
The Agency expects that orders that are partially or fully matched and the corresponding trades have the same timestamp reported in UTC. If the trade take place a few milliseconds/minutes after the orders have been matched this can be reported in the Execution Time (child element of the Data field No (30) Transaction timestamp of Table 1 XML schema.
In case of order reports that have been temporarily withdrawn at the end of the trading session (with Action type M) and have been re-introduced (Order status ‘ACT’ and Action type M) in the following session with the same Order ID (subject to order condition and market rules), it is expected that the Original Entry Time (child element of the Data field No (30) Transaction timestamp) will be populated with the timestamp when the order was entered in the market. The Transaction timestamp field itself would in this case reflect the new entry date and time for the latter session.
The timestamp of an order record reported with Action type C should reflect the cancelation or the expiration time (e.g. time of the permanent order withdrawal) and should be regularly reported if it cannot be derived from the order condition or the order duration. Please consult Chapter 3.2.
Data Field No (21) Contract ID vs Order ID
Orders as well as trades always refer to the tradable instrument i.e. specific contract (identified via Contract ID). As indicated in the TRUM, the description of field Contract ID is: “This field identifies the unique contract ID provided by the organised market place at which the contract is traded. The contract ID is venue-specific. The contract ID is needed to link all the orders to a specific contract.”
In case an order is initially referring to a “generic contract” and after the matching process the contract is replaced with a specific one entailing a different Contract ID, it is necessary to report the change. Reporting of such a lifecycle event shall be done by cancelling the order linked to a generic contract with Action type C, i.e. replacement of the underpinning contract with a specific and different one. The order with a new Order ID referring to the new contract (Contract ID) with Action type N shall be reported and same order ID should be used in the corresponding trade in Data field No (33) Linked Order ID.
Data Field No (11) Buy/Sell indicator
Field No (11) Buy/sell indicator reflects a fundamental characteristic of an order and if it is changed, it can be only reported as a cancelation (Action type C) of the existing order followed by a new order record (Action type N) with a different Order ID. If the IT system allows the change of the Buy/Sell indicator of an order, this is a functionality of the IT system and not the feature of the organized market place functioning. Therefore, such a change cannot be regarded as a modification of the existing order record but rather as a new order.
Data Field No (16) Order status
The complexity of an order lifecycle will be dependent on the characteristics of the order such as: Data Field No (14) Order type, Data Field No (15) Order condition, Data Field No (16) Order status and Data Field No (20) Order duration as well as on the business decisions in regard to price and quantity and rules of market players.
As stated in the TRUM, the Agency expects a single order status is reported within the record. If simultaneous events that are reflected in the order status happen, the expectation is that two records will be reported having the same transaction timestamps representing the time of the event.
In case an order has two order statuses (i.e. ACT and PMA) with the same timestamp and Action type E is needed in the record with PMA – how to identify such record?
At the moment it is not possible to invalidate only one order record (e.g. with order status PMA) if both order records have the same timestamp (and of course the same remaining fields of the key). Both order records will be invalidated by Action type E. In the example provided, the record with order status ACT will then have to be resubmitted. Combinations of common order statuses with action types and their meaning are presented in the following Table.
|Order status||Action type||Meaning|
|ACT||N||The first lifecycle event of an active order in a trading cycle sequence reflecting the initial status - activation of an order (initial price/quantity/conditions …)|
|ACT||M||Modification of a tradable order by the means of price/quantity or other business decision OR re-activation of a temporarily suspended order OR re-activation of a temporary withdrawn order, subject to market rules; the re-activation (same Order ID and Contract ID) can be combined with other modifications (price/quantity/ Original Entry Time etc.)|
|REF||M||Order status of tradable order when Quantity/Volume has been refilled from the Undisclosed Volume (Data field No (19)) as a consequence of the business decision and matching a disclosed/visible volume of the active order having the order condition HVO (Hidden Volume)|
|COV||M||Order status of tradable order reflecting the modification of the order type that has been changed from BLO (Block) or VBL (Variable Block) to a single order CON (Convertible) as a consequence of the business decision|
|PMA||M||An order is modified as consequence of matching process in which it was partially matched and is further tradable with remaining Quantity/Volume, if the order conditions and market rules are met|
|MAC||M||An order is modified as a consequence of matching process i.e. is full matched and is not any more tradable; the Quantity/Volume indicated in order with this status represents the matched Quantity/Volume|
|PMA||C||An order that was partially matched was cancelled due to the fact that for some reason has not originated a trade; the Agency expects this status only as an record reporting exceptional event|
|MAC||C||An order that was fully matched and was cancelled due to the fact that for some reason has not originated a trade; the Agency expects this status only as an record reporting exceptional event|
|WIT||M||An order has been temporarily withdrawn from the market by the participant (e.g. not tradable/visible on the screen i.e. deactivated), but can be re-activated subject to market rules and order conditions|
|WIT||C||An order has been permanently withdrawn from the market by the participant (e.g. having order duration GTC – Good Till Cancelled)|
|SUS||M||Order status indicating that it has been temporarily suspended from the trading by the system or the market operator (e.g. not tradable/visible on the screen any more), but can be re-activated subject to market rules and order conditions|
|SUS||C||An order has been permanently suspended from the trading by the system or the market operator (but not by the market participant)|
|EXP||C||Order status reflecting its expiration|
Order status ACT (active) with Action type N (new) in general indicates the first event in the order trading and lifecycle.
Fat finger error in order report
In case of the so called “fat finger” error (in regard to quantity, price, contract or other input) in the order report that has been erroneously submitted to the OMP, subsequently matched and resulted in a trade, the reporting entity should inform the Agency about the error via ARIS Central Service Desk (CSD) opening a contingency report indicating the scenario related to the data quality issue.
Reporting parties should open a contingency in case they are contacted by a market participant regarding the error and requesting the OMP to cancel the transaction(s). In this case, if parties agree to cancel the trade due to the error made within the order, the trade should be cancelled with action type C while order record should not be invalidated (with action type E) nor modified (with Action type M) but should remain as initially reported and visible to the market.
Orders that were activated (i.e. visible to the market) and originated trades should NOT be invalidated with Action type E (error), even if so called “fat finger” error occurs.
When and how to report the end of order lifecycle
When to report the end of order lifecycle
If an order has not been fully or at all matched and order expiration is not derivable from the order duration, it is necessary to report an order lifecycle event clarifying that the order is no longer on the market. An order status combined with Action type C should be reported.
How to report the end of order lifecycle
if an order is fully matched the end of its lifecycle is reported with order status MAC and Action type M. ARIS data statistics show that non-matched orders have most frequently the Order duration Good Till Cancelled (GTC) and are withdrawn from the trading/market having Order status WIT and Action type C. In case of the order expiration Order status EXP and Action type C shall be reported.
Regular combinations indicating the end of the order trading and its lifecycle are PMA/M, MAC/M, WIT/C and EXP/C.
An exception to the reporting of the order lifecycle end is the case when EXP/C is not required to be reported for orders with Order duration (Data field No (20)) or Order condition (Data field No (15)) from which expiration can be clearly derived.
However, in order to clearly derive the expiration of the order from order duration, the following applies:
|Accepted values of Data field No (20) Order duration||Additional fields to be populated||If the Additional field is not populated the following combination of Order status and Action type is expected to be reported as a final status of an order|
|Day (current day)||Last Trading date and time (Data field No (29))||EXP/C|
|SES (session or until gate closure)||Last Trading date and time (Data field No (29))||EXP/C|
|GTT (Good Till Time)||Expiration Date Time (child element of the TRUM Data field (20) Order duration)||EXP/C|
|GTD (Good Till Date)||Expiration Date Time (child element of the Data field (20) Order duration)||EXP/C|
|OTH (Other)||Expiration Date Time (child element of the Data field (20) Order duration)||EXP/C|
|GTC (Good Till Cancelled)||NA (as time is derived from the Transaction timestamp)||WIT/C|
However, even if the order expiration can be derived from the order duration the Agency still recommends to report the end of the order lifecycle with combination of the Order status and Action type as provided in the third column of the table above.
5 Lifecycle events related to trades
As stated in the TRUM, a trade report is a representation of any contract where two or more orders to trade were matched within an organised market place or an agreement on a bilateral trade which takes place off-market between two market participants.
The following text provides non-exhaustive examples of events which may occur after a trade has been reported to the Agency as new (Action type N) and provides guidance whether the event is reportable and if yes how to report lifecycle to trades and linked orders for standard contracts.
Trade records resulting from the matched orders referring to the standard supply contract shall always be reported with Action type N (new) and linked to the specific Order ID and referring to the underpinning contract.
If a reported trade is an execution (EXECUTION) of a non-standard contract, then the agreed Contract ID of the non-standard contract reported in Table 2 should be indicated in Field (32) Linked Transaction ID of the Table 1 execution report. The execution report should refer to the parameters and conditions agreed in the non-standard contract and is reported with Action type N, as well.
The lifecycle of a trade compared to that of an order involves less modifiable parameters as it is a steady arrangement represented by specific economic parameters traded at one defined point in time (one-off). Therefore, the Agency expects minor and only occasional modifications (Action type ‘M’) of the trade records.
How to report specific lifecycle events for trades
Data Field No (8) Beneficiary ID in REMIT Table 1
In case a trade report is to be updated with the Beneficiary ID, the expected way of reporting is described below according to different scenarios:
Action type M (modify) should be used in case the original trade report does not have the Beneficiary ID populated but has Data field No (10) Trading capacity of the market participant or counterparty populated with “A” for Agent. In this specific case, the record with Action type M must have the same timestamp as the last successfully reported record as providing missing information is not regarded as a new business event.
In case the Beneficiary ID was reported in the original trade report, but it needs to be amended for example due to the merger of two companies and consequent change of the ACER code of Beneficiary, this represents a type of novation. Therefore record with Action type C (cancel) shall be reported to indicate the cancelation of the deal with previously reported Beneficiary ID followed by reporting the trade record with a new Beneficiary ID and Action type N (new). In this case transaction timestamps should indicate the cancellation time agreement and time of the transaction with a new legal entity, respectively. Unique identifiers of aforementioned trades should be different.
There is no expectation to use the above mentioned lifecycle event(s) for the related matched orders.
Data Field No (3) ID of the trader and/or the market participant or counterparty as identified by the OMP
The change of Trader ID (Data field No (3) for the REMITTable1) does not represent a lifecycle event and there is no need to be reported as such.
Data Field No (25) Fixing index or reference price
If a price of the trade is fixed on the index or reference price (Data field No (25) for the REMIT Table1) and is not known at the time when the trade occurs, it is expected to report the trade referring to the fixed index and there is no expectation to report modification as the lifecycle event with the published price for the index once it is known.
Price and Quantity/Volume
According to the Agency’s understanding and referring to the standard contract trades (reported via REMIT Table 1) when price and quantity were already agreed, if during the delivery period two parties agree to amend the price and/or the quantity, this is a new transaction. The early termination with Action type C of the existing transaction should be reported first followed by the new transaction submission. The record with a different unique transaction identifier, new Contract ID, new price and quantity as well as relevant delivery period and Action type N should be reported. We do understand that market participants may understand this contract as the same underlying agreement. However, we believe this is in fact a new transaction executed at a different point in time, with different market information leading to different economics and only reporting it as new transaction correctly resonates the trading circumstances.
Cancellation of a trade (no effect on linked order previously reported)
If two orders match and result in a trade that is then cancelled or if for some reasons matched orders do not originate trade, it is not expected that order records are modified or amended while trade record might be cancelled with Action type C (e.g. due to the “fat error” issue in orders, not having available bilateral credit with counterparty or being prohibited from dealing with the counterparty or else).
Novation of the trade
The change of the counterparty as a legal entity (e.g. due to the company merges or selling company that was previous a part of the group i.e. intergroup contracts change the nature and become reportable or change of the ACER code of counterparty etc.) that entered into a trade/contract constitutes a case of novation. In this case all outstanding trades and contracts have to be novated with the new legal entity’s ID in order to notify the Agency about the change of the counterparty and report all outstanding or new events.
In order to report a novation, a cancelation of the corresponding record with Action type C and old Unique transaction identifier/Contract ID has to be done. In addition, the Transaction timestamp (Data field No (30) for the REMITTable1) shall indicate the day of the communication of the change of the legal entity, while the Termination date (Data field No (43) in REMITTable1) shall refer to the effective date of the change. A novated trade/contract with a new Unique transaction identifier/new Contract ID and Action type N should be reported referring to the new legal entity primarily in line with the timing of reporting transactions or as soon as the new ACER code is communicated to the counterparty. This process applies to both sides of the trade. If the novation has to be reported via so called “parallel channel” (e.g. due to termination of a market participant in CEREMP prior to the novation reporting) please consult ACER REMIT Information System Data Validation Document.
6 Lifecycle events related to standard and non-standard contracts
How to report specific contract lifecycle events
Data Field No (21) Contract ID for REMIT Table 1 and Data Field No (11) Contract ID for REMIT Table 2
Orders and trades executed on Organised Market Places are required to use the Organised Market Places’ contract ID (Data field No (21)) in the order and trade reports. Market participants or RRMs should not change or generate their contract ID in substitution of the contract ID used by the Organised Market Place for the reporting of orders to trade and trades. The Organised Market Place must have unique contract identifier not shared with any other contract and to be used for the lifetime of the tradable contract. The contract must always be represented by the same contract identifier throughout the lifecycle of the contract/order and contract/trade, i.e. up to the end date of delivery.
Similar principles shall be followed in case of a non-standard contract reported in Table 2. The Contract ID in Data field No (11) which is a unique identifier for the contract as assigned by the two market participants shall be used throughout the lifecycle (i.e. up to the end date of delivery) of the contract and the corresponding EXECUTION report(s) (reported in Data field No (32) Linked transaction ID of REMIT Table 1). Once the non-standard contract is reported to the Agency, any amendment to this contract should be reported as lifecycle event (modification) by using the same Contract ID of the original contract.
If reporting parties erroneously report Contract ID, they have to correct all the transaction records related to that contract. To do so, reporting parties have to first submit records with Action type E (error) for all related records (contracts/trades) in order to invalidate them, then resubmit all transactions with the corrected data i.e. correct Contract ID by using Action type N and report the timestamp reflecting the time at which the original trade/contract occurred.
Price and Quantity/Volume
Change in price and/or quantity of a trade under standard contract constitutes a new contract and the modification with Action type M of the existing contract is not allowed (see explanation under previous chapter).
Non-standard contracts, on the other hand, usually involve long-term (e.g. 5-10 year-long) agreements, therefore if the counterparties agree for example to increase the volume to be delivered or to amend the price index, they may amend the contract by reporting corresponding lifecycle event with Action type M.
Early termination of the contract and novation
In situations where the two counterparties may decide (e.g. due to the business decision or bankruptcy), to early terminate the contract prior to the end of the contract maturity this is in general reported via submitting a record with Action type C. Obligation to report such an event applies to both counterparties.
If the initial contract/trade is reported with REMIT Table 1, the termination should be reported with the corresponding record with Action type C. In addition, the Transaction timestamp in Data field No (30) shall indicate the termination agreement day, while the Termination date in Data field No (43) shall refer to the date when the contract ceases to exist.
In case of termination of a non-standard contract reported with REMIT Table 2, the reporting parties should submit a lifecycle event report related to the non-standard contract with Action type C (Data field No (45) “Action type” for Table 2). The report should also indicate the date when the cancelation of the contract was agreed in Data field No (12) Contract date. In order to indicate the effective termination date of the contract the data field Delivery end date the Data field No (43) should be populated.
The case of the change of the contract counterparty, including the Beneficiary (e.g. due to the fact that the legal entity has been terminated as REMIT market participant in CEREMP or has re-registered with another NRA or has been merged with another legal entity that become the owner of the contract) is consider a novation. The reporting pattern should follow instructions provided in the previous chapter Novation of the trade. Obligation to report such an event applies to both counterparties.
Additional content in the field Extra (function HasSubstring(field Extra, ‘FullSet’) can be considered when records are reported by OMP. Please refer to the ACER REMIT Information System Data Validation Document.
For any exception and/or instruction for the reporting via parallel channel, please refer to the ACER REMIT Information System Data Validation Document.