Nybörjarguide till kvantitativ handel

I den här artikeln kommer jag att presentera några av de grundläggande begrepp som följer med ett heltäckande kvantitativt handelssystem. Det här inlägget kommer förhoppningsvis att tjäna två målgrupper. Den första kommer att vara personer som försöker få ett jobb på en fond som kvantitativ handlare. Den andra kommer att vara personer som vill försöka starta sin egen ”detaljhandelsverksamhet” för algoritmisk handel.

Kvantitativ handel är ett extremt sofistikerat område inom kvantfinans. Det kan ta lång tid att skaffa sig de kunskaper som krävs för att klara en intervju eller konstruera egna handelsstrategier. Inte bara det, utan det kräver också omfattande kunskaper i programmering, åtminstone i ett språk som MATLAB, R eller Python. Men i takt med att handelsfrekvensen för strategin ökar blir de tekniska aspekterna mycket mer relevanta. Att vara bekant med C/C++ kommer därför att vara av yttersta vikt.

Ett kvantitativt handelssystem består av fyra huvudkomponenter:

  • Strategiidentifiering – Hitta en strategi, utnyttja en fördel och besluta om handelsfrekvens
  • Strategi Backtesting – Skaffa data, analysera strategins prestanda och ta bort fördomar
  • Exekveringssystem – Länka till ett mäklarföretag, automatisera handeln och minimera transaktionskostnaderna
  • Riskhantering – Optimal kapitalallokering, ”bet size”/Kelly-kriteriet och handelspsykologi

Vi börjar med att ta en titt på hur man identifierar en handelsstrategi.

Strategiidentifiering

Alla kvantitativa handelsprocesser börjar med en inledande period av forskning. Denna forskningsprocess omfattar att hitta en strategi, se om strategin passar in i en portfölj med andra strategier som du kanske använder, skaffa alla data som behövs för att testa strategin och försöka optimera strategin för högre avkastning och/eller lägre risk. Du måste ta hänsyn till dina egna kapitalkrav om du driver strategin som en ”privat” handlare och hur eventuella transaktionskostnader kommer att påverka strategin.

I motsats till vad många tror är det faktiskt ganska enkelt att hitta lönsamma strategier genom olika offentliga källor. Akademiker publicerar regelbundet teoretiska handelsresultat (om än oftast brutto av transaktionskostnader). Kvantitativa finansbloggar diskuterar strategier i detalj. Facktidskrifter kommer att beskriva några av de strategier som används av fonder.

Man kan fråga sig varför enskilda personer och företag är angelägna om att diskutera sina lönsamma strategier, särskilt när de vet att andra som ”tränger sig in i handeln” kan hindra strategin från att fungera på lång sikt. Anledningen ligger i att de ofta inte kommer att diskutera de exakta parametrar och inställningsmetoder som de har utfört. Dessa optimeringar är nyckeln till att förvandla en relativt medioker strategi till en mycket lönsam strategi. Faktum är att ett av de bästa sätten att skapa egna unika strategier är att hitta liknande metoder och sedan genomföra ett eget optimeringsförfarande.

Här är en liten lista över ställen där man kan börja leta efter strategiidéer:

  • Social Science Research Network – www.ssrn.com
  • arXiv Quantitative Finance – arxiv.org/archive/q-fin
  • Seeking Alpha – www.seekingalpha.com
  • Elite Trader – www.elitetrader.com
  • Nuclear Phynance – www.nuclearphynance.com
  • Quantivity – quantivity.wordpress.com

Många av strategierna som du kommer att titta på kommer att falla in i kategorierna medelvärdesomvändning och trendföljning/momentum. En medelvärdesvändningsstrategi är en strategi som försöker utnyttja det faktum att det finns ett långsiktigt medelvärde på en ”prisserie” (t.ex. spridningen mellan två korrelerade tillgångar) och att kortsiktiga avvikelser från detta medelvärde så småningom kommer att vända tillbaka. En momentumstrategi försöker utnyttja både investerarpsykologi och stora fondstrukturer genom att ”lifta med” på en marknadstrend, som kan samla momentum i en riktning, och följa trenden tills den vänder.

