CAT Bond valuation

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

CAT Bond valuation

Grześ Andruszkiewicz
Hi,

As part of a bigger project we are planning to implement valuation of
CAT (Catastrophe) Bonds, and we were thinking to do it as part of
QuantLib to leverage all the functionality that is not specific for
these products (like term structure, etc.). The bigger project will
produce the distribution of the losses of the underlying insurance
contract (against CAT events), so we will assume this as an input.

Does anyone have any experience with CAT Bonds? Or at least could give
us hints on where to start?

Kind regards,
Grzegorz

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Luigi Ballabio
Hi,
    apologies for the delay; I was on vacation without email (yes, it
felt nice).

I don't have experience with CAT bonds, but I might give hints on the
library side.
What model would you implement? And are you familiar with QuantLib already?

Luigi

On Thu, Jul 26, 2012 at 2:25 PM, Grześ Andruszkiewicz
<[hidden email]> wrote:

> Hi,
>
> As part of a bigger project we are planning to implement valuation of
> CAT (Catastrophe) Bonds, and we were thinking to do it as part of
> QuantLib to leverage all the functionality that is not specific for
> these products (like term structure, etc.). The bigger project will
> produce the distribution of the losses of the underlying insurance
> contract (against CAT events), so we will assume this as an input.
>
> Does anyone have any experience with CAT Bonds? Or at least could give
> us hints on where to start?
>
> Kind regards,
> Grzegorz
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Grześ Andruszkiewicz
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?

Kind regards,
Grzegorz

On 24 August 2012 11:24, Luigi Ballabio <[hidden email]> wrote:

> Hi,
>     apologies for the delay; I was on vacation without email (yes, it
> felt nice).
>
> I don't have experience with CAT bonds, but I might give hints on the
> library side.
> What model would you implement? And are you familiar with QuantLib already?
>
> Luigi
>
> On Thu, Jul 26, 2012 at 2:25 PM, Grześ Andruszkiewicz
> <[hidden email]> wrote:
>> Hi,
>>
>> As part of a bigger project we are planning to implement valuation of
>> CAT (Catastrophe) Bonds, and we were thinking to do it as part of
>> QuantLib to leverage all the functionality that is not specific for
>> these products (like term structure, etc.). The bigger project will
>> produce the distribution of the losses of the underlying insurance
>> contract (against CAT events), so we will assume this as an input.
>>
>> Does anyone have any experience with CAT Bonds? Or at least could give
>> us hints on where to start?
>>
>> Kind regards,
>> Grzegorz
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> QuantLib-dev mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Luigi Ballabio
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
<[hidden email]> 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?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Grześ Andruszkiewicz
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 <[hidden email]> 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
> <[hidden email]> 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?

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Luigi Ballabio
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
<[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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?

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Grześ Andruszkiewicz
Hi,

Thanks for a detailed reply! I will look into it after I come back
from holidays.

Grzegorz

On 10/15/12, Luigi Ballabio <[hidden email]> 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
> <[hidden email]> 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 <[hidden email]> 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
>>> <[hidden email]> 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?
>

--
Sent from my mobile device

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Grześ Andruszkiewicz
In reply to this post by Luigi Ballabio
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 <[hidden email]> 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
<[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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?


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Grześ Andruszkiewicz
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 <[hidden email]> 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 <[hidden email]> 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
<[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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?



------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Grześ Andruszkiewicz
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
<[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> 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?




------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
Reply | Threaded
Open this post in threaded view
|

Re: CAT Bond valuation

Luigi Ballabio
In reply to this post by Grześ Andruszkiewicz
Hi Grzegorz,
    as usual, apologies for the delay.

I've been looking at the RiskyBond class---I didn't remember it---and
I'm not sure of its approach. It tries to model bonds that can
default, but that's simply all bonds; it's just more or less likely
(and in fact, even when just discounting the amounts, one rarely uses
the risk-free curve; usually there's a spread added to the curve that
somewhat takes into account the possibility of default as an increased
discount factor that decreases the present value of the cash flows).

For modeling default explicitly, I wouldn't use a different class; I'd
just keep the existing one and, instead of a pricing engine that just
discounts, I'd use a pricing engine that takes default probability
into account in order to weigh the cash flow amounts. This way, the
same bond instance could be priced either way.

However, the above applies to the usual kind of bonds, in which a
coupon might disappear if the bond defaults but is otherwise fixed. In
your case, the coupon survives but varies in notional and amount,
which probably makes it a different beast, and the approach in
RiskyBond might work.  You could calculate your expected cash flows
based on your model (as RiskyBond does in expectedCashflows) and pass
those to the BondFunctions class for yield calculation etc.  Of course
this sidesteps the issues you found (such as amount() returning the
risk-free amount) but I think it can get you started quicker.

Later,
    Luigi


On Fri, Jan 4, 2013 at 5:33 PM, Grześ Andruszkiewicz <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>> <[hidden email]> 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 <[hidden email]>
>>> > 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
>>> >> <[hidden email]> 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?
>>
>>
>

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev