IndexedCoupon and ParCoupon cashFlows

[e.michelotti]

Hi all,
I think that a template function could be a good idea for the swap class,
in order to improve its flexibility.
On the other hand the simple swap should remain
a "simple" instrument as coded in the market.
My question was about the way the ParCoupon class computes the
accrualPeriod using the termStrucure DayCounter
and forgetting the index dayCounter.
I think this could be a problem, especially if the swap (or any other floating
leg)
has a spread over Libor.
More:
I think that the correct way to compute the cashFlow amount shoud be:

((discountStart/discountEnd-1.0)/accrualPeriod1() + spread())*AccrualPeriod2()*Notional()

where accrualPeriod1 is the natural accrual period of the rate (suppose
act360 for deposit)
and accrualPeriod2 is the accrual period of the instrument
(it could be different from the natual accrualPeriod).
But in this case also the ParCoupon class would need a DayCounter as input.

What do you think?
enrico

[Nicolas Di Césaré]

Selon [hidden email]:

> Hi all,
> I think that a template function could be a good idea for the swap class,
> in order to improve its flexibility.
> On the other hand the simple swap should remain
> a "simple" instrument as coded in the market.

Of course.

> My question was about the way the ParCoupon class computes the
> accrualPeriod using the termStrucure DayCounter
> and forgetting the index dayCounter.
> I think this could be a problem, especially if the swap (or any other
> floating
> leg)
> has a spread over Libor.
> More:
> I think that the correct way to compute the cashFlow amount shoud be:
>
> ((discountStart/discountEnd-1.0)/accrualPeriod1() +
> spread())*AccrualPeriod2()*Notional()
>
> where accrualPeriod1 is the natural accrual period of the rate (suppose
> act360 for deposit)
> and accrualPeriod2 is the accrual period of the instrument
> (it could be different from the natual accrualPeriod).
> But in this case also the ParCoupon class would need a DayCounter as input.
>
> What do you think?

I am agree with you. In IndexedCoupon class (and derived ones), the constructor
allows you to provide the instrument daycounter (I will complete the
documentation of IndexedCouponVector tonight or tomorrow).

Thus we have to replace ParCoupon by UpFrontIndexedCoupon and related function
in SimpleSwap.

Any objection?

Nicolas


--
Nicolas Di Césaré
http://nicolas.dicesare.free.fr

[e.michelotti]

Yes I have an objection.
Before doing that we should be sure that IndexedCoupon
properly computes the cashFlow. And I really dubt.
The problem is that the accrual end that is computed in the index by
shifting ahead the accrual start and not considering the real accrualEnd
date which could be different
(especially when the note is adjusted)

I think a good solution would be to insert a new function in the Xibor:
fixing(Date &startDate, Date &endDate) in such a way that it compute the
forward from these two dates,
and escaping any calculation of accrualEnd.
This function could be called properly from the cashFlow class.
What do you think?

