Inhaltsverzeichnis

1. Einleitung
2. Datenqualitätsprobleme
3. Aktuelle Regeln (TRUM Anhang VII)
4. Derzeitige Datenfelder & Problem
5. Vorgeschlagene Änderungen
6. Beispielvergleiche
7. Auswirkungen auf die Meldung
8. Anwendbarkeit der neuen Regeln
9. Schlussfolgerungen
10. Empfehlungen für Marktteilnehmer
11. Diskussionsfragen an ACER
12. Glossar der Begriffe
13. Anhänge & Quellen
14. Abschluss

---

Einleitung

ACER (Agentur für die Zusammenarbeit der Energieregulierungsbehörden) meldet anhaltende Datenqualitätsprobleme bei der REMIT‑Meldung von teilweise abgeglichenen Aufträgen (PMA). Betroffen sind insbesondere Aufträge mit nicht offengelegtem Volumen und Nachfüllungen (REF) aus dem versteckten Anteil.

Ziel dieses Dokuments: Darstellung der aktuellen Probleme und der Lösungsvorschläge zur präziseren Mengenmeldung auf EU‑Energiemärkten.

---

Datenqualitätsprobleme

Aktuelle Situation

In Tabelle 1 treten wiederholt Inkonsistenzen auf, wenn PMA‑Aufträge gemeldet werden. Besonders fehleranfällig sind Meldungen mit verdecktem Volumen (HVO) und Nachfüllungen (REF).

Typische Inkonsistenzen

Bei PMA‑Aufträgen ist die gemeldete Änderungsmenge uneinheitlich:

Aktuelle Regeln (TRUM Anhang VII)

Status & Aktionstypen

Derzeitige Datenfelder & Problem

Feld (40) – Quantity/Volume: Einfaches Feld (Wert + Einheit) – keine Trennung zwischen abgeglichen, sichtbar, nicht offengelegt.

Feld (41) – Total Notional Contract Quantity: Einfaches Pflichtfeld (Wert + Einheit) für alle Aufträge.

Feld (19) – Undisclosed Volume: Nur für HVO‑Bedingungen.

Folge: Es gibt keinen klaren Weg gleichzeitig darzustellen, (1) wie viel abgeglichen wurde, (2) wie viel sichtbar handelbar bleibt und (3) wie viel verborgen ist. Das führt zu divergierenden Interpretationen.

Vorgeschlagene Änderungen

1. Präzisierung der REMIT‑Beschreibung für Feld (40)

• Verfügbare sichtbare Einheiten
• Nicht offengelegte Einheiten
• Abgeglichene Einheiten

2. Neue XSD‑Struktur

OrderList

Das Feld quantity enthält drei Komponenten:

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

Ebenso für 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. Anpassung Feld (19) – Undisclosed Volume

Gilt nur für Aufträge mit HVO. Hat ein PMA‑Auftrag kein verstecktes Volumen, ist der Wert 0 (null) zu melden.

4. TradeList (unverändert)

Struktur bleibt einfach:

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

---

Beispielvergleiche

Beispiel 2.22: FAK‑Auftrag mit Teilfülle

FAK (Fill‑And‑Kill)

Szenario

• Auftrag über 15 MW
• 10 MW abgeglichen
• 5 MW Rest (gemäß FAK storniert)

Aktuelle Meldung (TRUM Anhang II v5.1)

T1: Order N + ACT (Neuer aktiver Auftrag)

T2: Order M + PMA (Teilweise abgeglichen)

Trade

Problem: Aus dem Auftragsdatensatz ist nicht ersichtlich, wie viel abgeglichen wurde; sichtbar ist nur der Rest (5 MW).

Vorgeschlagene Meldung

Vorteil: Vollständiges Bild des Auftragszustands – abgeglichen 10 MW, sichtbar 5 MW, verborgen 0 MW.

---

Beispiel 2.21: Iceberg‑Aufträge

Iceberg‑Auftrag (HVO): Teil sichtbar, Teil verborgen; nach Ausführung wird der sichtbare Anteil automatisch aus dem verborgenen Anteil nachgefüllt.

Szenario

1. Auftrag: 15 MW sichtbar + 15 MW verborgen
2. 5 MW des sichtbaren Teils abgeglichen
3. Nachfüllung: 5 MW wandern von verborgen zu sichtbar

Vorgeschlagene Meldung

Trade: 5 MW / 3720 MWh

Vorteil: Volle Transparenz – Ausführung sichtbar (5 → 0 MW nach REF), sichtbarer Anteil steigt (10 → 15 MW), verborgener sinkt (15 → 10 MW).

