08.10.2026 · Signal Titans Editorial

Knight Capital verlor 460 Millionen Dollar in 45 Minuten. Code, den die Firma seit 2003 nicht mehr nutzte, erwachte.

Das dicht gedrängte Handelsparkett der New York Stock Exchange in einer redaktionellen Komposition im Archivstil über die Trading-Panne von Knight Capital im Jahr 2012.

Am 1. August 2012 um 9.30 Uhr öffnete der US-Aktienmarkt, und eines seiner größten Handelshäuser begann, Aktien zu kaufen und zu verkaufen, die es nie hatte anrühren wollen. Rund 45 Minuten lang schickte der Order-Router von Knight Capital Millionen von Orders in den Markt. Als alles vorbei war, hatte Knight mehr als 460 Millionen Dollar verloren.

Kein Hacker war im Spiel. Kein Händler hatte auf eigene Faust gehandelt. Die Ursache war laut der US-Börsenaufsicht SEC ein Stück Software, das neun Jahre lang abgeschaltet gewesen war, ein Konfigurations-Flag, dem eine neue Bedeutung gegeben wurde, und einer von acht Servern, der nie ein Update erhielt.

Ein Unternehmen im Zentrum des Marktes

Knight war kein kleiner Akteur. Nach Darstellung der SEC machte sein Handel in den Jahren 2011 und 2012 in der Regel rund zehn Prozent des gesamten Handels mit börsennotierten US-Aktien aus. Eines seiner Kernsysteme war SMARS, ein algorithmischer Hochgeschwindigkeits-Router. SMARS nahm große „Eltern“-Orders aus anderen Teilen der Knight-Plattform entgegen und zerlegte sie in kleinere „Kind“-Orders, die es an Handelsplätze weiterleitete.

Im Sommer 2012 bereitete Knight SMARS auf ein neues Programm der New York Stock Exchange vor, das Retail Liquidity Program, das am 1. August starten sollte. Das bedeutete, neuen Code zu schreiben und ihn zu einem festen Termin in die Produktion zu bringen.

Alter Code, neue Bedeutung

Die neue Funktion sollte ein Stück Code ersetzen, das niemand mehr nutzte. Es gehörte zu einer alten Funktion namens Power Peg, die Knight seit 2003 nicht mehr verwendete. Der Code war nie entfernt worden. Er steckte noch immer in SMARS und ließ sich weiterhin aufrufen.

Der neue Code für das Retail Liquidity Program verwendete zudem ein Flag wieder, mit dem einst Power Peg eingeschaltet worden war. Knight wollte den alten Code löschen, sodass das Setzen des Flags auf „ja“ fortan stattdessen die neue Funktion aktivieren würde.

Darunter verbarg sich ein zweites, älteres Problem. Als Power Peg noch in Gebrauch war, verfolgte eine Funktion, wie viele Aktien jeder Eltern-Order bereits ausgeführt worden waren, und wies den Router an aufzuhören, sobald die Order erfüllt war. 2005 verlegte Knight diese Zählfunktion an eine andere Stelle im Code. Power Peg wurde danach nie wieder getestet. Sollte der schlafende Code je erwachen, wüsste er nicht mehr, wann er aufhören musste.

Sieben von acht Servern

Ab dem 27. Juli spielte Knight den neuen Code schrittweise auf die acht SMARS-Server auf. Auf einem davon kopierte der Techniker den neuen Code nicht. Niemand sonst überprüfte das Deployment, und Knight hatte keine schriftliche Vorgabe, die eine solche Prüfung verlangt hätte. Der achte Server behielt den alten Power-Peg-Code und bekam die neue Funktion nicht.

Am Morgen des 1. August trafen die Warnzeichen bereits ein. Ab etwa 8.01 Uhr verschickte ein internes System automatische E-Mails, die SMARS und einen Fehler mit der Beschreibung „Power Peg disabled“ erwähnten. Bis zur Markteröffnung um 9.30 Uhr waren 97 dieser Nachrichten an eine Gruppe von Knight-Mitarbeitern gegangen. Sie waren nicht als Alarme gedacht, und niemand reagierte darauf.

