RE: [Quantlib-dev] RE: R: Credit default pricing / G2++ model

Hi Toyin,
as you said, the procedure is the one described in Chapter 11 of the Brigo-Mercurio book: I think you should model the two curves using 2 different G2 models.
The problem is that when pricing options with bermudan features you need trees: every G2 model implies a tridimensional tree but I think that you cannot let the two processes evolve on the same tree since each tree (and in particular the number of nodes at each time step) depends on the model parameters.
I don't know which is the best way to proceed, but I'll think a little bit about that.
Let me know if you find some hint.

Marco
---------- Initial Header -----------

[Toyin Akin]

Hi,

Looks like the problem involving the MCAmericanBasketEngine class is being
handled.
Thanks guys.

One of the reasons why I was looking at this class is that theorectically
the logic enables you to
perform American/Bermudan pricing within a montecarlo framework via the LSMC
method
(Least Squares Monte carlo).

The logic within this class caters only for American options on equity, but
I was just wondering how much work it would take to convert this into a
Bermudan pricer with Interest rate models.

Thus simulate rates (2 rates in this case if the underlying is a FLT/FLT
swap) via Hullwhite, BK, HL G2++ etc... and then apply the LSMC logic to
price Bermudans.

With such a methodology in place, you can price quite a few structured deals
with a large number of factors, ie Bermudans on Quanto Basis Swaps, which
requires 3 underlying models, at least, in order to price this deal. One
each for the legs and one for the FX component. Forget using a Tree.

There are papers (ie Tiley) reporting that the results are quite good and
it's quite a general procedure.

FinancialCAD uses this methodology in pricing not only exotic Bermudan
swaptions but other tpyes of Interest rate products that have callable
provisions with a high number of underlying models.

However as the QuantLib code stands, I don't know if there is an easy way to
simply produce random paths of rates that follows one of the Interest rate
stochastic models.

I know that the MonteCarlo code caters for classes within the processes
directory, but I'm not too sure about the classes within the ShortRateModels
folder.

Can I simply ask for the Montecarlo class to spit out the simulated rates
from a HullWhite model for example?

Or another way to look at it is how easy is it to generate an array of the
simulated movement of rates from an interest rate model?

If so, how easy is this to do?

Best Regards,
Toyin Akin.

