ACER REMIT: Analysis of Quantity Information Reporting Proposals
Table of Contents
- Introduction
- Data Quality Issues
- Current Rules (TRUM Annex VII)
- Proposed Changes
- Example Comparisons
- Impact on Reporting
- Applicability of New Rules
- Conclusions
- Glossary of Terms
- Appendices
- 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:
- How much was matched
- How much remains visible for trading
- 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)
| Field | Value |
|---|---|
| 40. Quantity/Volume | 15 MW |
| 41. Total Notional Contract Quantity | 15 MWh |
T2: Order M + PMA (Partially matched)
| Field | Value |
|---|---|
| 40. Quantity/Volume | 5 MW (remainder only) |
| 41. Total Notional Contract Quantity | 5 MWh |
Trade
| Field | Value |
|---|---|
| 53. Quantity/Volume | 10 MW |
| 54. Total Notional Contract Quantity | 10 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/Volume | 10 MW | 5 MW | 0 MW |
| 54. Total Notional Contract Quantity | 10 MWh | 5 MWh | 0 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
- Order placed: 15 MW visible + 15 MW hidden
- 5 MW visible matched
- Automatic refill: 5 MW moves from hidden to visible
Proposed Reporting
| Field | Matched | Visible | Undisclosed |
|---|---|---|---|
| Quantity/Volume (Stage 1: N+ACT) | — | 15 MW | — |
| Total Notional Contract Quantity | — | 11160 MWh | — |
| Quantity/Volume (Stage 2: M+ACT with HVO) | 0 | 15 MW | 15 MW |
| Total Notional Contract Quantity | 0 | 11160 MWh | 11160 MWh |
| Quantity/Volume (Stage 3: M+PMA with HVO) | 5 MW | 10 MW | 15 MW |
| Total Notional Contract Quantity | 3720 MWh | 7440 MWh | 11160 MWh |
| Quantity/Volume (Stage 4: M+REF with HVO) | 0 | 15 MW | 10 MW |
| Total Notional Contract Quantity | 0 | 11160 MWh | 7440 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
- Webinars for market participants
- XML examples for all typical scenarios
- Updated TRUM guidance with detailed instructions
- Validation rules for automatic verification
Applicability of New Rules
When to Use New Structure?
- Partial match (PMA) of any order
- Orders with hidden volume (HVO)
- Iceberg orders
- Orders with undisclosed volume
- Volume refill (REF) from hidden part
- 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 cancel | Only upon PMA |
| FAK (Fill-And-Kill) | Fill partially, cancel remainder | ✅ YES (upon PMA) |
| IOC (Immediate-Or-Cancel) | Immediate execution or cancel | Only upon PMA |
| HVO (Hidden Volume Order) | Order with hidden volume | ✅ YES (always) |
| Iceberg Order | Iceberg order with auto-refill | ✅ YES (always) |
| GTC (Good-Till-Cancelled) | Valid until cancelled | Only upon PMA or HVO |
| Limit Order | Limit order | Only upon PMA or HVO |
| Market Order | Market order | Rarely (usually fully matched) |
Conclusions
Key Findings
- Problem is Real and Significant
- Current system creates ambiguity in reporting
- Different market participants interpret rules differently
- Market oversight data quality suffers
- 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
- Implementation Will Require Effort
- IT system changes
- Staff training
- Adaptation of reporting processes
- Long-term Benefits are Significant
- Improved data quality
- More effective market oversight
- Reduced operational risks from reporting errors
Recommendations for Market Participants
- Carefully study the proposed changes
- Assess impact on own reporting systems
- Provide feedback to ACER via online survey
- Prepare for implementation in advance
- Participate in webinars and ACER consultations
Questions for Discussion with ACER
- Critical issues of the proposed solution for their specific systems
- Additional guidance for specific order types
- Additional XML examples to facilitate implementation
- Clarifications in TRUM regarding order lifecycle
- Timeline and transition period for implementation
Glossary of Terms
| Term | English | Definition |
|---|---|---|
| ACER | Agency for the Cooperation of Energy Regulators | EU Agency for cooperation of energy regulators |
| REMIT | Regulation on Energy Market Integrity and Transparency | Regulation on energy market integrity and transparency |
| TRUM | Transaction Reporting User Manual | Transaction reporting user manual |
| PMA | Partially Matched | Partially matched order |
| MAC | Matched | Fully matched order |
| ACT | Active | Active order |
| REF | Refilled | Refilled (from hidden volume) |
| HVO | Hidden Volume Order | Order with hidden volume |
| FAK | Fill-And-Kill | Fill partially, cancel remainder |
| FOK | Fill-Or-Kill | Fill completely or cancel |
| IOC | Immediate-Or-Cancel | Immediate execution or cancel |
| GTC | Good-Till-Cancelled | Valid until cancelled |
| OMP | Organised Market Place | Organised market place |
| XSD | XML Schema Definition | XML 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.