Fünfundvierzig Minuten

Als der Markt öffnete, trafen Orders mit dem umfunktionierten Flag ein. Die sieben aktualisierten Server verarbeiteten sie korrekt. Auf dem achten Server lief Power Peg. Weil die Logik zum Zählen der Aktien Jahre zuvor verlegt worden war, feuerte er für jede Eltern-Order immer weiter Kind-Orders ab, ohne zu berücksichtigen, wie viele Aktien bereits gekauft oder verkauft worden waren.

Die Zahlen der SEC sind drastisch. Für gerade einmal 212 eingehende Eltern-Orders schickte SMARS Millionen von Kind-Orders hinaus, was zu mehr als vier Millionen Ausführungen in 154 Aktien mit insgesamt mehr als 397 Millionen Stück führte. Am Ende hielt Knight eine Netto-Long-Position von etwa 3,5 Milliarden Dollar in 80 Aktien und eine Netto-Short-Position von etwa 3,15 Milliarden Dollar in 74 weiteren. In Dutzenden von Aktien machten Knights Geschäfte einen großen Teil des Volumens aus und bewegten die Kurse um mehr als fünf Prozent.

Die Reaktion machte alles noch schlimmer. Knights Überwachungstool meldete Positionen erst, nachdem die Geschäfte bereits stattgefunden hatten, und setzte auf Menschen, die Bildschirme beobachteten, statt automatisch Alarm zu schlagen. Für einen solchen Fall hatte Knight keine Verfahren zur Reaktion auf Störfälle. Während die Ingenieure im laufenden Handel nach der Ursache suchten, deinstallierten sie den neuen Code von den sieben Servern, auf denen er korrekt eingespielt worden war. Daraufhin begannen auch diese Server, Orders über die alte Power-Peg-Logik zu leiten.

Die Rechnung

Knights Verlust aus den ungewollten Positionen belief sich auf etwa 460 Millionen Dollar. Innerhalb weniger Tage brauchte das Unternehmen eine Rettung: Eine Investorengruppe schoss 400 Millionen Dollar ein und erhielt dafür eine deutliche Mehrheitsbeteiligung. Später im selben Jahr willigte Knight in die Übernahme durch das Handelshaus Getco ein, und 2013 schlossen sich beide zu KCG Holdings zusammen. Im Oktober 2013 stellte die SEC fest, dass Knight gegen die Market Access Rule verstoßen hatte, die Broker verpflichtet, Kontrollen einzurichten, die fehlerhafte Orders vom Markt fernhalten. Knight zahlte eine Strafe von 12 Millionen Dollar.

Was Ingenieure bis heute daraus mitnehmen

Es wäre leicht, dem Techniker die Schuld zu geben, der einen Server übersehen hatte. Die Feststellungen der SEC weisen in eine nützlichere Richtung. Jedes Glied der Kette war eine fehlende Sicherung, keine einzelne falsche Entscheidung:

Toter Code, der neun Jahre lang aufrufbar blieb.
Ein Flag, das mit neuer Bedeutung wiederverwendet wurde, während das alte Verhalten noch existierte.
Ein Deployment ohne zweite Prüfung und ohne automatischen Abgleich, ob alle Server übereinstimmten.
Warnungen, die in einem Postfach landeten statt bei jemandem, der dafür zuständig war, das System zu stoppen.
Kein vorab festgelegter Plan, um den Handel anzuhalten, wenn sich das System fehlerhaft verhielt.

Nichts davon ist exotisch. Die meisten Produktionssysteme enthalten heute mindestens einen dieser Punkte. Knights Debakel zeigt, wie schnell sie sich gegenseitig verstärken, wenn sie im selben Moment zusammentreffen, im Tempo des Marktes.

Die bleibende Lehre ist leicht formuliert und schwer umzusetzen: Code, den man nicht mehr nutzt, ist nicht harmlos, nur weil man ihn nicht mehr aufruft. Löschen Sie ihn, oder gehen Sie davon aus, dass ihn eines Tages etwas aufrufen wird.