I would like to know what are the issues related to a possible CallableFloatingRateBond class in QuantLib and to have some hints on implementation.

My (very obvious) idea is to declare such a class like:

class CallableFloatingRateBond : public FloatingRateBond, public CallableBond
  CallableFloatingRateBond();  //ctor
  virtual ~CallableFloatingRateBond();  //dtor
  // ..?..
  // ..?..

Nevertheless, CallableFixedRateBond class inherits just from Bond class through the abstract CallableBond class, whose purpose seems to be for the most setting up pricing engine and relinkable handles to stuff like Black volatilities and discount curves.

In fact, CallableFixedRateBond implementation works a lot with PricingEngine::arguments* to set up cash flows and callability schedule, but this does not involve the issue of an IborIndex or a SwapIndex which should be amended along with the short term rate dynamics (e.g. an HullWhite short rate model discretized by a TreeCallableFixedRateBondEngine).

A different, raw, solution could be to:

  1. set up a FloatingRateBond with its CouponPricer;
  2. extract cash flows from this FRN and possible optionlets' prices;
  3. set CallableFixedRateBond cash flows equal to the ones extracted from above;
  4. price a CallableFixedRateBond by using the default implementation;
  5. sum optionlet's prices (if any) to 4.

A "dirty" class like this one could make the job of returning something like an OAS to the user just by shifting up IborIndex's / SwapIndex's term structure and HullWhite's term structure all together, but I am really wondering whether this is theoretically consistent.


1 Answer 1


No, I don't think the raw solution you sketch is going to work.

First and foremost, by extracting the cash flows from the bond you're discarding the dynamics of their rate under the Hull/White model you're using. You should both forecast and discount them on the tree; the way to do it correctly is implemented, e.g., in the DiscretizedSwap class (and explained at length in Implementing QuantLib). In your solution, you would underestimate the rates on one side of the tree and overestimate them on the other with respect to the true forecast, which in turn would lead to wrong exercise probabilities if you were to insert them into a CallableFixedRateBond.

Second, the treatment of the optionlets wouldn't be correct either. On the one hand, you would be already considering optionality during the CallableFixedRateBond calculation, so you would be putting it in twice. On the other hand, you can't just add optionlets; they're not independent, since calling the bond at one exercise date implies exercising all the optionlets coming after that date, whether any single one is in the money or not.

In conclusion: sorry, but you'll need a full solution, and that will take some work. You can use CallableFixedRateBond as a model implementation and look into DiscretizedSwap for how to model floating payments.

  • $\begingroup$ Thank you for your answer, Luigi, but I'm still missing a point: are there advantages in deriving CallableFloatingRateBond class either from CallableBond and FloatingRateBond? Or wouldn't this give me any device to manage more easily the issue of capped/floored forward rates according to short term rate dynamic? $\endgroup$
    – Lisa Ann
    Commented Sep 18, 2015 at 15:19
  • 1
    $\begingroup$ Hmm. I would have thought that inheriting from CallableBond would give you some functionality you can use, but looking at it it seems that you'll have to override most of it anyway (for instance, CallableBond::arguments expects to store the coupon amounts, which you don't want, and doesn't store any info on floating payments). On the other hand, inheriting from FloatingRateBond would let you inherit quite a lot of methods that would return the wrong value for a callable bond. The safer choice might be to inherit from CallableBond or even Bond, but I don't have a strong opinion. $\endgroup$ Commented Sep 18, 2015 at 15:32

Your Answer

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

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