Floating Coupons

[Toyin Akin-3]

 

Hi all,

 

In my opinion I would use the former.

 

(discount(start)/discount(end)-1.0) * nominal

 

One argument for this is that you can reduce the value of the float side of a swap to just the exchange of notionals. [(dcf(start) - dcf(end5y)) * Notional]

 

Thus if you were to employ Sum(Fra*accurualPeriod*Notional*dcf(end))

 

where Fra = (dcf(start)/dcf(end)-1)/accurualPeriod

 

for every period, the whole thing reduces to [dcf(start) - dcf(end5y)] * Notional

 

If you employ liborFixing * accrualPeriod * nominal, this will not happen.

 

In addition the former formula will contain the least error as you'll find

that if the first Fra period is slightly longer than normal, the period following it will be shorter.

So the errors roughly cancels out.

 

You are right that the liborFixing is what is actually paid, but for calculation purposes

if we are in the middle of a period where a rate has been fixed, then use the actual fixed value

(latter formula), for future cash flows use the former.

 

Enjoy,

Toy.

 

 

[Luigi Ballabio-4]

Hi Toyin,
         thanks for answering.

At 06:08 PM 3/28/02 +0000, Toyin Akin wrote:
>In my opinion I would use the former.
>
>(discount(start)/discount(end)-1.0) * nominal
>
>One argument for this is that you can reduce the value of the float side
>of a swap to just the exchange of notionals. [(dcf(start) - dcf(end5y)) *
>Notional]
>
>If you employ liborFixing * accrualPeriod * nominal, this will not happen.

I was aware of the simplification above, but I don't think that it's an
issue here since the Swap class is simply collecting the amounts from the
CashFlow instances in its legs and adding them up. The swap doesn't inspect
its cash flows to see whether they are fixed or floating, it just delegates
to each of them its own calculation. Thus, there is no way to perform the
symbolic calculation above.

>In addition the former formula will contain the least error as you'll find
>that if the first Fra period is slightly longer than normal, the period
>following it will be shorter.
>So the errors roughly cancels out.

Ok, I see this point.

(even though I could be picky and reply that if the _last_ period was
longer, there wouldn't be a shorter period to cancel out the error. Or if
we were already in the middle of the longer period, its fixing was
determined and would no longer cancel out the error of the following
shorter one.
As a matter of fact, I could be even nastier and point out that if forward
rates were allowed to be negative, there would be no guarantee that the
shorter period would cancel out the longer one; the two errors could add up
instead. But I won't be picky)

>You are right that the liborFixing is what is actually paid, but for
>calculation purposes
>if we are in the middle of a period where a rate has been fixed, then use
>the actual fixed value
>(latter formula), for future cash flows use the former.

Yes, this is what is done right now.

However, I'm not objecting to par coupons as such, but rather to attempts
to extend them beyond their possibilities. For instance, adding a spread is
still safe, but it forces one to add a parameter since the formula
         (discount(start)/discount(end)-1)*notional
now must become
         [(discount(start)/discount(end)-1) + spread*accrualPeriod] * notional
and a day counter (or an index, which contains a day counter) must be
passed to calculate the accrual period. But this can already be misleading:
if one writes
         FloatingCoupon(start,end,termStructure,0.0,actualactual)
he might think he is instantiating a coupon which pays the Libor fixing
over an accrual period calculated act/act, when in fact the act/act day
count is not used at all since he passed a 0.0 spread.

Moreover, what if one actually wants to pay the Libor fixing act/act?
The par formula is clearly not what one wants: should one use
     (discount(start)/discount(end))-1)
     ---------------------------------- * actact(end-start) * notional,
             act365(end-start)
which does no longer simplify? Or should one go ahead and use
     liborFixing * actact(end-start) * notional
and save himself the trouble?

I guess the question boils down to, what is the market practice these days?

Bye,
         Luigi

[Toyin Akin-3]

Hi Luigi,

You wrote...

> Moreover, what if one actually wants to pay the Libor fixing act/act?
> The par formula is clearly not what one wants: should one use
>     (discount(start)/discount(end))-1)
>    ---------------------------------- * actact(end-start) * notional,
>             act365(end-start)

I am confused as to why you divide by act365(end-start).

Lets say that I am in the middle of a period. The period has fixed and I was
to pay Libor fixing
act/act. I would look up a reuters page and pick the fixing based on actact
and not act365
(assuming that act365 is the market convention).

