{"id":7655,"date":"2026-10-10T16:22:47","date_gmt":"2026-10-10T16:22:47","guid":{"rendered":"https:\/\/technodidact.de\/?p=7655"},"modified":"2026-10-10T16:22:47","modified_gmt":"2026-10-10T16:22:47","slug":"der-power-peg-fehler-bei-knight-capital-anatomie-einer-algorithmischen-katastrophe","status":"publish","type":"post","link":"https:\/\/technodidact.de\/en\/der-power-peg-fehler-bei-knight-capital-anatomie-einer-algorithmischen-katastrophe\/","title":{"rendered":"Der Power-Peg-Fehler bei Knight Capital: Anatomie einer algorithmischen Katastrophe"},"content":{"rendered":"

von DerSchneider<\/strong><\/p>\n\n\n\n

\n\n\n\n

Einleitung<\/h2>\n\n\n\n

Es gibt Momente in der Technikgeschichte, in denen sich in wenigen Minuten zeigt, wie verletzlich hochkomplexe Systeme sein k\u00f6nnen. 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 \u2013 mehr, als das Unternehmen in den vorangegangenen Jahren an Gewinn erwirtschaftet hatte. Ursache war ein Softwarefehler, der auf einen \u00fcber Jahre vernachl\u00e4ssigten Codeabschnitt zur\u00fcckging: die Funktion \u201ePower Peg“.<\/p>\n\n\n\n

Was diesen Fall so lehrreich macht, ist nicht allein die H\u00f6he des Verlustes, sondern die Tatsache, dass er sich aus einer Kette vermeidbarer Fehler zusammensetzte \u2013 Fehler, die \u00fcber einen Zeitraum von neun Jahren entstanden und sich schlie\u00dflich an einem einzigen Tag zu einer Katastrophe verbanden. Der Fall wurde zum Musterbeispiel f\u00fcr regulatorische Versch\u00e4rfungen, f\u00fcr die Risiken des algorithmischen Hochfrequenzhandels und f\u00fcr die Frage, wie Unternehmen mit \u201etotem Code“ umgehen sollten.<\/p>\n\n\n\n

\n\n\n\n

Der Kontext: Knight Capital und der algorithmische Handel<\/h2>\n\n\n\n

Knight Capital Group war Ende der 2000er und Anfang der 2010er Jahre einer der gr\u00f6\u00dften Market Maker der Welt. Das Unternehmen wickelte t\u00e4glich Millionen von Aktienauftr\u00e4gen ab und war f\u00fcr viele Broker eine zentrale Infrastruktur \u2013 ein unsichtbarer, aber systemrelevanter Akteur im US-Aktienmarkt.<\/p>\n\n\n\n

Das Herzst\u00fcck dieser Operation war SMARS (Smart Market Access Routing System), ein automatisierter Order-Router. SMARS nahm \u201eElternauftr\u00e4ge“ von Brokern entgegen, zerlegte sie in kleinere \u201eKindauftr\u00e4ge“ und leitete diese an verschiedene Handelspl\u00e4tze weiter \u2013 ein Verfahren, das als algorithmische Order-Aufteilung bekannt ist. Die Geschwindigkeit, mit der SMARS arbeitete, war entscheidend f\u00fcr die Wettbewerbsf\u00e4higkeit von Knight: Millisekunden konnten \u00fcber Gewinn oder Verlust entscheiden.<\/p>\n\n\n\n

\n\n\n\n

Die Vorgeschichte: Power Peg und sein schleichender Verfall<\/h2>\n\n\n\n

Was war Power Peg?<\/h3>\n\n\n\n

Power Peg war eine Funktion innerhalb von SMARS, die in den 1990er Jahren entwickelt wurde. Ihre Aufgabe bestand darin, Kindauftr\u00e4ge zu generieren und dabei sicherzustellen, dass nicht mehr Aktien gehandelt wurden, als der urspr\u00fcngliche Elternauftrag vorsah. Eine kumulative Mengenfunktion z\u00e4hlte die bereits ausgef\u00fchrten Aktien und stoppte den Algorithmus, sobald der Elternauftrag vollst\u00e4ndig gef\u00fcllt war.<\/p>\n\n\n\n

Im Jahr 2003 stellte Knight die Nutzung von Power Peg ein. Der Code wurde jedoch nicht entfernt \u2013 weder gel\u00f6scht noch deaktiviert. Er blieb als schlafende Funktionalit\u00e4t im Produktionssystem, ausgel\u00f6st durch ein spezifisches Flag, das in der Software gesetzt werden konnte.<\/p>\n\n\n\n

Der folgenreiche Eingriff von 2005<\/h3>\n\n\n\n

Zwei Jahre nach der Stilllegung von Power Peg nahm Knight eine \u00c4nderung an der SMARS-Codebasis vor, die sich als fatal erweisen sollte. Die kumulative Mengenfunktion, die urspr\u00fcnglich Teil des Power-Peg-Codes war, wurde an eine fr\u00fchere Stelle in der Code-Sequenz verschoben. Diese \u00c4nderung war f\u00fcr andere, aktive Funktionen gedacht \u2013 doch sie hatte eine unbeabsichtigte Nebenwirkung: Der Power-Peg-Code wurde dadurch seiner F\u00e4higkeit beraubt, zu erkennen, wann ein Auftrag vollst\u00e4ndig ausgef\u00fchrt war.<\/p>\n\n\n\n

Knight testete den Power-Peg-Code nach dieser \u00c4nderung nicht erneut. Da die Funktion offiziell nicht mehr genutzt wurde, schien ein Regressionstest \u00fcberfl\u00fcssig. Die SEC stellte sp\u00e4ter fest, dass genau hier ein zentrales Vers\u00e4umnis lag: Wenn Code im System verbleibt \u2013 selbst wenn er inaktiv ist \u2013, muss er bei \u00c4nderungen an gemeinsamen Abh\u00e4ngigkeiten getestet werden.<\/p>\n\n\n\n

\n\n\n\n

Die Katastrophe von 2012: Eine Verkettung von Fehlern<\/h2>\n\n\n\n

Der Ausl\u00f6ser: Das NYSE Retail Liquidity Program<\/h3>\n\n\n\n

Im Jahr 2012 k\u00fcndigte die New York Stock Exchange die Einf\u00fchrung eines neuen Programms an: das Retail Liquidity Program (RLP). Es sollte Einzelhandelskunden bessere Preise bei Aktiengesch\u00e4ften erm\u00f6glichen. F\u00fcr Knight Capital war die Teilnahme an diesem Programm gesch\u00e4ftskritisch \u2013 ein Ausschluss h\u00e4tte Marktanteile gekostet.<\/p>\n\n\n\n

Knight beschloss, den alten Power-Peg-Code zu entfernen und durch neuen RLP-Code zu ersetzen. Das Flag, das fr\u00fcher Power Peg aktivierte, sollte nun den RLP-Code aufrufen. Der Plan war, den alten Code zu l\u00f6schen und den neuen zu integrieren \u2013 eine scheinbar saubere L\u00f6sung.<\/p>\n\n\n\n

Der Deployment-Fehler<\/h3>\n\n\n\n

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 \u2013 einen Server lie\u00df er aus. Es gab keine zweite Kontrolle, kein Vier-Augen-Prinzip, keine automatisierte Verifikation, dass alle Server identisch konfiguriert waren.<\/p>\n\n\n\n

Das Ergebnis: Auf sieben Servern lief der neue RLP-Code. Auf dem achten Server lief noch immer der alte Power-Peg-Code \u2013 mit dem entscheidenden Defekt aus dem Jahr 2005.<\/p>\n\n\n\n

Die 45 Minuten des Chaos<\/h3>\n\n\n\n

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

Was dann geschah, beschreibt die SEC sp\u00e4ter so: \u201eObwohl ein Teil von Knights Order-Handling-System erkannte, dass die Elternauftr\u00e4ge gef\u00fcllt waren, wurde diese Information nicht an SMARS kommuniziert.“ Der Server sendete weiter Orders \u2013 Millionen davon. Innerhalb von 45 Minuten gingen \u00fcber 4 Millionen Orders in den Markt, die zu 154 Aktien und 397 Millionen gehandelten Aktien f\u00fchrten.<\/p>\n\n\n\n

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\u00dflich gestoppt wurde, belief sich der Verlust auf \u00fcber 460 Millionen Dollar.<\/p>\n\n\n\n

Die verschlimmernde Reaktion<\/h3>\n\n\n\n

Was den Fall besonders tragisch macht, ist die Tatsache, dass der Schaden w\u00e4hrend der Fehlerbehebung noch vergr\u00f6\u00dfert wurde. Als Knights Techniker versuchten, das Problem zu identifizieren und zu beheben, deinstallierten sie den neuen RLP-Code von den sieben korrekt funktionierenden Servern \u2013 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.<\/p>\n\n\n\n

Die SEC stellte zudem fest, dass Knights internes System 97 automatisierte E-Mails generierte, die auf den Fehler hinwiesen \u2013 noch bevor die M\u00e4rkte \u00f6ffneten, ab etwa 8:00 Uhr morgens. Diese Nachrichten wurden jedoch nicht als Alarme erkannt oder beachtet, da sie nicht als Systemwarnungen konzipiert waren.<\/p>\n\n\n\n

\n\n\n\n

Die regulatorische Aufarbeitung<\/h2>\n\n\n\n

Die SEC-Untersuchung und das Marktzugangsgesetz<\/h3>\n\n\n\n

Die SEC leitete eine Untersuchung ein und erhob im Oktober 2013 Anklage gegen Knight Capital Americas LLC. Es war die erste Durchsetzungsma\u00dfnahme unter der 2010 verabschiedeten Market Access Rule (Rule 15c3-5), die Broker-Dealer verpflichtet, angemessene Risikokontrollen f\u00fcr ihren Marktzugang einzurichten <\/a>.<\/p>\n\n\n\n

Die SEC stellte eine Reihe von Vers\u00e4umnissen fest:<\/p>\n\n\n\n

Bereich<\/th>Festgestelltes Vers\u00e4umnis<\/th><\/tr><\/thead>
Code-Deployment<\/td>Keine angemessenen Kontrollen und Verfahren f\u00fcr die Bereitstellung und Testung des Order-Routers<\/td><\/tr>
Risikokontrollen<\/td>Keine Kontrollen unmittelbar vor Order-\u00dcbermittlung, die ausgehende mit eingehenden Orders vergleichen<\/td><\/tr>
Finanzielle Limits<\/td>Risikokontrollen konnten Orders, die voreingestellte Kapitalschwellen \u00fcberschritten, nicht verhindern<\/td><\/tr>
Konto-Verkn\u00fcpfung<\/td>Das Konto Nr. 33, das die fehlerhaften Ausf\u00fchrungen erhielt, war nicht an die automatisierten Kapitalkontrollen des Unternehmens angebunden<\/td><\/tr>
Incident-Response<\/td>Keine ausreichenden schriftlichen Verfahren f\u00fcr den Umgang mit schwerwiegenden technologischen Vorf\u00e4llen<\/td><\/tr>
\u00dcberpr\u00fcfung<\/td>Unzureichende \u00dcberpr\u00fcfung der Wirksamkeit der Risikomanagement-Kontrollen<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Knight Capital einigte sich auf einen Vergleich: 12 Millionen Dollar Strafe und die Verpflichtung, einen unabh\u00e4ngigen Berater f\u00fcr eine umfassende \u00dcberpr\u00fcfung der Kontrollen und Verfahren zu engagieren <\/a><\/a>.<\/p>\n\n\n\n

Die wirtschaftlichen Konsequenzen<\/h3>\n\n\n\n

Die unmittelbaren Folgen des Vorfalls waren verheerend. Knight Capital ben\u00f6tigte eine Notfallfinanzierung von 400 Millionen Dollar durch ein Konsortium unter F\u00fchrung von Jefferies Group, an dem sich unter anderem TD Ameritrade und die Blackstone Group beteiligten <\/a>. Die NYSE entzog Knight vor\u00fcbergehend die Market-Making-Verantwortung f\u00fcr \u00fcber 600 Wertpapiere.<\/p>\n\n\n\n

Die Aktion\u00e4re wurden massiv verw\u00e4ssert: Vor dem Vorfall notierte die Aktie \u00fcber 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<\/strong> sowie einen den Aktion\u00e4ren zurechenbaren Nettoverlust von 722,7 Millionen Dollar<\/strong> <\/a>. Der Handelsverlust durch den Vorfall selbst belief sich auf 456,7 Millionen Dollar<\/strong> <\/a>. Im Juli 2013 wurde Knight von GETCO \u00fcbernommen \u2013 das Unternehmen existierte nicht mehr als eigenst\u00e4ndige Einheit.<\/p>\n\n\n\n

\n\n\n\n

Die technischen und organisatorischen Lehren<\/h2>\n\n\n\n

Toter Code ist gef\u00e4hrlicher Code<\/h3>\n\n\n\n

Der Power-Peg-Fall ist ein Musterbeispiel f\u00fcr die Gefahren von \u201edormant code“ \u2013 Code, der im Produktionssystem verbleibt, obwohl er nicht mehr genutzt wird. Die SEC formulierte es so: Knight habe es vers\u00e4umt, den Code zu entfernen, und ihn stattdessen \u201eim Router belassen“.<\/p>\n\n\n\n

Die technische Gemeinschaft zog daraus die Lehre, dass Code, der nicht mehr ben\u00f6tigt wird, vollst\u00e4ndig entfernt werden sollte \u2013 nicht nur deaktiviert. Die Begr\u00fcndung: Jeder verbleibende Code stellt eine potenzielle Angriffsfl\u00e4che dar, insbesondere wenn er durch Flags oder andere Mechanismen aktiviert werden kann.<\/p>\n\n\n\n

Die Wiederverwendung von Flags als Antipattern<\/h3>\n\n\n\n

Ein besonders t\u00fcckisches Element des Falls war die Wiederverwendung des Power-Peg-Aktivierungsflags f\u00fcr den neuen RLP-Code. Diese Praxis \u2013 die Belegung eines Schalters mit neuer Semantik, w\u00e4hrend die alte Funktionalit\u00e4t im System verbleibt \u2013 wird heute als klarer Versto\u00df gegen gute Software-Engineering-Prinzipien angesehen. Sie schuf eine direkte Br\u00fccke zwischen dem neuen Feature und dem alten, fehlerhaften Code.<\/p>\n\n\n\n

Deployment ohne Verifikation<\/h3>\n\n\n\n

Der Fehler, den achten Server nicht zu aktualisieren, w\u00e4re durch einfache Ma\u00dfnahmen vermeidbar gewesen: ein zweiter Techniker, der die Installation \u00fcberpr\u00fcft, oder ein automatisiertes System, das die Konsistenz der Server-Konfigurationen pr\u00fcft. Die SEC stellte fest, dass Knight \u201ekeine schriftlichen Verfahren hatte, die eine solche \u00dcberpr\u00fcfung vorschrieben“.<\/p>\n\n\n\n

Das Fehlen von Sicherheitsnetzen<\/h3>\n\n\n\n

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 \u00dcberschreitung von Kapitalschwellen, keine M\u00f6glichkeit, den fehlerhaften Server zu isolieren. Daniel Hawke von der SEC brachte es auf den Punkt: \u201eBroker und H\u00e4ndler m\u00fcssen jede Komponente ihrer Systeme betrachten und sich fragen, was passieren w\u00fcrde, wenn die Komponente versagt, und welche Sicherheitsnetze vorhanden sind, um den Schaden zu begrenzen. Knight Capitals Vers\u00e4umnis, diese Fragen zu stellen, hatte katastrophale Folgen.“ <\/a><\/p>\n\n\n\n

Das Fehlen einer operationellen Risikofunktion<\/h3>\n\n\n\n

\u00dcber das Fehlen schriftlicher Verfahren hinaus offenbarte der Fall ein strukturelles Organisationsversagen<\/strong>: Ein Zeuge im Rahmen der anschlie\u00dfenden Sammelklage sagte aus, dass bei Knight Capital keine Unternehmens- oder operationelle Risikofunktion existierte<\/strong>. Auf die Frage, wer f\u00fcr operationelles Risiko zust\u00e4ndig sei, antwortete der ehemalige Leiter des globalen Marktrisikos mit einem Wort: \u201eNiemand.“<\/strong><\/p>\n\n\n\n

\n\n\n\n

Einordnung und Ausblick<\/h2>\n\n\n\n

Der Fall im Kontext des algorithmischen Handels<\/h3>\n\n\n\n

Der Knight-Capital-Vorfall war nicht das erste und nicht das letzte Ereignis dieser Art. Bereits 2010 hatte der \u201eFlash Crash“ gezeigt, wie fragil die automatisierten M\u00e4rkte sein k\u00f6nnen. Am 6. Mai 2010 verlor der Dow Jones innerhalb weniger Minuten rund 1.000 Punkte; einige Aktien verloren bis zu 99 Prozent ihres Wertes <\/a>. Der anschlie\u00dfende Untersuchungsbericht der SEC und CFTC stellte fest, dass kein einzelner Faktor f\u00fcr den Crash verantwortlich war, sondern das Zusammenspiel von hoher Volatilit\u00e4t, schwindender Liquidit\u00e4t und einem gro\u00dfen algorithmischen Verkaufsauftrag <\/a>.<\/p>\n\n\n\n

Nach 2012 folgten weitere Vorf\u00e4lle \u2013 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\u00e4ssigten Codeabschnitt, f\u00fchrte zu einem Verlust in der Gr\u00f6\u00dfenordnung eines mittleren Unternehmens.<\/p>\n\n\n\n

Regulatorische Konsequenzen<\/h3>\n\n\n\n

Die SEC nutzte den Fall, um die 2010 verabschiedete Market Access Rule erstmals durchzusetzen. Die Regel verpflichtet Broker-Dealer zu:<\/p>\n\n\n\n