ACER REMIT – Quantity Information Reporting (Inline, full)

ACER REMIT: Analysis of Quantity Information Reporting Proposals

Table of Contents

  1. Introduction
  2. Data Quality Issues
  3. Current Rules (TRUM Annex VII)
  4. Proposed Changes
  5. Example Comparisons
  6. Impact on Reporting
  7. Applicability of New Rules
  8. Conclusions
  9. Glossary of Terms
  10. Appendices
  11. Conclusion

Introduction

ACER (Agency for the Cooperation of Energy Regulators) has identified persistent data quality issues in reporting for partially matched orders (PMA - Partially Matched Orders) under REMIT (Regulation on Energy Market Integrity and Transparency) regulation.

Document Purpose: To explain current issues and proposed solutions for improving quantity information reporting on EU energy markets.


Data Quality Issues

Current Situation

ACER has consistently observed data quality issues in Table 1 reporting for partially matched orders (PMA), including cases involving:

  • Undisclosed volume
  • Refilled volume

Identified Inconsistencies

For PMA orders, there is inconsistency in reporting modified quantity:

Approach Correctness Description
Reporting remaining quantity CORRECT Aligns with order logic
Reporting matched quantity INCORRECT Creates confusion
Matched quantity + additional modification for remainder INCORRECT Unnecessarily complicates reporting

Current Rules

TRUM Annex VII: Order Statuses

Main Statuses and Action Types

Order Status Action Type Meaning
ACT (Active)N (New)First lifecycle event - order activation
ACT (Active)M (Modified)Order modification by price/quantity
MAC (Matched)N (New)Order matched immediately
MAC (Matched)M (Modified)Order fully matched, no longer tradable
MAC (Matched)C (Cancelled)Fully matched order cancelled (exceptional event)
PMA (Partially Matched)M (Modified)Order partially matched, remains tradable
PMA (Partially Matched)C (Cancelled)Partially matched order cancelled
REF (Refilled)M (Modified)Quantity refilled from hidden volume

Current Data Field Structure

Data Field (40) - Quantity/Volume: Single simple field with value and unit
— Does not separate matched, visible, and undisclosed quantities.

Data Field (41) - Total Notional Contract Quantity: Single simple field with value and unit — mandatory for all orders.

Data Field (19) - Undisclosed Volume: Applies to orders with HVO (Hidden Volume) condition.

Problem with Current Approach

The current system has no clear way to simultaneously reflect:

  1. How much was matched
  2. How much remains visible for trading
  3. How much remains hidden

This leads to different interpretations and inconsistent reporting among market participants.


Proposed Changes

1. Revised REMIT Regulation

New description for Data Field (40) Quantity/Volume:

  • Number of units remaining available and visible for trading
  • Number of undisclosed units
  • Number of matched units

2. New XSD Schema Structure

OrderList

The quantity field now contains three components:

<quantity>
  <Matched>
    <value>10</value>
    <unit>MW</unit>
  </Matched>
  <Visible>
    <value>5</value>
    <unit>MW</unit>
  </Visible>
  <Undisclosed>
    <value>0</value>
    <unit>MW</unit>
  </Undisclosed>
</quantity>

Similarly for Total Notional Contract Quantity

<totalNotionalContractQuantity>
  <Matched>
    <value>10</value>
    <unit>MWh</unit>
  </Matched>
  <Visible>
    <value>5</value>
    <unit>MWh</unit>
  </Visible>
  <Undisclosed>
    <value>0</value>
    <unit>MWh</unit>
  </Undisclosed>
</totalNotionalContractQuantity>

3. Updated Rules for Data Field (19)

Undisclosed Volume: Field applies to orders with HVO condition. If PMA order has no hidden volume, value 0 (zero) shall be reported in this field.

4. TradeList (remains unchanged)

Trade reporting structure remains simple:

<quantity>
  <value>10</value>
  <unit>MW</unit>
</quantity>

Example Comparisons

Example 2.22: FAK Order with Partial Match

