Optiver arbeitet in einer Umgebung, in der Softwareleistung direkt in finanzielle Ergebnisse eingehen kann und Fehler erhebliche Schäden auslösen können. Ein Einblick des Pragmatic Engineer beschreibt eigene Hardware, spezialisierte Netzwerke, große Plattformteams und zunehmende Investitionen in Informationsmodelle. Für andere Unternehmen ist das kein Bauplan für Hochfrequenzhandel. Interessant sind die Prinzipien dahinter: Engpässe messen, gemeinsame Plattformen stärken und Innovation mit klaren Risikogrenzen verbinden.
Die Quelle basiert auf Gesprächen mit Optiver-Verantwortlichen und ist kein unabhängiger Audit. Aussagen über Organisation, Prioritäten und Wettbewerbsvorteile sind daher als berichtete Unternehmensperspektive einzuordnen. Nachvollziehbar ist die allgemeine Lehre, dass technische Optimierung nur dort Wert schafft, wo sie eine geschäftliche Entscheidung verbessert. Wer Spezialhardware oder KI kopiert, ohne den eigenen Engpass zu kennen, produziert vor allem Kosten.
Was der Optiver-Einblick beschreibt
Der Bericht schildert extrem geringe Latenz als technische Grundlage des Handels. Optiver kombiniere dafür eigene Hardware, spezialisierte Netzwerkinfrastruktur und umfangreiches Plattformengineering. Gleichzeitig würden bessere Informationsmodelle zunehmend zum Differenzierungsfaktor. Die Quelle behauptet, dass die Firma inzwischen stärker in bessere Modelle als in weitere Latenzsenkung investiere. Diese Prioritätsaussage stammt aus dem Bericht und lässt sich nicht ohne Weiteres auf andere Unternehmen übertragen.
Ebenfalls beschrieben wird eine Engineering-Kultur mit hohem Veränderungsdruck und großer Vorsicht. Der Grund ist die mögliche unmittelbare finanzielle Wirkung einzelner Softwarefehler. Proprietäre Handelsfirmen hätten außerdem starke wirtschaftliche Anreize für ML- und KI-Infrastruktur und langjährige Erfahrung mit eigener Hochleistungsarchitektur. Das erklärt den Kontext, sagt aber nicht, dass Eigenbau für normale Unternehmenssoftware wirtschaftlich sinnvoll ist.
Latency: enemy number one
The Pragmatic Engineer über Optiver
Erste Lehre: den echten Engpass bestimmen
Bei Optiver ist Latenz in vielen Teilen des Stacks geschäftskritisch. In einem DACH-Mittelständler kann der Engpass anders aussehen: schlechte Stammdaten, langsame Freigaben, instabile Schnittstellen oder fehlende Beobachtbarkeit. Optimierung sollte deshalb mit einer Wertstrommessung beginnen. Relevant sind Zeit bis zur Entscheidung, Fehlerkosten, manuelle Übergaben und Ausfallwirkung. Erst danach lässt sich beurteilen, ob schnellere Infrastruktur, bessere Modelle oder ein einfacherer Prozess den größten Beitrag leisten.
- Latenz optimieren, wenn Millisekunden messbar Umsatz, Risiko oder Kundenerlebnis beeinflussen.
- Informationsmodelle verbessern, wenn Entscheidungen an unvollständigen oder verspäteten Signalen scheitern.
- Plattformen ausbauen, wenn viele Teams dieselben Betriebs- und Datenprobleme mehrfach lösen.
- Spezialhardware nur prüfen, wenn Standardinfrastruktur den belegten Engpass nicht wirtschaftlich löst.
- Prozess vereinfachen, wenn organisatorische Wartezeit größer ist als jede technische Verzögerung.
Diese Reihenfolge schützt vor Prestigeprojekten. Eine niedrigere Modelllatenz hilft wenig, wenn Daten erst täglich aktualisiert werden. Ein genaueres Modell bringt keinen Nutzen, wenn niemand eine Entscheidung daraus ableiten darf. Und ein Plattformteam schafft nur dann Hebel, wenn es wiederkehrende Anforderungen mit klaren internen Produkten löst. Geschäfts- und Technikmetriken müssen deshalb in einem gemeinsamen Zielbild verbunden sein.
Zweite Lehre: Plattformen als Risikokontrolle
Große Plattformteams sind nicht nur eine Komfortfunktion. Gemeinsame Deployment-Pfade, Telemetrie, Testumgebungen, Datenzugänge und Sicherheitskontrollen können Innovation beschleunigen und zugleich Risiken begrenzen. In Hochrisikoumgebungen sollten Produktteams nicht jede Schutzmaßnahme selbst erfinden. Eine Plattform kann freigegebene Komponenten, standardisierte Rollbacks und unveränderbare Auditdaten bereitstellen. Die Verantwortung für das fachliche Ergebnis bleibt dennoch beim jeweiligen Owner.
Für KI-Systeme gehören Modellregistrierung, Datenherkunft, Offline-Evaluation, kontrollierte Auslieferung und Produktionsmonitoring in diesen Plattformrahmen. Ein Modell darf nicht nur anhand einer Durchschnittsmetrik freigegeben werden. Es braucht Grenzwerte für relevante Fehlerklassen, einen Vergleich zur Baseline und eine klare Reaktion bei Drift. Je direkter die finanzielle oder operative Wirkung, desto stärker müssen Freigabe und Rücknahme automatisiert vorbereitet sein.
Dritte Lehre: Veränderung reversibel machen
- Geschäftliche Verlustgrenze und technische Abbruchkriterien vor der Änderung definieren.
- Neue Modelle oder Infrastruktur zunächst im Schattenbetrieb gegen die Baseline messen.
- Kleine Nutzer-, Daten- oder Traffic-Segmente gestuft freigeben.
- Automatische Limits, Kill-Switch und getesteten Rollback außerhalb des neuen Systems vorhalten.
- Ergebnis nach Qualität, Latenz, Kosten und unerwarteter Wirkung gemeinsam bewerten.
Reversibilität reduziert nicht jedes Risiko, macht aber Lernen kontrollierbarer. Ein Feature Flag hilft nur, wenn Abhängigkeiten und Datenänderungen ebenfalls rückgängig gemacht werden können. Bei Modellen muss außerdem verhindert werden, dass eine fehlerhafte Ausgabe sofort irreversible Aktionen auslöst. Dafür eignen sich Positions-, Budget- oder Transaktionslimits als Prinzip: Die konkrete Umsetzung hängt vom Prozess ab, die Grenze sollte aber unabhängig vom lernenden System durchgesetzt werden.
Was Unternehmen nicht kopieren sollten
Eigene Hardware und nanosekundenoptimierte Netzwerke sind nur bei extrem klarer wirtschaftlicher Rechtfertigung sinnvoll. Für viele Unternehmen sind verwaltete Cloud-Dienste, Standardhardware und gute Datenpipelines überlegen. Auch die Aussage, bessere Modelle würden zum Hauptvorteil, ist kontextabhängig. In regulierten oder kundennahen Prozessen können Erklärbarkeit, Stabilität und Integrationsqualität wichtiger sein als ein kleiner Modellgewinn. Der passende Zielwert ergibt sich aus dem Geschäftsrisiko.
Fazit
Der Optiver-Einblick zeigt eine Organisation, die geringe Latenz, eigene Infrastruktur, Informationsmodelle und strikte Risikokontrolle verbindet. Übertragbar ist nicht der konkrete Trading-Stack, sondern die Entscheidungslogik: echten Engpass messen, gemeinsame Plattformen aufbauen, Modelle gegen Geschäftswirkung bewerten und Änderungen reversibel begrenzen. Unternehmen sollten Spezialtechnik erst dann einsetzen, wenn Standardlösungen den belegten Engpass nicht mehr wirtschaftlich lösen.