The other day I found this piece of code in QuantLib

QL_REQUIRE(values[i]>0.0, "non positive fixing (" << values[i] << ") at date " << dates[i] << " not allowed");

Puzzle: Where is this snippet taken from ? Anyway, financial markets do not care. We currently have negative Euribor Fixings for 1w and 2w. Brokers started to quote zero strike floors on Euribor 3M and 6M already a year ago or so. Now, market participants start to assign significant premia to zero strike floors on the EUR CMS 10y rate.

The classic market model for options on Euribor or a swap annuity is the Black76 model

implying zero probability for negative underlying values, so a zero strike floor is worth zero always. One way to get around this is the shifted Black76 model

with a positive (or of course zero) shift . For EUR caps and floors is a common value currently.

It is quite simple to give a solution of such a shifted model in terms of the original model: Set , then you have the original model back, but in instead of . So to get an option price, plug in the shifted forward and the shifted strike into the original option pricing formula.

This is the density of the underlying implied by this model at (years) with an initial forward level of and a volatility of :

The model sets the lower bound for the underlying rate to . One can ask what the classic (i.e. non-shifted) Black76 implied volatility for option prices produced by our shifted model is. Here you go.

The shift parameter has produced a skew. Actually shifted underlyings have been a popular technique to produce skews, e.g. in the Libor market model, for a long time. Here our motivation is different, namely to produce negative rates.

You will have noticed that there is no implied volatility for strikes near zero, even if they are positive. That is because the call option price function in the shifted model looks like this (the red line)

starting at which is the sum of the forward and the shift and crossing the y axis (not very prominent in this plot) *above* the forward level because of its convexity, thus producing non-attainable prices for the non-shifted Black model. The green line marks the maximum price attainable in a non-shifted Black76 model.

I should say that I am always talking about non discounted prices – the discount or in case of swaptions the annuity factor is unity.

Next we need a shifted SABR model. It is constructed the same way as the shifted Black76 model:

with and and our shift . Here is a density with same parameters as above and .

The negative density for strikes near is nothing special, we already know this defect from the classic non-shifted Hagan model (we are using the standard expansion from 2002 here). The point is again that the density now covers the region from to zero strike level.

It seems that brokers like ICAP changed their primary model for swaption smiles to this one. They publish an ATM matrix together with a shift matrix assigning an individual shift to each option tenor / swap length pair. The shifts are constant across option tenors, but different for the different underlyings. At the moment the shifts are for the 1y underlying, going down to for the 30y underlying. They also publish smile spreads in the usual way, but as differences of *shifted* lognormal itm or otm volatilities and the *shifted* atm volatility.

In QuantLib we need to do several things to adopt these new quotation standards. I will try to package the changes into a pull request soon. The highlights are as follows.

The Smile Section class needs to know what kind of volatility nature it represents.

enum Nature { ShiftedLognormal, Normal }; SmileSection(const Date& d, const DayCounter&a dc = DayCounter(), const Date& referenceDate = Date(), const Nature nature = ShiftedLognormal, const Rate shift = 0.0);

As you can see we can also have normal smile sections. This is another standard for volatility quotation using the normal Black model

as a basis.

The ATM matrix now takes a shift matrix as an optional parameter.

SwaptionVolatilityMatrix::SwaptionVolatilityMatrix( const Calendar& cal, BusinessDayConvention bdc, const std::vector<Period>& optionT, const std::vector<Period>& swapT, const std::vector<std::vector<Handle<Quote> > >& vols, const DayCounter& dc, const bool flatExtrapolation, const std::vector<std::vector<Real> >& shifts)

The two swaption volatility cubes need to be adapted as well. Their interface does not change, but we have to use a shifted SABR model for the SABR cube for example. Also the moneyness definition for smile spread interpolation has to be adapted. And some other things I guess.

To do CMS pricing we need to get our hands on some CMS coupon pricer. My favourite one is the `LinearTsrPricer`

(it’s fast, it respects the put call parity, it just does not disappoint you). A terminal swap rate model for CMS coupons does not depend on certain strike ranges or a particular model for vanilla swaption valuation. Such a model is given by a mapping

where is the coupon payment date and the annuity of the underlying swap rate . Then (integration by parts) the npv of a general CMS coupon

is given by

with begin the fixing date of the coupon, and prices of market receiver and payer swaptions and weights This nice and concise derivation is taken from the three volume Piterbarg bible on interest rate derivatives.

The *linear* terminal swap rate model is given by a linear function . is determined by a no arbitrage condition already, but is free, and can for example be linked to a one factor mean reversion. Or just set as a free user choice directly.

The derivation says that you should integrate over the range where you have non zero put or call prices. For a shifted lognormal smile section input this means that we need to integrate over for a plain CMS coupon, if is the shift. The shift can be read from the `SmileSection`

which is input to the CMS coupon pricers and we are done.

The last thing I did so far is to make the Markov Functional Model work with the shifted smile sections. The result is a fully dynamic and consistent model which can reproduce densities given by marginal shifted SABR inputs for example. This way we get consistent with the TSR CMS pricing described above.

Enough for today, I will go into more details about the Markov functional model (and the linear TSR pricer) in one of the next posts.