>From: "marco\.tarenghi\@libero\.it" <[hidden email]>
>To: "toyin_akin" <[hidden email]>
>CC: "quantlib-users" <[hidden email]>,"quantlib-dev"
><[hidden email]>
>Subject: RE: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing
>/ G2++ model
>Date: Mon, 10 Oct 2005 10:49:51 +0200
>
>Hi Toyin,
>as you said, the procedure is the one described in Chapter 11 of the
>Brigo-Mercurio book: I think you should model the two curves using 2
>different G2 models.
>The problem is that when pricing options with bermudan features you need
>trees: every G2 model implies a tridimensional tree but I think that you
>cannot let the two processes evolve on the same tree since each tree (and
>in particular the number of nodes at each time step) depends on the model
>parameters.
>I don't know which is the best way to proceed, but I'll think a little bit
>about that.
>Let me know if you find some hint.
>
>Marco
>---------- Initial Header -----------
>
>From      : [hidden email]
>To          :
>[hidden email],[hidden email]
>Cc          :
>Date      : Fri, 07 Oct 2005 18:52:24 +0100
>Subject : RE: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing
>/ G2++ model
>
>
>
>
>
>
>
> >
> > Hi,
> >
> > Concerning the Bermudan FLT/FLT swap (or bermudan basis swaption)
>assuming
> > one leg is based on a LIBOR curve and the other on a BASIS curve, how
>does
> > one refer to each individual curve within a DiscretizedAsset class
>(assuming
> > that one wants to model the code similar to that of the DiscretizedSwap
> > class). Or is the infrastructure only suitable for only refering to a
>single
> > curve.
> >
> > It looks like you need to model two G2++ objects and their joint
>dynamics.
> >
> > Probably the logic presented within the beginning of Chapter 11 of
> > Brigo-Mercurio.
> >
> > Best Regards,
> > Toyin Akin.
> >
> >
> > >From: "Toyin Akin" <[hidden email]>
> > >To:
>[hidden email],[hidden email]
> > >Subject: RE: [Quantlib-dev] RE: R: [Quantlib-users] Credit default
>pricing
> > >/ G2++ model
> > >Date: Fri, 07 Oct 2005 17:21:56 +0100
> > >
> > >
> > >Hi Marco,
> > >
> > >Ignore my comments on bermudan swaptions on FLT/FLT swaps where both
>legs
> > >are of the same currency. This can be defined, as you said, within a
>new
> > >class inherited from the DiscretizedOption class if pricing via the
>Tree.
> > >
> > >However can the same be said with FLT/FLT swaps with different
>currencies
> > >on each leg (including exchange of notionals)?
> > >
> > >Best Regards,
> > >Toyin akin.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >>From: "Toyin Akin" <[hidden email]>
> > >>To:
> >
> >>[hidden email],[hidden email]
> > >>Subject: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing
>/
> > >>G2++ model
> > >>Date: Fri, 07 Oct 2005 08:54:53 +0100
> > >>
> > >>
> > >>Hi Marco,
> > >>
> > >>I too deduced that the main implementation was on page 149, but the
> > >>formula for M(0,T) is on pg 144. Thus I was refering just to this
>piece of
> > >>code.
> > >>
> > >>Thankyou for the explanation. I just wanted to know where the
> > >>simplification came from and now I know.
> > >>
> > >>As for the pricing of Bermudan swaptions on FLT/FLT swaps, surely some
> > >>modifications will need to be done within the G2++ class?
> > >>
> > >>In fact you would have 2 sets of logic, one for FLT/FLT (same
>currencies)
> > >>and one for FLT/FLT (different currencies). Or am I missing
>something...?
> > >>
> > >>A G2++ model is perfect for pricing bermudan options on swaps, where
>the
> > >>swaps have differing currency legs.
> > >>
> > >>Thankyou again,
> > >>Best Regards,
> > >>Toyin Akin.
> > >>
> > >>>From: "Tarenghi Marco" <[hidden email]>
> > >>>To: "Toyin Akin" <[hidden email]>
> > >>>Subject: R: [Quantlib-users] Credit default pricing / G2++ model
> > >>>Date: Fri, 7 Oct 2005 09:01:17 +0200
> > >>>
> > >>>
> > >>>Hi Toyin,
> > >>>for what concerning the implementation of the G2++ model, I have
>tested
> > >>>the QuantLib functions and I think they work quite well. The formulas
>in
> > >>>G2::SwaptionPricingFunction class you are referring to are those on
>page
> > >>>149 of the Brigo-Mercurio book and not those on page 144.
> > >>>Anyway they use the formulas on page 144, since mux_ = -M(0,T): the
>fact
> > >>>is that the expression of mux_ is obtained using the formulas on page
>144
> > >>>but simply setting s=0 and t=T, so that the expression simplifies a
>lot.
> > >>>
> > >>>I hope I have been clear enough.
> > >>>
> > >>>Also, you are right: this class can price only vanilla options.
> > >>>Bermudan and/or amortizing swaptions can be priced using trees, and
>these
> > >>>are available in the G2 class: what you have to do is to implement a
>new
> > >>>Swaption class which has to derive from the DiscretizedOption class.
> > >>>
> > >>>Sorry for answering directly to you and not to the mailing list but I
> > >>>cannot do it with my office pc...
> > >>>I should do it from home
> > >>>
> > >>>Best regards,
> > >>>Marco
> > >>>
> > >>>-----Messaggio originale-----
> > >>>Da: [hidden email]
> > >>>[mailto:[hidden email]]Per conto di Toyin
> > >>>Akin
> > >>>Inviato: giovedì 6 ottobre 2005 17:26
> > >>>A: [hidden email]; [hidden email]
> > >>>Oggetto: [Quantlib-users] Credit default pricing / G2++ model
> > >>>
> > >>>
> > >>>
> > >>>Hi folks,
> > >>>
> > >>>Are there any plans to implement credit default swaps/options within
> > >>>QuantLib?
> > >>>
> > >>>I read somewhere, within one of the wilmott forums, that someone did
> > >>>actually have some working code. However I'm not too sure whether
>they
> > >>>are
> > >>>going to dedicate this code to the QuantLib project.
> > >>>
> > >>>I certainly would like to get a good handle on a C++ implementation
>of
> > >>>Credit derivatives as I'm pretty new to it, however I don't want to
>start
> > >>>a
> > >>>new credit project which could take months if someone else already
>has
> > >>>some
> > >>>working code.
> > >>>
> > >>>Also, I am stepping through the code of the G2++ model, comparing the
> > >>>math
> > >>>there to that of the Brigo-Mercurio book and all seems well apart
>from
> > >>>one
> > >>>expression that I can't get my head around.
> > >>>
> > >>>This concerns the code within the constructor of the
> > >>>G2::SwaptionPricingFunction class.
> > >>>
> > >>>There are expressions for mux_ and muy_ which I believe corresponds
>to
> > >>>the
> > >>>same expressions at the bottom of page 144.
> > >>>
> > >>>Taking just the mux_ expression, for example, I cannot match up the
> > >>>expressions within the book to that of the code. It's the 2nd and 3rd
> > >>>expressions of the formula (according to the book) that I am having
>some
> > >>>trouble matching up.
> > >>>
> > >>>Can someone confirm that the code here is correct and it's just a
>case of
> > >>>some smart mathematical  manipulation (My brain has already died
>after
> > >>>validating all the other parts of the G2 model!!).
> > >>>
> > >>>Also from my analysis, it looks like we can only price options on
>vanilla
> > >>>swaptions under this G2++ implementation, no variation of notionals
> > >>>(amortisation), coupons, or margins (spreads). This should be
>possible
> > >>>but I
> > >>>believe that the limiting factor is because it is based on a
>SimpleSwap
> > >>>object which does not allow for such rich definitions of a swap.
> > >>>
> > >>>Also, does anyone know what code changes would be needed to implement
>a
> > >>>bermudan swaption on a FLT/FLT swap? I don't think that the
> > >>>SwaptionPricingFunction class is valid for this type of structure.
> > >>>
> > >>>Very good clean code by the way...
> > >>>
> > >>>Best Regards,
> > >>>Toyin Akin.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>DISCLAIMER:
> > >>>Privileged/Confidential Information may be contained in this message
>and
> > >>>in any of its attachments (the "message"). If you are not the
>addressee
> > >>>indicated in this message (or responsible for delivery of the message
>to
> > >>>such person), you may not copy or deliver this message to anyone. In
>such
> > >>>case, you should destroy this message and kindly notify the sender by
> > >>>reply e-mail. The contents of this message shall be understood as
>neither
> > >>>given nor endorsed by Banca Profilo S.p.A., nor Profilo Real Estate
>SGR
> > >>>S.p.A., nor Profilo Asset Management SGR S.p.A., nor Profilo Academy
> > >>>S.p.A.. Banca Profilo S.p.A., Profilo Real Estate SGR S.p.A., Profilo
> > >>>Asset Management SGR S.p.A., Profilo Academy S.p.A. do not accept
> > >>>liability for corruption, interception or amendment, if any, or the
> > >>>consequences thereof.
> > >>>Il presente messaggio e/o i suoi allegati (di seguito il "messaggio")
> > >>>possono contenere informazioni privilegiate e/o confidenziali. Se non
> > >>>siete i destinatari indicati nel messaggio (o persona incaricata di
> > >>>inoltrare il messaggio al/i destinatario/i), non potete copiare o
> > >>>inoltrare il messaggio ad altri e siete invitati a distruggerlo
>dandone
> > >>>informazione al mittente a mezzo e-mail. Il contenuto del presente
> > >>>messaggio non deve essere considerato come trasmesso o autorizzato nè
>da
> > >>>Banca Profilo S.p.A., nè da Profilo Real Estate SGR S.p.A., nè da
>Profilo
> > >>>Asset Management SGR S.p.A., nè da Profilo Academy S.p.A.. Nè Banca
> > >>>Profilo S.p.A., nè Profilo Real Estate SGR S.p.A., nè Profilo Asset
> > >>>Management SGR S.p.A., nè Profilo Academy S.p.A. si assumono alcuna
> > >>>responsabilità per eventuali intercettazioni, modifiche o
>danneggiamenti
> > >>>del presente messaggio e-mail e per le eventuali conseguenze.
> > >>
> > >>
> > >>
> > >>
> > >>-------------------------------------------------------
> > >>This SF.Net email is sponsored by:
> > >>Power Architecture Resource Center: Free content, downloads,
>discussions,
> > >>and more. http://solutions.newsforge.com/ibmarch.tmpl
> > >>_______________________________________________
> > >>Quantlib-dev mailing list
> > >>[hidden email]
> > >>https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> > >
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by:
> > >Power Architecture Resource Center: Free content, downloads,
>discussions,
> > >and more. http://solutions.newsforge.com/ibmarch.tmpl
> > >_______________________________________________
> > >Quantlib-dev mailing list
> > >[hidden email]
> > >https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads,
>discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Quantlib-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >
>

