Konsultation: Konzept zur Nutzung und Veröffentlichung von API-Webdiensten
Im Rahmen des Festlegungsverfahrens zum MaBiS-Hub (BK6-24-210) beabsichtigt die Bundesnetzagentur, die Kommunikation der IT-Systeme der Marktpartner mit dem MaBiS-Hub zukünftig über API-Webdienste zu realisieren. Die Einführung und Nutzung dieser Dienste erfordert eine zentrale Bereitstellung der Schnittstellenbeschreibungen und ein Regelwerk für deren Nutzung und Veröffentlichung. Diese Initiative zielt darauf ab, die energiewirtschaftlichen Geschäftsprozesse schneller an die Veränderungen der Energiewende anzupassen.
Problembeschreibung
Die Bundesnetzagentur beabsichtigt, die Kommunikation zwischen den IT-Systemen der Marktpartner und dem MaBiS-Hub zukünftig über
API-Webdienste zu gestalten. Dies basiert auf der Information der Beschlusskammer 6 vom 27. Mai 2025, die einen schnelleren Wandel der energiewirtschaftlichen Geschäftsprozesse im Zuge der Energiewende feststellt.
Daher sieht die Beschlusskammer 6 vor, dass auf Vorschlag der PG EDI@Energy auch für bestehende Prozesse API-Webdienste eingesetzt werden können. Die Herausforderung besteht darin, dass die Einführung und Nutzung zahlreicher API-Webdienste in der Marktkommunikation eine zentrale Bereitstellung der Schnittstellenbeschreibungen sowie ein Regelwerk für deren Nutzung und Veröffentlichung erfordert.
Das Konzeptpapier der PG EDI@Energy schlägt Lösungen für die zukünftige Nutzung, Veröffentlichung und Ausgestaltung dieser API-Webdienste vor. Die Diskussion im Community Hub soll eine koordinierte, gemeinsame Einreichung der Nutzer vorbereiten, um qualifiziertes Feedback zu diesen Vorschlägen zu geben und das weitere Vorgehen mit der Bundesnetzagentur zu beschließen.
Kontext
Das Festlegungsverfahren zur zukünftigen Aggregation und Abrechnung bilanzierungsrelevanter Daten (MaBiS-Hub) wurde im Oktober 2024 von der Beschlusskammer 6 eröffnet. Ziel dieses Verfahrens ist es, die Marktkommunikation weiterzuentwickeln.
Hauptgrund ist die Anforderung des Messstellenbetriebsgesetzes (MsbG), Last- und Zählerstandsgänge standardmäßig zu verarbeiten und gleichzeitig die Einhaltung der Datenschutzgrundverordnung (DSGVO) zu gewährleisten, insbesondere die Pseudonymisierung von Daten bis spätestens 2030. Das Verfahren soll die Marktregeln für die Bilanzkreisabrechnung Strom überarbeiten, um eine zukunfts- und leistungsfähige Neuausrichtung mit neuen Technologien zu erreichen und die beteiligten Marktpartner zu entlasten.
Die Beschlusskammer 6 geht davon aus, dass diese Ziele am besten durch einen zentralen Akteur, den MaBiS-Hub, erreicht werden können, der die erforderlichen Daten weitestgehend bündelt und die Abrechnung erstellt.
Das Festlegungsverfahren wurde in zwei Phasen unterteilt, um eine gestaffelte Umsetzung zu ermöglichen. Der erste Verfahrensblock fokussiert sich auf:
Die zentrale Aggregation aller viertelstundenscharf bilanzierten Marktlokationen und Tranchen zu Summenzeitreihen durch den MaBiS-Hub.
Die Aufbereitung der Messwerte von der Messlokation zur Marktlokation, ebenfalls durch den MaBiS-Hub.
Erst im zweiten Verfahrensblock werden Aspekte wie die vollständige zentrale Aggregation, Bilanzierung und Abrechnung behandelt. Die Beschlusskammer 6 hat bereits im Oktober 2024 und Februar 2025 Eckpunktepapiere zur öffentlichen Konsultation gestellt. Für Q3/2025 ist eine weitere marktweite Konsultation mit detailliert ausgearbeiteten Prozessdokumenten geplant. Die Beschlussfassung soll voraussichtlich in der ersten Jahreshälfte 2026 erfolgen, und die Produktivsetzung des MaBiS-Hub ist für die zweite Jahreshälfte 2028 angedacht.
Lösungsvorschläge
Ausgestaltung zukünftiger API-Webdienste - Fork:
Das Ziel dieser Erweiterungen ist es, die heute oft ineffizienten, bilateralen Klärprozesse durch proaktive, synchrone und nachverfolgbare API-Workflows zu ersetzen. Anstatt nur Daten zu übertragen, soll die API den Marktpartnern Werkzeuge an die Hand geben, um die Datenqualität proaktiv zu sichern und Prozesse zu automatisieren.
1. Proaktive Datenabfrage & Synchronisation
Beweggrund: Ein Großteil der heutigen Klärfälle entsteht, weil die Stammdaten zwischen den Marktpartnern (insb. zwischen Lieferant und Netzbetreiber) nicht synchron sind. Die folgenden "Lese"-Endpunkte ermöglichen es, die "Wahrheit" des Netzbetreibers jederzeit on-demand abzufragen und so Fehler zu vermeiden, bevor sie entstehen.
- Abfrage des Lieferstatus: Verhindert "Trial-and-Error"-Anmeldungen, indem ein Lieferant vorab prüfen kann, ob er an einer MaLo der aktuelle oder letzte Lieferant ist.
- Abfrage des MaLo-Portfolios: Revolutioniert den MaBIS-Prozess, indem ein Lieferant sein gesamtes aktives Portfolio zu einem Stichtag abfragen kann, anstatt mühsam Listen austauschen zu müssen.
- Implementierung: API/Wechselprozesse GPKE/PortfolioAbfrage.yaml
- On-Demand-Abruf von MaLo-Stammdaten: Ermöglicht einem Lieferanten, die vollständigen Stammdaten (inkl. Bilanzierungsgrundlagen) einer MaLo abzurufen, um die Synchronität sicherzustellen.
- Implementierung: API/Wechselprozesse GPKE/StammdatenAbfrage.yaml
2. Prozessuale Endpunkte zur Fehlervermeidung
Beweggrund: Viele transaktionale Prozesse (wie die Rechnungsstellung) scheitern an inkonsistenten Stammdaten. Diese Endpunkte verlagern die Prüfung an den Anfang des Prozesses.
- Validierung von Abrechnungsgrundlagen: Ermöglicht einem Rechnungssteller, abrechnungsrelevante Daten (z.B. JVP) vor dem Versand einer INVOIC gegen die Daten des Empfängers zu validieren. Dies kann die Klärfallquote bei Rechnungen drastisch senken.
- Implementierung: API/Wechselprozesse GPKE/AbrechnungsbasisValidierung.yaml
- Stammdaten-Änderungsvorschläge (PATCH): Formalisiert den heute oft informellen Prozess der bilateralen Klärung. Ein Marktpartner kann einen strukturierten Vorschlag zur Korrektur von Stammdaten einreichen. Nach Prüfung und Annahme durch den Dateneigentümer (z.B. VNB) wird die offizielle Marktkommunikation (UTILMD) angestoßen. Dies stellt sicher, dass die Daten beim "Master" bereits korrekt sind, wenn die UTILMD versendet wird.
- Implementierung: API/Wechselprozesse GPKE/StammdatenÄnderungsvorschlag.yaml
3. Angleichung an bestehende EDIFACT-Prozesse
Beweggrund: Um die Akzeptanz und Prozesssicherheit zu erhöhen, wurden bestehende API-Definitionen analysiert und um wichtige, aus der EDIFACT-Welt bekannte Kontexte ergänzt.
- Kontext für Messwertanfragen (ORDERS): Anfragen wurden um einen reasonCode erweitert, um den Geschäftskontext (z.B. Einzug, Jahresablesung) zu übermitteln.
- Implementierung: Schema/Werte/Werte_Anfrage/reasonCode.yaml
- Spezifikation für Ersatzwerte (MSCONS): Die Übermittlung von Werten wurde um Details zur Ersatzwertbildung (reasonOfSubstituteValueFormation, substituteValueFormationMethod) und das vollständige "Fachlichkeit"-Tupel (energyDirection) ergänzt, um die Datenqualität und Transparenz zu erhöhen.
- Implementierung: Schema/Werte/energyAmountMarketLocation2.yaml