QuantLib: twenty years of pricing infrastructure for derivatives

A library organised around instrument definitions, not around a task

The README states the goal plainly: a comprehensive software framework for quantitative finance, described as a free and open source library for modeling, trading and risk management in real life. The important word in that sentence is real. QuantLib is built around the conventions of actual instruments, which is why the vocabulary of the codebase is a financial vocabulary: day count conventions, calendars, term structures, coupon schedules, settlement rules.

That design produces a large surface area with a small core of concepts. To price a European option you construct a yield curve, a volatility surface, a Black-Scholes process, a stochastic process and an engine, and hand them to a pricing class. There is no shortcut for that structure because the shortcut would be the thing that gets day counts wrong on a specific corporate bond.

The repository tree reflects the shape. The ql directory holds the library. Examples contains named subdirectories that double as worked examples: AsianOption, BasketLosses, BermudanSwaption, Bonds, CDS, CVAIRS, CallableBonds, ConvertibleBonds, DiscreteHedging, EquityOption, FRA, FittedBondCurve, Gaussian1dModels, GlobalOptimizer, LatentModel, MarketModels, MulticurveBootstrapping, MultidimIntegral, Replication and Repo.

The Examples directory is the fastest way into the library. Each is a self-contained program that constructs one instrument and prices it, and reading a handful of them teaches the construction patterns faster than the reference documentation does.

The deprecation policy removes features roughly every five releases

QuantLib maintains a scheduled deprecation list, and this is the single most important operational fact about using it. Release 1.42 removed features deprecated in release 1.37. Release 1.43 removed features deprecated in release 1.38. The gap is consistently around five releases, which works out to roughly a year.

Release 1.43 then deprecated a new batch for removal in a future release, probably 1.48. The listed items include the AsIndex element of the CPI::InterpolationType enumeration, where the replacement is either Linear or Flat. The YoYInflationIndex::interpolated method and its interpolated_ data member are also listed, with the note that indexes no longer interpolate, coupons do. The Settlement element of the Israel::Market enumeration is deprecated in favour of an explicit market: TASE, Shir or Telbor. And passing --slow, --fast or --faster to the test suite is no longer supported.

Release 1.42 deprecated a comparable set: overloads of CashFlows::npv, BondFunctions::cleanPrice and BondFunctions::dirtyPrice that take a z-spread and a day-count convention, plus overloads of CashFlows::zSpread and BondFunctions::zSpread taking a day-count convention. The DefaultLogCubic and LogMixedLinearCubic interpolators are deprecated in favour of KrugerLog and KrugerLogMixedLinearCubic. A group of finite-difference boundary conditions including NeumannBC, DirichletBC, CrankNicolson, DMinus, DPlus, DPlusDMinus, DZero, ExplicitEuler, ImplicitEuler and Mixed variants are on the same list.

If you pin to a recent version, none of this touches you. If you follow a distribution package or track master, you will hit it, because these are signature changes rather than internal cleanups. The z-spread day-count case is the one most likely to catch you out, since the overload still exists and the call will compile.

Releases arrive as tarballs, with patch releases that exist only to stop a loop

Each release is published with both a .tar.gz and a .zip attached directly to the release page, which is an old-fashioned approach that still works. Version 1.43 was published on 2026-07-14 and version 1.42 on 2026-04-14, a three-month cadence for feature releases.

The patch release in between is the interesting case. Version 1.42.1 exists because of a single bug: a regression in the Gsr class that could lead to an infinite notification loop, credited to a reporter who flagged it. The fix was to avoid the notification loop in the GSR model, and the release was four days after 1.42.

This is worth understanding as a design property rather than an accident. QuantLib uses an observer pattern extensively, so a term structure updates its dependents when inputs change. A model whose update handler re-enters its own setter produces the infinite loop described above. The patch release isolating that single fix, rather than shipping a patch that bundled several changes, tells you how the project responds to a regression that reaches users.

The repository was last pushed on 2026-09-21, with 7,627 stars, 2,331 forks and 43 open issues. Forty-three open issues on a library this size is a very low ratio, and it is consistent with the deprecation-first approach: fewer open questions because the release notes answer most of them in advance.

