Libor Forward Process

[Fabio Ramponi]

Hi all,

I was trying to calibrate the Libor Forward Model, and I have a few questions for you:

1) In the market cap volatility matrices, usually the first quoted cap is referred to the rate which fixes today and has accrual start date 2 business days after today, is it right? If so, in order to have a coherent structure for the forward rates to be used in LMM, the first fixing date should be today (or the term structure reference date) and the first accrual start date 2 business days after.

In lfmprocess.cpp (line 49 and following), on the contrary, it seems that today is the first accrual start date (the settlement) and the first fixing date is 2 days before.

2) in lfmprocess.cpp, lines 49-70, where the times vector are filled, the accrual start and accrual end times are evaluated starting from the settlement date, while the fixing times from the startDate, which is n days before settlement. Could you please explain why the reference date is not the same for all the vectors?

3) the day counter used to calculate the times vectors in lfmprocess.cpp seems to be the index day counter (see line 44), but, to remain coherent with all the other QuantLib instruments, it wouldn't be better to use the term structure day counter instead?

Thanks a lot,

Fabio

----
Email.it, the professional e-mail, gratis per te: clicca qui

Sponsor:
I migliori fun sound Jamba!
Clicca qui

[quantlib-users-admin]

> Hi Fabio,
>
> in general the starting dates and the day counting etc. is chosen to be=
 
> (hopefully;-)  "compatible" with the existing cap/floor pricing to ensu=
re
> that the LMM cap/floor prices match to the prices of the BlackCapFloorE=
ngine
> in blackcapfloorengine.hpp or test-suite/capfloor.cpp
>
> You wrote:
> > 1) In the market cap volatility matrices, usually the first quoted ca=
p is
> > referred to the rate which fixes today and has accrual start date 2
> > business days after today, is it right? If so, in order to have a coh=
erent
> > structure for the forward rates to be used in LMM, the first fixing d=
ate
> > should be today (or the term structure reference date) and the first
> > accrual start date 2 business days after.
> agree.
> > In lfmprocess.cpp (line 49 and following), on the contrary, it seems =
that
> > today is the first accrual start date (the settlement) and the first =
fixing
> > date is 2 days before.
> The reference date of the index term structure is the settlement date, =
which
> is usually today+2 business days (line 49, the term structure is assume=
d to
> be spot, meaning today+2 business days, see also e.g. test-suite/
> capfloor.cpp, routine setup()). startDate of first fixing date is today=
 (line
> 50). The first accrual start date is again usually the settlement date =
(line
> 69).
>
> > 2) in lfmprocess.cpp, lines 49-70, where the times vector are filled,=
 the
> > accrual start and accrual end times are evaluated starting from the
> > settlement date, while the fixing times from the startDate, which is =
n days
> > before settlement. Could you please explain why the reference date is=
 not
> > the same for all the vectors?
> The times vector are intend to be compatible to them in ql/Instrument/
> capfloor.cpp (startTimes_, endTimes_ and fixingTimes_) to ensure consis=
tent
> pricing. Shortly spoken the accrual times are related to the term struc=
ture
> therefore they are evaluated using the term structure reference date, w=
hich
> is the settlement date. The fixing times are used to determ the volatil=
ity of
> the caplets. Therefore they are evaluated from startDate. (see also
> blackcapfloorengine.cpp)
>
> > 3) the day counter used to calculate the times vectors in lfmprocess.=
cpp
> > seems to be the index day counter (see line 44), but, to remain coher=
ent
> > with all the other QuantLib instruments, it wouldn\'t be better to us=
e the
> > term structure day counter instead?
> The initial values of the LMM libor rates are taken from the indexed co=
upons,
> which are using the method indexFixing() from the index object. Therefo=
re the
> initial rates are calculated using the day counter of the index (s.
> xibor.cpp, line 108). To be consistent and to make Monte Carlo pricing =
easier
> we are IMO better off using the index day counter for the times vectors=
.
> Please notice that accrualStartTimes and accrualEndTimes aren't used
> internally by the LiborForwardModelProcess. They are just calculated fo=
r
> convenience reasons to make life for MC pricing easier, s. test-suite/
> libormarketmodelprocess.cpp. (It is safe to use different day counters =
for
> the term structure within the index or for the volatility term structur=
e

> within the LfmHullWhitePrameterization etc.)
>
> hope that this helps and please comment on inconsistencies.
>
> cheers
>  Klaus
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, securit=

y?
> Get stuff done quickly with pre-integrated technology to make your job =
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Klaus Spanderen]

Hi Fabio,

in general the starting dates and the day counting etc. is chosen to be
(hopefully;-)  "compatible" with the existing cap/floor pricing to ensure
that the LMM cap/floor prices match to the prices of the BlackCapFloorEngine
in blackcapfloorengine.hpp or test-suite/capfloor.cpp

You wrote:
> 1) In the market cap volatility matrices, usually the first quoted cap is
> referred to the rate which fixes today and has accrual start date 2
> business days after today, is it right? If so, in order to have a coherent
> structure for the forward rates to be used in LMM, the first fixing date
> should be today (or the term structure reference date) and the first
> accrual start date 2 business days after.
agree.
> In lfmprocess.cpp (line 49 and following), on the contrary, it seems that
> today is the first accrual start date (the settlement) and the first fixing
> date is 2 days before.
The reference date of the index term structure is the settlement date, which
is usually today+2 business days (line 49, the term structure is assumed to
be spot, meaning today+2 business days, see also e.g. test-suite/
capfloor.cpp, routine setup()). startDate of first fixing date is today (line
50). The first accrual start date is again usually the settlement date (line
69).

> 2) in lfmprocess.cpp, lines 49-70, where the times vector are filled, the
> accrual start and accrual end times are evaluated starting from the
> settlement date, while the fixing times from the startDate, which is n days
> before settlement. Could you please explain why the reference date is not
> the same for all the vectors?
The times vector are intend to be compatible to them in ql/Instrument/
capfloor.cpp (startTimes_, endTimes_ and fixingTimes_) to ensure consistent
pricing. Shortly spoken the accrual times are related to the term structure
therefore they are evaluated using the term structure reference date, which
is the settlement date. The fixing times are used to determ the volatility of
the caplets. Therefore they are evaluated from startDate. (see also
blackcapfloorengine.cpp)

> 3) the day counter used to calculate the times vectors in lfmprocess.cpp
> seems to be the index day counter (see line 44), but, to remain coherent
> with all the other QuantLib instruments, it wouldn\'t be better to use the
> term structure day counter instead?
The initial values of the LMM libor rates are taken from the indexed coupons,
which are using the method indexFixing() from the index object. Therefore the
initial rates are calculated using the day counter of the index (s.
xibor.cpp, line 108). To be consistent and to make Monte Carlo pricing easier
we are IMO better off using the index day counter for the times vectors.
Please notice that accrualStartTimes and accrualEndTimes aren't used
internally by the LiborForwardModelProcess. They are just calculated for
convenience reasons to make life for MC pricing easier, s. test-suite/
libormarketmodelprocess.cpp. (It is safe to use different day counters for
the term structure within the index or for the volatility term structure
within the LfmHullWhitePrameterization etc.)

hope that this helps and please comment on inconsistencies.

cheers
 Klaus

Hi Klaus,
I have some comments about your reply to Fabio.


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".
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.

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. 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.

What do you think?

Thanks for your help!
Regards,
Marco





---------- Initial Header -----------

[Luigi Ballabio]

On 04/24/2006 08:47:49 AM, [hidden email] 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".

Today is natural enough, but it is not the only natural choice. On a  
desk I've been working with, all instruments were traded with two  
settlement days; therefore, it was natural to have the reference date  
of the curve at two business days from today.

Later,
        Luigi


----------------------------------------

Ogden's Law:
         The sooner you fall behind, the more time you have to catch up.

Luigi,
I agree that the choice of a reference date as two working days from today is a good choice, but in this case it sounds strange to me considering the reference date as that date for which discount = 1.
Moreover there are some instruments for which the settlement date is three working days from today (for example the bonds).
Any choice is good, but in the lfmprocess.cpp, according me there is no enough coherence among dates, probably due to fact that all the code we developed starting from QuantLib is based on the assumption of today as reference date.

Thanks,
Marco

---------- Initial Header -----------

[Luigi Ballabio]

On 04/24/2006 09:47:48 AM, [hidden email] wrote:
> I agree that the choice of a reference date as two working days from
> today is a good choice, but in this case it sounds strange to me
> considering the reference date as that date for which discount = 1.

I'm failing to get the difference. However, it was just a digression:  
as you said,

> Any choice is good

and I agree that we should check the date calculations in the LFM  
process.

Luigi


----------------------------------------

Humphrey's Requirements Uncertainty Principle:
        For a new software system, the requirements will not be
        completely known until after the users have used it.

[quantlib-users-admin]

>
> On 04/24/2006 08:47:49 AM, [hidden email] wrote:
> > The reference date of the term structure is defined as the date at
> > which discount =3D 1 (see file termstructure.hpp), and it seems natur=
al
> > to me that it should be today, unless we want to make some kind of
> > "forward pricing".
>
> Today is natural enough, but it is not the only natural choice. On a  
> desk I've been working with, all instruments were traded with two  
> settlement days; therefore, it was natural to have the reference date  =

> of the curve at two business days from today.
>
> Later,
> Luigi
>
>
> ----------------------------------------
>
> Ogden's Law:
>          The sooner you fall behind, the more time you have to catch up=

.
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, securit=
y?
> Get stuff done quickly with pre-integrated technology to make your job =
easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geron=
imo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=120709&bid&3057&dat=12164=
2
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Klaus Spanderen]

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