Portfolio Margin Considerations with the Automated Backtester (Part 2)

Last time I started to explain portfolio margin (PM) and why a model is needed to calculate it.

I previously thought the automated backtester incapable of calculating/tracking PM requirement (PMR) without modeling equations [differential, such as Black-Scholes] and dedicated code, but this is not entirely correct. The database will have historical price data for all options. The automated backtester can simulate position value at different underlying price changes by “walking the chain.” In order to know the price of a particular option if the underlying were to instantaneously move X% higher (lower), I can look to the strike price that is X% lower (higher) than the current market price. Some rounding will have to be involved because +/- 3%, 6%, 9%, and 12% will not fall square on 10- or 25-point increment strikes that may be available in the data set (in highest liquidity and therefore most reliable prices).

The automated backtester would not be able to perfectly calculate PMR. In order to be perfect, the backtester would need to model the risk graph continuously on today’s date, which would require implementation of differential calculus. Rounding of the sort that I described above is not entirely precise. Also in order to be perfect, we would have to match the PM algorithm used by the brokerage(s). These are kept proprietary.

Another reason the automated backtester would not be able to perfectly calculate PMR is because walking the chain does not take into account implied volatility (IV) changes. [Some] brokerages also stress portfolios with increased IV changes to the downside when calculating PMR.

We can approximate the additional IV stress a couple different ways. First, instead of stressing up and down X% we could stress more to the downside. Second, we could use vega values from the data set in addition to walking the chain. Vega is the change in option price per 1% change in IV. If we want to simulate a 10% IV increase, then, we could add vega * 10 to short positions. This would probably not be exact because vega does not remain constant as IV changes. Vomma, a second-order greek that will not be included in the data set, is the change in vega per 1% increase in IV. The change in option price is actually the sum of X unequal terms in a series as defined by vega and vomma (along with third-order greeks and beyond to be absolutely precise).

Regardless of the imprecision, I think some PM estimate given by logic built into the automated backtester would be better than nothing. And my preference would always be to overestimate rather than underestimate PMR.