En annan oerhört viktig aspekt av kvantitativ handel är frekvensen av handelsstrategin. Lågfrekvenshandel (LFT) hänvisar i allmänhet till alla strategier som håller tillgångar längre än en handelsdag. På motsvarande sätt hänvisar högfrekvenshandel (HFT) i allmänhet till en strategi som innehar tillgångar intradag. Ultrahögfrekvent handel (UHFT) avser strategier som innehar tillgångar i storleksordningen sekunder och millisekunder. Som detaljhandlare är HFT och UHFT säkert möjliga, men endast med detaljerad kunskap om handelns ”tekniska stapel” och dynamiken i orderboken. Vi kommer inte att diskutera dessa aspekter i någon större utsträckning i denna inledande artikel.

När en strategi, eller en uppsättning strategier, har identifierats måste den nu testas för lönsamhet på historiska data. Detta är domänen för backtesting.

Strategy Backtesting

Målet med backtesting är att ge bevis för att den strategi som identifierats via ovanstående process är lönsam när den tillämpas på både historiska och out-of-sample data. Detta skapar förväntningar på hur strategin kommer att prestera i den ”verkliga världen”. Backtesting är dock INTE en garanti för framgång, av olika skäl. Det är kanske det mest subtila området inom kvantitativ handel eftersom det innebär många bias, som måste övervägas noggrant och elimineras så mycket som möjligt. Vi kommer att diskutera de vanligaste typerna av bias, inklusive look-ahead bias, survivorship bias och optimeringsbias (även känd som ”data-snooping” bias). Andra områden som är viktiga inom backtesting är tillgänglighet och renhet hos historiska data, att ta hänsyn till realistiska transaktionskostnader och att bestämma sig för en robust backtestingplattform. Vi kommer att diskutera transaktionskostnader ytterligare i avsnittet Execution Systems nedan.

När en strategi har identifierats är det nödvändigt att få fram historiska data genom vilka man kan utföra testning och, kanske, förfining. Det finns ett betydande antal dataförsäljare inom alla tillgångsklasser. Deras kostnader skalar i allmänhet med datakvaliteten, -djupet och -aktualiteten. Den traditionella utgångspunkten för nybörjarkvanthandlare (åtminstone på detaljhandelsnivå) är att använda den kostnadsfria datamängden från Yahoo Finance. Jag kommer inte att uppehålla mig alltför mycket vid leverantörerna här, utan jag vill hellre koncentrera mig på de allmänna frågorna när man hanterar historiska datamängder.

De viktigaste frågorna när det gäller historiska data är noggrannhet/renlighet, överlevnadsbias och justering för företagsåtgärder som utdelningar och aktiesplittringar:

  • Noggrannhet avser den övergripande kvaliteten på data – om de innehåller några fel. Fel kan ibland vara lätta att identifiera, t.ex. med ett spikfilter, som väljer ut felaktiga ”spikar” i tidsseriedata och korrigerar för dem. Vid andra tillfällen kan de vara mycket svåra att upptäcka. Det är ofta nödvändigt att ha två eller flera leverantörer och sedan kontrollera alla deras uppgifter mot varandra.
  • Överlevnadsbias är ofta en ”egenskap” hos gratis eller billiga dataset. En datamängd med survivorship bias innebär att den inte innehåller tillgångar som inte längre handlas. När det gäller aktier innebär detta avnoterade/konkursade aktier. Denna bias innebär att alla aktiehandelsstrategier som testas på ett sådant dataset sannolikt kommer att prestera bättre än i den ”verkliga världen” eftersom de historiska ”vinnarna” redan har valts ut på förhand.
  • Företagsåtgärder omfattar ”logistiska” aktiviteter som utförs av företaget och som vanligen orsakar en steg-funktionsförändring i råpriset, som inte bör inkluderas i beräkningen av avkastningen av priset. Justeringar för utdelningar och aktieuppdelningar är de vanligaste bovarna. En process som kallas back adjustment är nödvändig att genomföra vid var och en av dessa åtgärder. Man måste vara mycket försiktig så att man inte förväxlar en aktiesplit med en riktig avkastningsjustering. Många näringsidkare har blivit tagna på sängen av en bolagsaktion!