In your calculation, by dividing by act365, the Fra rate (or fixing if you
like) is based on act365. But the client wants a fixing based on actact. So
even if there were no date adjustments due to weekends and holidays and the
dates/period is exactly the same as the fixing period, the rate
you have computed is incorrect.

In fact on some reuters pages where you see both fixings being quoted on
act365 and actact, you can convert from one to the other by multiplying by
the ratio of the daycount fractions.

Regards,
Toy.

----- Original Message -----
From: "Luigi Ballabio" <[hidden email]>
To: "Toyin Akin" <[hidden email]>;
<[hidden email]>
Sent: Friday, March 29, 2002 4:21 PM
Subject: Re: [Quantlib-users] Floating Coupons

>
> Hi Toyin,
>          thanks for answering.
>
> At 06:08 PM 3/28/02 +0000, Toyin Akin wrote:
> >In my opinion I would use the former.
> >
> >(discount(start)/discount(end)-1.0) * nominal
> >
> >One argument for this is that you can reduce the value of the float side
> >of a swap to just the exchange of notionals. [(dcf(start) - dcf(end5y)) *
> >Notional]
> >
> >If you employ liborFixing * accrualPeriod * nominal, this will not

happen.
>
> I was aware of the simplification above, but I don't think that it's an
> issue here since the Swap class is simply collecting the amounts from the
> CashFlow instances in its legs and adding them up. The swap doesn't
inspect
> its cash flows to see whether they are fixed or floating, it just
delegates
> to each of them its own calculation. Thus, there is no way to perform the
> symbolic calculation above.
>
> >In addition the former formula will contain the least error as you'll
find

> >that if the first Fra period is slightly longer than normal, the period
> >following it will be shorter.
> >So the errors roughly cancels out.
>
> Ok, I see this point.
>
> (even though I could be picky and reply that if the _last_ period was
> longer, there wouldn't be a shorter period to cancel out the error. Or if
> we were already in the middle of the longer period, its fixing was
> determined and would no longer cancel out the error of the following
> shorter one.
> As a matter of fact, I could be even nastier and point out that if forward
> rates were allowed to be negative, there would be no guarantee that the
> shorter period would cancel out the longer one; the two errors could add

up

> instead. But I won't be picky)
>
> >You are right that the liborFixing is what is actually paid, but for
> >calculation purposes
> >if we are in the middle of a period where a rate has been fixed, then use
> >the actual fixed value
> >(latter formula), for future cash flows use the former.
>
> Yes, this is what is done right now.
>
> However, I'm not objecting to par coupons as such, but rather to attempts
> to extend them beyond their possibilities. For instance, adding a spread

is
> still safe, but it forces one to add a parameter since the formula
>          (discount(start)/discount(end)-1)*notional
> now must become
>          [(discount(start)/discount(end)-1) + spread*accrualPeriod] *
notional
> and a day counter (or an index, which contains a day counter) must be
> passed to calculate the accrual period. But this can already be
misleading:

> if one writes
>          FloatingCoupon(start,end,termStructure,0.0,actualactual)
> he might think he is instantiating a coupon which pays the Libor fixing
> over an accrual period calculated act/act, when in fact the act/act day
> count is not used at all since he passed a 0.0 spread.
>
> Moreover, what if one actually wants to pay the Libor fixing act/act?
> The par formula is clearly not what one wants: should one use
>      (discount(start)/discount(end))-1)
>      ---------------------------------- * actact(end-start) * notional,
>              act365(end-start)
> which does no longer simplify? Or should one go ahead and use
>      liborFixing * actact(end-start) * notional
> and save himself the trouble?
>
> I guess the question boils down to, what is the market practice these

days?
>
> Bye,
>          Luigi
>

[Toyin Akin-3]

Hi Luigi,

(You may have recieved this already, I changed my clock settings earlier and
thus the timestamp
on my mail is incorrect...anyway I've tacked on a bit more at the bottom,
sunnary section.)

You wrote...

> Moreover, what if one actually wants to pay the Libor fixing act/act?
> The par formula is clearly not what one wants: should one use
>     (discount(start)/discount(end))-1)
>    ---------------------------------- * actact(end-start) * notional,
>             act365(end-start)

I am confused as to why you divide by act365(end-start).

