QuantLib › quantlib-users

callable bonds & bond options vs swaptions?

Classic

List

Threaded

2 messages Options

Chris Kenyon-2

callable bonds & bond options vs swaptions?

Hi,

the setup for callable bonds is rather different from swaptions, and maybe it can be improved.

Swaption (const boost::shared_ptr< VanillaSwap > &swap, const boost::shared_ptr< Exercise > &exercise, Settlement::Type delivery=Settlement::Physical)

... the Swaption takes a Swap and some data. Swaption is descendant of Option. A callable bond:

CallableFixedRateBond (Natural settlementDays, Real faceAmount, const Schedule &schedule, const std::vector< Rate > &coupons, const DayCounter &accrualDayCounter, BusinessDayConvention paymentConvention=Following, Real redemption=100.0, const Date &issueDate=Date(), const CallabilitySchedule &putCallSchedule=CallabilitySchedule())

... has a complete description and is a descendant of Bond, via CallableBond, not Option.

Now, granted, a swaption is an option on a swap and nothing happens before exercise whereas a bond may be paying coupons. However, it would be more parsimonious to copy the swaption definition idea for callable bonds and bond options, e.g.

CallableBond(const boost::shared_ptr< Bond > &bond, const CallabilitySchedule &putCallSchedule=CallabilitySchedule())
... descendant of Bond - and can define Puttable and Callable versions from the Callability vector. N.B. a CallabilitySchedule is a typedef for std::vector<boost::shared_ptr< Callability > >

BondOption(const boost::shared_ptr< Bond > &bond, const CallabilitySchedule &putCallSchedule=CallabilitySchedule(), Settlement::Type delivery=Settlement::Physical)
... descendant of Option. N.B. we need a Callability not an Exercise because we need the strike (in a swaption the strike is the fixed rate in the swap).

Any comments? This approach could be applied to ConvertibleBond as well.

Regards,
Chris

------------------------------------------------------------------------------

_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Allen Kuo-2

Re: callable bonds & bond options vs swaptions?

Chris: At the time we had this idea (see email below), but then we nixed it and went for the longer version, with the idea we'd eventually try to re-look at the problem. If you do refactor, I think you'll need to create a DiscretizedFixedRateBond (just like the DiscretizedSwap) and the structures would be parallel. At the time, Luigi noted that knowing the underlying was a Bond was not enough, since fixed and floating rate legs get discounted differently on tree engines. ( I later thought to myself- is there really a need for a floating rate callable bond, with little or no interest rate risk ? )

The idea of deriving from option rather than bond is more elegant from the interface perspective (as you know, options are naturally on some sort of underlying and it would be nice to wrap callability around fixed rate bonds and converts and/or whatever instruments) but I think at the time we figured out it would not be feasible underneath it all (I forget why now, perhaps its because of the need to create pretty customized discretized instruments to be rolled back on trees). Maybe you can figure out a way forward now ? I think options on fixed and floating rate Legs are pretty general classes. Also easy ways to transform from Instruments to "DiscretizedInstruments" may help (assuming we're still talking about the tree engines) but I assume that would be deep refactoring of Instrument.

Allen

On 08/01/2006 09:03:20 AM, Allen Kuo wrote:

>   I'm trying to build a callable bond class and was wondering what a
> QL preferred design would be. Two possibilities are below. I liked
> the economy of the first method but the ConvertibleBond class is
> designed the second way, so was not sure how to proceed.
>
> (1)
>   class CallableBond : public Bond {
> public:
>      CallableBond(const boost::shared_ptr<Bond> bond&
>                       const boost::shared_ptr<PricingEngine>& engine,
>                       const CallabilitySchedule& callability,
>                       );
>    etc.
> }

I like this one, but the problem is that the engine should know what
kind of bond it's being passed---or at least what kind of coupons it
contains. I.e., if you choose a tree engine, fixed-rate and
floating-rate coupons will be discounted in a different way on the
tree. Therefore, the above mightn't be as generic as it seems.

> (2)
> Analogous to the ConvertibleBond class, we would have three
> explicit constructors for each of three types of bonds (
> CallableZeroCouponBond , CallableFloatingRateBond ,
> CallableFixedCouponBond ).

This might be less nice, but it has the advantage of specifying the
kind of bond to be called. I would go for this one first; after the
code is done, we might try some refactoring to bring it closer to the
first design.

> Doing it this way, in the future though, we
> might need three more constructors for convertible bonds:

No, convertible bonds manage callability already. (By the way, you can
look at the relevant classes---Callability and such---so that you can
reuse them.)

Later,
Luigi

From: Chris Kenyon <[hidden email]>
To: [hidden email]; [hidden email]
Sent: Thu, May 27, 2010 10:06:38 PM
Subject: [Quantlib-users] callable bonds & bond options vs swaptions?