|
From: Grześ A. <gan...@gm...> - 2012-10-16 08:31:23
|
Hi, Thanks for a detailed reply! I will look into it after I come back from holidays. Grzegorz On 10/15/12, 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? > -- Sent from my mobile device |