För att genomföra ett backtestförfarande är det nödvändigt att använda en mjukvaruplattform. Du kan välja mellan en dedikerad backtestprogramvara, t.ex. Tradestation, en numerisk plattform, t.ex. Excel eller MATLAB, eller ett fullständigt anpassat genomförande i ett programmeringsspråk, t.ex. Python eller C++. Jag kommer inte att uppehålla mig alltför mycket vid Tradestation (eller liknande), Excel eller MATLAB, eftersom jag tror på att skapa en fullständig intern teknikstack (av skäl som beskrivs nedan). En av fördelarna med att göra detta är att backtestprogramvaran och exekveringssystemet kan vara tätt integrerade, även med extremt avancerade statistiska strategier. Särskilt för HFT-strategier är det viktigt att använda en anpassad implementering.

När man backtestar ett system måste man kunna kvantifiera hur bra det presterar. De ”branschstandardiserade” mätvärdena för kvantitativa strategier är maximal drawdown och Sharpe Ratio. Den maximala drawdown karakteriserar den största nedgången från topp till dal i kontots aktiekurva under en viss tidsperiod (vanligtvis årligen). Detta anges oftast i procent. LFT-strategier tenderar att ha större drawdowns än HFT-strategier på grund av ett antal statistiska faktorer. Ett historiskt backtest kommer att visa den tidigare maximala drawdownen, vilket är en bra vägledning för strategins framtida drawdownprestanda. Det andra måttet är Sharpe-kvoten, som heuristiskt definieras som genomsnittet av överavkastningen dividerat med standardavvikelsen för denna överavkastning. Med överavkastning avses här strategins avkastning över ett förutbestämt riktmärke, t.ex. S&P500 eller en 3-månaders statsskuldväxel. Observera att årlig avkastning inte är ett mått som vanligtvis används, eftersom det inte tar hänsyn till strategins volatilitet (till skillnad från Sharpe-kvoten).

När en strategi har backtestats och anses vara fri från bias (i den mån det är möjligt!), med en bra Sharpe och minimerade drawdowns, är det dags att bygga ett exekveringssystem.

Exekveringssystem

Ett exekveringssystem är det sätt på vilket listan över affärer som genereras av strategin skickas och exekveras av mäklaren. Trots att handelsgenereringen kan vara halv- eller till och med helautomatisk, kan utförandemekanismen vara manuell, halvmanuell (dvs. ”ett klick”) eller helautomatisk. För LFT-strategier är manuella och halvmanuella tekniker vanliga. För HFT-strategier är det nödvändigt att skapa en helautomatisk utförandemekanism, som ofta kommer att vara tätt sammankopplad med handelsgeneratorn (på grund av det ömsesidiga beroendet mellan strategi och teknik).

De viktigaste övervägandena vid skapandet av ett utförandesystem är gränssnittet till mäklarföretaget, minimering av transaktionskostnader (inklusive provision, slippage och spread) och avvikelse mellan live-systemets prestanda och den backtestade prestandan.

