Der Power-Peg-Fehler bei Knight Capital: Anatomie einer algorithmischen Katastrophe

von DerSchneider

Einleitung

Es gibt Momente in der Technikgeschichte, in denen sich in wenigen Minuten zeigt, wie verletzlich hochkomplexe Systeme sein können. Der 1. August 2012 war ein solcher Moment. An diesem Morgen verlor die US-amerikanische Broker-Dealer-Firma Knight Capital innerhalb von nur 45 Minuten rund 460 Millionen US-Dollar – mehr, als das Unternehmen in den vorangegangenen Jahren an Gewinn erwirtschaftet hatte. Ursache war ein Softwarefehler, der auf einen über Jahre vernachlässigten Codeabschnitt zurückging: die Funktion „Power Peg“.

Was diesen Fall so lehrreich macht, ist nicht allein die Höhe des Verlustes, sondern die Tatsache, dass er sich aus einer Kette vermeidbarer Fehler zusammensetzte – Fehler, die über einen Zeitraum von neun Jahren entstanden und sich schließlich an einem einzigen Tag zu einer Katastrophe verbanden. Der Fall wurde zum Musterbeispiel für regulatorische Verschärfungen, für die Risiken des algorithmischen Hochfrequenzhandels und für die Frage, wie Unternehmen mit „totem Code“ umgehen sollten.

Der Kontext: Knight Capital und der algorithmische Handel

Knight Capital Group war Ende der 2000er und Anfang der 2010er Jahre einer der größten Market Maker der Welt. Das Unternehmen wickelte täglich Millionen von Aktienaufträgen ab und war für viele Broker eine zentrale Infrastruktur – ein unsichtbarer, aber systemrelevanter Akteur im US-Aktienmarkt.

Das Herzstück dieser Operation war SMARS (Smart Market Access Routing System), ein automatisierter Order-Router. SMARS nahm „Elternaufträge“ von Brokern entgegen, zerlegte sie in kleinere „Kindaufträge“ und leitete diese an verschiedene Handelsplätze weiter – ein Verfahren, das als algorithmische Order-Aufteilung bekannt ist. Die Geschwindigkeit, mit der SMARS arbeitete, war entscheidend für die Wettbewerbsfähigkeit von Knight: Millisekunden konnten über Gewinn oder Verlust entscheiden.

Die Vorgeschichte: Power Peg und sein schleichender Verfall

Was war Power Peg?

Power Peg war eine Funktion innerhalb von SMARS, die in den 1990er Jahren entwickelt wurde. Ihre Aufgabe bestand darin, Kindaufträge zu generieren und dabei sicherzustellen, dass nicht mehr Aktien gehandelt wurden, als der ursprüngliche Elternauftrag vorsah. Eine kumulative Mengenfunktion zählte die bereits ausgeführten Aktien und stoppte den Algorithmus, sobald der Elternauftrag vollständig gefüllt war.

Im Jahr 2003 stellte Knight die Nutzung von Power Peg ein. Der Code wurde jedoch nicht entfernt – weder gelöscht noch deaktiviert. Er blieb als schlafende Funktionalität im Produktionssystem, ausgelöst durch ein spezifisches Flag, das in der Software gesetzt werden konnte.

Der folgenreiche Eingriff von 2005

Zwei Jahre nach der Stilllegung von Power Peg nahm Knight eine Änderung an der SMARS-Codebasis vor, die sich als fatal erweisen sollte. Die kumulative Mengenfunktion, die ursprünglich Teil des Power-Peg-Codes war, wurde an eine frühere Stelle in der Code-Sequenz verschoben. Diese Änderung war für andere, aktive Funktionen gedacht – doch sie hatte eine unbeabsichtigte Nebenwirkung: Der Power-Peg-Code wurde dadurch seiner Fähigkeit beraubt, zu erkennen, wann ein Auftrag vollständig ausgeführt war.

