IndexedCoupon and ParCoupon cashFlows

[e.michelotti]

Hi all,
I have two questions on CashFlow classes.

1- IndexedCoupon. The method fixing computes the fixing value according
to a specific index on a specific fixing date.
It shifts the fixingDate ahead by settlementDays to have the accrualStartDate
and it computes the accrualEndDate shifting ahead
the accrualStarDate by the index frequency.
The problem arise when we have a schedule from a FlaotingRateNote (which
is usually udjusted).
in fact if we have the following date in the FRN schedule:
start: 6-Nov-06 end 4-May-07
the UpFrontIndexedCoupon method computes the accrualEnd Date of the period
at 7-May-07
But the real accrualEnd coming from the floating rate note is 4-May-07.
And Obviosly the fixing rate is not correct.
Do you agree with me?
Have you ever encountered the same problem in matching the floating rate
note price and cashFlows?

2- MUCH MORE IMPORTANT
In the ParCoupon class the day counter is extracted from the termStructure
(index->termStructure()->dayCounter())
Is there a reason for that?
Because it causes a bunch of problem.
In fact if you try to instantiate a vector of FloatingRateCoupon without
spread non matter of the dayCounter,
the cashFlows are perfect.
But if you add spread you get that each cashflow is multiplied by the accrualPeriod
computed with the termStructure's DayCounter,
non matter of the DayCounter embedded in the index.
Suppose you have a 30bps spread FRN act360.
If the termStructure is on act365 or act7act basis (which are always the
case) all the spreads are multiplied for accrual periods which are smaller
than the real ones, leading to evident mispricing.
Do you agrre with me? Is there any reason why the ParCoupon class make this
calculation?

Many thanks to all,
Enrico



Hi all,
I have two questions on CashFlow classes.

1- IndexedCoupon. The method fixing computes the fixing value according
to a specific index on a specific fixing date.
It shifts the fixingDate ahead by settlementDays to have the accrualStartDate
and it computes the accrualEndDate shifting ahead
the accrualStarDate by the index frequency.
The problem arise when we have a schedule from a FlaotingRateNote (which
is usually udjusted).
in fact if we have the following date in the FRN schedule:
start: 6-Nov-06 end 4-May-07
the UpFrontIndexedCoupon method computes the accrualEnd Date of the period
at 7-May-07
But the real accrualEnd coming from the floating rate note is 4-May-07.
And Obviosly the fixing rate is not correct.
Do you agree with me?
Have you ever encountered the same problem in matching the floating rate
note price and cashFlows?

2- MUCH MORE IMPORTANT
In the ParCoupon class the day counter is extracted from the termStructure
(index->termStructure()->dayCounter())
Is there a reason for that?
Because it causes a bunch of problem.
In fact if you try to instantiate a vector of FloatingRateCoupon without
spread non matter of the dayCounter,
the cashFlows are perfect.
But if you add spread you get that each cashflow is multiplied by the accrualPeriod
computed with the termStructure's DayCounter,
non matter of the DayCounter embedded in the index.
Suppose you have a 30bps spread FRN act360.
If the termStructure is on act365 or act7act basis (which are always the
case) all the spreads are multiplied for accrual periods which are smaller
than the real ones, leading to evident mispricing.
Do you agrre with me? Is there any reason why the ParCoupon class make this
calculation?

Many thanks to all,
Enrico

[Daniele De Francesco-2]

Hi Enrico,

I see your previous similar question from the 29th of July went
unanswered... I definitely think that you are right and that the ParCoupon
class should use the dayCount of the index and not of the TermStructure that
the index relies on.
I don't know what the other people on the list think, but I think that if
you wanted to submit a patch, you definitely should.

Am I right to assume that point 2 or your latest message is about the same
question?

About point 1 I am confused, because I can't find the file in which those
dates are set. I would really like to help (if I can), but can you point me
to the right portion of the code?

-Daniele


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Tuesday, August 10, 2004 3:02 AM
To: [hidden email]
Subject: [Quantlib-users] IndexedCoupon and ParCoupon cashFlows


Hi all,
I have two questions on CashFlow classes.

1- IndexedCoupon. The method fixing computes the fixing value according to a
specific index on a specific fixing date. It shifts the fixingDate ahead by
settlementDays to have the accrualStartDate and it computes the
accrualEndDate shifting ahead the accrualStarDate by the index frequency.
The problem arise when we have a schedule from a FlaotingRateNote (which is
usually udjusted). in fact if we have the following date in the FRN
schedule:
start: 6-Nov-06 end 4-May-07
the UpFrontIndexedCoupon method computes the accrualEnd Date of the period
at 7-May-07 But the real accrualEnd coming from the floating rate note is
4-May-07. And Obviosly the fixing rate is not correct. Do you agree with me?
Have you ever encountered the same problem in matching the floating rate
note price and cashFlows?

