2
$\begingroup$

Due to the periodic fixing of floating rate bonds's coupon rates, in order to calculate the bond clean price one must tell the pricing engine to account for previous LIBOR rate fixing.

If I am right (I'm a very QuantLib noob), here is an example of how it works: in the BONDS TO BE PRICED chapter you can see

...
libor3m->addFixing(Date(17, July, 2008),0.0278625);
...

which says that the last fixing date was on 17 July 2008 and the rate fixed by the central bank was equal to $2.79\%$ on annual basis.

Now let you are using QuantLibXL's qlIndexAddFixings() to practically make the same of the C++ code (the fixing will then be used as trigger in qlBondSetCouponPricer()) but you're playing with the evaluation date and a dozen of bonds: in this case you cannot specify the fixings by hand, neither you need a true past value but just something which sounds likely.

How can I make the fixing of every bond to be equal to a default value whatever the bond and the evaluation date without setting it by hand?

It would be possibly sufficient a way to extract the required last fixing date from a FloatingRateBond object.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
4
$\begingroup$

I think to have the answer:

  1. use qlBondPreviousCashFlowDate() pointing at your FloatingRateBond object to get the last date of payment;
  2. use qlInterestRateIndexFixingDate() to get the fixing date referring to the last payment date;
  3. use qlIndexAddFixings() to add a fixing rate to the fixing date you got above;
  4. repeat for each one of your bonds if they share the same IborIndex.

So far I've tried this proceedings using several evaluation dates amended through qlCalendarAdvance() (TARGET calendar) just with the Bonds.xls spreadsheet, but spacing from 2M to 12M in the future doesn't give any issue and the pricing engine has always been able to find a price for the floating rate bond of the example.

P.S.: if someone familiar with the C++ version wanted to explain the proceedings in that language, I'm sure it would be really appreciated.

Improve this answer
$\endgroup$
3
  • 3
    $\begingroup$ This looks correct. However, if you just want to add a default value, you can avoid determining the exact fixing dates and just call qlIndexAddFixing for each date from here to whenever in the future you want to go. The fixings won't be used when they're in the future relative to the evaluation date. (Well, they shouldn't be used. You might want to not take my word for it and do the experiment.) $\endgroup$
    – Luigi Ballabio
    Sep 20, 2013 at 8:12
  • $\begingroup$ Hi, Luigi! Instead of making an IborIndex object for each bond, I think a better idea would be to create a unique IborIndex object for each tenor (the most frequent tenors on the market are 3M, 4M, 6M and 12M) with a looong array of fixing dates. This could avoid any issue related to any fixing dates should come in the past and in the future. $\endgroup$
    – Lisa Ann
    Sep 20, 2013 at 9:55
  • 1
    $\begingroup$ Yes, you can also do that. But you can be more casual about creating IborIndex objects, since all those corresponding to the same index (say, all the Euribor 3M instances) share the fixings. If you add the fixings to one instance, other instances you'll create will see them, too. $\endgroup$
    – Luigi Ballabio
    Sep 20, 2013 at 11:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.