Build systems, continuous integration and the tools nobody expects to find

QuantLib builds through several systems at once, which is unusual and reflects its age and its audience. The tree contains CMakeLists.txt and CMakePresets.json, a Makefile.am with autogen.sh and configure.ac for the autotools path, QuantLib.sln and QuantLib.vcxproj for Visual Studio, QuantLib.spec.in for packaging, and quantlib.pc.in with quantlib-config.in for pkg-config integration.

Continuous integration covers the platforms that matter. There are separate workflow files for Linux, MSVC, macOS and CMake, plus an AppVeyor configuration and a .lsan.txt for LeakSanitizer. Static analysis runs through .clang-format, .clang-tidy, .lgtm.yml and a .msvc-analysis.ruleset. Coverage is tracked through Coveralls and Codecov.

Three directories in the tree are less usual. There is a fuzz-test-suite, which tells you the parsers and numerical routines are fuzz-tested. There is a dockerfiles directory. And there is an .agents directory alongside top-level AGENTS.md and CLAUDE.md files, which are instructions for automated coding agents working in the repository.

Those last two files are the clearest signal of how this project is maintained in 2026. A quantitative finance library with a fifteen-year history of careful conventions has added agent instruction files to its root, meaning contributors are expected to hand work to automated tools and the maintainers want that work to follow house rules. For anyone contributing, those files are the first thing to read.

BSD 3-Clause by badge, and unlabelled by metadata

The licensing picture needs two sentences. The README carries a badge reading Licensed under the BSD 3-Clause License, pointing at LICENSE.TXT, and the body text states that QuantLib is Non-Copylefted Free Software and OSI Certified Open Source Software. GitHub, however, reports the license field as NOASSERTION rather than BSD-3-Clause.

That combination is common on older repositories whose metadata predates license detection or whose LICENSE file uses a header the detector cannot classify. It is not a signal of restriction. The authoritative source is LICENSE.TXT in the tree root, and the README's own wording about non-copylefted free software and OSI certification settles the practical question for anyone considering commercial use inside a proprietary product.

There is also a CITATION.cff file, which is a newer addition and a welcome one for a project that has been around long enough to be cited in academic work. Combined with the Zenodo DOI badge in the README, it means the project has a formal citation path rather than relying on a URL that may move.

What the README covers and where everything else lives

The README is short, which is appropriate for a project this old and this documented elsewhere. It points to the download page, installation instructions, usage and design documentation, and a version history page listing changes for each past release. Questions go to the quantlib-users mailing list, described as the preferred channel and the one with the largest audience. Bugs go to GitHub issues, and patches as pull requests.

That division is worth noting for evaluation purposes. If you are deciding whether QuantLib fits your problem, the README will tell you it is comprehensive and leave every substantive question open. The questions that matter are all documented on quantlib.org: whether a specific instrument is covered, which day count conventions are implemented, how a particular term structure is bootstrapped, and which interpolation types are available.

The repository itself is the better source for two other things. The Examples directory tells you what the library considers a complete, well-formed pricing program. The ChangeLog.txt file, sitting alongside the release notes on the website, gives a longer history than the release page does.

One last practical note. QuantLib is a C++ library, and most Python users arrive through the separate QuantLib-Python bindings with a SWIG interface. Those bindings are a different repository, so the C++ library's release cadence and its Python wrapper's release cadence do not move together, and it is worth checking which version of the wrapper you have before assuming a C++ feature is reachable from Python.

Editorial conclusion

QuantLib is not a codebase to read in an afternoon. Its value is that its day count conventions, calendars and instrument definitions match what the market actually uses, and that its release notes tell you precisely when a definition changed. The practical implication for adopting it is the deprecation cadence: features marked for removal are typically gone within about five releases, so pin the version and read the release notes rather than tracking master. Start with the Examples directory, which covers options, bonds, CDS and CVA in enough detail to serve as reference implementations.

Frequently asked questions

Official sources

1. Issues
2. lballabio/QuantLib on GitHub
3. Project website
4. README
5. Releases