Bij assetmanagers en banken worden in toenemende mate coders aangenomen op de positie van traders. Coders zijn personen die technisch goed onderlegd zijn en kunnen programmeren. Het idee is dat zij een deel van de handel kunnen automatiseren, waardoor de trades sneller, preciezer en autonoom kunnen worden uitgevoerd.
Deze praktijk is al bekend van high-frequency traders. Die werken al jarenlang met algoritmes om hun transacties uit te kunnen voeren. Dit is nodig om volatiliteit van de markt optimaal te kunnen benutten. Zodra een bepaalde prijs bereikt wordt, neergaand of opgaand, treedt automatisch een aan- of verkoop op. Dit is duidelijk een ‘sign of the times’ en niet te stoppen. Echter, is het een probleem of juist een kans?
Voor frontoffices is het een kans op veel hogere winsten. Echter, er worden op andere plekken in de organisatie tal van problemen gecreëerd.
Feit is dat alle code fouten kan bevatten. De kans op schade hierdoor is klein, maar de impact kan groot zijn. Zeker als het om grote bedragen gaat, wat in de regel zo is, want anders zou het niet de moeite lonen om er code voor te schrijven.
De code kan daarnaast gehackt worden, van binnenuit of van buitenaf. Wederom geldt, de kans is niet groot. Zeker van buitenaf is het niet eenvoudig om door de security en andere beschermingswallen heen te komen. Als het echter wel lukt, de code wordt aangepast en het blijft ongedetecteerd, dan kan de schade niet te overzien zijn.
Ook is het de vraag of er checks en balances op het ontwikkelproces zelf zitten. Vindt er een ‘code review’ plaats door een derde? Wordt de code via een gecontroleerd proces in productie genomen, waarbij voldoende wordt getest? Bij reguliere software is dit gangbaar, maar de vraag is of dit voor de code die in de frontoffice wordt ontwikkeld ook het geval is.
Ten slotte, als de code eenmaal in productie is genomen, dan is de vraag wie er regulier onderhoud aan pleegt en wie er support levert bij issues. Het onderhoud kan business-gedreven zijn, bijvoorbeeld door een andere gekozen handelsstrategie. Als de persoon die code heeft geschreven de enige is die dit kan, dan is sprake van een keyman exposure en dus een groot risico voor de organisatie. Het support daarentegen zal meestal issue-gedreven zijn als bijvoorbeeld het programma vastloopt of foutmeldingen genereert. In dat laatste geval zal de melding waarschijnlijk bij de servicedesk terecht komen en dan is het maar zeer de vraag of zij support kunnen en willen leveren.
Kortom: kansen zijn aanwezig, maar het gebruik van code door ’trader-coders’ dient wel gedragen en ondersteund te worden binnen de gehele organisatie om de risico’s te beperken.
David Atkins is business change consultant. Hij blogt voornamelijk over aangelegenheden in de financiële sector.
