Why Callable Floating-Rate Bonds Require Joint Rate and Exercise Modeling
Summary
The document examines why a callable floating-rate bond cannot be priced reliably by combining a standard floating-rate bond with a callable fixed-rate bond calculation. The proposed shortcut extracts floating coupons and optionlet values, then inserts them into the callable bond framework. The accepted answer explains that this loses the dependence of floating payments on the short-rate model’s state across the pricing tree.
A consistent approach must forecast and discount floating payments on the tree, as in a discretized swap implementation. The shortcut also mishandles optionality: it can count optionlet value twice, and separately adding optionlets ignores that an early bond call removes later coupons and their optionlet exposures together. The discussion gives conceptual implementation guidance, not a complete class design or code solution; it concludes that a full model is needed, using callable fixed-rate bond and discretized swap implementations as references.
Key ideas
- Floating coupons must be forecast and discounted consistently on the short-rate model tree.
- Extracting cash flows in advance discards their dependence on the model’s rate state.
- Adding optionlet values separately can double-count optionality.
- A call decision affects later floating coupons and optionlets jointly, so independent addition is inconsistent.
Tags
Full text
# CallableFloatingRateBond in QuantLib: just a matter of multiple inheritance?
# 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:
- set up a `FloatingRateBond` with its `CouponPricer`;
- extract cash flows from this FRN and possible optionlets' prices;
- set `CallableFixedRateBond` cash flows equal to the ones extracted from above;
- price a `CallableFixedRateBond` by using the default implementation;
- 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 by Luigi Ballabio (score 3, accepted)
https://quant.stackexchange.com/a/20794
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.Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.