When portfolio structures live in five different places, something always gets out of sync. There's a concept in software engineering called configuration drift: the gradual divergence of a system's actual state from its intended state, usually caused by changes applied in one place that don't propagate cleanly to others. It's a well-known headache in IT infrastructure. It's a largely unspoken crisis in energy trading.
Here's a scenario that will be immediately recognisable to anyone who manages a portfolio across multiple trading applications.
You restructure a portfolio — perhaps a new offshore wind farm comes online, or you're adding a battery to an existing cluster. You update the structure in your day-ahead bidding tool. A week later, someone notices the intraday algo is still trading against the old portfolio boundaries. Your ancillary tool has a third version, configured six months ago during a different reorganisation. And your internal reporting system — well, that's a fourth interpretation entirely.
Which one is right? The honest answer is: none of them, fully. Each was correct at the moment it was configured. Reality has moved on.
"Configuration drift is not a mistake. It's an inevitability when portfolio structures live in multiple disconnected systems."
Configuration drift sounds like an administrative annoyance. In practice, it creates a chain of problems that are hard to trace back to their source.
P&L attribution errors. If your portfolio boundaries are slightly different in three systems, your P&L reconciliation at end of day is going to require manual correction. Multiply that by every trading day. Multiply that by the hours someone senior spends hunting down the discrepancy.
Compliance exposure. Regulatory reporting requires accurate, consistent position data. If your systems hold different versions of reality, your reported positions may not reflect what actually happened. Under REMIT, that's not just inconvenient — it's a liability.
Slower response to market opportunities. When a trader wants to add a new delivery area or adjust a trading scope, they need to make that change in every connected application. If that takes hours, they may miss the window.
The instinctive response to configuration drift is tighter processes: more rigorous change management, checklists, validation steps, approval workflows. These help at the margins. They don't solve the underlying problem.
The underlying problem is architectural: portfolio structures should exist in one authoritative place, and all connected systems should read from that source. Changes should propagate automatically. What is true for the position management system should be true for the execution system, the nomination system, and the reporting system — without human coordination in between.
This is a solved problem in other industries. It isn't solved yet in multi-market energy trading — but it's going to be.
The concept we keep coming back to in conversations with trading desks is deceptively simple: define a portfolio once, and have all connected systems reflect it.
Not a synchronisation batch that runs overnight. Not a manual export-import between systems. Not a fragile middleware layer that breaks during upgrades. A single, authoritative portfolio definition that connected applications treat as truth.
This changes the workflow fundamentally. A portfolio manager makes one change, and it's done. The trader doesn't need to wonder which system has the latest version. Compliance has one source to report from.
We're building toward this. The details are coming. But the principle — centralised portfolio management as the foundation of a multi-market trading platform — is the design direction we've committed to.
Next in this series → How automated multi-market orchestration changes what's possible for trading desks operating across day-ahead, intraday, and ancillary markets.