Reply To: Modelling Nordpool Power type contracts

Phil Walsh

It’s actually quite a chunky subject this one, but I would say that the primary advantage of approach 2 over approach 1 is that it provides cleaner daily and cumulative P&L, which is why I favour it.

As these contracts are essentially exchange-traded swaps with no daily margining, and so only begin to settle once the final child contract has expired, the entire P&L needs to be associated with the child contract in order to correctly reflect settlement. This means that the P&L of the parent contract always needs to fall to zero at expiry (as opposed to a standard future where it is appropriate to realise P&L at expiry as though the position had been closed out).

There are different approaches for ensuring that the P&L moves to zero. Specifically for the monthly contact, by managing the pre and post expiry (or swap settlement) period of that contract in one trade (approach 2) rather than converting the position into an explicit swap instrument to track the settlement (approach 1) essentially removes one of the instances where the P&L on the parent contract needs to fall to zero.

For the quarterly and annual contracts, which do need to cascade I recommend a small custom process which sets the mvalue of the parent trade to zero, and keep the trade at a validated status. I don’t think there is officially a JVS function which will do this for a ComFut, however I found that the following function which is only officially supported for FX instruments will work.


It’s worth noting that the OL standard cascading script also has the capability to set the mvalue to zero, but it does this using a function which sets the trade status to closeout. This then means that PNL Detail can’t be used for reporting the move to zero on the day of expiry, since closeout trades simply drop out of PNL Detail. Using my recommended approach means that the trade stays in PNL Detail and correctly reflects the P&L at expiry. It also has the advantage that the parent contract can be amended post expiry/cascade, which is useful given that it is fairly common that some kind of correction is required around the cascade events.

So, with a combination of modelling the monthly contract in one transaction and the non-closeout approach for the quarterly and yearly contracts, you should find that you don’t have to introduce some specific logic in the P&L calculations themselves or the reporting layer.

Download PDF version

This field is for validation purposes and should be left unchanged.