Financial institutions can rely on open-source pricing and risk models for the right jobs, such as independent price checks, model validation benchmarks, training and building new tools, if they hold that code to the same standard as any other model. Before relying on one, ask four questions: can we read it, does it match the market, does it run in time, and who stands behind it. Open source does not remove model risk. It makes the model inspectable.

Read → Match → Run → Stand Behind

Why this question matters now

For most of my career in financial markets, sophisticated pricing and risk models were built inside banks, bought from specialist vendors or embedded in large proprietary systems. Seeing exactly how a number was calculated could be difficult, sometimes impossible.

That is changing. Institutional-quality open-source libraries now exist, and AI coding tools make them usable by people who are not professional software developers. An analyst, risk manager or portfolio manager can increasingly ask an AI assistant to explain an unfamiliar codebase or build an analysis on top of it. The question for a financial institution is no longer whether this code exists. It is when it is safe to rely on it.

Financial institutions already operate within extensive expectations for how models are developed, validated, documented and monitored. Those expectations do not depend on who wrote the code. An open-source model has to earn its place the same way an internal or vendor model does.

The four tests

1. Can we read it?

The main advantage of open source is that the calculation is visible. Dominic O'Kane, former head of quantitative research in Europe at Lehman Brothers and creator of the open-source library FinancePy, built it specifically so a user could look down through "at most two, if not three layers and see exactly where the calculations are being performed" (13:44).

Compare that with the black box. As Dominic put it, a buy-side analyst checking an option price against Bloomberg cannot see how Bloomberg got there. With readable code, "you could see if you can reproduce Bloomberg and then you can play around with it" (32:25).

Readable does not mean read. Someone at the institution still has to understand the code that matters for the decision being made.

2. Does it match the market?

Textbook models and trading-floor models are not the same thing. Real prices depend on settlement periods, holiday calendars and weekend adjustments that textbooks rarely mention. Dominic's example is a simple FX forward: get those details wrong and "you can lose several thousand dollars on a trade the minute you do the trade" (13:44).

The test is whether the library handles the conventions of the markets you actually trade. A model that prices the textbook version of a product correctly can still misprice the real one.

Markets also do things models assume they cannot. Dominic opened our conversation with the night in 1994 when his firm's risk system crashed because a scenario pushed interest rates below zero, "something that our models said could never happen" (00:00). Since then we have seen negative policy rates, a negative oil futures price in 2020, and nickel on the London Metal Exchange nearly quadrupling within days in 2022. A model needs room for the world to behave differently than expected (30:52). It also needs checks that catch obvious input mistakes, such as a 5% coupon typed as 5 instead of 0.05 (31:48). Good libraries manage both.

3. Does it run in time?

A model that is right but slow can still be useless. Dominic compared it to a weather forecast: if it takes a week to forecast tomorrow, it does not help. On a trading floor, the risk numbers have to be ready for the trader the next morning (26:05). Much of a quant's real work is finding approximations that keep a model accurate enough while making it fast enough.

Speed used to be a strong argument against readable languages like Python. That has changed. FinancePy uses a tool called Numba that compiles Python into machine code, which Dominic describes as giving "speeds roughly equivalent to C++" (13:44). Readability and speed are no longer a forced choice, but performance should still be tested on the institution's own portfolio and deadlines.

4. Who stands behind it?

This is the test institutions most often skip. Open-source code may be maintained by one person, a small group or a large community. Each has different implications for how bugs are found and fixed, how quickly the code keeps up with markets, and who the institution can talk to when something breaks.

Coverage matters too. Even a broad library has gaps. When I asked Dominic about jump-to-default risk on credit default swaps, he said FinancePy calculates interest rate, spread and recovery rate risk, but not the loss on default itself, and that he probably should add it (21:34). That kind of candor is a strength of open source. It is also a reminder to check that the library actually covers the risks you need it to.

Finally, the institution stands behind its own use of the model. When parameters are uncertain, the answer is not to trust the code more. Dominic described how banks priced default correlation conservatively and held back reserves against the range of possible values (22:02). The same discipline applies whatever the source of the model.

Where open-source models fit today

Applying those tests, open-source pricing libraries are well suited to four jobs.

Using an open-source library as the production pricing engine for a trading book is a bigger step. It is possible, but it requires the same validation, controls and support arrangements as any production system.

Questions to ask before relying on an open-source model

  1. Has someone on our side read the code that drives the numbers we will use?
  2. Does it handle the conventions, calendars and settlement rules of the markets we trade?
  3. How does it behave under extreme inputs, and does it catch obvious input errors?
  4. Does it run fast enough for our portfolio and our deadlines?
  5. Which risks does it calculate, and which does it leave out?
  6. Who maintains it, how active is that work, and how are fixes reviewed?
  7. Have we validated it against our own models, vendor prices or market quotes?
  8. If the code changes, how will we know, and how will we re-test?

Where this is heading

The bigger shift is not only that good financial code is available for free. It is that the people who understand the finance can now work with that code directly. With AI coding tools, the question becomes less "Can I program this?" and more "Do I understand the financial problem well enough to tell the software what I want?"

That favors institutions with deep domain expertise. The firms that combine experienced people, transparent models and disciplined validation will be able to test ideas faster and build tools that once required a dedicated technology team.

About the author

Michael McLaughlin has more than 30 years in structured finance and private credit. At Macquarie Group from 2008 to 2023, he built the credit markets business from inception into a portfolio financing platform that averaged a $5 billion portfolio and generated more than $1 billion in cumulative net revenue. He has advised Hebbia on AI research software for financial services, and builds his own finance applications with AI coding tools and open-source software.

Through Path66, Michael works with financial institutions and investment firms on asset finance, liquidity, capital raising, data-driven due diligence and the practical application of emerging technology in finance. He hosts Stack to Street, where he interviews the developers building the software that will change financial institutions. Full bio.

Source

From Physics to Wall Street, Stack to Street with Dominic O'Kane, creator of FinancePy. Full transcript on the episode page.