Es sollte kaum überraschen, dass Python, beliebteste Programmiersprache für Datenanalysezwecke, im Bereich des Investment-Bankings die erste Wahl ist. Doch in der Finanzwelt, in ihrem abstrakten Dschungel aus Märkten, Daten und Algorithmen, hat sich eine Python-Variante herausgebildet, deren Funktionsweise wenigen bekannt sein dürfte.

Tatsächlich unterscheidet sie sich hier so stark von ihrem Standardgebrauch im IT-Bereich, dass Eingeweihte ihr eine eigene Bezeichnung verliehen haben: Bank Python.

Die bankspezifischen Abspaltungen der Softwaresprache Python haben quantitative Analyst:innen – im Finanzjargon auch Quants genannt – über einen Zeitraum von mehreren Jahren entwickelt. Die Anfänge hierfür sind vermutlich im Jahr 2002 zu finden, als Python, damals kaum anerkannte Technologie, erstmals großflächig auf Rechnern innerhalb der Wertpapierabteilung von Goldman Sachs installiert wurde.

Dies gab unlängst Sean Hunter, ehemaliger Vizepräsident des Strategie-Teams bei Goldman Sachs, bekannt, der damals laut eigener Angaben für die großangelegte Software-Distribution zuständig war.

„Alles, was wir taten, war streng geheim, Außenstehende sollten nichts davon erfahren“, erzählt Hunter über seine Zeit bei Goldman Sachs. Zuvor habe man dort Perl verwendet. „Perl ist zwar sehr leistungsfähig, aber auch sehr kompliziert und schwer zu verstehen.“

Python verlange zwar einen ähnlichen Grad an konzeptueller Raffinesse, „doch es ist viel einfacher, dies in Code umzusetzen“, so der IT-Stratege. Der Wechsel zu Python habe es etwa ermöglicht, mittels eines einzigen Codebefehls asynchrone Updates auf 20.000 Computern zu installieren.

Auch Cal Paterson, ehemaliger Python-Entwickler bei Bank of America, Citibank und JPMorgan, weiß von Bank Pythons exotischem Eigenleben abseits von Open-Source-Standards zu berichten. In einem Blogbeitrag beschreibt er, wie Python in der Welt der Investmentbanken mittlerweile in einem merkwürdigen Paralleluniversum existiert.

Bank Python sei dabei ursprünglich aus der Notwendigkeit heraus entstanden, Finanzmodelle auf der Grundlage von MS Excel zu erstellen. Genauso, wie sich Änderungen in den Tabelleneinträgen bei Excel auf alle weiteren Funktionen und Berechnungen mit diesen Werten auswirken, würden Änderungen von Vermögens-, Unternehmens- oder Bonitätsbewertungen in einer langen kausalen Kette alle weiteren Transaktionen beeinflussen, an denen diese beteiligt sind.

Um keine sensiblen Details preiszugeben, fasst Paterson seine Beobachtungen fragmentarisch in einem imaginären Bank-Python-System – „Minerva“ genannt – zusammen. Minerva ist auf einer einzigen großen Objektdatenbank aufgebaut, die die überwiegende Mehrheit aller täglich benötigten Daten zu Wertpapieren, Finanzinstrumenten und Devisenhandel enthält.

Dem Londoner Softwareentwickler zufolge verwendet Bank Python diese „brutal einfache“ Wertedatenbank zur Fehlervermeidung. Allen gängigen Programmierpraktiken zuwider enthält sie sogar Minervas gesamten Quellcode, der üblicherweise in einem separaten Dateisystem gespeichert wird. Das habe den Vorteil, dass sich Minerva leicht von überall starten lässt.

Zusätzlich ist Minerva auf firmeneigene Bibliotheken für Tabellenoperationen gestützt, die bereits vor den heute gebräuchlichen Python-Pendants entwickelt wurden, und läuft ausschließlich auf einer bankinternen integrierten Entwicklungsumgebung (IDE). Paterson zufolge bestätige dies die unliebsame Ansicht, dass Investmentbanken unter dem berüchtigten Not-invented-here-Syndrom (NIH) litten – also Entwicklungen, die außerhalb ihrer Institutionen entstanden sind, misstrauten.

