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ä:
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!
Ei kommentteja:
Lähetä kommentti