# CallableFloatingRateBond in QuantLib: just a matter of multiple inheritance?

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
{
public:
CallableFloatingRateBond();  //ctor
virtual ~CallableFloatingRateBond();  //dtor
protected:
// ..?..
private:
// ..?..
};


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.

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.
• 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? – Lisa Ann Sep 18 '15 at 15:19
• 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. – Luigi Ballabio Sep 18 '15 at 15:32