HFT (high-frequency trading) treidauksesta puhutaan paljon ja sitä pidetään ihmeellisenä. Luin Yhdysvallan rahoitustarkastuksen SEC:n raportin Knight Capital Americas LLC:n tyrimisestä. Tuli mieleen deja vu, tämä on jo nähty ennenkin. Kyseessä on oikeastaan aika tyypillinen vanhan ison ohjelmistoprojektin ongelma. Raportti löytyy täältä:

http://www.sec.gov/litigation/admin/2013/34-70694.pdf

Knight Capital hävisi nopeasti 460 miljoonaa dollaria elokuussa 2012 virheellisen toiminnan johdosta. Yritys menetti tappioidensa myötä itsenäisyyden ja se liitettiin Getco LLC:een. Knightin kuten rahoitusmarkkinoilla toimivien yritysten toiminta yleensä on paljolti luottamustoimintaa ja sen menettäessä toiminta on vaikeaa. Knight oli Yhdysvaltalainen suuri market maker eli yritys joka takaa niin osto- myyntilaidan. Jotkut pörssit vaativat tällaisia market makereita, jotka takaavat osakkeiden likviditeetin ja heidän liiketoimintansa tulot syntyvät osto- ja myyntilaidan erosta. Knight oli ennen ongelmiaan 19 000 Yhdysvaltaisen osakkeen market maker ja keskimääräinen päivävaihto oli 21 miljardia dollaria. Nämä yritykset toimivat hyvin pienillä marginaaleilla, mutta suurilla voluumeilla. Katsonpa mielenkiinnon vuoksi tarkemmin tuota SEC:n raporttia ja Knightin ohjelmistonkehitysprojektia.

 

Kappaleessa neljä sanotaan jo joitain vihjeitä mistä ongelmat juontavat: "Järkevä teknologia hallinnan ydin on laadunvarmistus, jatkuva parantaminen, kontrolloitu testaus ja käyttäjien hyväksyntä sekä prosessien mittaus kontrollointi, säännöllinen ja tarkat katselmukset asianmukaisten sääntöjen kanssa mukaanlukien vahva sekä riippumaton auditointi prosessi". Varsin mielenkiintoista kun rahoitustarkastus Yhdysvalloissa antaa noin tarkkoja tuotekehitysohjeita. 

 

Knightilta petti katastrofaalisesti tuotekehityksen laadunvalvonta sekä tuotekehitysprosessi. Se ei havainnut syntyviä riskejä. Knight oli kehittänyt softan jota kutsuttiin SMARSiksi. Tämän ohjelman tarkoitus oli pilkkoa suuri toimeksianto pienemmiksi alitoimeksiannoiksi. Tässä SMARSissa oli "Power Peg" niminen ominaisuus, joka kyttäsi alitoimeksiantojen suoritusta  ja kertoi kumulatiivista summaa päätoimeksiannolle. Tätä Power Peg ominaisuutta ei käytetty enää vuoden 2003 jälkeen, mutta koodi jätettiin pyörimään kuitenkin serveriin. Sen aktivoinnin laukaisisi lippu. 

 

NYSE, Yhdysvaltojen pääpörssi, julkaisi vuonna 2012 Retail Liquidity Program (RLP), jonka tarkoitus on parantaa likviditeettia ja saada tiukemmat spredit. Knight osallistui ohjelmaan, koska se oli toimintaan selkeä parannus. Uusi Knightin kehittämä ohjelmisto käytti tätä Power Peg ominaisuuden lippua, mutta se ohitettiin hallitusti uudessa ohjelmaversiossa. Uuden ohjelmiston asennusvaiheessa Knightin insinööri kopioi uuden koodin seitsemään serveriin kun se olisi pitänyt kopioida kaikkiin kahdeksaan koneeseen, yhteen jäi väärä versio ohjelmistosta. Elokuun ensimmäisenä päivänä serverifarmi joutui käytännön töihin kun RLP:hen kuulunut asiakas syötti toimeksiannon. Koska muihin servereihin paitsi yhteen oli asennettu uusi softa, joka hanskasi RLP:n, niin Power Peg aktivoitui tässä vanhan ohjelmiston serverissä ja tämä ominaisuus sylki kiihtyvään tahtiin alitoimeksiantoja. Tämä rytinä kesti 45 mnuuttia ja SMARS lähetti miljoonia toimeksiantoja joista neljä miljoonaa toimeksiantoa suoritettiin 154 osakkeessa ja yhteensä 397 miljoonaa osaketta vaihtoi omistajaa. Knight omisti long puolella 3,5 miljardin edestä osakkeita ja short puolella 74 osakkeessa 3,15 miljardia ja suorat tappiot tästä toiminnasta olivat 460 miljoonaa. Knightilla oli erilaisia riskimonitoreita (PMON), mutta ne eivät olleet automaattisia ja ne eivät estäneet ajoissa tätä toimintaa.

 

Softan tekeminen on softan tekemistä olkoon ympäristö mitä tahansa. Pitkään ylläpidettävästä ohjelmistosta täytyy putsata roskat pois tai koodista tulee sellaista spagettia että sitä ei voi enää hallita. Laajoissa kriittisissä ohjelmistoissa pitää olla valvontaosioita jotka tarvittaessa vetävät palvelun hallitusti alas. Aivan kuten SEC sanoi rutiinit pitää olla sellaisia, että tuollaista asennusvirhettä ei voi tapahtua. Ei tällä tapauksessa ole suoraan tekemistä korkeataajuuksisen treidauksen kanssa vaan tuotekehityksen prosessien kanssa. Sen on oltava tarkkaa ja varmistavaa. Tuon ongelman syynä ei ollut ohjelmistobugi vaan väärä tapa toimia!