The Architecture of Bank Python: An Oral History of Proprietary Financial Systems

The infrastructure of major investment banks often relies on massive, proprietary ecosystems that blend general-purpose languages like Python with custom-built object stores and execution environments. These systems are designed to solve high-scale financial problems that off-the-shelf software could not handle at the time of their creation, resulting in "alternate IT realities" where developers work with tools that cannot be Googled or supported by AI.

The Core Architecture: Python and Proprietary Object Stores

Investment banks frequently build internal platforms that integrate a programming language with a global object database. A primary example is the use of Python paired with a system like "Barbara," which serves as a global object store for the entire bank.

The Role of the Object Store

In these environments, the object store (such as Barbara) acts as more than just a database; it is the central repository for application state, data, and even the system's own source code.

• Source Code Storage: In some configurations, the source code for the system is stored within the object store itself (e.g., in a special "sourcecode" ring) rather than on a traditional disk.
• State Management: Applications often store internal state by writing dataclasses directly into the object store with minimal locking or transaction overhead.
• Global Access: These systems often feature a default "ring" or global area that allows broad access to data across the bank, though specific permissions systems are required to manage sensitive transactions.

Lineage and Influence

These Python-centric systems (such as "Alpha" at JPM or "Quartz" at Merrill) are often descendants of earlier proprietary languages. Many originated from the SecDB/Slang ecosystem at Goldman Sachs, where SecDB served as the object store and Slang was a C-like language that allowed unconventional features, such as spaces in variable names.

The Challenge of Legacy Migration in Finance

Migrating away from these proprietary systems is a historically difficult process due to the extreme risk-to-reward ratio associated with financial infrastructure.

Risk vs. Reward

Developers and architects face a significant imbalance when attempting to modernize legacy systems:

• Capped Upside: The primary benefit of a successful migration is often a promotion or professional recognition.
• High Downside: A failure during migration can lead to a huge outage that could "tank the business."

The "Big Bang" vs. Gradual Refactor

While gradual refactors are generally preferred, some financial systems are so deeply integrated that they require a "big bang" migration. This often leads to a situation where battle-tested, performant legacy systems are replaced by "shiny, new systems" that may introduce more bugs, often driven by the desire of engineers to have a more impressive resume.

Operational Realities of Proprietary Banking Tech

Working within these ecosystems creates a unique set of technical and operational constraints that are often invisible to the rest of the software industry.

Software Archaeology

Engineers often encounter components that seem redundant or inefficient by modern standards. However, these are typically the result of "software archaeology," where the code was written because a mature, off-the-shelf solution simply did not exist at the time of development.

Extreme Edge Cases

Financial systems must handle complexities that go beyond standard coding:

• Regulatory Constraints: For example, Korean trading may require servers to be physically located in Korea and traders to be licensed in Korea, even if they are operating from New York.
• Trade Breaks: Entire systems are dedicated to tracking "trade breaks" (disagreements between banks on a specific fill), some of which remain open for years due to litigation or corporate insolvency.
• Long-term Order Persistence: Some systems have historically maintained "Good Till Cancel" orders dating back decades (e.g., orders from 1997).

The "Alternate IT Reality"

Because these systems are proprietary, the skillsets developed by engineers are tied to a single company. This creates a workforce of specialists who cannot rely on external documentation, Stack Overflow, or AI assistants, as the tools they use do not exist in the public domain. This is further complicated by the lack of comprehensive documentation, making the internal knowledge transfer highly dependent on a few individuals.