Knight testete den Power-Peg-Code nach dieser Änderung nicht erneut. Da die Funktion offiziell nicht mehr genutzt wurde, schien ein Regressionstest überflüssig. Die SEC stellte später fest, dass genau hier ein zentrales Versäumnis lag: Wenn Code im System verbleibt – selbst wenn er inaktiv ist –, muss er bei Änderungen an gemeinsamen Abhängigkeiten getestet werden.

Die Katastrophe von 2012: Eine Verkettung von Fehlern

Der Auslöser: Das NYSE Retail Liquidity Program

Im Jahr 2012 kündigte die New York Stock Exchange die Einführung eines neuen Programms an: das Retail Liquidity Program (RLP). Es sollte Einzelhandelskunden bessere Preise bei Aktiengeschäften ermöglichen. Für Knight Capital war die Teilnahme an diesem Programm geschäftskritisch – ein Ausschluss hätte Marktanteile gekostet.

Knight beschloss, den alten Power-Peg-Code zu entfernen und durch neuen RLP-Code zu ersetzen. Das Flag, das früher Power Peg aktivierte, sollte nun den RLP-Code aufrufen. Der Plan war, den alten Code zu löschen und den neuen zu integrieren – eine scheinbar saubere Lösung.

Der Deployment-Fehler

In der Woche vor dem 1. August 2012 spielte Knight den neuen RLP-Code schrittweise auf die acht SMARS-Server auf. Am entscheidenden Tag kopierte ein Techniker den neuen Code auf sieben der acht Server – einen Server ließ er aus. Es gab keine zweite Kontrolle, kein Vier-Augen-Prinzip, keine automatisierte Verifikation, dass alle Server identisch konfiguriert waren.

Das Ergebnis: Auf sieben Servern lief der neue RLP-Code. Auf dem achten Server lief noch immer der alte Power-Peg-Code – mit dem entscheidenden Defekt aus dem Jahr 2005.

Die 45 Minuten des Chaos

Am Morgen des 1. August 2012, kurz nach Handelsbeginn, erreichten 212 kleine Einzelhandelsaufträge das SMARS-System. Sieben Server verarbeiteten sie korrekt. Der achte Server jedoch – auf dem der repurposed Flag den Power-Peg-Code aktivierte – begann, Kindaufträge zu generieren, ohne jemals zu stoppen.

Was dann geschah, beschreibt die SEC später so: „Obwohl ein Teil von Knights Order-Handling-System erkannte, dass die Elternaufträge gefüllt waren, wurde diese Information nicht an SMARS kommuniziert.“ Der Server sendete weiter Orders – Millionen davon. Innerhalb von 45 Minuten gingen über 4 Millionen Orders in den Markt, die zu 154 Aktien und 397 Millionen gehandelten Aktien führten.

Knight akkumulierte 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 Aktien. Als das System schließlich gestoppt wurde, belief sich der Verlust auf über 460 Millionen Dollar.

Die verschlimmernde Reaktion

Was den Fall besonders tragisch macht, ist die Tatsache, dass der Schaden während der Fehlerbehebung noch vergrößert wurde. Als Knights Techniker versuchten, das Problem zu identifizieren und zu beheben, deinstallierten sie den neuen RLP-Code von den sieben korrekt funktionierenden Servern – in der Annahme, der neue Code sei die Ursache. Dadurch wurde auf diesen Servern der alte Power-Peg-Code aktiviert, der dort ebenfalls noch vorhanden war. Aus einem fehlerhaften Server wurden so acht fehlerhafte Server.

Die SEC stellte zudem fest, dass Knights internes System 97 automatisierte E-Mails generierte, die auf den Fehler hinwiesen – noch bevor die Märkte öffneten, ab etwa 8:00 Uhr morgens. Diese Nachrichten wurden jedoch nicht als Alarme erkannt oder beachtet, da sie nicht als Systemwarnungen konzipiert waren.

