CallableFloatingRateBond in QuantLib: just a matter of multiple inheritance?

Question

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.

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.