First principles or side by side: which testing approach fits your ETRM system?
Here’s a scenario worth thinking through if you monitor position limits. You come in one morning, nobody on the desk has done anything unusual, no new trades of any size, and yet your reported limit utilisation has moved. Far enough, in the worst case, to put you over a hard regulatory line. No one traded. Your reported utilisation is over it anyway. And the cause is sitting inside your own software.
Where the number actually comes from
Position limits cap how large a position you can hold in certain commodity derivatives. They're a hard line: in the US the CFTC enforces federal limits, in the EU they're set under the markets in financial instruments rules, and in the UK they apply to critical contracts under the FCA's regime, where the trading venues now set the limits. Cross one, and it's a reportable breach, not a rounding error.
The catch is that the figure you monitor against that line isn’t something you observe directly. Your ETRM/CTRM platform calculates it. It nets long positions against short ones, converts options and other instruments into a futures-equivalent position, and aggregates across accounts, entities and related products to produce the number you actually report. A lot of logic sits between a trade and a limit utilisation.
A change in the engine, not on the desk
Now change that engine. An upgrade, a configuration change, a patch to how an instrument is modelled or how positions roll up. The trades are identical. The way the system aggregates or converts them is not. The computed position shifts, and your utilisation against the limit shifts with it.
That’s how you breach without trading. The movement doesn’t come from the market or the desk. It comes from a change to the calculation, and it can go either way. A limit you thought you were comfortably inside, or a utilisation that now under-reports a real exposure. Both are problems. One earns you a breach; the other hides one.
Why it’s so easy to miss
This is the insidious part. When a position moves because someone traded, there’s a cause you can see and a person who knows about it. When it moves because the aggregation logic changed, nothing prompts a second look. The desk did nothing. The number simply settled in a slightly different place.
The usual defence after an upgrade is a manual spot-check: pick a few positions, confirm they look about right, sign off. Across a handful of instruments that works. Across thousands of positions, with netting and futures-equivalent conversions layered through them, a subtle change in how one product aggregates can pass every spot-check and still shift your headline number. You’re sampling. The change is systemic.
Prove the engine still computes the same way
The reliable way to catch this isn’t to look harder at the answer. It’s to compare the calculation itself, before and after the change. Run the same positions through the current system and the upgraded one, side by side, and surface every difference. A difference is either intended, in which case you record why, or it’s a fault, in which case you’ve found it in test rather than in a regulator’s query.
Worth being precise here. This proves your position engine still computes the way it did before a change, against a known baseline. It doesn’t independently re-derive what the true position ought to be, and a person still decides whether a difference was meant. What it removes is the nasty surprise: the breach that came from your own software while nobody was looking.
There’s an evidence dimension too. If a regulator ever queries a limit figure, “the engine behaved consistently through every change, and here’s the evidence” is a far stronger position than reconstructing months of upgrades from memory.
A breach you can explain is a bad day. A breach you can’t see coming, from a system you trusted to compute the way it always has, is a worse one. The defence is simple to state and harder to do by hand: prove the engine still calculates the same way, every time it changes.