Die regulatorische Aufarbeitung

Die SEC-Untersuchung und das Marktzugangsgesetz

Die SEC leitete eine Untersuchung ein und erhob im Oktober 2013 Anklage gegen Knight Capital Americas LLC. Es war die erste Durchsetzungsmaßnahme unter der 2010 verabschiedeten Market Access Rule (Rule 15c3-5), die Broker-Dealer verpflichtet, angemessene Risikokontrollen für ihren Marktzugang einzurichten .

Die SEC stellte eine Reihe von Versäumnissen fest:

Knight Capital einigte sich auf einen Vergleich: 12 Millionen Dollar Strafe und die Verpflichtung, einen unabhängigen Berater für eine umfassende Überprüfung der Kontrollen und Verfahren zu engagieren .

Die wirtschaftlichen Konsequenzen

Die unmittelbaren Folgen des Vorfalls waren verheerend. Knight Capital benötigte eine Notfallfinanzierung von 400 Millionen Dollar durch ein Konsortium unter Führung von Jefferies Group, an dem sich unter anderem TD Ameritrade und die Blackstone Group beteiligten . Die NYSE entzog Knight vorübergehend die Market-Making-Verantwortung für über 600 Wertpapiere.

Die Aktionäre wurden massiv verwässert: Vor dem Vorfall notierte die Aktie über 10 Dollar, nach der Rettungsaktion wurden neue Aktien zu 1,50 Dollar ausgegeben. Im Jahr 2012 fiel der Umsatz von Knight von 1,4 Milliarden auf 736 Millionen Dollar. Das Unternehmen berichtete einen operativen Nettoverlust von 536,7 Millionen Dollar sowie einen den Aktionären zurechenbaren Nettoverlust von 722,7 Millionen Dollar . Der Handelsverlust durch den Vorfall selbst belief sich auf 456,7 Millionen Dollar . Im Juli 2013 wurde Knight von GETCO übernommen – das Unternehmen existierte nicht mehr als eigenständige Einheit.

Die technischen und organisatorischen Lehren

Toter Code ist gefährlicher Code

Der Power-Peg-Fall ist ein Musterbeispiel für die Gefahren von „dormant code“ – Code, der im Produktionssystem verbleibt, obwohl er nicht mehr genutzt wird. Die SEC formulierte es so: Knight habe es versäumt, den Code zu entfernen, und ihn stattdessen „im Router belassen“.

Die technische Gemeinschaft zog daraus die Lehre, dass Code, der nicht mehr benötigt wird, vollständig entfernt werden sollte – nicht nur deaktiviert. Die Begründung: Jeder verbleibende Code stellt eine potenzielle Angriffsfläche dar, insbesondere wenn er durch Flags oder andere Mechanismen aktiviert werden kann.

Die Wiederverwendung von Flags als Antipattern

Ein besonders tückisches Element des Falls war die Wiederverwendung des Power-Peg-Aktivierungsflags für den neuen RLP-Code. Diese Praxis – die Belegung eines Schalters mit neuer Semantik, während die alte Funktionalität im System verbleibt – wird heute als klarer Verstoß gegen gute Software-Engineering-Prinzipien angesehen. Sie schuf eine direkte Brücke zwischen dem neuen Feature und dem alten, fehlerhaften Code.

Deployment ohne Verifikation

Der Fehler, den achten Server nicht zu aktualisieren, wäre durch einfache Maßnahmen vermeidbar gewesen: ein zweiter Techniker, der die Installation überprüft, oder ein automatisiertes System, das die Konsistenz der Server-Konfigurationen prüft. Die SEC stellte fest, dass Knight „keine schriftlichen Verfahren hatte, die eine solche Überprüfung vorschrieben“.

Das Fehlen von Sicherheitsnetzen

