• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Pricing a down-and-in barrier call option using the combinatorial formula

Hi friends,

I am trying to price a down-and-in barrier call option. Lyuu's book gives a simple combinatorial formula for the probability that the underlying hits the barrier and makes \(j\) upward moves, as


However, when I implement the algorithm in Python, the option value isn't close to the Black-Scholes price, no matter what \(n\)(number of time steps), I choose. Am I doing something fundamentally wrong? This is my code snippet:

# Optimal algorithm for European down-and-in call barrier  options

import numpy as np
import math

def priceDownAndInCall(S, X, H, r, sigma,
                         T, N, optionType):

    # Binomial tree parameters
    dt = T/N
    u = math.exp(sigma*math.sqrt(dt))
    d = 1/u
    disc = math.exp(-r*T)

    a = math.log(X/(S*(d**N)))/math.log(u/d)
    a = math.ceil(a)
    h = math.log(H/(S*(d**N)))/math.log(u/d)
    h = math.floor(h)

    # Risk-neutral probabilities
    p = (math.exp(r*dt)-d)/(u-d)
    q = 1-p

    # Start at layer 2h
    S = S * (u**(2*h)) * (d**(N-2*h))
    b = 1 * (p**(2*h)) * (q ** (N-2*h))

    C = b * (S-X)

    for j in range(2*h-1,a-1,-1):
        b = (p*(N-2*h+j+1)/(q*(2*h-j)))*b
        S = S * (d/u)
        C = C +  b * (S-X)

    return disc * C

C = priceDownAndInCall(100, 102, 97, 0.05, 0.20, 1, 50, 'C')

If anybody has a piece of code that works, that would help as well.

Maybe binomial tree algorithms only have pedagogical value, simple and intuitive. As an aside, therefore, what method would a pricing engine in the real world use to price a barrier - numerically solve the PDE or Monte Carlo?

Thanks in advance guys,
Last edited:

Daniel Duffy

C++ author, trainer
This is a standard barrier option,, yes? Closed solutions are available (e.g. Haug 2007).
Debugging: take a large barrier, does the solution approach classic Black Scholes (initial sanity check).
@Daniel Duffy , let me try with a large barrier and see if it approaches the classic BS-price.

@yetanotherquant , the link is so so cool, I would like to get my hands wet on Quantlib. I am delivering a talk to my team on Options pricing with Python - to give a flavour of how its done. I am going to include some fun topics : smile pricing using Vanna Volga, spread options. Having said that, I want to make sure it is as close as possible to the real thing.

I have attached my power-point slides and a PDF doc on stuff I plan to talk about. Any tips would be great!


  • Options pricing using Python.pptx
    1.7 MB · Views: 237
  • Options pricing with Python-Examples.pdf
    366.9 KB · Views: 211
Yes, @vertigo is right (at least with the fact, that the non-toy volatility models are complex).
But this is one more advantage of QuantLib: in my example there is a helper-method, which generates a flat volatility, i.e. the simplest possible

flatVol(const Date& today,
    const boost::shared_ptr<Quote>& vol,
    const DayCounter& dc) {
    return boost::shared_ptr<BlackVolTermStructure>(new
        BlackConstantVol(today, NullCalendar(), Handle<Quote>(vol), dc));

In my case it is really enough because I want to (approximately) show the realm of possible scenarios to retail speculators (image how they would look at me if I would start talking about Heston et al :))

But nothing prevents you from specifying a more advanced vola-structure in QuantLib and then supplying the pricing engine with it.
By the way, an idea to price American(!) barrier options with monte-carlo is generally bad.
For this you need a least-square Monte-Carlo, which I myself, often use.
But if I have an alternative (lattice / finite difference) pricing method, which is already implemented and tested (in QuantLib) then I use it with much more pleasure.
In the real world you would specify a local stochastic volatility model (Heston + local) and price via monte carlo method. Some companies are dumb enough to use only stochastic vol, but let's forget this.

@vertigo and @yetanotherquant , thanks, this conversation is so thoughful and enlightening for me! I want to get my hands wet with C++, Boost, so as an exercise, I'll try to create some notes and implment the Heston model. :)