2- MUCH MORE IMPORTANT
In the ParCoupon class the day counter is extracted from the termStructure
(index->termStructure()->dayCounter())
Is there a reason for that?
Because it causes a bunch of problem.
In fact if you try to instantiate a vector of FloatingRateCoupon without
spread non matter of the dayCounter, the cashFlows are perfect. But if you
add spread you get that each cashflow is multiplied by the accrualPeriod
computed with the termStructure's DayCounter, non matter of the DayCounter
embedded in the index. Suppose you have a 30bps spread FRN act360. If the
termStructure is on act365 or act7act basis (which are always the
case) all the spreads are multiplied for accrual periods which are smaller
than the real ones, leading to evident mispricing. Do you agrre with me? Is
there any reason why the ParCoupon class make this calculation?

Many thanks to all,
Enrico

[e.michelotti]

Hi Daniele,
You are right,
the second question was about the same issue.

For the first part the reference code is on xibor.cpp,
on fixing(const Date &) const.
The date arrive from the IndexedCoupon cashFlow
please look at indexedcoupon.hpp
on function fixing().
Many thank to you,
enrico
<>-- Messaggio originale --
<>From: Daniele De Francesco <[hidden email]>
<>To: "'[hidden email]'" <[hidden email]>,
<> [hidden email]
<>Subject: RE: [Quantlib-users] IndexedCoupon and ParCoupon cashFlows
<>Date: Wed, 11 Aug 2004 09:04:27 -0400
<>
<>
<>Hi Enrico,
<>
<>I see your previous similar question from the 29th of July went
<>unanswered... I definitely think that you are right and that the ParCoupon
<>class should use the dayCount of the index and not of the TermStructure
that
<>the index relies on.
<>I don't know what the other people on the list think, but I think that
if
<>you wanted to submit a patch, you definitely should.
<>
<>Am I right to assume that point 2 or your latest message is about the
same
<>question?
<>
<>About point 1 I am confused, because I can't find the file in which those
<>dates are set. I would really like to help (if I can), but can you point
<>me
<>to the right portion of the code?
<>
<>-Daniele
<>
<>
<>-----Original Message-----
<>From: [hidden email] [mailto:[hidden email]]
<>Sent: Tuesday, August 10, 2004 3:02 AM
<>To: [hidden email]
<>Subject: [Quantlib-users] IndexedCoupon and ParCoupon cashFlows
<>
<>
<>Hi all,
<>I have two questions on CashFlow classes.
<>
<>1- IndexedCoupon. The method fixing computes the fixing value according
to
<>a
<>specific index on a specific fixing date. It shifts the fixingDate ahead
<>by
<>settlementDays to have the accrualStartDate and it computes the
<>accrualEndDate shifting ahead the accrualStarDate by the index frequency.
<>The problem arise when we have a schedule from a FlaotingRateNote (which
<>is
<>usually udjusted). in fact if we have the following date in the FRN
<>schedule:
<>start: 6-Nov-06 end 4-May-07
<>the UpFrontIndexedCoupon method computes the accrualEnd Date of the period
<>at 7-May-07 But the real accrualEnd coming from the floating rate note
is
<>4-May-07. And Obviosly the fixing rate is not correct. Do you agree with
<>me?
<>Have you ever encountered the same problem in matching the floating rate
<>note price and cashFlows?
<>
<>2- MUCH MORE IMPORTANT
<>In the ParCoupon class the day counter is extracted from the termStructure
<>(index->termStructure()->dayCounter())
<>Is there a reason for that?
<>Because it causes a bunch of problem.
<>In fact if you try to instantiate a vector of FloatingRateCoupon without
<>spread non matter of the dayCounter, the cashFlows are perfect. But if
you
<>add spread you get that each cashflow is multiplied by the accrualPeriod
<>computed with the termStructure's DayCounter, non matter of the DayCounter
<>embedded in the index. Suppose you have a 30bps spread FRN act360. If
the
<>termStructure is on act365 or act7act basis (which are always the
<>case) all the spreads are multiplied for accrual periods which are smaller
<>than the real ones, leading to evident mispricing. Do you agrre with me?
<>Is
<>there any reason why the ParCoupon class make this calculation?
<>
<>Many thanks to all,
<>Enrico
<>
<>

[Nicolas Di Césaré]

Le mer 11/08/2004 à 15:04, Daniele De Francesco a écrit :
> Hi Enrico,
>
> I see your previous similar question from the 29th of July went
> unanswered... I definitely think that you are right and that the ParCoupon
> class should use the dayCount of the index and not of the TermStructure that
> the index relies on.
> I don't know what the other people on the list think, but I think that if
> you wanted to submit a patch, you definitely should.
>

Hi all,

UpFrontIndexedCoupon and InArrearCoupon classes use the index dayCount.
template function IndexedCouponVector allows you to create a Xibor leg
set up-front or set in-arrear. Finally, using that leg you can build
Swap and Cap/Floor.

SimpleSwap is not build using a leg but with an "hard coded" ParCoupon.
Moreover Swaption, SwaptionHelper and SwapRateHelper use SimpleSwap.

We can add template argument to these classes to obtain more flexibility
or create a new set of classes with the "correct" Coupon.

What do you thing about that?




--
Nicolas Di Césaré <[hidden email]>