Det finns många sätt att skapa gränssnitt till ett mäklarföretag. De sträcker sig från att ringa upp din mäklare på telefon till ett helautomatiserat högpresterande Application Programming Interface (API). Helst vill du automatisera utförandet av dina affärer så mycket som möjligt. Detta gör att du kan koncentrera dig på ytterligare forskning och att du kan köra flera strategier eller till och med strategier med högre frekvens (i själva verket är HFT i princip omöjligt utan automatiserat utförande). De vanliga backtestingprogrammen som beskrivs ovan, t.ex. MATLAB, Excel och Tradestation, är bra för enklare strategier med lägre frekvens. Det kommer dock att bli nödvändigt att konstruera ett internt system för utförande som är skrivet i ett högpresterande språk som C++ för att man skall kunna göra någon riktig HFT. Som en anekdot kan jag nämna att vi i den fond där jag tidigare var anställd hade en 10-minuters ”handelsslinga” där vi hämtade nya marknadsdata var tionde minut och sedan utförde affärer baserade på denna information inom samma tidsram. Detta skedde med hjälp av ett optimerat Python-skript. För något som närmar sig minut- eller sekundfrekvensdata tror jag att C/C++ skulle vara mer idealiskt.

I en större fond är det ofta inte kvanthandlarens domän att optimera utförandet. I mindre butiker eller HFT-företag är det dock handlarna som är utförarna och därför är det ofta önskvärt med en mycket bredare uppsättning färdigheter. Tänk på detta om du vill bli anställd av en fond. Dina programmeringskunskaper kommer att vara lika viktiga, om inte viktigare, än dina talanger inom statistik och ekonometri!

En annan viktig fråga som faller under begreppet utförande är minimering av transaktionskostnader. Det finns i allmänhet tre komponenter i transaktionskostnaderna: Provisioner (eller skatt), som är de avgifter som tas ut av mäklarfirman, börsen och SEC (eller liknande statliga tillsynsmyndigheter), glidning, som är skillnaden mellan vad du hade tänkt att din order skulle fyllas till och vad den faktiskt fylldes till, och spread, som är skillnaden mellan köp- och säljpriset för det värdepapper som handlas. Observera att spreaden INTE är konstant och är beroende av den aktuella likviditeten (dvs. tillgången på köp/säljorder) på marknaden.

Transaktionskostnader kan göra skillnaden mellan en extremt lönsam strategi med ett bra Sharpe-förhållande och en extremt olönsam strategi med ett fruktansvärt Sharpe-förhållande. Det kan vara en utmaning att korrekt förutsäga transaktionskostnader från ett backtest. Beroende på strategins frekvens behöver du tillgång till historiska börsdata, vilket inkluderar tickdata för köp- och säljpriser. Hela team av kvantforskare ägnar sig åt optimering av utförandet i de större fonderna, av dessa skäl. Tänk på ett scenario där en fond behöver avyttra en stor mängd affärer (skälen till att göra det är många och varierande!). Genom att ”dumpa” så många andelar på marknaden kommer de snabbt att sänka priset och kanske inte få ett optimalt utförande. Därför finns det algoritmer som ”droppmatar” order på marknaden, även om fonden då löper en risk att det blir en ”slippage”. Dessutom finns det andra strategier som ”utnyttjar” dessa nödvändigheter och kan utnyttja ineffektiviteten. Detta är området för fondstrukturarbitrage.

Den sista stora frågan för utförandesystem gäller avvikelser mellan strategins prestanda och den backtestade prestandan. Detta kan ske av ett antal skäl. Vi har redan diskuterat look-ahead bias och optimeringsbias på djupet när vi betraktar backtests. Vissa strategier gör det dock inte lätt att testa för dessa bias före driftsättning. Detta förekommer främst inom HFT. Det kan finnas buggar i exekveringssystemet såväl som i själva handelsstrategin som inte syns på ett backtest men som DÅ syns i livehandel. Marknaden kan ha genomgått ett regimskifte efter det att din strategi har införts. Nya regleringsmiljöer, förändrat investerarsentiment och makroekonomiska fenomen kan alla leda till avvikelser i hur marknaden beter sig och därmed i din strategis lönsamhet.

Riskhantering

