Re: Floating Coupons

Posted by Luigi Ballabio-4 on Mar 29, 2002; 7:04am
URL: http://quantlib.414.s1.nabble.com/Floating-Coupons-tp1948p1949.html

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