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 utilization has moved. Far enough, in the worst case, to put you over a hard regulatory line. No one traded. Your reported utilization is over it anyway. And the cause is sitting inside your own software.
Position limits cap how large a position you can hold in certain commodity derivatives. They’re a hard line, set by regulators: the CFTC enforces federal limits in the US, and the EU sets them under its markets in financial instruments rules. 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 utilization.
Now change that engine. An upgrade, a configuration change, a patch to how an instrument is modeled 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 utilization 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 utilization that now under-reports a real exposure. Both are problems. One earns you a breach; the other hides one.
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 defense 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.
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 defense is simple to state and harder to do by hand: prove the engine still calculates the same way, every time it changes.