Re: Libor Forward Process

Posted by Klaus Spanderen on
URL: http://quantlib.414.s1.nabble.com/Libor-Forward-Process-tp4723p4725.html

Hi Marco,

you wrote:

> The reference date of the term structure is defined as the date at which
> discount = 1 (see file termstructure.hpp), and it seems natural to me that
> it should be today, unless we want to make some kind of "forward pricing".

If you look at the test-suite for interest rate derivatives, e.g. cap/floor,
swap or swaptions then you'll see that this "kind of forward pricing" is the
standard approach within the QL-test-suite. LFM Process is designed to work
closely together with the calibration routines in ql/ShortRateModels/
LiborMarketModels. These classes support only the standard convention, first
fixing is today, settlement in n=settlementDays, term structure referenceDate
= settlementDate. I'm calibrating using todays spot (usually today+2 days;-)
market data from the screen, which implies that the fixing schedule of my
process is fixed.I don't want to create the illusion of flexibility in
lfmprocess.cpp, which isn't supported by the downstream classes.

Brigo, Mercurio in "Interest Rate Models", chapter 6.17 shows a nice algorithm
to derive more flexible processes given such a calibrated "standart process".
If I get some time I'll implement this algorithm on top of the existing
processes to allow e.g. forward starting deals.

> And the implementation in lfmprocess.cpp is slightly different from the one
> in the blackcapfloorengine (actually in the capfloor.cpp) file. In
> capfloor.cpp, the fixingTimes are computed using the yearFraction method
> going from today to the fixingDate, and today is found as Date today =
> Settings::instance().evaluationDate();
> So, "today" is independent of the choice of the reference date, while this
> is not the case in the implementation of the libor forward process. Anyway
> I'm a little bit puzzled about the definition of referencedate of the term
> structure and I'll probably send a mail just to discuss this topic.

agreed. The current implementation of lfmprocess sets today = referenceDate -
settlementDays to be consistent with the calibration pricer.

> Second, I'm not sure I've understood why your choice of the daycounter
> should make easier the Monte Carlo simulation, but anyway the index
> daycounter is used to determine the initial values of the forward rates
> just in the sense that they are used to compute the year fraction between a
> start and an end date, but it is not used to compute neither fixing nor
> start nor end times.

IMO the problem arrives because we can have three (or four) day counters used
to define a LFM process namely the index day counter, the yield day counter,
the vola term structure day counter (and your correlation model might give
you another day counter).  To don't mix them up I forced the LFM process to
use one day counter internally for all calculation, the index day counter.
Any other choice is as good as this one. This decision matters if a
"customer" of this class is doing Monte-Carlo simulation because the time
grid for the MC simulation is then defined with respect to the index day
counter. E.g. it is safe to use different day counters to initialise a
LfmHullWhiteParameterization but internally everything get mapped onto the
index day counter.

> According to me, in order to compute such times, an
> independet daycounter should be used, for example the
> TermStructure::dayCounter(), as (again) it is actually done in capfloor.cpp
> for example.

The problem here IMO is that the pricing engine in ql/PricingEngines/CapFloor/
blackcapfloorengine.cpp ends up with two term structures (Cap instrument and
BlackModel) and assumes that the day counters of them are the same without
checking it.  (s. line 30 and 34)

thoughts?

cheers
 Klaus