So soll auch GitHub kaum von Investmentbanken genutzt werden. Der Eigengeschmack von Bank Python ziehe sich zudem durch die meisten Bankinstitutionen, weil IT-Angestellte die grundlegende Ideologie ihrer Tätigkeit von Investmentbank zu Investmentbank mitnähmen.

Paterson kommt zu dem Schluss, dass Bank Python entgegen üblicher Konventionen eher daten- als codeorientiert ist. Denn für gewöhnlich schreibt man Code, der die Realität abzubilden sucht, um diesen sodann mit Daten zu füttern.

Bei Minerva sei es umgekehrt: Die Daten würden zunächst „in Tabellen angeordnet, und der Code lebt getrennt davon“, so der Softwareentwickler. Als weiteres Minerva-Beispiel führt er unter anderem ein eigentümliches „Bürgsystem“ an, in dem grundlegende Änderungen am Code lediglich durch dessen jeweilige:n Urheber:in freigegeben werden müssten.

Somit könne es jedoch passieren, dass dringende Änderungen blindlings abgesegnet würden – allein basierend auf dem Ruf derjenigen Person, die die Änderung veranlasse, so Paterson.

Bankinterne Softwareinfrastrukturen werden häufig zu Recht als Altsysteme (auch: Legacy-Systeme) bezeichnet. Man denke nur an die unzähligen Vorgänge, Schnittstellen und Funktionalitäten, die eine einzige Finanztransaktion auf ihrem Weg von A nach B durchlaufen muss.

Um eventuelle Störungen von angekoppelten IT-Systemen oder internen Prozessen zu vermeiden, sind Banken daher meist gut darin beraten, vor allzu großen Änderungen ihrer hochkomplexen Unternehmenssoftware abzusehen.

Dies habe bei ihm persönlich etwa zu existenzieller Langeweile durch den langanhaltenden Gebrauch von Windows 7 und MS Outlook 10 geführt, moniert Paterson. Im Falle von Python kann das Festhalten an überholten Standards bedeuten, dass Code mitunter noch in der veralteten Version Python 2 geschrieben ist, die sich deutlich von der 2008 erschienenen Version Python 3 unterscheidet und nicht mit dieser kompatibel ist.

Entgegen der gängigen Vermutung, Banken hinkten der Gegenwart hinterher, bergen die streng geheimen Codes laut Sean Hunter andererseits jedoch ein besonderes Innovationspotenzial. Denn oftmals müssten Banken automatisierte Lösungen für sehr spezifische Fälle entwickeln – etwa in Form von MVP, sogenannter Minimal Viable Products, deren Implementierung sich erst in Folge auf die globale Praxis auswirkt.

So sieht der gelernte Jazzmusiker etwa auch die Anfänge des Cloud-Computing bei Goldman Sachs begründet. Und noch ein Fakt dürfte ausschlaggebend für Bank Python als Innovationstreiber sein: Banken verfügen über einen enormen globalen Datenschatz, was wiederum mit großem Erkenntnispotenzial einhergeht.

Doch sowohl die Legacy-Systeme der Banken einerseits als auch ihre eigentümlichen Codepraktiken andererseits dürften es dem IT-Personal umso schwieriger machen, nach einer langjährigen Beschäftigung in den hohen Sphären der Großbanken wieder in einem anderen IT-Bereich Fuß zu fassen – selbst dann, wenn dies nur den Sprung zu Fintech bedeutet.

Umgekehrt stehen die Chancen, mit Python-Kenntnissen den Karriereweg ins Bankwesen zu finden, etwas besser. Doch auch hier könnte es Paterson zufolge mehrere Monate Einarbeitungszeit erfordern, sich mit den Eigenheiten von Bank Python vertraut zu machen.

Dass Python besonders Big-Data-freundlich ist, liegt vor allem an seiner großen Auswahl an datenanalysebasierten Softwarebibliotheken. Für die grundlegende Arbeit mit großen Datenmengen eignen sich etwa die Bibliotheken pandas und NumPy – letztere wurde sogar 2008 bei der Hedgefonds-Firma AQR Capital Management entwickelt.

