|
From: Jonathan S. <sw...@gm...> - 2022-06-20 21:06:25
|
If the product knocks in or out during its lifetime then it is no longer the same product - in the case of the knock-out it becomes nothing and in the case of the knock-in it becomes a regular option and should be priced as such. Your position management system should be able to handle these lifecycle events so that you see the right positions in your book. Having said that, I still think it could make sense to improve the validations on these barrier products to provide better error messages in case of invalid inputs. 2022년 6월 20일 (월) 22:50, Ashish Bansal <ash...@gm...>님이 작성: > I am not pricing with barrier breach on the inception day. > > Assuming the trade started out of barrier limit, i.e. higher than barrier > for DI and DO type, I am pricing during the life of trade. During life the > underlying could move knocking the barrier. The code starts showing error > after the breach. > > I am looking to improve code so that during life of trade it shows right > price output instead of error. > > Ashish > > On Mon, Jun 20, 2022, 4:16 PM Jonathan Sweemer <sw...@gm...> wrote: > >> I can reproduce the exception that you're seeing. As for the explanation, >> I'm not an expert in this code, but here's my take on it: >> >> 1. for Down-Out, when I pass the spot less than the barrier, I get >>> RunTimeerror for interpolation range. Should I block the pricing at all in >>> this case? Can't the engine handle it? >> >> Generally you'd expect a down-and-out call to be quoted with spot above >> the barrier, so starting with spot below the barrier is kind of a >> degenerate case, as the product knocks out before it even starts, so I >> believe the exception is warranted (though perhaps not as informative as it >> could be). >> >> 2. For Down-in, I am getting the same error whereas the option gets >>> activated and is still live then why is this not priced by the engine? Am >>> I doing something wrong? >> >> Similar to question 1, you'd expect a down-and-in call to be quoted with >> spot above the barrier, but in this case I agree that a case can be made >> for the product to be live (i.e. knocked-in at inception), although it >> would probably depend on the specific deal terms how to handle this case. >> If you have any such deal terms to refer to, then you might want to submit >> a pull request to handle them accordingly in the code. >> >> >> >> On Mon, Jun 20, 2022 at 5:11 PM Ashish Bansal <ash...@gm...> >> wrote: >> >>> Following is the code that I am using to evaluate the barrier option. >>> Here if I pass the spot which has crossed the barrier for knock-in or >>> knock-out options, I get an error. The down-out is in the code and for >>> down-in, I took the example given in row# 266 of with spot price as 94 from: >>> >>> https://github.com/lballabio/QuantLib/blob/master/test-suite/barrieroption.cpp >>> >>> My python code: >>> >>> ############################################################################ >>> import QuantLib as ql >>> >>> # Setting Barrier option parameters >>> calculation_date = ql.Date(1, 6, 2021) >>> maturity_date = ql.Date(25, 11, 2021) >>> spot_price = 577.0 >>> strike_price = 770.0 >>> volatility = 43.56/100 >>> option_type = ql.Option.Call >>> risk_free_rate = 0.175/100 >>> barrier_price = 400.0 >>> barrier_type = ql.Barrier.DownOut >>> rebate = 0 # no rebate >>> day_count = ql.Actual365Fixed() >>> calendar = ql.TARGET() >>> >>> >>> marketpremium = 18.64 >>> >>> ql.Settings.instance().evaluationDate = calculation_date >>> >>> # Constructing the EU option in QL >>> payoff = ql.PlainVanillaPayoff(option_type, strike_price) >>> eu_exercise = ql.EuropeanExercise(maturity_date) >>> barrier_eu_option = >>> ql.BarrierOption(barrier_type,barrier_price,rebate,payoff, eu_exercise) >>> >>> # The Black-Scholes-Merton process is constructed >>> spot_handle = ql.QuoteHandle( >>> ql.SimpleQuote(spot_price) >>> ) >>> flat_rate_ts = ql.YieldTermStructureHandle( >>> ql.FlatForward(calculation_date, >>> risk_free_rate, >>> day_count) >>> ) >>> flat_vol_ts = ql.BlackVolTermStructureHandle( >>> ql.BlackConstantVol(calculation_date, >>> calendar, >>> volatility, >>> day_count) >>> ) >>> bs_process = ql.BlackScholesProcess(spot_handle, >>> flat_rate_ts, >>> flat_vol_ts) >>> >>> # compute the theoretical price using the AnalyticEuropeanEngine >>> >>> barrier_eu_option.setPricingEngine(ql.FdBlackScholesBarrierEngine(bs_process)) >>> br_eu_price = barrier_eu_option.NPV() >>> print("The theoretical price for EU barrier is %lf" % br_eu_price) >>> >>> ############################################################################ >>> >>> Regards, >>> Ashish >>> >>> On Fri, 17 Jun 2022 at 02:40, Jonathan Sweemer <sw...@gm...> >>> wrote: >>> >>>> Hi Ashish, can you share your code or a link to it? >>>> >>>> 2022년 6월 17일 (금) 03:35, Ashish Bansal <ash...@gm...>님이 작성: >>>> >>>>> Hi, >>>>> >>>>> Any guidance on this error in barriers? >>>>> >>>>> Regards, >>>>> Ashish >>>>> >>>>> On Tue, 14 Jun 2022 at 13:03, Ashish Bansal <ash...@gm...> >>>>> wrote: >>>>> >>>>>> Dear team, >>>>>> >>>>>> I need some guidance on the pricing of the barrier option using >>>>>> the FdBlackScholesBarrierEngine in the event that the barrier is hit: >>>>>> 1. for Down-Out, when I pass the spot less than the barrier, I get >>>>>> RunTimeerror for interpolation range. Should I block the pricing at all in >>>>>> this case? Can't the engine handle it? >>>>>> 2. For Down-in, I am getting the same error whereas the option gets >>>>>> activated and is still live then why is this not priced by the engine? Am >>>>>> I doing something wrong? >>>>>> >>>>>> What is the difference between FdBlackScholesBarrierEngine >>>>>> and AnalyticBarrierEngine? I compared a few results and found a slight >>>>>> difference in values. Any suggestion on which one to use? >>>>>> >>>>>> Any help would be appreciated. >>>>>> >>>>>> Thanks >>>>>> Ashish >>>>>> >>>>> _______________________________________________ >>>>> QuantLib-users mailing list >>>>> Qua...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users >>>>> >>>> |