What a Trading Operations Desk Actually Needs on Day One

Scheduling is the part of physical trading nobody gets into the business to do. It doesn’t generate revenue, the trade already happened, the position is already set and yet it has to be done correctly, on time, at every gate closure, without exception. For a new trading desk, that creates an odd kind of pressure: you need to be operational immediately, on infrastructure you haven’t built yet, for a task that adds no commercial upside if it goes right and real financial and reputational cost if it goes wrong. 

Most teams solve this one of three ways, and each comes with a cost that doesn’t show up until later. 

Some build it in-house. It’s a reasonable first instinct, the logic isn’t exotic, and a capable developer can get something working. What’s harder to see upfront is the communication-protocol layer underneath: TSOs across European markets each have their own message formats, testing requirements, and certificate processes, and those requirements change. A scheduling tool that worked at launch needs ongoing maintenance every time a protocol updates and that maintenance falls on whoever built it, indefinitely, as a background tax on a team that has other things to do. 

Some lean on scheduling functionality bolted onto an existing ETRM or EDM system. This is often adequate for the basics, but it’s rarely built as a focused, modern scheduling tool because it isn’t one. The integration is frequently file-based, extending it to a new market is its own small project, and the interface reflects however the parent system was designed years ago rather than what a dispatcher actually needs to see at a glance. 

And some outsource the whole process to another balance-group-responsible party. That solves the tooling question entirely, but at the cost of control and an ongoing service margin and it’s not a decision easily reversed once the operational dependency is in place. 

What a new desk or an established one that’s outgrown spreadsheets and legacy tooling actually needs is narrower than any of these three options assume: correct schedules and nominations, delivered to the TSO on time, every gate closure, with one place to see the status of everything and get alerted the moment something doesn’t match. Not a full trading system. Not a research or build project. Not a second vendor relationship on top of the first. 

That’s the specific gap DispoEnergy is built to close: automated, real-time scheduling and nomination, with Volue handling the TSO testing and connection setup so a new market or counterparty goes live in hours or days rather than as its own IT initiative. No infrastructure to host. No certificates to track down and renew. No protocol update landing on your desk as an unplanned sprint. 

The protocol complexity that makes in-house builds so hard to finish is exactly the part Volue has already been through, repeatedly, market by market. As Helmut Spindler, GM Trading & Optimization at Volue, puts it: “Setting up scheduling and nomination in a new market is genuinely hard work the first time… every country brings its own rules and its own requirements, like different exchange formats, different conformance tests and different conventions for how a nomination is meant to look. It is unglamorous work, and there is no way around it. Once the first customer in a market is live, however, the next one always becomes easier than the last.” A new customer doesn’t start that climb from zero they start wherever Volue’s already gotten to.