Re: [Quantlib-dev] CAT Bond valuation

[Grześ A. <gan...@gm...>]

Hi,

I think I can see why (2) doesn't really work :(. Why are most of the
methods on the Bond class non-virtual? And why is the pricer in this class
used only for npv and settlementPrice, and not for all the other things
(i.e. clean and dirty prices)---that seem rather similar?

Cheers,
Grzegorz


On 4 January 2013 16:33, Grześ Andruszkiewicz <gan...@gm...> wrote:

> Hi,
>
> Coming back to the risky bonds, I am still trying to figure out what would
> be the best design. Obviously I know a few not-so-elegant ways to just make
> it work, so this is not what I am after.
>
> The first and maybe main question is what do CashFlow::amount() and
> Coupon::nominal() represent. By looking at Luigi's QL book, and the Bond
> class implementation, I would say that amount() is the expected amount of
> the coupon (this is implied by the implementation of NPV calculation for
> bonds), and nominal() is the risk-free nominal value (implied by the
> calculation of the capital repayments in the Bond class again).
>
> All this makes sense for risk-free coupons, but not really for the risky
> ones. To make the current NPV calculation work, we should assume that
> amount() returns the expected amount as I said, but this breaks the yield
> calculation. The yield in the risky case is usually used to compare the
> market-implied riskiness of two different bonds, because obviously
> comparing just the market price is not enough. Hence one should use the
> risk-free amount() for this calculation. As for the nominal(), one could
> safely use the risk-free value, but it might be inconsistent with amount()
> for notes where the notional changes (decreases) as e.g. defaults or
> catastrophes happen.
>
> Also I am not sure about what things like the clean and dirty price mean
> for a risky bond.
>
> A few immediate ideas:
> (1) Add a new virtual method to CashFlow for the riskfreeAmount() (a
> better name anyone?) with default implementation to return the amount().
> Then we could change the Bond class to use the new value for appropriate
> quantities (yield() for example). This seems the cleanest way to do it, but
> it is a fundamental change in some core classes.
>
> (2) Create a base class for risky bonds, that inherits from the Bond
> class. Inside keep two copies of the the coupon list (or dynamically
> calculate one of these from the other)---one with expected amount(), and
> one with risk-free amount(). Override appropriate methods (yield() again
> for example) accordingly. This introduces obvious data and partly code
> duplication, but leaves the core classes unchanged.
>
> (3) Just go the same way as RiskyBond and subclasses (from
> experimental/credit) went---forget about the Bond subclass and use the
> amount() for risk-free values.  This is maybe the most pragmatic approach,
> but then some bonds are not a Bond... And we get loads of code duplication.
>
> I would be grateful for all comments and suggestions.
>
> Cheers,
> Grzegorz
>
> PS. What is the process for committing changes to the code base? Should I
> just commit using my Sourceforge account, or do I need extra permission?
> Are the changes reviewed by anyone?
>
>
> On 19 December 2012 15:18, Grześ Andruszkiewicz <gan...@gm...>wrote:
>
>> Hi Luigi,
>>
>> After spending way too much time on reading termsheets and talking to
>> people I am finally ready to write some code :)
>>
>> I managed to find a class that seems rather similar to what I am trying
>> to achieve: RiskyFloatingBond in experimental/credit. It seems to create
>> coupons as if there was no credit (CAT in my case) risk. The risk is only
>> taken into account while calculating (1) NPV (2) expectedCashflows(). In my
>> case I would still need to run Monte Carlo simulation in these two places.
>> If I ignore (2) for now, then I hopefully will be able to use the standard
>> approach for MC.
>>
>> Have you seen this class before? It was written by Roland Lichters in
>> 2008. Unfortunately a quick search didn't find any associated tests. Is it
>> actually used?
>>
>> This kind of approach gives me an easy way to calculate the yield of the
>> bond (disregarding the risks), which is often used by practitioners to
>> compare different bonds, combined with expected loss.
>>
>> Kind regards,
>> Grzegorz
>>
>>
>>
>> On 15 October 2012 15:11, Luigi Ballabio <lui...@gm...>wrote:
>>
>>> Grześ,
>>>     apologies for the delay.  As I was telling you, there's currently
>>> no example for coupon amounts calculated in a MC simulation.  If you
>>> want to go that route, you'll have to:
>>>
>>> - write the simulation itself.  There are a number of engines you can
>>> use as an example, so you should be covered with regards to creating a
>>> path generator, a path pricer and the several other pieces you'll
>>> need.  The notable difference in your case is that you'll want to
>>> return a number of cashflow amounts from the simulation, not a single
>>> number.  To do that, you'll have to use the second template argument
>>> of PathPricer: I think all the existing engines use its default (that
>>> is, Real for a single number) but you'll have to specify that you'll
>>> return a vector<Real> or something like it.
>>>
>>> - link the coupons to the simulation.  Again, there's no code doing
>>> this yet.  What I'd do is to create a new class inheriting from
>>> CashFlow and taking a pointer to the MC simulation.  When their
>>> amount() method is called, instances of this class should ask the
>>> simulation for the corresponding result.  In turn, this means that a)
>>> they should know which cashflow they are (the 1st, the 2nd...) among
>>> those calculated by the simulation and b) the simulation must
>>> implement some kind of caching to avoid being run several times as the
>>> Bond class asks its cashflows for their amounts.
>>>
>>> The above should keep you busy for a while :)
>>> Let me know when you need further advice...
>>>
>>> Later,
>>>     Luigi
>>>
>>>
>>> On Thu, Sep 13, 2012 at 5:56 PM, Grześ Andruszkiewicz
>>> <gan...@gm...> wrote:
>>> > Hi Luigi,
>>> >
>>> > Thanks for a long reply. We were just trying to follow your advice and
>>> > extend the Bond class, but we found a few potential issues:
>>> > 1. The Coupon class seems to have a fixed notional, whereas in our
>>> > case the notional could become smaller as a result of CAT events (that
>>> > deplete the notional of the CAT bond)
>>> > 2. The Bond class seems to assume that we can always calculate the
>>> > coupon amounts (independently for every coupon). I am not sure that
>>> > this is possible for CAT bonds (i.e. that coupons will be correlated
>>> > as a result of depleting the notional, catastrophe seasonality, etc.),
>>> > at least I am not comfortable to assume it at this point.
>>> > 3. Moreover, we wanted to have a way to price these instruments using
>>> > Monte Carlo techniques, i.e. use the underlying CAT engine to generate
>>> > random scenarios of events, given the events calculate the NPV of the
>>> > bond for every case, and average the results at the end. It is not
>>> > clear to how to achieve this with the Bond class...
>>> >
>>> > Are there other types of instruments in QuantLib with similar
>>> > characteristics, that we could use as examples?
>>> >
>>> > Kind regards,
>>> > Grzegorz
>>> >
>>> > On 31 August 2012 15:45, Luigi Ballabio <lui...@gm...>
>>> wrote:
>>> >> Hi Grześ,
>>> >>     I'd start by doing the least possible coding :)   Let me
>>> elaborate.
>>> >>
>>> >> In the architecture of QuantLib, you'll need an instrument class
>>> >> (describing the contract) and an engine class (doing the actual
>>> >> pricing).  You can ask your resident expert (hi, Lorenzo) or read
>>> >> chapter 2 of <https://sites.google.com/site/luigiballabio/>.
>>> >>
>>> >> As for the instrument, it is very tempting to inherit it from the
>>> >> existing Bond class (it's a bond, after all).  In the short term,
>>> >> that's what I advice.
>>> >>
>>> >> In the long term, I'm a bit worried that functions taking a Bond
>>> >> instance (such as, for instance, BondFunctions::yield, which
>>> >> calculates the bond yield) would take a CAT bond and do their job like
>>> >> they do for each other bond; that is, extract its coupons and perform
>>> >> the yield calculations disregarding the catastrophe feature.  This
>>> >> might or might not be what you want.
>>> >>
>>> >> In the _very_ short term, though, I'd just use the existing fixed-rate
>>> >> and floating-rate bond classes and use those until you see that the
>>> >> thing works.  It will save you some development time which I'd rather
>>> >> use for getting to a first working version.
>>> >>
>>> >> Which brings me to the second part, i.e., the engine class.  It will
>>> >> probably need to contain a discount curve and your loss distribution.
>>> >> Any idea about how you'll use them?
>>> >>
>>> >> Later,
>>> >>     Luigi
>>> >>
>>> >>
>>> >> On Fri, Aug 24, 2012 at 5:08 PM, Grześ Andruszkiewicz
>>> >> <gan...@gm...> wrote:
>>> >>> Hi Luigi,
>>> >>>
>>> >>> Thanks for your reply! I personally can't claim to be proficient with
>>> >>> Quantlib, but my colleague Lorenzo (CC'd) did the 3-day course in
>>> >>> London with yourself, so he must be an expert ;)
>>> >>>
>>> >>> I don't think there are any established models for CAT bonds. We are
>>> >>> actually part of one of these academic-industry projects and one of
>>> >>> the goals is to come up with a model and implementation for these
>>> >>> instruments. We thought it might be a good idea to make this
>>> >>> implementation part of quantlib, to make it potentially useful for
>>> >>> someone.
>>> >>>
>>> >>> To start with, I would be grateful for any hints on where to start,
>>> >>> e.g. what would be your first guess on the place in the class
>>> >>> hierarchy where this instrument would fit?
>>>
>>
>>
>