Enrico.
<>-- Messaggio originale --
<>From: Nicolas Di Césaré <[hidden email]>
<>To: [hidden email]
<>Cc: QuantLib <[hidden email]>,
<> [hidden email]
<>Subject: Re: [Quantlib-users] IndexedCoupon and ParCoupon cashFlows
<>Date: Thu, 12 Aug 2004 17:48:14 +0200
<>
<>
<>Selon [hidden email]:
<>
<>> Hi all,
<>> I think that a template function could be a good idea for the swap class,
<>> in order to improve its flexibility.
<>> On the other hand the simple swap should remain
<>> a "simple" instrument as coded in the market.
<>
<>Of course.
<>
<>> My question was about the way the ParCoupon class computes the
<>> accrualPeriod using the termStrucure DayCounter
<>> and forgetting the index dayCounter.
<>> I think this could be a problem, especially if the swap (or any other
<>> floating
<>> leg)
<>> has a spread over Libor.
<>> More:
<>> I think that the correct way to compute the cashFlow amount shoud be:
<>>
<>> ((discountStart/discountEnd-1.0)/accrualPeriod1() +
<>> spread())*AccrualPeriod2()*Notional()
<>>
<>> where accrualPeriod1 is the natural accrual period of the rate (suppose
<>> act360 for deposit)
<>> and accrualPeriod2 is the accrual period of the instrument
<>> (it could be different from the natual accrualPeriod).
<>> But in this case also the ParCoupon class would need a DayCounter as
input.
<>>
<>> What do you think?
<>
<>I am agree with you. In IndexedCoupon class (and derived ones), the constructor
<>allows you to provide the instrument daycounter (I will complete the
<>documentation of IndexedCouponVector tonight or tomorrow).
<>
<>Thus we have to replace ParCoupon by UpFrontIndexedCoupon and related
function
<>in SimpleSwap.
<>
<>Any objection?
<>
<>Nicolas
<>
<>
<>--
<>Nicolas Di Césaré
<>http://nicolas.dicesare.free.fr
<>
<>
<>-------------------------------------------------------
<>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
<>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
<>Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
<>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
<>_______________________________________________
<>Quantlib-users mailing list
<>[hidden email]
<>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Daniele De Francesco-2]

Hi Enrico,

I think I have understood what you think is the problem with the fixing of a
coupon rate on an index: You are saying that we should calculate the rate
for a floating coupon based on its accrual start and end.

I am not an authority in the field (maybe one day...) but I think that the
way it's written so far is the correct way. I think you are confusing the
calculation of accrual (which uses start and end dates of the accrual
period) and fixing of a floating rate (which follows a different system).

Let me describe how the floating rate fixing works (at least in up front
indexed couponss) so that if I'm making a mistake you can correct me right
away:
Just before the coupon starts accruing (the number of days is in the
variable fixingDays_) the libor index for a specific period is looked up and
that rate (plus applicable spread) is going to be the rate for the coupon
that is about to start accruing. That's how it is done every period in
practice.
So for a semi-annual bond which pays on 15th Jan and 15th July, for example,
and which has two fixing days, you would check the 6-month libor fixings on
the 13th and read up what rate will be applied to the coupon starting in 2
days.

When we try to model the future, we try to derive from the current rates
what that 6-month libor index will be like in the future.
So, let's take the 13th of January of NEXT YEAR for example. On that day the
6 month index fixing will be a representation of a forward rate starting
settlementDays_ after that day and ending exactly 6 months later.
And that's exactly what the code in xibor.cpp does!

I hope I haven't managed to confuse anyone!!!

-Daniele

-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Thursday, August 12, 2004 12:00 PM
To: Nicolas Di Césaré
Cc: QuantLib; [hidden email]
Subject: Re: [Quantlib-users] IndexedCoupon and ParCoupon cashFlows


Yes I have an objection.
Before doing that we should be sure that IndexedCoupon
properly computes the cashFlow. And I really dubt.
The problem is that the accrual end that is computed in the index by
shifting ahead the accrual start and not considering the real accrualEnd
date which could be different
(especially when the note is adjusted)

I think a good solution would be to insert a new function in the Xibor:
fixing(Date &startDate, Date &endDate) in such a way that it compute the
forward from these two dates, and escaping any calculation of accrualEnd.
This function could be called properly from the cashFlow class. What do you
think?

