# Error in barrier option pricing Monte Carlo

I am currently trying to price an up-and-out call with Monte Carlo simulation. For an option with these parameters :

• Barrier: 65
• $K$ = 50
• $\sigma$ = 30%
• $R$ = 1%
• $T$ = 1Y
• $S_0$ = 50

With 10.000 simulations and $dt = \frac{1}{500}$ I obtain an option price close to 0.80 (95% interval confidence : [0.76 ; 0.853]) whereas a pricer gives 0.73. When rising number of simulations the price increases so I am likely doing something wrong.

Here is the python chunk of code that I use:

all_final_payoffs = np.zeros((nb_simulations,1),dtype=float)

for i in tqdm(range(nb_simulations)):
path_generated_asset = np.zeros((1, nb_time), dtype=float)
path_generated_asset[0, 0] = S0
for j in range(1, nb_time):
X = np.random.randn(1)
path_generated_asset[0, j] = simulate_price(path_generated_asset[0, j - 1], interest_rate, volatility, dt, X)
all_final_payoffs[i,0] = compute_barrier_call_payoff(path_generated_asset[0,:],strike,barrier)
option_price = np.mean(all_final_payoffs)*math.exp(-interest_rate*maturity)


And the two functions used :

def compute_barrier_call_payoff(asset_path,strike,barrier):
if max(asset_path)>=barrier:
return 0
else:
if asset_path[-1]-strike>0:
return asset_path[-1]-strike
return 0

def simulate_price(S,R,Vol,dt,X):
return S*math.exp((R-(Vol**2)/2)*dt + Vol*math.sqrt(dt)*X)


Does someone know where my error is? Thanks a lot!

Edit: When increasing the number of simulations to 20.000 and time steps to 2000, I get the price in 3 minutes (very long) on Python. Same code in C# on the same Mac, the program gives me the result in 7 seconds. When increasing simulations to 50.000 and time steps to 4.000 it takes roughly 35 seconds to give me 0.74$. Edit 2 : Launching the Python code with Cython and typed variables it takes 1 minute. • What happens if you take$dt$smaller? – Raskolnikov Dec 2 '17 at 14:50 • With$ dt = \frac{1}{1000}$and I obtained 0.778 (1 minute), with$dt = \frac{1}{2000}$I got 0.71 (1 min 45 sec) and finally with 20.000 simulations and$dt = \frac{1}{2000}$I got 0.76 (3 min 50). It seems better when decreasing$ dt\$, thanks a lot! – AlexM Dec 2 '17 at 15:05
• One of the ways in which a barrier option is tackled, is to measure how close you are to the barrier while still in. If you get closer, you make your time measurements finer so as to not miss a possible crossing. If you are far away, you can keep larger time steps. – Raskolnikov Dec 2 '17 at 19:39

The path dependency of barrier options requires a sufficient number of steps to accurately model price evolution. For example, the stock price simulation,

for dt=1/10,

for dt=1/500,

for dt=1/1000,

It can be seen that, if you use fewer number of steps, a barrier might not be triggered which would otherwise have been triggered if more number of steps were used. That is, increasing number of steps better models the underlying's price movement, thus increasing accuracy of the simulation. This becomes very important while pricing path dependent derivatives.

• It joins the previous answer given by @Raskolnikov, thanks a lot! – AlexM Dec 2 '17 at 20:27

You can also read through the answer to this related question: How are Brownian Bridges used in derivatives pricing in practice?

Please also note that the timings mentioned are terribly slow. I know speed is not Python's strong point, but still. 3m50s for 20000 simulations with 2000 time steps (dt=1/2000) gives one the wrong idea of how efficient MC can be or not. Downloading this pricer you can see that this shouldn't really take more than half a second (on a budget laptop). Using this app you can also play around with the the Brownian Bridge technique and see how if you use it you then don't need such low dt's to get accurate Monte Carlo barrier prices.

• Thanks a lot for your answer, I am going to read this post and its answer! I am lauching my python code through PyCharm IDE, maybe it can explain why it's pretty slow even if I'm using numpy package..? If we add that, during the execution I had other CPU-consuming programs launched, 3min50 for 40.000.000 iterations is normal? – AlexM Dec 6 '17 at 23:20
• You're welcome, let me know if something isn't clear. The fact that other programs were running may have slowed it down. What do you mean 40.000.000 iterations? As in 20.000 paths x 2000 time steps? Or something else? – Yian Pap Dec 6 '17 at 23:44
• Since I am performing a double loop (one for each path and the other for time steps) it performs roughly 40M iterations, am I wrong? – AlexM Dec 7 '17 at 0:10
• No that's right, that what I thought you meant. I have no idea how slow/fast Python is supposed to be for such computations. But a C++ program does those 40.000.000 iterations in 0.5 seconds. Download the program I linked to and play around if you want, price that option you priced and see what you get. – Yian Pap Dec 7 '17 at 0:18
• I will download and try it soon, I went on the website it seems pretty cool! Also, I think I will run my code on Python, C++ and C# and make a kind of benchmark to see the real difference between them, think it could be interesting. Thanks @Yian Pap ! – AlexM Dec 7 '17 at 9:43