In November, a London-based software engineer Cal paterson published a fascinating “Bank Python oral history“, describing it as” The strange world of Python, as used by the big investment banks … all Python ecosystem.
In an email interview with The New Stack, Paterson told me he had worked at more than one institution using his own version of Bank Python – and the “strong similarities” suggest IT people were carrying the banner of his basic ideology when they left an investment bank. to another.
“If you know that a certain important function existed in a previous bank in a certain file, it probably exists in the same file in your current bank,” he said.
His own work history includes writing Python in proprietary internal environments at JP Morgan (Athena) and Bank of America Merill Lynch (Quartz), as well as a four month gig as a Python developer at Citibank. (Although Paterson also adds that even within the investment banking industry, “some banks have it and some don’t.”)
To avoid revealing specific details to the employer, his blog post just featured a fictitious amalgamation of what he has seen throughout his career. But it still offers a great chance to explore an exotic fork of an entire programming language, which is almost completely unknown to the general public.
Highlighting the intrigue in his essay, Paterson writes that “foreign systems, like foreign countries, can be empowering when experienced firsthand.”
No file systems, just a large object database
First big surprise: Bank Python does not have access to a filesystem! But it doesn’t seem either need one, because most of what it would run on already exists in a massive object database, representing things like trade and market data. These objects represent everything from simple bonds to more complex derivative instruments.
“If bad news about a company comes out and a credit bureau lowers its credit rating, then someone in bonds will update the affected Bond object,” Paterson’s essay explained.
And it instantly propagates to all other calculations that include the value of that bond object – as easy as changing the value of a cell in an Excel spreadsheet, all formulas using that cell automatically update its own value. (This also allows the implementation of additional convenient features such as “time travel” through your data to see its values in the past or the future.)
An anthropologist might argue that this structure holds clues about the culture of investment banking. Interestingly, Paterson described this stack in his essay as “heavily influenced by the technological dependence of the financial industry, which is another way of putting it: there is a lot of MS Excel.”
Over the years, he acknowledged in his essay, many have had logical business reasons for an enterprise-wide move to Kubernetes, microservices, and a service mesh. But weaning reluctant users from their familiar Microsoft spreadsheet “takes that basic agency away from Excel users, who no longer understand the business process they run and now have to negotiate with ridiculous tech dweebs for every software change.” .
He continued, “Using simple Python functions, in a source-controlled system, is a better compromise than the modern equivalent of Java 2 Enterprise Edition.
“Financiers are able to learn Python, and while they might never be amazing, they can contribute at a much higher level and even make their own changes and deploy them. “
So, Bank Python programs first open a connection to this object database, and then they leave. But it’s even crazier than that, since even the main of your app source code is stored in this database, where it is executed by a single task processing “executor”.
In his essay, Paterson compared it to something like Jenkins or systemd – and notes that this setup has several advantages. “It can restart your software if it crashes and sends alerts if it continues to crash.” It stores the logs. It understands the dependencies between tasks (much like systemd does), so if the task that generates the data your task needs fails, your task doesn’t even try to start but triggers more alerts.
But more importantly, it allows you to run code in a large, security-conscious institution just by creating a very simple initialization file. “This is a big deal because negotiating anything at a big bank is a frustration exercise – delivery times for hardware can be measured in months,” Paterson wrote. “Getting people to agree with you, of course, takes a lot longer than that.”
Custom Python, “invented” in-house
Bank Python implementations also appear to use their own proprietary data structure for tables, providing faster access to medium-sized datasets (while also storing them more efficiently in memory).
“Some implementations are chunks of C ++ (not atypical for financial software) and others are thin veneers on sqlite3,” Paterson said. (His friend Salim Fadhley, a London-based developer, even released an (all Python) version of the table data structure called eztable.)
Paterson concludes that while most programs have a code-driven approach, Bank Python would be characterized as being data-driven. Although it is ostensibly object-oriented, “you group data into the tables and then the code lives separately.
Needless to say, Bank Python inevitably ends up having its own internal Integrated Development Environment (IDE) to handle all of its unique configuration quirks, and it even has its own unique version control system for the code. Paterson acknowledged the uncharitable assessment that this is just a great exercise in mistrust of anything outside the company (known in programming as cowardly Syndrome of “not invented here”).
The biggest drawback is with the developers who work there, because every year you shift into your employer’s bespoke monoculture, “the skills you need to interact with normal software atrophy.” Just an example: “When everything is in the same repository and all the code is just an import, the software package just doesn’t appear. “
Of course, after years of working in banks, Paterson also experienced a more personal problem: “existential boredom resulting from prolonged exposure to Windows 7 and MS Outlook 2010”.
Developers Share “Bank Python” Stories
Paterson’s blog post sparked developer interest on social media, garnering 546 upvotes in the Reddit programming forum, and another 864 positive votes on Hacker News. “Having worked in an investment bank before that caused flashbacks,” Hacker News admitted commentator.
“Honestly, that sounds like a lot less foolish that a lot of “conventional” batteries, another drive commented.
regarding the Bank Python article: I’ve worked on systems that were almost equally ‘locked down’ and had (seemingly) weird choices inside BUT also some amazing, creative, incredibly useful / usable ideas that I would do without hesitate – sometimes in horrible, sometimes in good code.
– Su-Shee (@[email protected]) (@sheeshee) November 14, 2021
But this is a glimpse into an alternate universe where entire software systems are ultimately prepared in-house. One Hacker News comment came from Sean hunter, former vice president of Goldman Sachs strategist (or “strats”) team, who posted that he had been the one who introduced Python there between 2002 and 2003.
And Hunter shared other memories with the eFinancialCareers to place, remembering that during his next nine years at Goldman Sachs, they even created a DevOps environment ahead of its time deploying code updates with a CI / CD pipeline – written in Perl.
“Back then it was 20 million lines of C ++ and 10 million lines of Java and we were extending it to all of our machines around the world,” Hunter said. He thinks that at the time, there was nothing like it elsewhere in the world.
And there was also an internal cloud-like computing grid where the computations were spread across different servers. (In a subsequent comment, Hunter recalled that 667 different developers had signed up in a single two-week cycle.) “Everything we did was top secret and no one outside would ever know.” , he told eFinancial Carers of his time at Goldman Sachs. “Banks build huge amounts of things for specific use cases that don’t exist yet, and then the world catches up.”
Respect for ‘Bank Python’ contributors
Paterson appreciated Hunter’s comments on Hacker News and said he had also heard people working outside the financial industry say they liked the idea of Bank Python. “I think there are a number of ‘k8s dissidents’ who don’t like the direction in which software creation is headed.”
He also suggested that today, the Beacon Company is essentially marketing “a white label version of Bank Python”.
But under his reaction seems to be a real appreciation for all the care and effort that has gone into building a complete Bank Python ecosystem.
Today, the core Python team has now grown and become more professionalized / fewer volunteers – but Paterson believes that in 2010 a large bank that created the Python ecosystem (including Interpreter ) ultimately could have put in more man-hours than Python’s original, smaller, all-volunteer core team.
In our interview, Paterson described the system as “brilliant” and told me he wished he could always use it.