MaBiS-Hub: Central Balancing Settlement for the Power Market, Start Date Open

What the MaBiS-Hub is

The MaBiS-Hub centralises balancing settlement for power. Instead of each distribution grid operator aggregating the settlement-relevant data itself, a nationwide platform will take over in future. The Bundesnetzagentur opened the procedure BK6-24-210 for it on 2 October 2024. Read correctly, the MaBiS-Hub is a platform and data topic with a multi-year migration programme, not a short-term format change.

In substance this is about the central aggregation of quarter-hourly market locations into total time series. One legal driver is Section 52 (3) MsbG, which requires pseudonymised market communication. The rebuild is closely tied to the smart meter rollout and the end of the standard load profile, with a balancing interval of 15 minutes. Operation is expected to sit with the four transmission grid operators. That shifts not just one task but the whole data architecture of balancing.

Central instead of decentral: the new architecture

The core is a shift from decentral, bilateral settlement to a central exchange, the same direction the HEDWIG reporting duty under § 111g EnWG takes for regulatory data. Today each grid operator communicates bilaterally via EDIFACT; in future aggregation and settlement run through the hub with a 1:1 connection for every market role. That cuts the number of connections sharply and makes the balancing data uniform across the country.

With the central platform, new functional units appear. The metering data processor (MWV) takes over the central processing of metering data, and the balancing and aggregation responsible party (BAV) takes over balancing. The connection is web service based with certificates instead of the former n:m communication. Instead of open market location IDs, pseudonymous codes run through the system, and the hub core is built modularly from aggregation, settlement and pseudonymisation.

For IT this means rebuilding the interfaces and the data logic at the same time. Whoever couples the web service based hub connection cleanly to the existing systems and provides for pseudonymisation in the data model can serve the central settlement without putting the running operation at risk. The format stays EDIFACT: under Bundesnetzagentur notice no. 58, no additional API web services are planned for the MaBiS hub, and new use cases will be expressed in EDIFACT. How market communication develops as a whole is covered in the piece on MaKo 2026 with EDIFACT, AS4 and API web services.

Two blocks and the timeline to 2029

The Bundesnetzagentur has split the procedure into two blocks to stage the complexity. The timeline is tight, and the final go-live is not yet legally binding. Whoever knows the sequence can plan migration and connection cleanly, rather than putting everything on one date.

Where the dates come from matters, and the public debate often blurs it. Every date from 2028 onward comes from the BDEW introduction scenario, which the Bundesnetzagentur put out for consultation unchanged in procedure BK6-24-210-1. None of it is decided: notice no. 58 of 1 October 2026 calls the MaBiS hub ruling pending. The start date is open. The data protection end date under Section 52 (3) MsbG is 2030. Splitting the procedure into Block 1 and Block 2 decouples the consultation and the ruling for the two topics in time.

Who is affected: DSOs, MPOs, BGMs and suppliers

The change affects practically all market roles but shifts responsibility noticeably. Distribution grid operators lose their central aggregation role, and metering point operators deliver directly to the hub. Whoever knows their own role can prepare the right interfaces and data duties in a targeted way.

Distribution grid operators will mainly supply master data in future and lose responsibility for aggregation and settlement. Metering point operators connect directly to the hub, which raises the requirements for data quality and availability. Balancing group managers and suppliers receive faster, standardised settlement data on a quarter-hourly basis. Above all this stands one condition: the go-live presupposes nearly complete data quality, and in the BDEW introduction scenario the bar is set at nearly 100 percent.

Challenges and risks

Centralisation creates efficiency, but also new risks. An honest view has to name the concentration risk and the open governance questions, rather than selling the MaBiS-Hub only as an efficiency gain.

The central risk is a single point of failure: if the hub goes down, grid operators lack the daily aggregate data. How real this is was shown by a warning shot from live operation, because one transmission grid operator could not complete the balancing settlement on time for weeks in June 2025 due to software problems. On top of this comes the question of risk shifting: BDEW and VKU reject the idea that operating errors of the hub should be passed financially onto the grid operators. The deadline pressure is also considerable, and the BDEW itself rates the timeline as extremely demanding. edna and other associations flag open governance questions.

What companies should do now

The MaBiS-Hub is a multi-year programme, not a deadline project. Whoever secures data quality now and builds the interface readiness avoids expensive stress in the test and parallel operation that the BDEW scenario places in 2028 and 2029. A regulatory rebuild then becomes a stable foundation for the further digital work in balancing.

1. Follow the procedures actively and submit comments

   Follow the procedures BK6-24-210-1 and -2 closely and submit comments through the associations. As long as governance, liability and the go-live date are not fixed, it pays to bring your own requirements into the consultation early, rather than accepting finished rules at the end.

2. Bring data quality to nearly 100 percent

   Bring master, metering and location data to a nearly complete quality. Because the go-live presupposes very high data completeness, your own data base decides whether the connection to the hub runs smoothly or ends in clarification cases.

3. Prepare IT for hub communication

   Prepare IT for the 1:1 hub communication and the quarter-hour logic. Web service based, certificate-backed interfaces and pseudonymisation in the data model should be tested early, so that live operation does not become the first stress test.

4. Budget for parallel operation and couple it

   Budget for test and parallel operation, from July 2028 to October 2029 in the BDEW scenario, and couple both with the smart meter rollout. The same clean data base carries several duties and makes the investment valuable beyond a single go-live.

Further reading

Frequently asked questions