Vielleicht der schwerwiegendste Aspekt war das Fehlen jeglicher Echtzeit-Sicherheitsnetze. Es gab keine Kontrolle, die die ausgehenden Orders mit den eingehenden verglich, keine automatische Abschaltung bei Überschreitung von Kapitalschwellen, keine Möglichkeit, den fehlerhaften Server zu isolieren. Daniel Hawke von der SEC brachte es auf den Punkt: „Broker und Händler müssen jede Komponente ihrer Systeme betrachten und sich fragen, was passieren würde, wenn die Komponente versagt, und welche Sicherheitsnetze vorhanden sind, um den Schaden zu begrenzen. Knight Capitals Versäumnis, diese Fragen zu stellen, hatte katastrophale Folgen.“

Das Fehlen einer operationellen Risikofunktion

Über das Fehlen schriftlicher Verfahren hinaus offenbarte der Fall ein strukturelles Organisationsversagen: Ein Zeuge im Rahmen der anschließenden Sammelklage sagte aus, dass bei Knight Capital keine Unternehmens- oder operationelle Risikofunktion existierte. Auf die Frage, wer für operationelles Risiko zuständig sei, antwortete der ehemalige Leiter des globalen Marktrisikos mit einem Wort: „Niemand.“

Einordnung und Ausblick

Der Fall im Kontext des algorithmischen Handels

Der Knight-Capital-Vorfall war nicht das erste und nicht das letzte Ereignis dieser Art. Bereits 2010 hatte der „Flash Crash“ gezeigt, wie fragil die automatisierten Märkte sein können. Am 6. Mai 2010 verlor der Dow Jones innerhalb weniger Minuten rund 1.000 Punkte; einige Aktien verloren bis zu 99 Prozent ihres Wertes . Der anschließende Untersuchungsbericht der SEC und CFTC stellte fest, dass kein einzelner Faktor für den Crash verantwortlich war, sondern das Zusammenspiel von hoher Volatilität, schwindender Liquidität und einem großen algorithmischen Verkaufsauftrag .

Nach 2012 folgten weitere Vorfälle – etwa der Flash Crash von 2015 oder die Probleme bei der London Stock Exchange. Was Knight Capital jedoch einzigartig macht, ist die Klarheit der Ursachenkette: Ein einzelner unterlassener Deployment-Schritt, kombiniert mit einem jahrelang vernachlässigten Codeabschnitt, führte zu einem Verlust in der Größenordnung eines mittleren Unternehmens.

Regulatorische Konsequenzen

Die SEC nutzte den Fall, um die 2010 verabschiedete Market Access Rule erstmals durchzusetzen. Die Regel verpflichtet Broker-Dealer zu:

• Risikokontrollen vor der Order-Übermittlung
• Finanziellen Limits für Handelsaktivitäten
• Schriftlichen Verfahren für Code-Deployment und Incident-Response
• Regelmäßigen Überprüfungen der Wirksamkeit dieser Kontrollen

Die Botschaft war klar: Wer Zugang zum Markt hat, trägt Verantwortung für die Sicherheit seiner Systeme. Die 12-Millionen-Dollar-Strafe war symbolisch bedeutsam, auch wenn sie im Verhältnis zum verursachten Schaden gering erscheint.

Die technische Perspektive: Was wurde gelernt?

In der Software-Engineering-Community wurde der Fall zu einem vielzitierten Lehrstück. Die zentralen Lehren:

1. Code-Hygiene ist keine Option: Nicht genutzter Code muss entfernt werden. Die Vorstellung, dass „schlafender“ Code harmlos sei, ist trügerisch.
2. Regressionstests für alle Code-Pfade: Wenn Code im System verbleibt, muss er bei Änderungen an gemeinsamen Abhängigkeiten getestet werden – auch wenn er offiziell nicht genutzt wird.
3. Deployment ist ein kritischer Prozess: Automatisierte Verifikation, Vier-Augen-Prinzipien und Konsistenzprüfungen sind unerlässlich.
4. Alarme müssen als Alarme funktionieren: Die 97 E-Mails, die Knight vor Handelsbeginn erhielt, waren eine verpasste Gelegenheit. Systeme müssen so gestaltet sein, dass sie auf Fehler aufmerksam machen – nicht nur Daten protokollieren.
5. Incident-Response braucht Verfahren: Die Verschlimmerung des Problems durch die Deinstallation des neuen Codes auf den funktionierenden Servern zeigt, wie wichtig klare, geübte Reaktionspläne sind.