[Luigi Ballabio]

On 10/10/2005 05:02:31 PM, Toyin Akin wrote:
>
> One of the reasons why I was looking at this class is that  
> theorectically the logic enables you to perform American/Bermudan  
> pricing within a montecarlo framework via the LSMC method
> (Least Squares Monte carlo).

Yes---but I think the code should be heavily optimized.

> However as the QuantLib code stands, I don't know if there is an easy  
> way to simply produce random paths of rates that follows one of the  
> Interest rate stochastic models.
>
> I know that the MonteCarlo code caters for classes within the  
> processes directory, but I'm not too sure about the classes within  
> the ShortRateModels folder.

Given a OneFactorModel instance, model->dynamics()->process() gives you  
the process followed by the underlying state variable. It should be  
possible to pass it to the Monte Carlo framework. The same applies  
(with a few more methods to call) to TwoFactorModel.

Later,
        Luigi

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

This gubblick contains many nonsklarkish English flutzpahs, but the
overall pluggandisp can be glorked from context.
-- David Moser

[Toyin Akin]

Hi Luigi,

As I understand it, the state variable is not actually the short rate itself
and thus I suspect there may be intermediate steps involved in order to go
from this to the rate itself.

I've been looking at the MonteCarlo, Processes and the Shortratemodel
framework for the last 2 days now in order to determine the best way to
achieve this goal, but I haven't actually fully comprehended the
relationships between these classes.

