Inside 'Bank Python': the secret in-house Python forks running investment banks

At many of the largest investment banks, Python doesn’t look like the Python everyone else uses. Cal Paterson describes a class of internal systems he calls ‘Bank Python’ — effectively proprietary forks of the entire Python ecosystem that thousands of engineers work inside, yet which barely register on the public web. Using a composite system he names ‘Minerva,’ he sketches how these platforms actually function.

The foundation is a global key-value store called Barbara, built crudely from pickle and zip, that holds Python objects in a hierarchical keyspace. Most day-to-day data — trades, instruments, market data, even applications’ own internal state — is read from and written to Barbara rather than a filesystem, which Minerva scripts don’t get. It uses namespaces called ‘rings’ (with a default global ring), supports overlay stacks that fall through ring by ring on lookup, replicates writes Dynamo/BigTable-style, and is robust precisely because it’s so simple, with a roughly 16MB soft limit per compressed object.

Layered on top is Dagger, which models financial instruments as a directed acyclic graph. Instruments, positions, and nested ‘books’ all expose a value() method, and when an underlying instrument changes — say a bond gets downgraded — Dagger automatically reprices every dependent derivative, in principle all the way up to a single book valuing the whole bank. The mental model is essentially Excel’s dependency graph reimplemented in Python, but with real code, tests, and version control instead of sprawling spreadsheet files. The piece is notable as a rare public window into how this insular, influential corner of enterprise software really works.