Knight Capital: 45 minut i ponad 460 mln dolarów straty

Knight Capital Americas był w 2012 roku jednym z dużych amerykańskich pośredników giełdowych. Rankiem 1 sierpnia 2012 jego router zleceń zaczął kupować i sprzedawać akcje bez kontroli. Cała historia poniżej opiera się na postanowieniu SEC nr 70694 z 16 października 2013 i dokumentach, które spółka złożyła w SEC. Numery paragrafów wskazują miejsca w postanowieniu.

1. Poranek 1 sierpnia 2012 i system SMARS

Tego dnia giełda NYSE uruchamiała Retail Liquidity Program (RLP), program obsługi zleceń klientów detalicznych. Knight przygotował do niego zmiany w SMARS (Smart Market Access Routing System), swoim automatycznym routerze zleceń. SMARS przyjmował zlecenia nadrzędne z innych części platformy i dzielił je na zlecenia podrzędne, wysyłane na rynek (par. 12).

Od około 8:01 czasu wschodniego system wysłał 97 automatycznych e-maili z komunikatem „Power Peg disabled” (par. 19). Wiadomości nie były zaprojektowane jako alerty, pracownicy zwykle ich nie czytali i nikt nie zareagował przed otwarciem rynku o 9:30.

2. Martwy kod i flaga użyta ponownie

Nowy kod RLP miał zastąpić fragment odpowiadający za funkcję Power Peg, z której Knight zrezygnował w 2003 roku. Kod Power Peg przez dziewięć lat pozostawał na serwerach produkcyjnych i dało się go uruchomić (par. 13). Nowa funkcja RLP przejęła flagę, która wcześniej włączała Power Peg. Po usunięciu starego kodu ta sama flaga miała włączać już tylko RLP.

W starym kodzie była jeszcze jedna pułapka. Power Peg przestawał wysyłać zlecenia podrzędne, gdy funkcja zliczająca wykonane akcje wykazała, że zlecenie nadrzędne jest zrealizowane. W 2005 roku Knight przeniósł tę funkcję w inne miejsce kodu SMARS i nie sprawdził, czy Power Peg nadal działa poprawnie (par. 14). Od tej pory Power Peg, uruchomiony ponownie, nie miałby hamulca.

3. Siedem serwerów z nowym kodem, jeden bez

Od 27 lipca 2012 Knight wdrażał kod RLP etapami, kilka serwerów dziennie. Jeden z techników nie skopiował nowego kodu na jeden z ośmiu serwerów SMARS (par. 15). Knight nie wymagał, by wdrożenie sprawdzał drugi technik, i nie miał pisemnych procedur takiej weryfikacji. Nikt nie zauważył, że na ósmym serwerze wciąż jest Power Peg.

1 sierpnia zlecenia kierowane do siedmiu zaktualizowanych serwerów obsługiwane były poprawnie. Zlecenia z przejętą flagą, które trafiały na ósmy serwer, uruchamiały Power Peg (par. 16).

4. 45 minut na rynku

Ósmy serwer dla każdego zlecenia nadrzędnego wysyłał w szybkiej sekwencji kolejne zlecenia podrzędne, niezależnie od liczby już wykonanych transakcji. Inna część systemu Knighta wiedziała, że zlecenia są zrealizowane, ale ta informacja nie docierała do SMARS (par. 16).

Wystarczyło 212 zleceń nadrzędnych. W około 45 minut SMARS wysłał miliony zleceń podrzędnych, które dały ponad 4 mln transakcji w 154 spółkach na łącznie ponad 397 mln akcji (par. 17). Knight niechcący zbudował pozycję długą netto o wartości około 3,5 mld USD w 80 spółkach i krótką netto o wartości około 3,15 mld USD w 74 spółkach. W przypadku 75 spółek transakcje Knighta stanowiły ponad 20% obrotu i przyczyniły się do zmian cen o ponad 5% (par. 18).

5. Naprawa, która pogorszyła sytuację