Den sista pusselbiten i den kvantitativa handeln är riskhanteringen. ”Risk” innefattar alla de tidigare bias som vi har diskuterat. Den omfattar teknisk risk, t.ex. att servrar som är samlokaliserade på börsen plötsligt utvecklar ett fel på hårddisken. Det inbegriper mäklarrisker, t.ex. att mäklaren går i konkurs (inte så tokigt som det låter, med tanke på den senaste skräcken med MF Global!) Kort sagt täcker det nästan allt som kan tänkas störa handelsgenomförandet, vilket det finns många källor till. Hela böcker ägnas åt riskhantering för kvantitativa strategier, så jag kommer inte att försöka belysa alla möjliga riskkällor här.

Riskhantering omfattar också det som kallas optimal kapitalallokering, som är en gren av portföljteorin. Detta är det sätt på vilket kapitalet allokeras till en uppsättning olika strategier och till affärerna inom dessa strategier. Det är ett komplext område och bygger på en del icke-trivial matematik. Den branschstandard genom vilken optimal kapitalallokering och strategiernas hävstångseffekt är relaterade kallas Kelly-kriteriet. Eftersom detta är en introduktionsartikel kommer jag inte att uppehålla mig vid dess beräkning. Kelly-kriteriet gör vissa antaganden om avkastningens statistiska natur, vilket inte ofta stämmer på finansmarknaderna, så näringsidkare är ofta konservativa när det gäller genomförandet.

En annan viktig del av riskhanteringen är att hantera sin egen psykologiska profil. Det finns många kognitiva fördomar som kan smyga sig in i handeln. Även om detta visserligen är mindre problematiskt med algoritmisk handel om strategin lämnas i fred! En vanlig bias är förlustaversion, där en förlorande position inte avslutas på grund av smärtan av att behöva realisera en förlust. På samma sätt kan vinster tas för tidigt eftersom rädslan för att förlora en redan vunnen vinst kan vara för stor. En annan vanlig bias är den så kallade recency bias. Detta visar sig när handlare lägger för stor vikt vid nyligen inträffade händelser och inte vid det långsiktiga perspektivet. Sedan finns det naturligtvis det klassiska paret av känslomässiga bias – rädsla och girighet. Dessa kan ofta leda till under- eller överbelåning, vilket kan orsaka en sprängning (dvs. att kontots eget kapital går mot noll eller värre!) eller minskad vinst.

Sammanfattning

Som framgår är kvantitativ handel ett ytterst komplext, om än mycket intressant, område inom den kvantitativa finansvärlden. Jag har bokstavligen skrapat på ytan av ämnet i den här artikeln och den börjar redan bli ganska lång! Hela böcker och artiklar har skrivits om frågor som jag bara har gett en mening eller två till. Innan man söker jobb inom kvantitativ fondhandel är det därför nödvändigt att göra en betydande mängd grundstudier innan man söker jobb inom kvantitativ fondhandel. Du behöver åtminstone en omfattande bakgrund inom statistik och ekonometri, med stor erfarenhet av genomförande, via ett programmeringsspråk som MATLAB, Python eller R. För mer sofistikerade strategier i den högre frekvensen kommer dina färdigheter troligen att innefatta modifiering av Linuxkärnan, C/C++, assemblerprogrammering och optimering av nätverkslatens.

Om du är intresserad av att försöka skapa egna algoritmiska handelsstrategier, skulle mitt första förslag vara att du blir bra på att programmera. Min preferens är att bygga så mycket som möjligt av datagriparen, strategins backtester och exekveringssystemet själv. Om ditt eget kapital står på spel, skulle du då inte sova bättre på natten i vetskap om att du har testat ditt system till fullo och är medveten om dess fallgropar och särskilda problem? Att lägga ut detta på en leverantör kan visserligen spara tid på kort sikt, men kan bli extremt dyrt på lång sikt.

Lämna ett svar

Din e-postadress kommer inte publiceras.