Friss RAM oder stirb! Bei 50 ms Latenz könnten Sie auch gleich per Fax handeln …

137 adaptierbare Stellschrauben, alle Entscheidungen im Arbeitsspeicher (RAM), Failover in Millisekunden: FI Investments hat eine Trading-Software gebaut, die dem typischen Kernbank-Stack jede Ausrede nehmen will. Für IT-Leiter in Nicht-FinTechs lautet daher die Frage: Wollen wir weiter Batch-Orakel pflegen oder den eigenen Matchcode auf GPU-Takt bringen?

von Vito Micoli, Geschäftsführer von FI Investments

Mainframe-Kern, aufgesetzte ESB-Schichten, dutzende Policy-Gates – so sieht der Alltag vieler Handelsabteilungen aus. Zwischen Kurs-Tick und Order-Ausführung liegen dort leicht 50 ms Netz- und Middleware-Latenz. Als Faustformel hat sich FI jedoch gesetzt: Wer mehr Code im Storage als im RAM hat, verliert gegen jede Colocation-fähige FinTech-Box. Entsprechend eliminiert die Trading-Software diese Strecke, indem sie in-memory auf einem Multi-Socket-Cluster entscheidet; sodass Netzzeit der einzig unvermeidliche Faktor bleibt.

Architektur: Cloud-native ohne Kuschelkurs

In Sachen Architektur besteht das hoch spezialisierte, modular aufgebaute Handelssystem aus mehreren Schichten mit jeweils spezifischen Technologien und besonderen Merkmalen.”

Im Decision Core setzt die Software auf C++ und Java 21, wobei die Implementierung NUMA-optimiert ist, um die Leistung auf Mehrkernsystemen zu maximieren. Dabei kommen ein Shared-Memory-Bus und Lock-free Queues zum Einsatz, um eine effiziente und Thread-sichere Kommunikation zu gewährleisten. Kubernetes werden auf der Container-Ebene in einer Aktiv-aktiv-Konfiguration genutzt, die ein Failover von unter 100 Millisekunden ermöglicht und damit eine hohe Ausfallsicherheit gewährleistet. Die Konnektivität sichert eine eigens entwickelte TCP-Lösung, kombiniert mit einem FIX-Gateway, das durch ein Challenge-Handshake-Verfahren sowie eine Session-Replay-Guard besondere Security-Mechanismen implementiert. Python- und Java-basierte Batch-Prozesse sowie HDFS finden sich im Analytics-Bereich, um eine Tick-Historie von 20 Terabyte zu verwalten und eine Wochenend-Rekalibrierung der Modelle durchzuführen. Dabei läuft alles in redundanten Clustern über zwei Rechenzentren. Stateful Sets und Persist-Volumes replizieren synchron; selbst ein Datacenter-Drop erzeugt nur einen kurzen Spike in p99-Latenz – kein Trading-Abort.

Algorithmik: 137 Hebel statt AutoML-Blackbox

Die Software kombiniert klassische Zeitreihen-Statistik, Fuzzy-Regler und ein proprietäres neuronales Netz mit nicht-linearen Transferfunktionen. Dabei entstehen die 137 Parameter aus Modell-Topologie, Positionsgrenzen und Risiko-Coefficients. Sie werden nicht via genetische Algorithmen erraten, sondern wöchentlich in einem Offline-Grid aus 40 GPU-Nodes neu kalibriert.

Das Ergebnis: ein adaptiver, aber deterministischer Entscheidungsraum – prüf- und auditfähig.”

DevSecOps & Governance inside BaFin-Grenzen

Vom Git-Commit über GitLab CI bis hin zu SIT-, QA- und Produktionsumgebungen werden Deployments ausschließlich als Immutable Container-Images durchgeführt.

Die Software folgt einer durchgängigen CI/CD-Pipeline, was sicherstellt, dass jedes Release reproduzierbar, versionssicher und auditierbar bleibt.”

Zur vollständigen Nachvollziehbarkeit aller Handelsentscheidungen kommt ein „Flying Recorder“ zum Einsatz, der jeden eingehenden Kurs-Tick, jede Modellantwort und jede abgesetzte Order mit Nanosekunden-Präzision persistiert. So lassen sich auch regulatorisch relevante Trades ex-post exakt rekonstruieren und einer Allokation zuordnen.

Security by Isolation – kein TensorFlow, kein Supply-Chain-Risk

Die Plattform nutzt weder populäre ML-Frameworks noch externe Math-Libs.

Angriffsflächen wie Adversarial Samples oder Poisoned Dependency Trees entfallen.”

Netzwerkseitig schützt ein proprietäres Protokoll mit Challenge-Handshake; anomale Paket-Sequenzen erzeugen sofort einen Quarantäne-Swing zur Reserve-Node.

Integrations-Reality-Check

In der praktischen Umsetzung zeigt sich, dass Standardprotokolle allein nicht ausreichen. Zwar ist FIX als Schnittstelle für Orderrouten und Marktdaten ein regulatorisch, funktional gesetzter Standard, doch in Latenz-sensitiven Szenarien ist FIX allein zu träge. Statt Marktdaten über JMS-Topics oder Message Queues zu propagieren, sollten Micro-Batches direkt in Shared Memory gepusht werden. Nur so lassen sich die notwendigen Antwortzeiten im Mikrosekundenbereich realisieren.

Auch beim Thema Containerisierung ist ein differenzierter Blick notwendig.”

Container sind nicht per se stateless. Im Gegenteil: Für viele produktive Szenarien, insbesondere im regulierten Eigenhandel, sind Stateful Sets mit Persistent Volume Claims unumgänglich. Solange Write-ahead-Logs nachvollziehbar und – im Sinne regulatorischer Anforderungen – revocable bleiben, ist auch aus Sicht der BaFin eine persistente Container-Architektur konform und auditierbar.

Ein weiterer, oft unterschätzter Aspekt ist die operative Governance:

Wer Eingriffe in Echtzeit durch manuelle Overrides erlaubt, verspielt nicht nur Performance, sondern öffnet auch Angriffs- und Fehlerpotenzial.”

Der Control Handover muss im Code entschieden werden. Mikrosekunden-Vorteile lassen sich nur erzielen, wenn das Governance-Modell konsequent in der Ausführungslogik verankert ist und die Entscheidung dem fertig entwickelten Code überlassen bleibt.

RAM-native schlägt Regulation Fatigue

FI Investments demonstriert, dass ein regulierungskonformes Set-up keine Ausrede für Legacy-Lethargie ist. Mikrosekunden-Entscheidungen plus lückenloses Audit schließen sich nicht aus, solange IT-Abteilungen den Mut haben, In-Memory-Architekturen vor Gremium-Workflows zu stellen. Wer weiter Batch-Jobs zum Sonnenaufgang startet, tradet nicht, sondern wartet. Vito Micoli, FI Investments