Nützlich für den Finanzbereich sind auch Matplotlib für Datenvisualisierungen und SciPy für fortgeschrittene statistische und mathematische Funktionen. Darauf aufbauend lassen sich Bibliotheken wie Scikit und Pybrain verwenden, die mit effizienten Machine-Learning-Algorithmen für Trendprognosen ausgestattet sind.

Pythons einzige Achillessehne ist das sogenannte Global Interpreter Lock (GIL): Der Python-Interpreter, der den Code liest und ausführt, kann jeweils nur einen Codestrang nach dem anderen bearbeiten. In der Praxis sorgt dies jedoch selten für Wartezeiten, wenn man zuvor Codeblöcke parallelisiert und auf einem Computercluster laufen lässt.

Für intensive Rechenprozesse mit großen Datenmengen lässt sich Python zudem gut in Verbindung mit Frameworks wie Spark und Hadoop verwenden und verfügt über Programmierschnittstellen für NoSQL-Datenbanken wie MongoDB.

Zur Verkürzung der Rechenzeit ist es außerdem möglich, Funktionen in C oder C++ zu schreiben und anschließend in Python-Module einzubetten. Die Rechenmodelle werden dabei üblicherweise zunächst als Prototyp formuliert, anschließend kalibriert und in Python getestet, um erst dann für den Endgebrauch bereitgestellt zu werden.

Laut einer Umfrage von KD Nuggets war die Programmiersprache R noch bis 2016 die Nummer 1 in Sachen Data-Science, was in ihrem weitverbreiteten Einsatz an Universitäten begründet war. Python folgte dicht auf Platz 2, holte jedoch bereits im Folgejahr auf, als die beiden Sprachen etwa gleichauf bei knapp unter sechzig Prozent lagen.

In den Jahren 2018 und 2019 wuchs Pythons Anteil sodann auf zwei Drittel an, während nur noch knapp die Hälfte der Befragten R bevorzugten. Der Trend setzte sich fort: Auf E-Financial-Careers, der führenden Stellenbörse für Finanzdienstleistungen, fanden sich Mitte 2022 2.231 offene Stellen für Python und nur 456 Stellen für R.

Obwohl R ursprünglich die besseren Pakete für statistische Analysen und Visualisierungen bot, konnte sich Python vermutlich vor allem aufgrund seiner Benutzungsfreundlichkeit und einer besseren Handhabung der objektorientierten Programmierung (OOP) durchsetzen. Auch die dynamische Typisierung bei Python ist weniger fehleranfällig, und in puncto Geschwindigkeit soll Python sogar viermal schneller sein als R.

Data-Scientists, die die strengen Methoden der Mathematik zu schätzen wissen, werden für statistische Auswertungen und Datenvisualisierungen vermutlich immer noch die Vorzüge von R loben. Doch die Lücke schließt sich zunehmend.

Das breite Anwendungsspektrum von Python und dessen Spezialisierung auf die wachsenden Bereiche Big Data, künstliche Intelligenz und Deep-Learning-Algorithmen hat es zu einer bevorzugten Allroundsprache für Datenanalysezwecke gemacht – auch in der Finanzbranche.

Einer der Hauptgründe hierfür dürfte sein, dass die IT-Abteilungen von Banken, die einen Großteil des gesamten Bankpersonals ausmachen, in der Regel von Informatiker:innen ohne ausgeprägtes Wissen über Datenanalyse geführt werden.

Denn während R eher datenzentriert ist, benötigt man für das Programmieren mit Python keinerlei Statistikkenntnisse – ein Plus für die heutigen Programmierer:innen im Investmentbanking, die überwiegend codebasiert arbeiten und selten über einen professionellen Hintergrund in Statistik oder Finanzmathematik verfügen.

Gerade in der schnelllebigen und zugleich abstrakten Welt des Investmentbankings ist es von besonderem Vorteil, eine Programmiersprache zu verwenden, die sowohl in der akademischen Forschung als auch bei Endkund:innen verbreitet ist. Angesichts der Beliebtheit von Python im Finanzbereich ist daher auch in Zukunft mit einer wachsenden User-Community zu rechnen.

Das wiederum lässt eine aktive Weiterentwicklung von Tools für Bank Python und somit eine wachsende Diskrepanz zwischen Bank Python und Open-Source-Python erwarten.
Dieser Beitrag erschien erstmals im April 2022