---

Beispiel 2.54: Auftragslebenszyklus mit REF

Aktuelles Problem

Treten PMA und REF gleichzeitig auf, ist unklar, welcher Status zu melden ist.

Vorgeschlagene Lösung

Regel: Führt eine Geschäftsentscheidung zu mehreren gleichzeitigen Ereignissen (z. B. PMA + REF bei Icebergs), reicht der Status „PMA“ aus; „REF“ muss nicht zusätzlich angegeben werden.

Die Struktur mit drei Komponenten erlaubt die Abbildung beider Effekte in einem Datensatz:

---

Auswirkungen auf die Meldung

Vorteile

• ✅ Vollständiger Zustand zu jedem Zeitpunkt
• ✅ Eindeutige Interpretation, weniger Fehler
• ✅ Lückenlose Rekonstruktion des Auftragslebenszyklus
• ✅ Bessere Aufsicht (z. B. Manipulationsindikatoren)
• ✅ Präzisere Liquiditäts‑ und HVO‑Analysen

Herausforderungen

• ⚠️ Teilweise mehr Datensätze / größere XML‑Dateien
• ⚠️ Anpassungen der IT‑Systeme & Tests
• ⚠️ Schulung der Fach‑ und Reporting‑Teams
• ⚠️ Übergangs‑ und Validierungsaufwand

Risikominderung

1. Webinare für Marktteilnehmer
2. XML‑Beispiele für alle typischen Szenarien
3. Aktualisierte TRUM‑Guidance mit Detailanweisungen
4. Validierungsregeln zur automatischen Prüfung

---

Anwendbarkeit der neuen Regeln

Wann verwenden?

1. Teilabgleich (PMA) beliebiger Aufträge
2. Aufträge mit verstecktem Volumen (HVO)
3. Iceberg‑Aufträge
4. Aufträge mit nicht offengelegtem Volumen
5. Nachfüllung (REF) aus verborgenem Anteil
6. Kombinationen der o. g. Fälle

Wann nicht?

Bei einfachen Aufträgen ohne PMA/HVO genügt die Angabe der sichtbaren Komponente wie bisher.

Betroffene Auftragstypen

---

Schlussfolgerungen

Kernaussagen

1. Das Problem ist real und relevant. Die derzeitige Struktur erzeugt Mehrdeutigkeit und ungleiche Auslegung.
2. Die Lösung ist schlüssig. Trennung in Abgeglichen/Sichtbar/Nicht offengelegt schafft Transparenz und Standardisierung.
3. Die Umsetzung erfordert Aufwand. IT‑Änderungen, Tests, Schulungen und Prozessanpassungen sind nötig.
4. Langfristiger Nutzen überwiegt. Bessere Datenqualität, wirksamere Aufsicht, geringeres Betriebsrisiko.

Empfehlungen für Marktteilnehmer

1. Vorgaben gründlich prüfen.
2. Auswirkungen auf eigene Systeme bewerten.
3. Feedback im Konsultationsprozess einbringen.
4. Vorbereitung der Implementierung starten.
5. An ACER‑Webinaren und Konsultationen teilnehmen.

Diskussionsfragen an ACER

1. Kritische Punkte für das eigene System
2. Zusätzliche Leitlinien für spezielle Auftragstypen
3. Weitere XML‑Beispiele zur Erleichterung der Implementierung
4. Präzisierungen im TRUM zum Auftragslebenszyklus
5. Zeitleiste und Übergangsfristen

---

Glossar der Begriffe

---

Anhänge & Quellen

A. Struktur TRUM Anhang II v5.1 (Auszug)

• 1. Order‑ & Trade‑Meldung (Tabelle 1): Auktionen; kontinuierlicher Handel; Broker (inkl. Voice); bilaterale Geschäfte (off OMP)
• 2. Meldung nichtstandardisierter Kontrakte (Tabelle 2)
• 3. Meldung Transportverträge (Tabellen 3 & 4)

B. Referenzen

• ACER REMIT Reporting Guidance: Offizielle Seite
• TRUM (Transaction Reporting User Manual) – ACER‑Portal

---

Abschluss

Die ACER‑Vorschläge zur Mengeninformationsmeldung erhöhen die Transparenz und Qualität der REMIT‑Daten deutlich. Trotz notwendiger Umstellungen überwiegen die langfristigen Vorteile für Marktüberwachung, Automatisierung und Fehlerminimierung.