Pricing of Structured Product with Schedules

[Haoyun XU]

Hi Luigi,

I am considering the feasibility of using QuantLib's existing finite difference framework to price more exotic products like knockout daily accumulators (KODA). However, after reading the code for quite a while, I am still struggling. Really appreciated if you can show me the right direction.

Basically, these products may have a schedule with multiple periods. The payment is settled at each period end. They may also have features like KO (daily or periodically) and KI (American, European, etc). 

We would like to build the mesh and evolve backward in time just once to get the price and Greeks. For instance, the KODA is actually a bunch of knockout forwards, which can be further decomposed into knockout calls and puts. However,instead of pricing each of these components then adding them up, we would like to evolve on the mesh once and change the payoff on the fly. Does the current framework support this? Or do you have a better design?

Also, I wonder what's the place of such structure product in the instrument hierarchy?

Thank you very much for your time!

Best,

Henry

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

Hello,
    I'm a bit rusty when it comes to finite differences, but it should
be possible to implement what you want. I would start by looking at
some existing engines, such as FDBermudanEngine or
FdBlackScholesBarrierEngine (the first uses the old framework, the
second the new one).  They both provide examples of how to use the
hooks provided by the framework.  For instance, FDBermudanEngine
implements an executeIntermediateStep method that you too might
customize for your instrument; it would be executed at any stopping
date, and you would use it for applying the payoff (probably
calculating it and adding it to the value of your instrument; the Size
arguments that FDBermudanEngine ignores is the order number of the
stopping date, so you would use it to know at which payment date
you're stopping). Instead, the initializeStepCondition method is used
to set a condition which will be applied at each step (you might want
to use this for the KI/KO feature, but you could also use a boundary
condition).  I'm less familiar with the new framework, so I won't try
and describe the second engine.

Sorry I don't have time to go into more details.  I guess what I'm
trying to say is: if you try to look at those example (possibly step
into their code with a debugger?) you should get a better idea of how
they work and when the various features are applied, so that you can
apply your own customization.

Let me know if this helped, or if you get stuck again.

Later,
    Luigi







On Tue, Jul 23, 2013 at 8:41 AM, Haoyun XU <[hidden email]> wrote:

> Hi Luigi,
>
> I am considering the feasibility of using QuantLib's existing finite
> difference framework to price more exotic products like knockout daily
> accumulators (KODA). However, after reading the code for quite a while, I am
> still struggling. Really appreciated if you can show me the right direction.
>
> Basically, these products may have a schedule with multiple periods. The
> payment is settled at each period end. They may also have features like KO
> (daily or periodically) and KI (American, European, etc).
>
> We would like to build the mesh and evolve backward in time just once to get
> the price and Greeks. For instance, the KODA is actually a bunch of knockout
> forwards, which can be further decomposed into knockout calls and puts.
> However,instead of pricing each of these components then adding them up, we
> would like to evolve on the mesh once and change the payoff on the fly. Does
> the current framework support this? Or do you have a better design?
>
> Also, I wonder what's the place of such structure product in the instrument
> hierarchy?
>
>
> Thank you very much for your time!
>
> Best,
> Henry

--
<https://implementingquantlib.blogspot.com>
<https://twitter.com/lballabio>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users