Correlated paths may be an issue as well.

Do you think it would be possible to add an utility class (possibly with
static functions) that given a stochatic interest rate model, it can simply
generate an array of sample paths?

Or maybe provide a quick dirty example of how this can be done.

I know you are a busy guy...

Best Regards,
Toyin Akin.

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email],
>[hidden email],[hidden email]
>Subject: Re: [Quantlib-dev] Hold your horses... Bermudan pricing /
>MCAmericanBasketEngine / LSMC!
>Date: Mon, 10 Oct 2005 15:20:34 +0000
>
>
>On 10/10/2005 05:02:31 PM, Toyin Akin wrote:
>>
>>One of the reasons why I was looking at this class is that  theorectically
>>the logic enables you to perform American/Bermudan  pricing within a
>>montecarlo framework via the LSMC method
>>(Least Squares Monte carlo).
>
>Yes---but I think the code should be heavily optimized.
>
>>However as the QuantLib code stands, I don't know if there is an easy  way
>>to simply produce random paths of rates that follows one of the  Interest
>>rate stochastic models.
>>
>>I know that the MonteCarlo code caters for classes within the  processes
>>directory, but I'm not too sure about the classes within  the
>>ShortRateModels folder.
>
>Given a OneFactorModel instance, model->dynamics()->process() gives you  
>the process followed by the underlying state variable. It should be  
>possible to pass it to the Monte Carlo framework. The same applies  (with a
>few more methods to call) to TwoFactorModel.
>
>Later,
> Luigi
>
>----------------------------------------
>
>This gubblick contains many nonsklarkish English flutzpahs, but the
>overall pluggandisp can be glorked from context.
>-- David Moser
>