FAK (Fill-And-Kill) - "Fill-And-Kill" condition

Scenario

  • Order placed for 15 MW
  • 10 MW matched
  • 5 MW remaining (order cancelled per FAK condition)

Current Reporting (TRUM Annex II v5.1)

T1: Order N + ACT (New active order)

FieldValue
40. Quantity/Volume15 MW
41. Total Notional Contract Quantity15 MWh

T2: Order M + PMA (Partially matched)

FieldValue
40. Quantity/Volume5 MW (remainder only)
41. Total Notional Contract Quantity5 MWh

Trade

FieldValue
53. Quantity/Volume10 MW
54. Total Notional Contract Quantity10 MWh

Problem: From the order record it's unclear how much was matched. Only the remainder is visible (5 MW).

Proposed Reporting

Field Matched Visible Undisclosed
53. Quantity/Volume10 MW5 MW0 MW
54. Total Notional Contract Quantity10 MWh5 MWh0 MWh

Advantage: Complete picture of order state: ✅ Matched: 10 MW ✅ Remaining visible: 5 MW ✅ No hidden: 0 MW


Example 2.21: Iceberg Orders

Iceberg order - order with HVO (Hidden Volume Order) condition, where part of the volume is hidden from market and automatically refills the visible part after execution.

Scenario

  1. Order placed: 15 MW visible + 15 MW hidden
  2. 5 MW visible matched
  3. Automatic refill: 5 MW moves from hidden to visible

Proposed Reporting

FieldMatchedVisibleUndisclosed
Quantity/Volume (Stage 1: N+ACT)15 MW
Total Notional Contract Quantity11160 MWh
Quantity/Volume (Stage 2: M+ACT with HVO)015 MW15 MW
Total Notional Contract Quantity011160 MWh11160 MWh
Quantity/Volume (Stage 3: M+PMA with HVO)5 MW10 MW15 MW
Total Notional Contract Quantity3720 MWh7440 MWh11160 MWh
Quantity/Volume (Stage 4: M+REF with HVO)015 MW10 MW
Total Notional Contract Quantity011160 MWh7440 MWh

Trade: 5 MW / 3720 MWh

Advantage: Complete transparency — execution visible (5 MW → 0 after REF); visible volume refill (10 → 15 MW); hidden volume decrease (15 → 10 MW).


Example 2.54: Order Lifecycle with REF

Current Problem

In the current schema, when simultaneous partial match and automatic refill from hidden volume occur, there's a dilemma: which status to indicate: PMA or REF? How to reflect both events simultaneously?

Proposed Solution

Rule: When one business decision leads to multiple simultaneous events (e.g., PMA + REF for iceberg orders), only status 'PMA' is sufficient. Indication of status 'REF' is not required.

The new structure with three components (Matched/Visible/Undisclosed) allows both events to be reflected in one record:

Field Matched Visible Undisclosed
Quantity 5 MW (matched) 15 MW (refilled) 10 MW (decreased)

Impact on Reporting

Advantages of Proposed System

  • ✅ Complete picture of order state at any point in time
  • ✅ No ambiguity in data interpretation
  • ✅ Ability to accurately reconstruct order lifecycle
  • ✅ Improved ability to detect manipulation
  • ✅ Better market liquidity analysis and hidden volume insights

Disadvantages and Challenges

  • ⚠️ More rows in reports for some scenarios
  • ⚠️ Increased XML file sizes
  • ⚠️ Need to adapt participants' IT systems
  • ⚠️ Development and testing costs
  • ⚠️ Staff training on new rules
  • ⚠️ Transition and validation efforts

Risk Mitigation

  1. Webinars for market participants
  2. XML examples for all typical scenarios
  3. Updated TRUM guidance with detailed instructions
  4. Validation rules for automatic verification

Applicability of New Rules

When to Use New Structure?

  1. Partial match (PMA) of any order
  2. Orders with hidden volume (HVO)
  3. Iceberg orders
  4. Orders with undisclosed volume
  5. Volume refill (REF) from hidden part
  6. Any combination of the above scenarios

