FinancePy: a Python derivatives pricing library built for readable code and Numba speed
A Python Finance Library that focuses on the pricing and risk-management of Financial Derivatives, including fixed-income, equity, FX and credit derivatives.
At a glance
- What is it?
- FinancePy packages pricing and risk models for fixed income, equity, FX and credit derivatives into one Python library, with a product-first layout and Numba compilation. It suits students, quants and risk managers who want to read the code, not just call it.
- Who is it for?
- FinancePy fits students, academics and quants who want to read the pricing code down to the lowest level and are willing to accept a first-import compile delay and a beta label. It is a poor fit if you need a supported commercial SLA, a non-GPL licence, or a library whose API is stable across major versions.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 2, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What FinancePy covers that a general quant stack does not
Most Python quant code starts from a model: you pick Black-Scholes, then bolt a product on top. FinancePy inverts that. The README says the design is "product-based rather than model-based", so someone pricing a specific instrument finds the product class first and takes the default model unless they want to change it. The products folder is split into Bonds, Credit, Equity, FX and Rates, with names like bond_convertible.py, cds.py, equity_variance_swap.py, fx_barrier_option.py and ibor_swaption.py. That naming is the documentation. If you know the instrument, you know the file.
The stated audience is broad: students of finance and of Python, academics teaching or researching, traders, quantitative analysts, risk managers, portfolio managers and fund managers. Those groups want different things from a library, and the README tries to serve all of them with one rule set: keep the code simple enough that anyone with basic Python fluency can check it, keep it all in Python so a reader can follow it to the lowest level, and use Numba to recover the performance lost by staying in Python. Whether that trade holds depends on your workload, not on the library's ambition.
The four-folder architecture and how a price actually gets computed
The repository splits into market, models, products and utils. The market folder holds term structures and surfaces: discount_curve.py, discount_curve_flat.py, composite_discount_curve.py, equity_vol_curve.py, fx_vol_surface.py, swaption_vol_surface.py. The models folder holds the mathematics: bachelier.py, bdt_tree.py, black_scholes.py, vasicek_mc.py. The utils folder holds dates, calendars, day counts and schedule generation, which is where most pricing bugs live in practice.
The README is explicit about the call direction: model pricing functions "are not usually called directly but are called from the products objects". So the flow is market data into a curve or surface object, that object into a product constructor, and the product method into a model. You can bypass the product layer and call a model directly, but then you own the argument order and the conventions.
For most products the README states a Monte-Carlo implementation is provided, described as a reference for testing and a way to understand payments, timings and conditions. That is a genuinely useful design choice. A Monte-Carlo path makes the cashflow schedule legible in a way a closed-form formula does not, and it gives you a second number to compare against the analytic one.
Installing FinancePy and running a first date calculation
The README gives one install path: pip. There is no conda channel documented and no source build instructions in the README, though pyproject.toml and setup.py are present in the repository root if you want to build from a checkout.
pip install financepyTo upgrade an existing installation the README gives the standard form:
pip install --upgrade financepyThen start a Python terminal and do a wildcard import from the utils package. The README warns that the first import can take several seconds because Numba compiles the models, and that the compiled code is cached on your machine afterwards, so later imports are almost instant.
from financepy.utils import *The README supplies a one-line check. Construct a date and add two days to it:
Date(19, 2, 2026).add_days(2)The README says you should see 21-FEB-2026. If you do not, the install or the import did not complete as expected. From there, the README points to examples/scripts and examples/notebooks in the repository, and to the generated API documentation at domokane.github.io/FinancePy. The README states the notebooks folder contains over 90 example notebooks.
The Numba compile delay is a real cost, not a footnote
The README's own warning is the most important operational fact about FinancePy: the first import of a model triggers Numba compilation, which takes several seconds, and only that first import is slow. For a notebook session that runs for an hour, this is invisible. For a short-lived process, a serverless function, or a test suite that spawns a fresh interpreter per case, it is a fixed tax on every run.
The version constraints in pyproject.toml tighten this further. FinancePy requires Python >=3.10 and <3.15, and pins numpy>=2.3.5,<2.4, scipy>=1.16.3,<1.17, pandas>=2.3.3,<=2.4, matplotlib>=3.10.6,<3.11 and numba>=0.67.0,<0.68.0. Those are narrow ranges. If your environment already holds a different NumPy or Numba, you will be resolving a conflict rather than installing a library. requirements.txt pins the same versions exactly, and its comment notes the pins track the latest Anaconda release.
The repository also carries a beta signal in two places: the README says the library "is currently in beta version", and pyproject.toml declares Development Status :: 4 - Beta. Treat the API as something that can move between minor releases, and check CHANGELOG.md before upgrading.
Where FinancePy is the wrong tool
The licence is the first boundary. pyproject.toml declares GPL-3.0-or-later, and the repository ships a LICENSE file. GPL-3.0 is a copyleft licence. If you embed FinancePy in a proprietary pricing service or distribute it inside a closed product, the licence terms become a question for your legal team, not a technical one. FinancePy is not offered under a permissive licence, and the README does not describe any commercial licensing option.
The second boundary is support. The README states the software is distributed "FREE AND WITHOUT ANY WARRANTY" and directs bug reports to the GitHub issue tracker. There is no vendor, no support contract and no documented deprecation policy. A trading desk that needs a named contact when a swaption price looks wrong should look elsewhere.
The third boundary is scope by asset class. The products folders cover Bonds, Credit, Equity, FX and Rates. If your work sits outside those five groups, the library has nothing for you, and the product-first design that helps a rates quant gives you no starting point at all.
Finally, the README's own contribution rules tell you something about the codebase's priorities: contributors are asked to avoid "very pythonic constructions", with a loop preferred over a list comprehension because Numba can be faster. If you expect idiomatic modern Python throughout, you will find the style deliberately plainer than that.
FinancePy compared with QuantLib and GS Quant
QuantLib is the obvious reference point and appears in the search terms people use around this project. QuantLib is a C++ library with Python bindings, built around a set of abstractions (term structures, instruments, pricing engines) that a user assembles at runtime. Its performance comes from C++. FinancePy makes the opposite bet: everything stays in Python so a reader can follow the code to the lowest level, and Numba supplies the speed. The README claims calculation speeds "similar to C/C++" for the compiled models. The practical difference is inspection. With FinancePy you can read the actual pricing function in Python. With QuantLib you are reading C++ or trusting the binding.
GS Quant is a different shape again: it is a bank-published quant toolkit, and the search terms people use alongside FinancePy suggest interest in that style of library. The distinction that matters here is governance and audience. FinancePy is a single-author project, hosted on GitHub, with a public issue tracker and an invitation in the README to contribute. GS Quant comes from an institution. If your organisation requires a named counterparty behind the code, the two are not substitutes.
For students and academics, the comparison is simpler. FinancePy's examples and notebooks are the teaching material, and the README points directly at them. A C++ library with bindings is a harder first read.
Maintenance, upgrades and the GPL-3.0 licence in practice
The last push to the repository was on 2026-09-22, and the most recent release listed is V1.1.2 on 2026-08-21, following V1.1.1 on the same day and v1.1.0 on 2026-08-07. The project is not archived. The version in pyproject.toml is 1.1.2, matching the latest release tag.
Upgrade cost is dominated by the dependency pins rather than by API churn. Because NumPy, SciPy, pandas, matplotlib and Numba are all pinned to narrow ranges, a FinancePy upgrade can force a wider environment change, and a wider environment change can force a FinancePy upgrade. Check CHANGELOG.md and the release notes for the version you are moving to before you touch the pins.
On licence: GPL-3.0-or-later means the obligations attach to distribution, not to private use. Running FinancePy inside your own analysis, or in a notebook you never ship, is a different situation from bundling it into software you distribute. The repository does not document an alternative licence, and this is a question for a lawyer rather than for the README. What the material does establish is that the licence is copyleft and that the README offers the software without warranty.
The contribution requirements are worth knowing even if you never contribute: PEP8 compliance, comments on every class and function, at least one broad test case plus unit tests per function, and a preference for plain loops over clever constructions. Those rules explain why the code reads the way it does.
Editorial conclusion
FinancePy fits students, academics and quants who want to read the pricing code down to the lowest level and are willing to accept a first-import compile delay and a beta label. It is a poor fit if you need a supported commercial SLA, a non-GPL licence, or a library whose API is stable across major versions. Before adopting, run the Date(19,2,2026).add_days(2) import check, confirm your Python version sits inside the >=3.10,<3.15 range in pyproject.toml, and read the examples/scripts directory for the product you actually price.
Frequently asked questions
How do I install FinancePy?
The README gives a single command: pip install financepy. To upgrade an existing installation, use pip install --upgrade financepy.
How do I check that FinancePy imported correctly?
After running from financepy.utils import *, the README suggests evaluating Date(19, 2, 2026).add_days(2), which should return 21-FEB-2026.
Why is the first import of FinancePy slow?
The README states that FinancePy relies on Numba to compile many of the models, so the first import of a model can take several seconds. The compiled code is cached on your machine and later imports are almost instant.
What licence does FinancePy use?
pyproject.toml declares GPL-3.0-or-later, and the repository includes a LICENSE file. The README does not describe any alternative or commercial licence.
Which Python versions does FinancePy support?
pyproject.toml sets requires-python to >=3.10,<3.15, with pinned ranges for numpy, scipy, pandas, matplotlib and numba.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/domokane-financepy)