Quantitative finance projects you can build, check and explain

Reference article

A project that prints a 40% return proves nothing, because anyone can find a rule that worked on past data. A project that prices an option two ways and shows the two prices agree to the cent proves you can build something correct. That is what a reviewer looks for: a result checked against something independent, and a plain account of where it breaks.

This page gives eight projects you can build in Python, each one a small piece of real quantitative finance work. Every entry lists what you build, the maths, free data where data is needed, the check that proves the code is right, and the trap that makes the project worth showing. The projects go from easier to harder. Projects 1 to 4 are about pricing, and 5 to 8 are about data.

What makes a project worth showing

In our view, a reviewer reading your GitHub wants three things:

1. A check against something independent. Two methods that agree, a known formula, or a test on data the model never saw.
2. A named data window. "US daily closes, 2010 to 2024" is a fact a reader can repeat. "Past data" is not.
3. Honest limits. A short list of where the method breaks.

A return figure on its own shows none of the three. If a project reports one, report it as the result of a method on a named window, beside the costs you assumed, and never as what someone should expect.

Project 1: a Black-Scholes pricer and implied volatility solver

Build: a function that prices European calls and puts with the Black-Scholes formula, and a second function that finds the implied volatility from a price.

The maths: $C = S N(d_1) - K e^{-rT} N(d_2)$, with $d_1 = \frac{\ln(S/K) + (r + \sigma^2/2) T}{\sigma \sqrt{T}}$ and $d_2 = d_1 - \sigma \sqrt{T}$. Invert it for $\sigma$ with Newton's method, falling back to bisection when Newton steps out of range.

The check: put-call parity, $C - P = S - K e^{-rT}$, must hold to rounding error for every input. Then compare a few prices with our free Black-Scholes calculator and implied volatility calculator.

The trap: deep out-of-the-money options. Their prices are tiny, so a rounding error of one cent in the price moves the implied volatility a lot. Our free page inverting Black-Scholes for implied volatility explains why. Show a plot of how far the volatility moves for a one-cent change in price.

Project 2: a Monte Carlo pricer with a standard error

Build: price the same European call by simulating many final prices and averaging the discounted payoff. Then add antithetic variates: pair each normal draw $Z$ with $-Z$.

The maths: the estimate is an average, so its standard error is the sample standard deviation of the payoffs divided by $\sqrt{n}$. Four times the paths halves the error.

The check: run it 100 times with different seeds. About 95 of the 100 intervals of two standard errors either side of the estimate should contain the Black-Scholes price from Project 1.

The trap: reporting a price without its standard error. Our free page the Monte Carlo pricing estimator and its standard error covers the reason in full.

Project 3: a binomial tree, and the early exercise of an American put

Build: a Cox-Ross-Rubinstein binomial tree. Price a European call, then an American put, which may be exercised at any time.

The maths: each step goes up by $u = e^{\sigma \sqrt{\Delta t}}$ or down by $d = 1/u$, with risk-neutral probability $p = (e^{r \Delta t} - d)/(u - d)$. For the American put, at each node take the larger of the value of holding and the value of exercising now.

The check: as the number of steps grows, the European price must approach the Black-Scholes price from Project 1. Plot the error against the number of steps. Compare with our free binomial option pricing calculator.

The trap: the error does not fall smoothly; it zig-zags between odd and even step counts. Show the zig-zag and explain it, rather than hide it.

Project 4: a delta-hedging simulation

Build: sell one call, hedge it by holding $\Delta = N(d_1)$ shares, and rebalance at fixed times along simulated price paths. Record the profit and loss at expiry.

The check: with the volatility used to simulate equal to the volatility used to hedge, the average profit and loss should be close to zero, and its spread should shrink as you rebalance more often. Plot the standard deviation of the hedging error against the number of rebalances.

The trap: hedge with the wrong volatility. Simulate at 25% and hedge at 20%, and show that the profit and loss is now biased, not only noisy. That shows you understand what a hedger is exposed to.

Project 5: an honest backtest of a simple rule

A Backtest runs a written trading rule over past data to see what it would have done. It is the easiest project to do badly.

Build: one simple rule, such as a moving-average crossover on a broad index, tested with trading costs and a walk-forward split: choose any settings on one window, then test them on the next window, never the other way round.

