OptionLab evaluates a multi-leg options strategy without a broker

Seven outputs from one strategy description

OptionLab is a Python library for evaluating options trading strategies, described as lightweight and designed to provide quick evaluation of strategies. The README lists what it produces, and the list is the best summary of the package's scope.

You get the profit and loss profile of the strategy on a user-defined target date. You get the range of stock prices for which the strategy is profitable, which the documentation defines precisely as generating a return of at least one cent. You get the Greeks, delta, theta, rho, vega and gamma, associated with each leg of the strategy. You get the resulting debit or credit on the trading account. You get the maximum and minimum returns within a specified lower and higher price range of the underlying asset. You get the expected profit when the strategy is profitable and the expected loss if it proves unprofitable. And you get the strategy's probability of profit.

That is a coherent set of answers to one question: if I put this structure on, what happens. The per-leg Greeks matter because a strategy's risk is the sum of its legs, and a strategy's expected value depends on how often and how much each side wins, which is exactly what the expected profit, expected loss and probability of profit summarise.

The author is Roberto Gomes, PhD, and the project topics name computational finance, options pricing, options trading, trading algorithms, trading strategies and Black-Scholes.

Installing from pip, and what the dependency list implies

The installation section is short, because the package is a normal Python distribution.

pip install optionlab

The pyproject.toml describes the real shape of the thing. The package is built with poetry-core, the version is 1.9.1 in the metadata, and the Python constraint is 3.10 or later.

The runtime dependencies are the interesting part, because they describe the model. scipy and pandas carry the numerical work and the data handling. matplotlib is there for the plots, which says the package can draw its own payoff diagrams. pydantic is used for validation, so the strategy inputs are checked rather than trusted. And holidays is a dependency that only makes sense for one reason: expiry dates follow the exchange calendar, and a library that evaluates strategies around expiry has to know when the market is closed.

jupyter is listed as a runtime dependency too, which is unusual and is a hint about the intended use. The examples directory is full of notebooks, and a strategy evaluation that produces charts is expected to be explored interactively rather than called from a service.

There is a skills/ directory at the root of the repository, which is not a name you see in a pure numerical library, and a CHANGELOG.md, so the project has been maintained with attention to its history.

The examples show which strategies the author had in mind

The examples directory is the most informative part of the repository for anyone deciding whether the library covers their case, and it reads like a catalogue of classic structures.

There is a black_scholes_calculator notebook, which tells you the package includes the Black-Scholes pricing itself rather than expecting you to bring your own prices. There is a calendar spread, a call spread, a covered call, an iron condor, a naked call, a non-simultaneous call spread and a short straddle.

Two of those deserve a note. A non-simultaneous call spread is a structure where the two legs expire on different dates, which is precisely the case where an off-the-shelf pricer that assumes a single expiry gets the risk wrong. And a short straddle is a short volatility position, the case where the loss is theoretically unbounded, so a library that reports maximum and minimum returns over a price range is doing the most valuable thing it can for that structure.

There is also a data file, msft_22-November-2021.csv, which suggests the package can read a price series and evaluate a strategy against actual historical prices rather than only against a model.

The examples also use the notebook format end to end, with a .gitignore in that directory, which fits a library whose output is a chart and a table of numbers you want to read.

What the package deliberately does not claim

The disclaimer section is short and worth quoting in substance, because it sets the boundary of what the numbers mean.

It is free software and is provided as is. The author makes no guarantee that its results are accurate and is not responsible for any losses caused by the use of the code. The caution notice adds that options are very risky derivatives and, like any other type of financial vehicle, trading options requires due diligence, and that the code is provided for educational and research purposes only.

So this is a study tool by the author's own account. That does not make it less useful; it makes the use case different. A library that tells you the break-even price of a covered call in a given month, and the delta of each leg, is genuinely valuable for learning and for pre-trade research, and it is exactly the kind of thing you would otherwise do by hand in a spreadsheet.

What it is not is a risk system. The probability of profit is a model output under the assumptions the package encodes, and the author is explicit that he does not stand behind the accuracy. There is no market data connection in the dependency list, no broker integration and no order routing.

The licensing sits in the same spirit. The repository is GPL-3.0, and the metadata records a GPL classifier. For a research or teaching tool that is unproblematic, and it is worth remembering for anyone who wants to embed the library in a commercial product.

A typed, tested, benchmarked Python package rather than a script

The development tooling tells you what kind of project this is, and it is more disciplined than a typical single-author script collection.

The package uses poetry as its package manager, and the pyproject.toml declares a dev dependency group with mypy for type checking, black with the jupyter extra for formatting, pytest, pytest-benchmark and ruff. The pytest configuration sets addopts to exclude benchmark tests by default and registers a benchmark marker, with the note that benchmarks are run with pytest -m benchmark.

The source code must be formatted using black, according to the contribution section, and the project uses git hooks with pre-commit to customise actions on the repository.

The benchmark marker is worth a second look, because it tells you the author cared about the performance of the evaluation itself. A library that evaluates a strategy across a range of underlying prices and a range of dates is doing a lot of numerical work, and if each evaluation re-prices every leg from scratch then a sweep can become slow. A dedicated benchmark suite suggests the hot paths were at least measured.

pydantic in the runtime dependencies and mypy in the dev group together mean the strategy inputs are validated at the boundary and the code is type checked, which matters for a library whose users will be modelling combinations with a dozen fields each.

Where the gap is: model inputs, and the cost of being wrong

The honest limitation is about the model rather than the code.

The README describes outputs on a user-defined target date, with a user-specified lower and higher price range for the underlying. That range is a choice you make, and the maximum and minimum returns it reports are only the extremes within the range you chose. A strategy whose worst case lies outside your range will look better than it is. The documentation does not say what the default range is, or whether the range is automatically widened, so this is a parameter to check rather than an assumption to make.

The same applies to the probability of profit and the expected profit and expected loss. Those figures come from the model the package implements, and the disclaimer tells you the author makes no guarantee about their accuracy.

The alternative to using it is to price the same structure yourself, which is what the black_scholes_calculator notebook in the examples suggests is possible within the package itself, and what you would do by hand in a spreadsheet otherwise. The difference in approach is that OptionLab gives you a whole strategy in one call, with the per-leg Greeks and the payoff profile assembled for you, so the trade is between a fast, consistent evaluation and a hand calculation you fully understand.

For a project where the numbers feed a decision, that is a decision about how much you need to trust a model, and the project's own documentation answers it by saying the code is for educational and research purposes only.

Editorial conclusion

OptionLab fits a student, researcher or quant who needs to price and interrogate a multi-leg options structure without a broker terminal, because the package returns the profit and loss profile, the profitable price range, the Greeks and the probability of profit from one call. It does not fit a live execution system, since it has no market data connection and no order routing, and it does not fit a risk system, since the probability of profit is a model output under assumptions the author explicitly declines to guarantee. Before adopting it, read the disclaimer in the project documentation, check that the model inputs you need are in the pyproject dependency list, and treat the outputs as a study aid: the author states the results are provided as is with no guarantee of accuracy and no responsibility for losses.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. rgaveiga/optionlab on GitHub