from holidays.
> 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