Enrico.
<>-- Messaggio originale --
<>From: Nicolas Di Césaré <[hidden email]>
<>To: [hidden email]
<>Cc: QuantLib <[hidden email]>,
<> [hidden email]
<>Subject: Re: [Quantlib-users] IndexedCoupon and ParCoupon cashFlows
<>Date: Thu, 12 Aug 2004 17:48:14 +0200
<>
<>
<>Selon [hidden email]:
<>
<>> Hi all,
<>> I think that a template function could be a good idea for the swap
class, <>> in order to improve its flexibility. <>> On the other hand the
simple swap should remain <>> a "simple" instrument as coded in the market.
<> <>Of course. <> <>> My question was about the way the ParCoupon class
computes the <>> accrualPeriod using the termStrucure DayCounter <>> and
forgetting the index dayCounter. <>> I think this could be a problem,
especially if the swap (or any other <>> floating <>> leg) <>> has a spread
over Libor. <>> More: <>> I think that the correct way to compute the
cashFlow amount shoud be: <>> <>>
((discountStart/discountEnd-1.0)/accrualPeriod1() + <>>
spread())*AccrualPeriod2()*Notional()
<>>
<>> where accrualPeriod1 is the natural accrual period of the rate (suppose
<>> act360 for deposit) <>> and accrualPeriod2 is the accrual period of the
instrument <>> (it could be different from the natual accrualPeriod). <>>
But in this case also the ParCoupon class would need a DayCounter as input.
<>> <>> What do you think? <> <>I am agree with you. In IndexedCoupon class
(and derived ones), the constructor <>allows you to provide the instrument
daycounter (I will complete the <>documentation of IndexedCouponVector
tonight or tomorrow). <> <>Thus we have to replace ParCoupon by
UpFrontIndexedCoupon and related function <>in SimpleSwap. <> <>Any
objection? <> <>Nicolas <> <>
<>--
<>Nicolas Di Césaré
<>http://nicolas.dicesare.free.fr
<>
<>
<>-------------------------------------------------------
<>SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
<>100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 <>Save
50% off Retail on Ink & Toner - Free Shipping and Free Gift.
<>http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
<>_______________________________________________
<>Quantlib-users mailing list <>[hidden email]
<>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Nicolas Di Césaré]

Le jeu 12/08/2004 à 17:59, [hidden email] a écrit :

> Yes I have an objection.
> Before doing that we should be sure that IndexedCoupon
> properly computes the cashFlow. And I really dubt.
> The problem is that the accrual end that is computed in the index by
> shifting ahead the accrual start and not considering the real accrualEnd
> date which could be different
> (especially when the note is adjusted)
> I think a good solution would be to insert a new function in the Xibor:
> fixing(Date &startDate, Date &endDate) in such a way that it compute the
> forward from these two dates,
> and escaping any calculation of accrualEnd.
> This function could be called properly from the cashFlow class.
> What do you think?

I am a little bit confused. I try to summarize :
-First, IndexedCoupon allows to compute the acrrual period with the
daycount of the instrument and use the Xibor market conventions to
compute forward.
-Second, do you think that fixing method of Xibor doesn't respect market
convention or that you cannot respect the reset/payment schedule of the
FRN? (sorry, I don't know the market convention for FRN )





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

[Luigi Ballabio-2]

On 2004.08.12 20:23, Daniele De Francesco wrote:

> I think I have understood what you think is the problem with the
> fixing of a coupon rate on an index: You are saying that we should  
> calculate the rate for a floating coupon based on its accrual start  
> and end.
>
> I am not an authority in the field (maybe one day...) but I think  
> that the way it's written so far is the correct way. I think you are  
> confusing the calculation of accrual (which uses start and end dates  
> of the accrual period) and fixing of a floating rate (which follows a  
> different system).

I second Daniele's view.  If you have two Euribor coupons in different  
swaps with the same fixing date and a different end date because of  
adjustment, the two coupons will pay different amounts (because of the  
difference in the accrual period) but they will sure pay the same rate.
The rate is the fixing of the Euribor index at the fixing date--and the  
Euribor index leads its own life, independent of the fact that someone  
pays coupons based on it.

Later,
        Luigi

[Luigi Ballabio-2]

On 2004.08.12 17:48, Nicolas Di Césaré wrote:
> I am agree with you. In IndexedCoupon class (and derived ones), the
> constructor allows you to provide the instrument daycounter (I will  
> complete the documentation of IndexedCouponVector tonight or  
> tomorrow).
>
> Thus we have to replace ParCoupon by UpFrontIndexedCoupon and related
> function in SimpleSwap.
>
> Any objection?

The choice between ParCoupon and IndexedCoupon is the subject of an  
argument that Nando and I are having since a few years, with me arguing  
that we should use IndexedCoupon and him supporting ParCoupon. You all  
can cast your votes :)

In the meantime, I'd go for a compilation flag allowing one to choose  
one or the other when building the library. Thoughts?

Later,
        Luigi

[Luigi Ballabio-2]

On 2004.08.12 08:29, [hidden email] wrote:

> I think that the correct way to compute the cashFlow amount shoud be:
>
> ((discountStart/discountEnd-1.0)/accrualPeriod1() +
> spread())*AccrualPeriod2()*Notional()
>
> where accrualPeriod1 is the natural accrual period of the rate
> (suppose act360 for deposit)
> and accrualPeriod2 is the accrual period of the instrument
> (it could be different from the natual accrualPeriod).
> But in this case also the ParCoupon class would need a DayCounter as
> input.
>
> What do you think?

I think you're right--ParCoupon should be corrected. I'll put this in  
my todo list.

Later,
        Luigi

[Nicolas Di Césaré]

Selon Luigi Ballabio <[hidden email]>:

> The choice between ParCoupon and IndexedCoupon is the subject of an
> argument that Nando and I are having since a few years, with me arguing
> that we should use IndexedCoupon and him supporting ParCoupon. You all
> can cast your votes :)
>
> In the meantime, I'd go for a compilation flag allowing one to choose
> one or the other when building the library. Thoughts?
>

Yes, but your discussion with Nando is still open : what should be the default
choice ?

#ifdef USE_PARCOUPON

#else

#endif

or

#ifdef USE_INDEXEDCOUPON

#else

#endif


Nicolas

--
Nicolas Di Césaré
http://nicolas.dicesare.free.fr

[Luigi Ballabio-2]

On 2004.08.16 16:38, Nicolas Di Césaré wrote:

> Selon Luigi Ballabio <[hidden email]>:
>
> > The choice between ParCoupon and IndexedCoupon is the subject of an
> > argument that Nando and I are having since a few years.
> >
> > In the meantime, I'd go for a compilation flag allowing one to
> > choose one or the other when building the library.
>
> Yes, but your discussion with Nando is still open : what should be  
> the default choice ?

Well, if you ask me, I'd say IndexedCoupon. That's the point of my  
arguing with Nando :)

Does anybody know which is the most common choice among practitioners?
Later,
        Luigi

[Ferdinando M. Ametrano-3]

>Well, if you ask me, I'd say IndexedCoupon. That's the point of my
>arguing with Nando :)
>
>Does anybody know which is the most common choice among practitioners?

As far as NPV is concerned Nando just says that ParCoupon is the most
common choice among practitioners: they will always say that the floating
leg is priced at par 100.

Besides, if you are picky about using IndexedCoupon you might also consider
the minor implied convexity adjustment.

This said I'm officially agnostic on the issue :)

ciao -- Nando

[Luigi Ballabio-2]

On 2004.08.16 17:01, Ferdinando Ametrano wrote:
>> Does anybody know which is the most common choice among  
>> practitioners?
>
> As far as NPV is concerned Nando just says that ParCoupon is the most  
> common choice among practitioners: they will always say that the  
> floating leg is priced at par 100.

Yes, they will _say_ so, but do they just price it at 100 when they  
trade?

> Besides, if you are picky about using IndexedCoupon you might also  
> consider the minor implied convexity adjustment.

Sure. That's why we're still arguing: IndexedCoupon has the right rate  
and a slight convexity we're neglecting, while ParCoupon has no  
convexity but a slightly 'wrong' rate--i.e., forecast over a period  
which could differ as much as two or three days from the index tenor.
There's no obvious choice :(

> This said I'm officially agnostic on the issue :)

Ditto. Anyone stepping in for either choice?

Later,
        Luigi