Lets say that I am in the middle of a period. The period has fixed and I was
to pay Libor fixing
act/act. I would look up a reuters page and pick the fixing based on actact
and not act365
(assuming that act365 is the market convention).

In your calculation, by dividing by act365, the Fra rate (or fixing if you
like) is based on act365. But the client wants a fixing based on actact. So
even if there were no date adjustments due to weekends and holidays and the
dates/period is exactly the same as the fixing period, the rate
you have computed is incorrect.

In fact on some reuters pages where you see both fixings being quoted on
act365 and actact, you can convert from one to the other by multiplying by
the ratio of the daycount fractions.

*** NEW BIT ***

In summary...

If the question is a client wants to pay LIBOR(act/act) over a
daycountfraction of act/act
then you divide by act/act. If the question is that the client wants to pay
LIBOR(act/365) over a daycountfraction of act/act (a pretty wierd request I
must say) then I see your point. However
I was under the impression that the definition of a particular fixing rate
(LIBOR rate if you like)
indicates the daycountfraction over which the rate is to be paid out.

In fact looking at your Indexes namespace, it looks like for each currency,
you have hard coded
the daycountfraction convention. You either need a new Euribor365 index, or
have the daycountfraction passed in as a parameter.

Regards,
Toy.


----- Original Message -----
From: "Luigi Ballabio" <[hidden email]>
To: "Toyin Akin" <[hidden email]>;
<[hidden email]>
Sent: Friday, March 29, 2002 4:21 PM
Subject: Re: [Quantlib-users] Floating Coupons

>
> Hi Toyin,
>          thanks for answering.
>
> At 06:08 PM 3/28/02 +0000, Toyin Akin wrote:
> >In my opinion I would use the former.
> >
> >(discount(start)/discount(end)-1.0) * nominal
> >
> >One argument for this is that you can reduce the value of the float side
> >of a swap to just the exchange of notionals. [(dcf(start) - dcf(end5y)) *
> >Notional]
> >
> >If you employ liborFixing * accrualPeriod * nominal, this will not

happen.
>
> I was aware of the simplification above, but I don't think that it's an
> issue here since the Swap class is simply collecting the amounts from the
> CashFlow instances in its legs and adding them up. The swap doesn't
inspect
> its cash flows to see whether they are fixed or floating, it just
delegates
> to each of them its own calculation. Thus, there is no way to perform the
> symbolic calculation above.
>
> >In addition the former formula will contain the least error as you'll
find

> >that if the first Fra period is slightly longer than normal, the period
> >following it will be shorter.
> >So the errors roughly cancels out.
>
> Ok, I see this point.
>
> (even though I could be picky and reply that if the _last_ period was
> longer, there wouldn't be a shorter period to cancel out the error. Or if
> we were already in the middle of the longer period, its fixing was
> determined and would no longer cancel out the error of the following
> shorter one.
> As a matter of fact, I could be even nastier and point out that if forward
> rates were allowed to be negative, there would be no guarantee that the
> shorter period would cancel out the longer one; the two errors could add

up

> instead. But I won't be picky)
>
> >You are right that the liborFixing is what is actually paid, but for
> >calculation purposes
> >if we are in the middle of a period where a rate has been fixed, then use
> >the actual fixed value
> >(latter formula), for future cash flows use the former.
>
> Yes, this is what is done right now.
>
> However, I'm not objecting to par coupons as such, but rather to attempts
> to extend them beyond their possibilities. For instance, adding a spread

is
> still safe, but it forces one to add a parameter since the formula
>          (discount(start)/discount(end)-1)*notional
> now must become
>          [(discount(start)/discount(end)-1) + spread*accrualPeriod] *
notional
> and a day counter (or an index, which contains a day counter) must be
> passed to calculate the accrual period. But this can already be
misleading:

> if one writes
>          FloatingCoupon(start,end,termStructure,0.0,actualactual)
> he might think he is instantiating a coupon which pays the Libor fixing
> over an accrual period calculated act/act, when in fact the act/act day
> count is not used at all since he passed a 0.0 spread.
>
> Moreover, what if one actually wants to pay the Libor fixing act/act?
> The par formula is clearly not what one wants: should one use
>      (discount(start)/discount(end))-1)
>      ---------------------------------- * actact(end-start) * notional,
>              act365(end-start)
> which does no longer simplify? Or should one go ahead and use
>      liborFixing * actact(end-start) * notional
> and save himself the trouble?
>
> I guess the question boils down to, what is the market practice these