When NOT to Use?

For simple orders without partial match and hidden volume, it's sufficient to specify only the Visible component, as in the current schema.

Order Types Affected by Changes

Order Condition Description New Structure Required?
FOK (Fill-Or-Kill)Fill completely or cancelOnly upon PMA
FAK (Fill-And-Kill)Fill partially, cancel remainder✅ YES (upon PMA)
IOC (Immediate-Or-Cancel)Immediate execution or cancelOnly upon PMA
HVO (Hidden Volume Order)Order with hidden volume✅ YES (always)
Iceberg OrderIceberg order with auto-refill✅ YES (always)
GTC (Good-Till-Cancelled)Valid until cancelledOnly upon PMA or HVO
Limit OrderLimit orderOnly upon PMA or HVO
Market OrderMarket orderRarely (usually fully matched)

Conclusions

Key Findings

  1. Problem is Real and Significant
    • Current system creates ambiguity in reporting
    • Different market participants interpret rules differently
    • Market oversight data quality suffers
  2. Proposed Solution is Logical and Comprehensive
    • Separation of quantity into three clear components (Matched/Visible/Undisclosed)
    • Complete transparency of order lifecycle
    • Unified standard for all participants
  3. Implementation Will Require Effort
    • IT system changes
    • Staff training
    • Adaptation of reporting processes
  4. Long-term Benefits are Significant
    • Improved data quality
    • More effective market oversight
    • Reduced operational risks from reporting errors

Recommendations for Market Participants

  1. Carefully study the proposed changes
  2. Assess impact on own reporting systems
  3. Provide feedback to ACER via online survey
  4. Prepare for implementation in advance
  5. Participate in webinars and ACER consultations

Questions for Discussion with ACER

  1. Critical issues of the proposed solution for their specific systems
  2. Additional guidance for specific order types
  3. Additional XML examples to facilitate implementation
  4. Clarifications in TRUM regarding order lifecycle
  5. Timeline and transition period for implementation

Glossary of Terms

TermEnglishDefinition
ACERAgency for the Cooperation of Energy RegulatorsEU Agency for cooperation of energy regulators
REMITRegulation on Energy Market Integrity and TransparencyRegulation on energy market integrity and transparency
TRUMTransaction Reporting User ManualTransaction reporting user manual
PMAPartially MatchedPartially matched order
MACMatchedFully matched order
ACTActiveActive order
REFRefilledRefilled (from hidden volume)
HVOHidden Volume OrderOrder with hidden volume
FAKFill-And-KillFill partially, cancel remainder
FOKFill-Or-KillFill completely or cancel
IOCImmediate-Or-CancelImmediate execution or cancel
GTCGood-Till-CancelledValid until cancelled
OMPOrganised Market PlaceOrganised market place
XSDXML Schema DefinitionXML schema definition

Appendices

A. Current TRUM Annex II v5.1 Structure

The document contains reporting examples for various trading scenarios:

Section 1: Order and trade reporting via Table 1

  • 1.1. Auction contracts
  • 1.2. Continuously traded contracts on exchanges
  • 1.3. Broker contracts (including voice-brokered)
  • 1.4. Bilateral contracts (off organised market place)

Section 2: Non-standard contract reporting via Table 2

Section 3: Transportation contract reporting via Tables 3 and 4

B. References and Resources

ACER Official Documentation:

  • REMIT Reporting Guidance: https://www.acer.europa.eu/remit-documents/remit-reporting-guidance
  • TRUM (Transaction Reporting User Manual): ACER official portal

Conclusion

ACER's proposed changes to the quantity information reporting schema for partially matched orders represent a significant step forward in improving data quality and transparency on European energy markets. While implementation will require effort from all market participants, the long-term benefits of improved market oversight, reduced operational risks, and process standardization significantly outweigh short-term costs. The success of this initiative depends on active participation of all stakeholders in the consultation process and careful preparation for implementation of new rules.