Notice no. 58: UTILTS stays, the API replacement is off

What has applied since 1 October

The message type versions from notice no. 56 have applied since 1 October 2026, to everyone under an implementation obligation. 25 AHB and MIG versions, 13 EDIFACT message types, and alongside them the general rules 6.1d, check identifier overview 4.0, decision tree diagrams 4.3, AS4 profile 1.2, transmission path rules 1.10. That was the expected half of the balance sheet. We went through the detail before the deadline: which versions, and where exception cases tend to surface.

Ask two suppliers how big the changeover was and you get two answers. One calls it a consolidation with no new business processes. A software house counts a breadth reaching almost every format with substantive content and names PARTIN, COMDIS, MSCONS. Both readings hold up. No new processes, plenty of changed edges.

Then notice no. 58 landed, on that same 1 October.

Notice no. 58 withdraws the API replacement

UTILTS stays. That is the day's news in two words, and it contradicts a draft the same ruling chamber had published nine weeks earlier.

The rest of the decision follows from that. APIs newly proposed in the consultation: withdrawn. API web services: expected to stay limited to MaLo-Ident and control for the time being. The BDEW application aids on location bundles and calculation formulas are to come down from the MaKo platform altogether. Those aids are dated 18 August 2026, which made them seven weeks old when the decision retired them.

The APIs were not the only casualty. The proposed restriction of the special invoice to the energy price and capacity price variant was dropped too, because for the cases described in the GPKE it is not to be explicitly limited to particular grid usage variants. Two central points, both reversed between draft and decision. That does not happen often.

The regulator against its own draft

Same authority, nine weeks apart, opposite directions. We are not going to resolve that here. We are going to put the two texts next to each other and leave them there.

And the later decision was not the only objection on record. The EDI@Energy project group, where market participants draft the documents under BDEW leadership, used the same consultation to ask for a slower cadence.

Both sides lost something. The APIs are gone, though the chamber's own draft had carried them. The cadence stays at six months, though the project group had asked for twelve, and the versions from notice no. 58 apply bindingly from 1 April 2027. We described that argument over the cadence before the deadline. It is settled.

Who actually caused the reversal? The notice is half-open about it. The comments received were discussed with grid operators, grid users, the software industry and the Federal Network Agency. Which of them tipped the decision is not recorded anywhere.

The market reads the outcome as a commitment to the installed base: the authority has confirmed the continued use of EDIFACT as the basis both for the data formats and for the MaBiS hub, according to the announcement of the EDI@Energy 2026 conference on 17 and 18 November in Leipzig. That fits the notice, which foresees no further build-out of additional API web services for the MaBiS hub proceeding and wants new use cases expressed in EDIFACT as well.

That leaves "for the time being" doing a lot of work. Delay, or quiet burial? The notice does not say. Next data format consultation: February 2027.

Three documents for 1 April 2027

The April package is the smallest in years. Three documents, and only one of them concerns everyone who exchanges market communication.

For EDIFACT, the decision tree diagrams, the code lists and the API web services, no new documents were published on 1 October 2026. So no adjustment need arises in those areas for 1 April 2027 either. A release without format work has been rare lately, and it is the best news for houses still cleaning up after October.

Why the certificate question hits two deadlines

The least conspicuous document in the package is the one you need IT for. 44 pages, dated 31 July 2026, two building sites inside it.

First: two binding documents that disagreed with each other. The rules held no unambiguous provision for transporting redispatch EDIFACT messages, AS4 in particular, while the check identifier overview already assumed they would be. Version 1.11 closes the gap by extending the scope with the value RD for redispatch 2.0 process data. Not a feature. Housekeeping.

Second: the certificates, and this is where the lead time sits. Exchange over REST runs on mutual TLS. Per market partner ID, receiving documents needs a TLS certificate with a unique Subject DN, while sending them needs an X.509 certificate fit for TLS client authentication. One certificate can do both jobs, as long as its Extended Key Usage shows client authentication. Even an S/MIME certificate from content data security qualifies, if it carries that extension.

The reasoning sits in the change log, and it points outward.

The trigger named in the same log is a shift in the conditions around publicly trusted TLS certificates, and that shift has nothing to do with energy. Public certificate authorities are stripping the client authentication extension out of publicly trusted TLS certificates. For the Chrome Root Program, 15 March 2027 is the cut-off that gets cited; individual providers name earlier dates, and the published figures partly contradict one another. The MaKo deadline sits a good two weeks after that.

Underneath sit the operational requirements. RSA key length of at least 3072 bits. An overlap of at least ten working days whenever a certificate is swapped. REST only over port 443, TLS 1.2 or higher, Server Name Indication. None of this is difficult. All of it takes longer than a format patch.

What electricity and gas grid operators plan differently now

The dividing line does not run between electricity and gas. It runs between redispatch and standard market communication.

The longer horizon hangs on the same sentence. In the MaBiS hub proceeding, no further build-out of additional API web services is foreseen, and new use cases will be expressed in EDIFACT. Production go-live was pencilled in for the second half of 2028 in the key points paper. Anyone who aligned their target architecture to an API layer over the summer is now moving that assumption by years, not by one release. How EDIFACT, AS4 and the API layer fit together is set out in our overview of MaKo 2026.

Challenges and risks

Reversed preparatory work is lost work, and someone paid for it. Development, procurement or a tender aimed at the API replacement between February and September 2026 now returns nothing. Pulling the application aids off the platform at least signals the direction clearly. It does not give the months back.

Harder to price is the damage to planning confidence. When a consultation announces a full replacement and a decision nine weeks later withdraws it, the next consultation becomes harder to read. Practical consequence for February 2027: a draft is a draft. Not a roadmap.

The third risk is the quiet one. Three documents sound like nothing, so the April package slides down the priority list, and then the certificate work starts late. Procuring a suitable certificate takes longer than adapting a format. The certificate market moves two weeks before the MaKo deadline.

There is an upside, and it should be said. A quiet April package buys room. One service provider holds the effort to be manageable if you plan early enough, and notes that the first days after a deadline decide whether backlogs form. Spring 2027 leaves space for that cleanup for once. The exception cases you count there also become the benchmark AI for exception cases has to beat later.

What utilities should do now

Five steps, in this order.

The run-up to 1 April 2027

1. Clean up the roadmap

   Strike every initiative built on the API replacement of UTILTS from the plan, the budget and the service provider contracts. UTILTS processing stays an operational task, with no end date in sight.

2. Take a certificate inventory

   Which certificates are in use today for AS2, SMTP, SFTP and REST, and when does each one expire? Does the dispatch certificate carry an Extended Key Usage with client authentication? Answer those three, then build the ten working day overlap into the replacement date rather than discovering it later.

3. Settle the PKI question with IT security

   If public certificate authorities stop supplying client authentication, the client certificates have to come from a private PKI. Architecture decision, with operations attached. Not a purchase.

4. Document the redispatch transport paths

   Check the paths you use today against the new allocation in version 1.11, before it becomes binding.

5. Evaluate October before April takes the capacity

   Analyse the exception cases of the first weeks by check identifier. It costs one analysis and gives you the best test basis for the next release. On the gas side it is worth looking at GeLi Gas 2.0 in parallel, because the same check identifiers apply there.

And February 2027? Read the consultation early, and flag it internally with a caveat. October showed how far a draft can sit from the result.

Further reading

Frequently asked questions