Knight nie miał procedur reagowania na takie incydenty i polegał na zespole technicznym, który szukał przyczyny na działającym systemie produkcyjnym (par. 27). W jednej z prób naprawy zespół odinstalował nowy kod RLP z siedmiu serwerów, na których działał prawidłowo. Od tej chwili przejęta flaga uruchamiała Power Peg także na nich.

Zawiodły też zabezpieczenia finansowe. Kontrola limitu ceny nie obejmowała zleceń złożonych przed otwarciem na aukcję otwarcia, a takie były wszystkie 212 zleceń (par. 20 i 21). Główne narzędzie monitorowania ryzyka, PMON, pokazywało pozycje dopiero po transakcjach, nie wysyłało automatycznych alertów, a przy dużym obrocie się opóźniało (par. 25).

6. Rachunek: 440 czy 460 mln USD

W dokumentach pojawiają się dwie kwoty i obie są prawdziwe. W raporcie 8-K z 6 sierpnia 2012 Knight Capital Group podał zrealizowaną stratę przed opodatkowaniem na poziomie około 440 mln USD, po zamknięciu całej błędnej pozycji. SEC w postanowieniu z października 2013, po dochodzeniu, ustaliła stratę na ponad 460 mln USD (par. 1 i 17).

Tego samego 6 sierpnia spółka zawarła umowę finansowania. Inwestorzy, wśród nich Jefferies, Blackstone, GETCO, Stephens, Stifel i TD Ameritrade, zobowiązali się kupić zamienne akcje uprzywilejowane za 400 mln USD. 1 lipca 2013 Knight Capital Group połączył się z GETCO, a obie firmy stały się spółkami zależnymi KCG Holdings.

7. Co zarzuciła SEC

16 października 2013 SEC ogłosiła ugodę z Knight Capital Americas. Firma zapłaciła 12 mln USD kary, dostała naganę i nakaz zaprzestania naruszeń. Musiała też zatrudnić niezależnego konsultanta do przeglądu kontroli ryzyka i procesów wytwarzania oprogramowania. Była to pierwsza sprawa SEC na podstawie Rule 15c3-5, zasady dostępu do rynku przyjętej w listopadzie 2010.

Według SEC Knight nie miał kontroli, które zatrzymałyby błędne zlecenia przed wysłaniem na rynek, ani automatycznych limitów kapitałowych. Nie miał też procedur nadzoru nad wdrażaniem kodu i reagowania na incydenty. SEC stwierdziła również naruszenia Regulation SHO przy oznaczaniu zleceń krótkiej sprzedaży (par. 46 do 48).

8. Lekcje dla wdrożeń według SEC

W paragrafie 41 postanowienia SEC wskazała trzy konkretne działania, które mogły zapobiec zdarzeniom z 1 sierpnia:

• pisemna procedura wymagająca prostego, podwójnego sprawdzenia wdrożenia kodu RLP mogła wykryć pominięty serwer,
• włączenie e-maili BNET Reject do monitorowania systemów mogło ostrzec zespół przed otwarciem rynku,
• protokół wymagający ponownego przetestowania Power Peg w 2005 roku mógł ujawnić, że funkcja zliczania akcji przestała działać w tym kodzie.

Z tych samych ustaleń wynikają ogólniejsze wnioski. Nieużywany kod powinien znikać z serwerów produkcyjnych, a nie tylko przestać być wywoływany. Stara flaga przypisana nowej funkcji zachowuje dawne znaczenie wszędzie tam, gdzie został stary kod. System wysyłający zlecenia na rynek potrzebował też mechanizmu, który zatrzymałby go przy nieprawidłowym działaniu. SEC zwróciła uwagę, że takiej procedury Knight nie miał (par. 20).

9. Podsumowanie

Awaria Knight Capital nie wymagała żadnego wyrafinowanego błędu. Wystarczył martwy kod pozostawiony na dziewięć lat, flaga przypisana nowej funkcji, jedno pominięte kopiowanie plików i brak drugiej osoby, która by to sprawdziła. Podobny wzorzec widać w awarii CrowdStrike z 2024 roku, gdzie jedna aktualizacja trafiła naraz do wszystkich urządzeń.