Annex VII
Guidance on reporting lifecycle events
| Version | Effective Date |
|
Annex VII Version 1.1 |
16 November 2022 |
|
Annex VII to the Transaction Reporting User Manual (TRUM) represents ACER’s guidance on the reporting of lifecycle events. The instructions provided herein are based on the available documentation, such as the TRUM, FAQs on REMIT transaction reporting, Q&As on REMIT, ACER’s own data analysis, as well as numerous consolidated instructions provided as answers to questions received from market participants (MPs), registered reporting mechanisms (RRMs) and organised market places (OMPs). With this Annex, ACER aims to consolidate and clarify further lifecycle reporting requirements. The current document covers the reporting of lifecycle events for gas and electricity supply contracts. Market participants and organised market places should bear in mind that it is their obligation to comply with REMIT ensuring that ACER receives all data on REMIT transactions in the correct format and in compliance 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 participants. Market participants should be able to provide to ACER all the information about any changes in the reported data that are due to lifecycle events. All REMIT reportable transaction events, from the start and through all the 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. |
Related documents:
- 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.
For records reported in Table 1, the following TRUM data fields constitute the key which uniquely identifies the record reported in Table 1 (for all uses: orders, trades, bilateral contracts, executions)[1]:
- Data Field (58) Action type
- Data Field (1) ID of the market participant
- Data Field (11) Buy/sell indicator
- Data Field (31) Unique transaction ID (for trade records)
- Data Field (13) Order ID (for order records)
- Data Field (21) Contract ID (for order and trade records)
- Data Field (27) Organised Market Place ID/OTC
- Data Field (33) Linked order ID
For Table 2 the following TRUM data fields constitute the key:
- Data Field (45) Action type
- Data Field No (1) ID of the market participant
- Data Field (3) ID of other market participant
- Data Field (10) Buy/sell indicator
- Data Field (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), except Data Field Action Type, 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[2]
The possible Action types for lifecycle events reportable under Data Field (58) for REMIT Table 1 and Data Field (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. |
b) 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. |
c) 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 the 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;
- Early termination of an outstanding contract;
- Termination of an existing contract due to a novation.
|
Action type C (cancel) indicates the last event in the transaction sequence as triggered by a business decision or as a result of a business event. Action type C (cancel) should NOT be used for deleting wrongly submitted information but Action type E (error) should be used for that purpose instead. |
d) 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 incorrect. 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 previously successfully reported, but will not remove 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.
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 |
|---|---|---|---|
| N (new) |
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. |
Transaction time Table 1: Transaction timestamp in Data Field (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 (12) should reflect the exact date the contract was agreed. Unique transaction identifiers Unique transaction identifiers are in Table 1: Data Field (13) Order ID, Data Field (21) Contract ID, Data Field (31) Unique transaction ID; in Table 2: Data Field (11) Contract ID. The unique identifier shall be unique as defined in TRUM and used through all reported lifecycle events of the transaction. |
| M (modify) |
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. |
Transaction time Table 1: Transaction timestamp in Data Field (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 (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: Data Field (13) Order ID, Data Field (21) Contract ID, Data Field (31) Unique transaction ID; in Table 2: Data Field (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 |
| C (cancel) |
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. |
Transaction time Table 1: Transaction timestamp (Data Field (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 (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: Data Field (13) Order ID, Data Field (21) Contract ID; Data Field (31) Unique transaction ID; Table 2: Data Field (11) Contract ID) As the transaction has completed its lifecycle, the unique identifier should not be re-used for identifying other transaction. |
| E (error) |
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. |
Transaction time The record with action type E needs to have the same Transaction time value (Table 1: Data Field (30) Transaction timestamp; Table 2: Data Field (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: Data Field (13) Order ID, Data Field (21) Contract ID; Data Field (31) Unique transaction ID; Table 2: Data Field (11) Contract ID) of the invalidated record can be re-used. XML Content 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 it represents the willingness to trade a specific contract under certain conditions.
4.1 How to report specific order lifecycle events
4.1.1 Data Field (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 (i.e. Action type C indicates the end of the order’s lifecycle, therefore after sending the cancellation the order cannot be further modified). Additionally, the same Order ID cannot be re-used for another 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 (33) Linked order ID in the TRUM. This is important also for the appropriate understanding of the trading cycle and lifecycle events.
4.1.2 Data Field (30) Transaction timestamp
The timestamp of the lifecycle events with Action type N (new) should reflect the time when an order was activated by the system or by the 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 (16) and Action type M reported for the remaining quantity of the order left for trading.
ACER expects that orders that are partially or fully matched and the corresponding trades have the same timestamp reported in UTC. If the trade takes place a few milliseconds/minutes after the orders have been matched, this timestamp (different from the transaction time) can be reported in the Execution Time field of the trade report available in the REMITTable 1 schema (executionTime child element of the Data Field (30) Transaction timestamp).
In case of order reports that have been temporarily withdrawn at the end of the trading session (reported with Order status ‘WIT’ and Action type M) and have been re-introduced in the following session with the same Order ID and reported with Order status ‘ACT’ and Action type M (being subject to order condition and market rules), reporting parties may decide to populate the Original Entry Time field of the order report available in the REMITTable 1 schema (originalEntryTime child element of the Data Field (30) Transaction timestamp) with the timestamp indicating the time when the order was originally entered in the market. The Transaction timestamp field itself would in this case reflect the new entry date and time for the latter session (i.e. when the order was re-introduced).
The timestamp of an order record reported with Action type C should reflect the cancelation (e.g. the time of the permanent order withdrawal) or the expiration time of the order. Action type C should be reported if the end of the order’s lifecycle cannot be derived from the information indicated under order condition or the order duration. For more information, please consult Chapter 3.2.
4.1.3 Data Field (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 this change. Reporting of such a lifecycle event shall be done by cancelling the order linked to a generic contract with Action type C and by reporting an order with a new Order ID referring to the new contract (Contract ID) with Action type N. The same new order ID should also be used in the corresponding trade in Data Field (33) Linked Order ID.
4.1.4 Data Field (11) Buy/Sell indicator Data Field (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.
4.1.5 Data Field (16) Order status
The complexity of an order lifecycle will depend on the characteristics of the order such as: Data Field (14) Order type, Data Field (15) Order condition, Data Field (16) Order status and Data Field (20) Order duration as well as on the business decisions in regard to price and quantity and rules of market players.
Data Field (16) Order status is a mandatory field for all orders.
As stated in the TRUM, ACER expects a single order status is reported within the record. If two simultaneous events that are reflected in the order status happen, the expectation is that two records, one per each status, will be reported having the same transaction timestamps representing the time of the event.
An exception to the guidance above is possible, but only when the multiple order statuses are the result of one business decision and one order status is sufficient to explain the changes in an order. For example, for an order where partial matching and automatic refilling from the hidden quantity occur simultaneously (typical for Iceberg orders), only one order record is expected to be sent to ARIS with order status ‘PMA’ for ‘Partial matched’. In this case the indication of order status ‘REF’ for ‘Refilled’ is not requested.
4.1.6 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 | In general, 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 …) |
| MAC | N | The first lifecycle event of an order represents a matched order. The order will not be visible to the market as active order, as it gets matched immediately. This event may occur in case of orders traded on screen (e.g. on broker platforms) when the market participant is aggressing the initiator’s order. |
| WIT | N | The combination is applicable for withheld orders. Withheld orders are inactive orders inserted in the order book. Upon their activation they become active orders, which are to be reported with order status ‘ACT’ and action type ‘M’. ACER does not request that such withheld orders are reported under REMIT, however it aims to facilitate the REMIT reporting for those reporting parties who are entering into transactions related to such orders. |
| 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 (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 COV (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. |
4.1.7 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 ACER 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. However, the order record should remain as it was initially reported and made visible to the market, and it should not be invalidated (with action type E) nor modified (with Action type M).
|
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. |
4.2 When and how to report the end of order lifecycle
4.2.1 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.
4.2.2 How to report the end of order lifecycle
The reporting of the end of the order’s lifecycle to ARIS depends on different scenarios, such as the order was removed from the market because it was fully matched, the market participant/system/market operator removed it from the market, or the order expired.
|
Regular combinations indicating the end of the order trading and its lifecycle are PMA/M, MAC/M, WIT/C and EXP/C. |
If an order is fully matched, then the end of its lifecycle is reported with order status MAC and Action type M. In case the order was removed from the market as a result of the market participant’s action, the last order record should have Order status WIT and Action type C. This is also mandatory for orders reported with Data Field (20) Order duration GTC (good till cancelled).
In case the order expired because it had reached its duration, the last order record representing the end of the order lifecycle should be reported with Order status EXP and Action type C.
An exception to such reporting are orders where the expiration date and time can be clearly derived from other fields reported within the record.
In order to clearly derive the expiration of the order from order duration, the following applies:
| Accepted values of Data Field (20) Order duration | Reference fields to identify the expiration of the order | If the Reference 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) | The expiration time is derived from the Transaction timestamp of the first record of the order reported with Action type N | - |
| SES (session or until gate closure) | Last Trading date and time (Data Field (29)) | - |
| GTT (Good Till Time) | Expiration Date Time (child element of the TRUM Data field (20) Order duration in REMITTable 1 schema) | EXP/C |
| GTD (Good Till Date) | Expiration Date Time (child element of the Data field (20) Order duration in REMITTable 1 schema) | EXP/C |
| OTH (Other) | Expiration Date Time (child element of the Data field (20) Order duration in REMITTable 1 schema) | EXP/C |
| GTC (Good Till Cancelled) | The expiration time is derived from the Transaction timestamp of the last record reported with Action type C | WIT/C |
However, even if the order expiration can be derived from the order duration, ACER still recommends to report the end of the order lifecycle with combination of the Order status EXP and Action type C.
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 Data 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. See the following chapter for more details.
5.1 How to report specific lifecycle events for trades
5.1.1 Data Field (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 (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.
5.1.2 Data Field (3) ID of the trader and/or the market participant or counterparty as identified by the OMP
The change of Trader ID (Data Field (3) for the REMITTable1) does not represent a lifecycle event and there is no need to be reported as such.
5.1.3 Data Field (25) Fixing index or reference price
If a price of the trade is fixed on the index or reference price (Data Field (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.
5.1.4 Price and Quantity/Volume
According to ACER’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. ACER understands that market participants may consider 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.
ACER is aware that in some cases counterparties to a trade might decide to modify the quantity right after the conclusion of the trade but before the start of the delivery period at the organised market place where the trade was concluded. Since the change in the quantity occurred before delivery and was visible to the market, it is expected to be reported as modification with Action type M. On the other hand, if the modification occurs outside the organised market place, then an early termination with Action type C of the existing trade should be reported first, followed by a new transaction submission with Action type N by indicating the modified quantity, even if the modification took place before delivery.
5.1.5 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 the trade records shall 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).
5.1.6 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 ACER 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 (30) for the REMITTable1) shall indicate the day of the communication of the change of the legal entity, while the Termination date (Data Field (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
6.1 How to report specific contract lifecycle events
6.1.1 Data Field (21) Contract ID for REMIT Table 1 and Data Field (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 (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 (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 (32) Linked transaction ID of REMIT Table 1). Once the non-standard contract is reported to ACER, 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.
6.1.2 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.
6.1.3 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 (30) shall indicate the termination agreement day, while the Termination date in Data Field (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 (45) ‘Action type’ for Table 2). The report should also indicate the date when the cancelation of the contract was agreed in Data Field (12) Contract date. In order to indicate the effective termination date of the contract the data field Delivery end date the Data Field (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 considered 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.
Version history
| Version | Effective Date |
|
Annex VII Version 1.0 |
30 June 2020 |
[1]Additional content in the field Extra (function HasSubstring(field Extra, ‘FullSet’) can be considered when records are reported by an OMP. Please refer to the ACER REMIT Information System Data Validation Document.
[2]For any exception and/or instruction for the reporting via parallel channel, please refer to the ACER REMIT Information System Data Validation Document.