Data: state the market, the source and the window. The source must allow your use.

The check: run the same rule on shuffled returns, which have no pattern. It should earn no more than the drift and chance give it. If it does better, look for a bug, such as using tomorrow's price today. Then compute the deflated Sharpe ratio with our free deflated Sharpe ratio calculator, counting every setting you tried.

The trap: look-ahead bias and testing many settings, then reporting the best one. Our free page what a backtest is, in plain words is the start.

Past results of a method on past data are not a forecast. Say so in your README.

Project 6: value at risk and expected shortfall, with a backtest of the breaches

Build: compute one-day 99% value at risk (VaR) and expected shortfall for a portfolio of two or three assets, three ways: historical, normal (parametric) and Monte Carlo.

The check: count the days on which the loss was larger than the VaR. At 99%, about 1 day in 100 should break it. Test the count with Kupiec's proportion-of-failures test. Compare one result with our free VaR and expected shortfall calculator.

The trap: the normal method misses fat tails, so it breaks too often in a crisis window. Show the breach count per year, not only in total. Our free page what a VaR number actually says explains what the number does not say.

Project 7: forecasting volatility, scored out of sample

Build: forecast tomorrow's Volatility three ways: a rolling 20-day standard deviation, an exponentially weighted average (EWMA), and a GARCH(1,1) model, for example with the Python arch library.

The check: score each forecast only on days after the data it was fitted on, with a loss function made for variance forecasts, such as QLIKE: $\text{QLIKE} = \frac{r_t^2}{h_t} - \ln \frac{r_t^2}{h_t} - 1$, where $h_t$ is the forecast variance and $r_t$ the return. Use the average over the test window.

The trap: fitting GARCH on the whole sample and then scoring it on the same sample. That is a look at the answers. Keep the test window untouched.

Project 8: principal components of the yield curve

Build: download daily US Treasury yields at several maturities, for example the constant-maturity series on FRED, the data service of the Federal Reserve Bank of St. Louis. Take daily changes, and run principal component analysis (PCA).

The maths: PCA finds the directions of largest variance through the eigenvectors of the covariance matrix. Our free page principal components, derived rather than asserted derives it.

The check: report the share of variance each of the first three components explains, and plot their loadings against maturity. Then compare the shapes with the level, slope and curvature pattern that textbooks describe. Repeat on two separate windows and say whether the shapes hold.

The trap: running PCA on yield levels instead of daily changes. Levels drift for years, so the result says more about the trend than about how the curve moves.

Writing it up

For each project, a README with five short parts works well, in our view:

1. The question, in one sentence.
2. The data: source, market, window, and any cleaning.
3. The method, with the maths in a few lines.
4. The check, with its result.
5. The limits.

On a resume, describe what you built and how you checked it, for example "Monte Carlo option pricer; matches the closed form within two standard errors on 95 of 100 seeds". Do not put a backtest return on a resume as if it were a track record.

Where Thuztra Learn fits

Thuztra Learn is our product. The calculators linked above are free. The maths behind projects 1 to 4 is in Learn's Level 2 modules on Monte Carlo, PDE methods, and Greeks and implementation; projects 5 to 8 lean on its modules on statistical inference, risk measures and tails, and market data. For what to study first, see the quantitative finance syllabus. Membership is a paid subscription: see what Thuztra Learn is and what it costs.

Education only, not advice. Nothing here promises a job or a trading result.

In short

Pick projects with a built-in check: a second method, a known formula, or an out-of-sample test. Write down the data window and the limits. Report what you verified, never a return figure as if it were a promise.

Terms used here

• Quantitative finance
• Option
• Volatility
• Backtest
• Implied volatility
• Walk-forward analysis
• Deflated Sharpe ratio

Related

More on these topics

• Installing Python on your computer
• Running your first notebook
• What Python is, and why quants use it
• Black-Scholes as a heat equation
• Multilevel Monte Carlo
• Quasi-Monte Carlo and effective dimension

Topics

• projects
• python
• careers
• getting started
• backtesting
• option pricing

Also in the library

• Quant puzzles
• Interview questions
• Quant brainteasers
• Glossary
• Reference articles