seasonality for inflation term structures is currently in the advanced design stage with Piero Del Boca doing most of the coding work (commentaries provided by Luigi, Nando, Marco Bianchetti and myself). So far the discussion has been off-line but it seemed to everyone involved that we've got to a stage where public comments would acce
lerate the process. Below is an introduction to seasonality in inflation, the proposed interface changes and additions, and a (brief) summary of the discussion so
far. The DRAFT code is attached.
This post is quite long - I've put a set of feedback questions at the end, so just scroll down if you want to see them.
N.B. - the usual disclaimers apply!
Introduction
Zero and YoY inflation term structures are generally built
from ZCIIS and YYIIS quotes respectively. These are available on, e.g. Bloomberg from a variety of providers. They are generally only available at integer yearly maturities hence the bits-in-between need to be filled in somehow. Unlike nominal term structures, there is evidence of yearly patterns in, e.g. historical monthly CPI fixings. This is important for the mark-to-market of instruments priced from these term structures that pay off at different points to the quotes. Clearly this fill-in is not on a no-arbitrage basis. It is generally small.
A good introduction is available at http://papers.ssrn.com/sol3/papers.
cfm?abstract_id=583642, Impact of Seasonality in Inflation Derivatives Pricing, by Belgrade and Benhamou.Theoretically:
- if seasonality is multiplicative for the zero inflation curve then the seasonality correction required for the year-on-year curve is very, very small (effects from changes of measure).
- if seasonality is additive for zero inflation then it is non-stationary for year-on-year.
Empirically:
- if you are interested then get the UK RPI series (it goes back to 1947) and try using X11 to remove the trend (the current X12 takes much longer to implement ... ), or use the seasonality estimator in any number of time-series packages, e.g. R. Then see what you think it looks like. Arguably seasonality could be additive for the last fe
w years but multiplicative over longer horizons. Up to you!
- seasonality is also a way of getting in future expected one-off events into the term structure,
when
these do not occur at integer year points.
QuantLib: Inflation Term Structures + Seasonality
We want to give users with the ability to provide a seasonality correction to the term structures. The aim is for this to be as non-invasive as possible (does not break existing code) but for seasonality to be an inherent part of the term structures using a bridge-like design pattern, with an addin class called Seasonality. Thus, e.g. for ZeroInflationTermStructure a constructor becomes:
ZeroInflationTermStructure(const DayCounter& dayCounter,
&
nbsp; const Period&
lag,
Frequency frequency,
Rate baseZeroRate,
const Handle<YieldTermStructure>& yTS,
const boost::shared_ptr<Seasonality> &seasonality = boost::shared_ptr<Seasonality>());
The get/set is defined in the base InflationTermStructure class as:
public:
void setSeasonality(const boost::shared_ptr<Seasonality> &seasonality = boost::shared_ptr<Seasonality>());
boost::shared_ptr<Seasonality> seasonality() const;
bool hasSeasonalityCorrection() const;
If seasonality is present it is used. If you setSeasonality() then you
remove it. Setting will interact correctly with observability.
The interface for Seasonality is very simple. A class derived from seasonality class must
provide implementations for correcting both rates - note that these can, of course, be dummies returning the rate they were given. Note also that when these methods are called they are given "this" and the method can downcast it to a Zero- or YoY- term structure safely because it will only be called from the respective class.
class Seasonality {
public:
//! \name Seasonality interface
// <at> {
virtual Rate correctZeroRate(const Date &d, const Rate r,
 
; const InflationTermStructure *iTS) const = 0;
virtual Rate correctYoYRate(const Date
&d, const Rate r,
const InflationTermStructure *iTS) const = 0;
// <at> }
virtual ~Seasonality() {}
};
There are obviously details missing, these are provided in the concrete constructors for the derived classes, see attached files. Hierarchy:
&
nbsp; (abstract) Seasonality
(abstract)
MultiplicativeSeasonality and (abstract) AdditiveSeasonality
(concrete) StationaryMultiplicativeSeasonality as on left/tbd
and
(concrete) NonStationaryMultiplicativeSeasonality as on left/tbd
Current DRAFT implementations for the Multiplicative versions and updated term structures are attached.
Discussion
1) Alternative design: by inh
eritance (... please let me know if you feel I've misquoted you!)
<Luigi>
No, I wasn't suggesting to use a spread. I was just saying that
we
could use the same pattern as for other curves, as in:
class InflationCurve {
// no seasonality correction embedded here
};
class SeasonalityCorrectedInflationCurve { // terrible name, just to
make myself clear
SeasonalityCorrectedInflationCurve(Handle<InflationCurve>,
shared_ptr<Seasonality>);
Real inflationImpl { /* adds correction to the underlying curve */ } };
</Luigi>
response
<Chris>
as currently implemented, the seasonality doesn't cause much extra complexity in the base class, so I suggest leaving it in. I don't think that the added complexity of an extra class specifically including it adds enough to be
worth having (seasonality is intrinsic to inflation too).
...
and you know some specific properties (e.g. effect sums to unity over
a year, repeats, etc.),
that doesn't seem like the right way to do it.
</Chris>
2) Alternative design: for govt bonds
This does assume that you are bootstraping from either YYIIS or ZCIIS.
To bootstrap a govt inflation curve with seasonality would require a design update. Anybody have any comments on this? E.g. "I really need this", "not now", ...
Note - this is not a why-not-have-it-anyway because the bootstrapping for govt linkers is very different as later bonds can have an effect on earlier parts of the TS.
Summary / Questions
Seasonality can be important in pricing inflation structures (especially derivatives) so we propose to add it. Given that it is intrinsic to inflation we feel that it should be inherent to the term struc
tures (although ignore-able), also since it is relatively simple to add in. Currently the Multiplicative version is nearly ready.
Alternative designs (that we decided against) would include seasonality via inheritance, or provide for bootstrapping using govt inflation linkers. Given that the govt market and swap market are fairly separate we don't aim to cover the govt market now, also for technical reasons.
Note that we essentially view seasonality as an empirical, non-parametric, add-in. We do not provide methods or models to calculate it from data - this is out of scope.
Q1 - What is missing/wrong for the current objectives (seasonality for swap curves)?
Q2 - What other objectives are important for you? (e.g. parametric models, govt mkt)
ALL SUGGESTIONS WELCOME ... especially if they come with code examples!
N.B. - t
he usual disclaimers apply!
RSS Feed