Die Frage der Systemrelevanz

Knight Capital war kein kleines Unternehmen – es war ein systemrelevanter Akteur im US-Aktienmarkt. Der Vorfall warf die Frage auf, wie die Gesellschaft mit der Konzentration kritischer Infrastruktur in den Händen weniger, hochautomatisierter Firmen umgehen soll. Die Rettung durch ein Bankenkonsortium und die Übernahme durch GETCO verhinderten einen Kollaps, aber sie warfen auch die Frage auf, ob der Markt allein solche Risiken tragen kann.

Fazit

Der Power-Peg-Fehler bei Knight Capital ist mehr als eine technische Anekdote. Er ist ein Fall, in dem sich in 45 Minuten die Konsequenzen von neun Jahren Nachlässigkeit entluden. Ein Codeabschnitt, der 2003 stillgelegt, aber nicht entfernt wurde. Eine Änderung von 2005, die nicht getestet wurde. Ein Deployment-Fehler von 2012, der nicht überprüft wurde. Und das Fehlen jeglicher Sicherheitsnetze, die den Schaden hätten begrenzen können.

Die eigentliche Tragik liegt nicht im Versagen der Technik – sondern im Versagen der Prozesse, die Technik sicher machen sollen. Knight Capital hatte die Ressourcen, die Expertise und die Zeit, diese Fehler zu vermeiden. Was fehlte, war die institutionelle Disziplin, die Risiken des eigenen Systems ernst zu nehmen.

Für die heutige Zeit, in der algorithmische Systeme immer mehr Bereiche des Lebens durchdringen – von Finanzmärkten über Logistik bis hin zu KI-gesteuerten Entscheidungen –, bleibt der Fall aktuell. Er erinnert daran, dass Komplexität ohne entsprechende Kontrolle nicht Sicherheit bedeutet, sondern nur eine größere Oberfläche für das Unerwartete.

Quellen

1. U.S. Securities and Exchange Commission, Press Release 2013-222: SEC Charges Knight Capital With Violations of Market Access Rule, 16. Oktober 2013 .
2. U.S. Securities and Exchange Commission, In the Matter of Knight Capital Americas LLC, Administrative Proceeding File No. 3-15570, 16. Oktober 2013.
3. U.S. Securities and Exchange Commission, SEC News Digest: Enforcement Proceedings, 16. Oktober 2013 .
4. Traders Magazine, Knight Revenue Cut in Half in 2012, Loss Exceeds $500M, 15. April 2013 .
5. The New York Times (DealBook), Knight Capital Says Trading Glitch Cost It $440 Million, 2. August 2012 .
6. The New York Times (DealBook), Trying to Be Nimble, Knight Capital Stumbles, 2. August 2012 .
7. Bloomberg, Knight Bruised in Haywire Day as Loss Reaches $440 Million, 2. August 2012 .
8. Nasdaq Analyst Blog, Knight Capital to Merge with Getco, 20. Dezember 2012 .
9. Chicago Federal Reserve Bank, Chicago Fed Letter, Oktober 2012 .
10. SEC/CFTC Joint Staff Report, Statement on the May 6 Flash Crash, 1. Oktober 2010 .
11. CFTC Commissioner Bart Chilton, Statement on the Joint CFTC/SEC Staff Report on the May 6 Flash Crash, 1. Oktober 2010.
12. Google Books, Flash Crash: Elektronischer Börsenhandel .