Battery energy storage system (BESS) operators across Europe have gotten very good at one thing: trading. Pull price signals, run the optimisation algorithm, charge low, discharge high. The imbalance market math works. The payback periods are shrinking.

But those spreads are compressing. As more batteries enter the market chasing the same price signals, arbitrage margins narrow. This is already visible in the UK and Germany, and the rest of Europe is catching up fast.

The next layer of revenue looks different. Congestion management, FCR, aFRR, DSO capacity contracts. These are structured flexibility services where grid operators pay you for being available and responsive, not just for moving energy at the right moment. In markets like the Netherlands, where DSOs are rejecting new grid connections entirely, the demand for distributed flexibility is becoming desperate. But the same trend is building across Belgium, Germany, the Nordics, and Southern Europe as renewable penetration outpaces grid reinforcement everywhere.

Here’s the problem. Most BESS software was built to observe the market and act independently. It was never designed to have a conversation with a grid operator. And that conversation is exactly what flexibility markets require.

The Protocol Gap

Participating in demand response programs and flexibility services means your battery needs to receive dispatch signals from a DSO or TSO, confirm activation within strict timeframes, report certified metering data, and settle through auditable channels. Each of these steps follows standardised communication protocols that grid operators have used for years.

The most relevant one for BESS operators entering flexibility markets is OpenADR 2.0b. Originally built for automated demand response, OpenADR has become the standard for communication between grid operators and distributed assets. It defines how a flexibility request gets issued, how your asset acknowledges it, how you report what you actually delivered, and how the whole exchange gets logged for settlement.

For BESS operators, OpenADR is the gateway into congestion management and DSO capacity products. It’s also increasingly a prerequisite. DSOs awarding flexibility contracts want assets that communicate through standardised, certified interfaces, not custom API integrations that break when something changes on either side.

The problem is that most battery management platforms have no OpenADR capability at all. The EMS talks to the energy market. It talks to the BMS. It talks to the customer app. But it doesn’t speak the language that grid operators use to coordinate distributed energy resources (DER). That missing grid interoperability layer is the difference between an asset that trades and an asset that provides grid services.

What It Takes to Get There

Adding demand response capability to an existing BESS platform isn’t a full rebuild. It’s an integration layer, a protocol adapter that sits between your EMS and the grid operator’s VTN (Virtual Top Node) platform.

In practice, this means implementing an OpenADR VEN (Virtual End Node) that can register your assets with DSO platforms, receive and parse DR event signals, map those signals to your battery’s charge/discharge logic, report telemetry and metering data back in the required format, and handle the authentication and security that certified OpenADR communication requires.

The companies getting this right aren’t building from scratch. Pre-certified OpenADR VEN stacks already exist as deployable microservices, cutting integration timelines from quarters to weeks. One manufacturer recently achieved full OpenADR 2.0 certification and regulatory approval using this approach, reducing development effort by roughly 40 percent compared to a ground-up build. The pattern is the same whether you’re integrating pool pumps, heat pumps, EV chargers, or battery systems: start with a certified protocol layer, adapt it to your hardware and control logic, and own the code going forward.

The architecture needs to be modular. Once you have a working OpenADR adapter, the same pattern extends to other grid protocols: CIM for TSO information exchange, IEEE 2030.5 for broader DER coordination, OCPP 2.0.1 if you’re running hybrid storage-plus-charging sites. Whether your assets participate individually or through a virtual power plant (VPP) aggregator, the protocol layer is the same. Each of these follows the same principle of translating between your internal logic and an external standard.

The Timing Matters

Operators who integrate with grid platforms first will get preferred access to flexibility contracts. DSOs under pressure to manage congestion will choose assets they can rely on, assets that speak their language and respond within certified parameters. TSO prequalification for balancing services has specific technical gates.

For a typical commercial BESS installation, revenue stacking — combining arbitrage with even one regulated flexibility service — can increase annual revenue per installed kWh by 40 to 70 percent. The interoperability layer isn’t a cost centre. It’s the unlock.

The standards exist. The DSO platforms are being built right now. The only question is whether your software will be ready when they go live.