days?
>
> Bye,
>          Luigi
>

[Luigi Ballabio-4]

Hi Toyin,
        well, I told you I was stepping out to show my ignorance...
I'm satisfied with your points now. I'm still not satisfied with my
own classes, since I suspect there's some redundancy in the
parameters which can mislead users. I'll have to look into that.

Thanks for having been an excellent sparring partner.

Bye,
        Luigi

--

[Toyin Akin-3]

Hi Luigi,

No problems, I find it all enjoyable.

In fact if you are looking at these set of classes you may also want to look
at some sort of
delayed reset adjustments (ie fixed at the end rather than the beginning of
a period, or even fixed at any time during a particular period, I know
you'll have convexity adjustment problems to deal with)
and maybe also Constant Maturity Swaps Quantos would be good too.
(You can see I'm struggling now!!)

Your work on using Quantlib via Python is quite brilliant.
Have you guys considered applying the few variables within your python
classes to enable
them to work with pythoncom?

I would have though that this would be the fastest way to com enable your
library.

However, since I've never done it before (I'm not too sure if you can apply
the COM parameters
to python shadow classes) I could be talking absolute garbage...

Regards,
Toy.


----- Original Message -----
From: "Luigi Ballabio" <[hidden email]>
To: "Toyin Akin" <[hidden email]>;
<[hidden email]>
Sent: Monday, April 01, 2002 1:17 PM
Subject: Re: [Quantlib-users] Floating Coupons

>
> Hi Toyin,
> well, I told you I was stepping out to show my ignorance...
> I'm satisfied with your points now. I'm still not satisfied with my
> own classes, since I suspect there's some redundancy in the
> parameters which can mislead users. I'll have to look into that.
>
> Thanks for having been an excellent sparring partner.
>
> Bye,
> Luigi
>
> --

[Toyin Akin-3]

Hi Luigi,

Some other thing about the fixings... will be how your payment dates and
fixing dates are
determined. You may have two banks, one in London, one in New York where a
LIBOR fixing is to be paid to the New York bank. You must have 2 calendars.
A fixing calendar with London holidays only and a payment calendar of both
London and New York. Thus for a particular
fixing rate, you need 2 calendars. It's even worst than that, a client may
want a fixing rule of 1
day rather than the default of 2 days. A client may even specify the holiday
location s/he requires
for a paricular deal. At the moment the quantlib classes present the default
for the currency and
thus there is no way to present a customised fixing for a user without using
derivation.

The nightmare begins... :-)

Regards,
Toy.


----- Original Message -----
From: "Luigi Ballabio" <[hidden email]>
To: "Toyin Akin" <[hidden email]>;
<[hidden email]>
Sent: Monday, April 01, 2002 1:17 PM
Subject: Re: [Quantlib-users] Floating Coupons

>
> Hi Toyin,
> well, I told you I was stepping out to show my ignorance...
> I'm satisfied with your points now. I'm still not satisfied with my
> own classes, since I suspect there's some redundancy in the
> parameters which can mislead users. I'll have to look into that.
>
> Thanks for having been an excellent sparring partner.
>
> Bye,
> Luigi
>
> --

[Marco Marchioro-2]

At 03:50 PM 3/31/02 +0100, Toyin Akin wrote:

>Your work on using Quantlib via Python is quite brilliant.
>Have you guys considered applying the few variables within your python
>classes to enable
>them to work with pythoncom?
>
>I would have though that this would be the fastest way to com enable your
>library.
>
>However, since I've never done it before (I'm not too sure if you can apply
>the COM parameters
>to python shadow classes) I could be talking absolute garbage...
>
>Regards,
>Toy.

You are not talking about garbage. The power of python, and the whole QuantLib
with it, can be completely transferred to the COM environment. The task was
not trivial and required a lot of development time. That's why it is not
available
for free. The end product, I have to say, is terrific, you can use the
whole QuantLib from VisualBasic(or other languages that support COM) with
the same ease of python.

This porting is called QuantKit and is marketed by RiskMap. It is not just
the porting of QuantLib but has additional parts that are built around
QuantLib. It includes,
among other things, a more sophisticated Monte Carlo engine, bond classes,
and more.

If you are interested in QuantKit, please contact privately
<[hidden email]> for detailed info.

         Marco Marchioro