I denne artikel vil jeg introducere dig til nogle af de grundlæggende begreber, der ledsager et kvantitativt handelssystem fra ende til anden. Dette indlæg vil forhåbentlig tjene to målgrupper. Den første vil være personer, der forsøger at få et job i en fond som kvantitativ erhvervsdrivende. Det andet vil være personer, der ønsker at forsøge at oprette deres egen “detail” algoritmiske handelsvirksomhed.
Kvantitativ handel er et ekstremt sofistikeret område inden for kvantefinansiering. Det kan tage lang tid at få den nødvendige viden til at bestå en samtale eller konstruere sine egne handelsstrategier. Ikke alene det, men det kræver også omfattende ekspertise inden for programmering, i det mindste i et sprog som MATLAB, R eller Python. Men efterhånden som handelsfrekvensen af strategien stiger, bliver de teknologiske aspekter meget mere relevante. Derfor vil det være af afgørende betydning at være fortrolig med C/C++.
Et kvantitativt handelssystem består af fire hovedkomponenter:
- Strategiidentifikation – Findelse af en strategi, udnyttelse af en fordel og beslutning om handelsfrekvens
- Backtesting af strategien – Fremskaffelse af data, analyse af strategiens ydeevne og fjernelse af skævheder
- Udførelsessystem – Tilknytning til et børsmæglerselskab, automatisering af handlen og minimering af transaktionsomkostninger
- Risikostyring – Optimal kapitalallokering, “bet size”/Kelly-kriteriet og handelspsykologi
Vi vil begynde med at se på, hvordan man identificerer en handelsstrategi.
Strategiidentifikation
Alle kvantitative handelsprocesser begynder med en indledende periode med research. Denne forskningsproces omfatter at finde en strategi, se, om strategien passer ind i en portefølje af andre strategier, du måske kører, indhente alle nødvendige data til at teste strategien og forsøge at optimere strategien for at opnå højere afkast og/eller lavere risiko. Du skal tage højde for dit eget kapitalbehov, hvis du kører strategien som “detail”-handler, og hvordan eventuelle transaktionsomkostninger vil påvirke strategien.
I modsætning til hvad mange tror, er det faktisk ret ligetil at finde rentable strategier gennem forskellige offentlige kilder. Akademikere offentliggør regelmæssigt teoretiske handelsresultater (om end for det meste brutto af transaktionsomkostninger). Kvantitative finansblogs vil diskutere strategier i detaljer. Fagblade vil beskrive nogle af de strategier, der anvendes af fonde.
Man kan spørge sig selv, hvorfor enkeltpersoner og virksomheder er ivrige efter at diskutere deres rentable strategier, især når de ved, at andre “crowding the trade” kan forhindre strategien i at fungere på lang sigt. Årsagen ligger i, at de ofte ikke vil diskutere de nøjagtige parametre og afstemningsmetoder, som de har udført. Disse optimeringer er nøglen til at forvandle en relativt middelmådig strategi til en yderst rentabel strategi. Faktisk er en af de bedste måder at skabe sine egne unikke strategier på at finde lignende metoder og derefter gennemføre sin egen optimeringsprocedure.
Her er en lille liste over steder, hvor man kan begynde at lede efter ideer til strategier:
- 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
Mange af de strategier, du vil se på, vil falde ind under kategorierne mean-reversion og trend-following/momentum. En mean-reverting-strategi er en strategi, der forsøger at udnytte det faktum, at der findes en langsigtet middelværdi på en “prisserie” (som f.eks. spredningen mellem to korrelerede aktiver), og at kortsigtede afvigelser fra denne middelværdi til sidst vil vende tilbage. En momentumstrategi forsøger at udnytte både investorpsykologi og store fondes struktur ved at “hoppe med på en markedstrend”, som kan samle momentum i én retning, og følge trenden, indtil den vender.
Et andet enormt vigtigt aspekt af kvantitativ handel er handelsstrategiens frekvens. Lavfrekvenshandel (LFT) henviser generelt til enhver strategi, der holder aktiver længere end en handelsdag. Tilsvarende henviser højfrekvenshandel (HFT) generelt til en strategi, der holder aktiver intradag. Ultrahøjfrekvent handel (UHFT) henviser til strategier, der holder aktiver i sekunders og millisekunders størrelsesorden. Som detailhandler er HFT og UHFT bestemt muligt, men kun med detaljeret kendskab til handelens “teknologiske stak” og ordrebogsdynamikken. Vi vil ikke diskutere disse aspekter i større omfang i denne indledende artikel.
Når en strategi, eller et sæt strategier, er blevet identificeret, skal den nu testes for rentabilitet på historiske data. Det er backtestingens domæne.
Strategy Backtesting
Målet med backtesting er at give bevis for, at den strategi, der er identificeret via ovenstående proces, er rentabel, når den anvendes på både historiske og out-of-sample data. Dette skaber en forventning om, hvordan strategien vil fungere i den “virkelige verden”. Backtesting er imidlertid af forskellige årsager IKKE en garanti for succes. Det er måske det mest subtile område inden for kvantitativ handel, da det indebærer adskillige bias, som skal overvejes nøje og elimineres så meget som muligt. Vi vil diskutere de almindelige typer af bias, herunder look-ahead bias, survivorship bias og optimeringsbias (også kendt som “data-snooping” bias). Andre områder af betydning inden for backtesting omfatter tilgængelighed og renhed af historiske data, indregning af realistiske transaktionsomkostninger og valg af en robust backtesting-platform. Vi vil diskutere transaktionsomkostninger yderligere i afsnittet om eksekveringssystemer nedenfor.
Når en strategi er blevet identificeret, er det nødvendigt at fremskaffe de historiske data, gennem hvilke man kan udføre testning og måske forfining. Der findes et betydeligt antal dataleverandører på tværs af alle aktivklasser. Deres omkostninger stiger generelt med dataenes kvalitet, dybde og aktualitet. Det traditionelle udgangspunkt for begyndende kvantehandlere (i det mindste på detailniveau) er at bruge det gratis datasæt fra Yahoo Finance. Jeg vil ikke dvæle for meget ved udbyderne her, men snarere koncentrere mig om de generelle problemer, når man beskæftiger sig med historiske datasæt.
De vigtigste problemer med historiske data omfatter nøjagtighed/renhed, survivorship bias og justering for corporate actions såsom udbytte og aktiesplits:
- Nøjagtighed vedrører den overordnede kvalitet af dataene – om de indeholder nogen fejl. Fejl kan nogle gange være lette at identificere, f.eks. med et spike-filter, som udvælger ukorrekte “spikes” i tidsseriedata og korrigerer for dem. Andre gange kan de være meget svære at opdage. Det er ofte nødvendigt at have to eller flere udbydere og derefter kontrollere alle deres data i forhold til hinanden.
- Overlevelsesbias er ofte et “træk” ved gratis eller billige datasæt. Et datasæt med survivorship bias betyder, at det ikke indeholder aktiver, som ikke længere handles. I forbindelse med aktier betyder det, at aktierne er afnoteret/konkursramte. Denne bias betyder, at enhver aktiehandelsstrategi, der testes på et sådant datasæt, sandsynligvis vil præstere bedre end i den “virkelige verden”, da de historiske “vindere” allerede er blevet forhåndsudvalgt.
- Selskabshandlinger omfatter “logistiske” aktiviteter, der udføres af virksomheden, og som normalt forårsager en trinvis ændring i råprisen, der ikke bør indgå i beregningen af kursens afkast. Justeringer for udbytte og aktiesplits er de almindelige syndere. Det er nødvendigt at foretage en proces, der kaldes “back adjustment”, ved hver af disse handlinger. Man skal være meget forsigtig med ikke at forveksle et aktiesplit med en egentlig afkastjustering. Mange erhvervsdrivende er blevet taget ved næsen af en corporate action!
For at kunne gennemføre en backtest-procedure er det nødvendigt at bruge en softwareplatform. Du har valget mellem dedikeret backtest-software, såsom Tradestation, en numerisk platform såsom Excel eller MATLAB eller en fuldstændig tilpasset implementering i et programmeringssprog såsom Python eller C++. Jeg vil ikke dvæle for meget ved Tradestation (eller lignende), Excel eller MATLAB, da jeg tror på at skabe en fuld in-house teknologistak (af grunde, der er skitseret nedenfor). En af fordelene ved at gøre dette er, at backtest-softwaren og eksekveringssystemet kan være tæt integreret, selv med ekstremt avancerede statistiske strategier. Især for HFT-strategier er det vigtigt at anvende en tilpasset implementering.
Når man backtester et system, skal man være i stand til at kvantificere, hvor godt det præsterer. “Industriens standardmetrikker” for kvantitative strategier er det maksimale drawdown og Sharpe-ratio. Det maksimale drawdown karakteriserer det største fald fra top til lavpunkt i kontoens egenkapitalkurve over en bestemt tidsperiode (normalt årligt). Dette angives oftest som en procentdel. LFT-strategier vil have en tendens til at have større drawdowns end HFT-strategier på grund af en række statistiske faktorer. En historisk backtest vil vise det tidligere maksimale drawdown, hvilket er en god rettesnor for strategiens fremtidige drawdown-præstationer. Den anden måling er Sharpe-ratio, som heuristisk er defineret som gennemsnittet af merafkastet divideret med standardafvigelsen af dette merafkast. Her henviser merafkastet til strategiens afkast over et forudbestemt benchmark, f.eks. S&P500 eller en 3-måneders statsobligation. Bemærk, at annualiseret afkast ikke er et mål, der normalt anvendes, da det ikke tager højde for strategiens volatilitet (i modsætning til Sharpe-ratio).
Når en strategi er blevet backtestet og anses for at være fri for bias (i det omfang, det er muligt!), med en god Sharpe-værdi og minimerede drawdowns, er det tid til at opbygge et eksekveringssystem.
Eksekveringssystemer
Et eksekveringssystem er det middel, hvormed listen over handler, der genereres af strategien, sendes og eksekveres af mægleren. På trods af at handelsgenereringen kan være halv- eller endog fuldautomatisk, kan udførelsesmekanismen være manuel, halvmanuel (dvs. “et klik”) eller fuldautomatisk. For LFT-strategier er manuelle og halvmanuelle teknikker almindelige. For HFT-strategier er det nødvendigt at skabe en fuldt automatiseret eksekveringsmekanisme, som ofte vil være tæt koblet til handelsgeneratoren (på grund af den indbyrdes afhængighed mellem strategi og teknologi).
De vigtigste overvejelser, når der skabes et eksekveringssystem, er grænsefladen til mæglerfirmaet, minimering af transaktionsomkostninger (herunder provision, slippage og spread) og afvigelse mellem live-systemets præstationer og backtestede præstationer.
Der er mange måder at skabe en grænseflade til et mæglerfirma. De spænder fra at ringe til din mægler i telefonen helt til en fuldt automatiseret højtydende Application Programming Interface (API) med høj ydeevne. Ideelt set ønsker du at automatisere udførelsen af dine handler så meget som muligt. Dette frigør dig til at koncentrere dig om yderligere forskning, ligesom det giver dig mulighed for at køre flere strategier eller endda strategier med højere frekvens (faktisk er HFT stort set umuligt uden automatiseret udførelse). Den almindelige backtesting-software, der er skitseret ovenfor, såsom MATLAB, Excel og Tradestation, er god til lavere frekvens og enklere strategier. Det vil imidlertid være nødvendigt at konstruere et internt eksekveringssystem, der er skrevet i et højtydende sprog som C++, for at kunne udføre reel HFT. Som en anekdote kan nævnes, at vi i den fond, jeg tidligere var ansat i, havde et 10-minutters “trading loop”, hvor vi hentede nye markedsdata hvert 10. minut og derefter udførte handler på grundlag af disse oplysninger inden for samme tidsramme. Dette foregik ved hjælp af et optimeret Python-script. Til noget, der nærmer sig data med minut- eller sekundfrekvens, tror jeg, at C/C++ ville være mere ideelt.
I en større fond er det ofte ikke kvantehandlerens domæne at optimere udførelsen. Men i mindre forretninger eller HFT-firmaer ER forhandlerne udførerne, og derfor er det ofte ønskeligt med et meget bredere sæt af færdigheder. Husk det, hvis du ønsker at blive ansat i en fond. Dine programmeringsfærdigheder vil være lige så vigtige, hvis ikke vigtigere, end dine talenter inden for statistik og økonometri!
Et andet vigtigt spørgsmål, der falder ind under banneret om udførelse, er minimering af transaktionsomkostningerne. Der er generelt tre komponenter i transaktionsomkostningerne: Provisioner (eller skat), som er de gebyrer, der opkræves af mæglerfirmaet, børsen og SEC (eller lignende statslige tilsynsorganer); slippage, som er forskellen mellem det, som du havde til hensigt at udføre din ordre til, og det, som den faktisk blev udført til; spread, som er forskellen mellem bud- og salgsprisen på det værdipapir, der handles. Bemærk, at spreadet IKKE er konstant og afhænger af den aktuelle likviditet (dvs. tilgængeligheden af købs-/salgsordrer) på markedet.
Transaktionsomkostninger kan gøre forskellen mellem en ekstremt profitabel strategi med en god Sharpe-ratio og en ekstremt urentabel strategi med en forfærdelig Sharpe-ratio. Det kan være en udfordring at forudsige transaktionsomkostningerne korrekt ud fra en backtest. Afhængigt af frekvensen af strategien skal du have adgang til historiske børsdata, som vil omfatte tick-data for bid/ask-priser. Hele hold af kvantefolk er af disse grunde dedikeret til optimering af udførelsen i de større fonde. Tænk på et scenarie, hvor en fond har brug for at afvikle en betydelig mængde handler (og grundene hertil er mange og forskelligartede!). Ved at “dumpe” så mange aktier på markedet vil de hurtigt presse prisen og måske ikke opnå optimal udførelse. Derfor findes der algoritmer, som “drypper” ordrer ind på markedet, selv om fonden så løber en risiko for “slippage”. Desuden er der andre strategier, der “udnytter” disse nødvendigheder og kan udnytte ineffektiviteten. Dette er området for fondsstrukturarbitrage.
Det sidste store problem for udførelsessystemer vedrører afvigelser i strategiens præstationer fra de backtestede præstationer. Dette kan ske af en række årsager. Vi har allerede diskuteret look-ahead bias og optimeringsbias i dybden, når vi ser på backtests. Nogle strategier gør det imidlertid ikke let at teste for disse bias forud for implementering. Dette forekommer mest overvejende i HFT. Der kan være fejl i eksekveringssystemet såvel som i selve handelsstrategien, som ikke viser sig på en backtest, men som VIRKELIG viser sig i livehandel. Markedet kan have været udsat for et regimeskifte efter implementeringen af din strategi. Nye reguleringsmiljøer, ændrede investorstemninger og makroøkonomiske fænomener kan alle føre til afvigelser i den måde, markedet opfører sig på, og dermed i din strategis rentabilitet.
Risikostyring
Den sidste brik i det kvantitative handelspuslespil er processen med risikostyring. “Risiko” omfatter alle de tidligere skævheder, som vi har diskuteret. Den omfatter teknologirisiko, f.eks. at servere, der er co-placeret på børsen, pludselig udvikler en fejl på harddisken. Det omfatter mæglerrisiko, f.eks. at mægleren går konkurs (ikke så tosset, som det lyder, når man tænker på den seneste skræk med MF Global!). Kort sagt dækker den næsten alt, der kan forstyrre handelsimplementeringen, og der er mange kilder hertil. Hele bøger er afsat til risikostyring for kvantitative strategier, så jeg vil ikke forsøge at belyse alle mulige risikokilder her.
Risikostyring omfatter også det, der kaldes optimal kapitalallokering, som er en gren af porteføljeteorien. Det er den måde, hvorpå kapital allokeres til et sæt af forskellige strategier og til handlerne inden for disse strategier. Det er et komplekst område og er baseret på en del ikke-triviel matematik. Den branchestandard, hvormed optimal kapitalallokering og strategiernes gearingsgrad er relateret, kaldes Kelly-kriteriet. Da dette er en introducerende artikel, vil jeg ikke dvæle ved beregningen heraf. Kelly-kriteriet gør nogle antagelser om afkastenes statistiske karakter, som ikke ofte holder stik på de finansielle markeder, så de erhvervsdrivende er ofte konservative, når det gælder gennemførelsen.
En anden vigtig komponent i risikostyring er at håndtere ens egen psykologiske profil. Der er mange kognitive skævheder, der kan snige sig ind på handel. Selv om dette ganske vist er mindre problematisk med algoritmisk handel, hvis man lader strategien være i fred! En almindelig bias er tabsaversion, hvor en tabende position ikke lukkes på grund af smerten ved at skulle realisere et tab. På samme måde kan overskud tages for tidligt, fordi frygten for at miste et allerede opnået overskud kan være for stor. En anden almindelig bias er kendt som “recency bias”. Dette viser sig, når handlende lægger for stor vægt på de seneste begivenheder og ikke på det længere sigt. Så er der naturligvis det klassiske par af følelsesmæssige skævheder – frygt og grådighed. Disse kan ofte føre til under- eller overbelåning, hvilket kan medføre blow-up (dvs. at kontoens egenkapital går mod nul eller værre!) eller reduceret overskud.
Summarum
Som det fremgår, er kvantitativ handel et yderst komplekst, om end meget interessant, område inden for kvantitativ finansiering. Jeg har bogstaveligt talt skrabet på overfladen af emnet i denne artikel, og den er allerede ved at være temmelig lang! Der er blevet skrevet hele bøger og artikler om emner, som jeg kun har givet en sætning eller to til. Derfor er det nødvendigt at foretage et betydeligt grundarbejde, før man søger job inden for kvantitativ fondshandel, før man søger job inden for kvantitativ fondshandel. Som minimum har du brug for en omfattende baggrund inden for statistik og økonometri med stor erfaring med implementering via et programmeringssprog som MATLAB, Python eller R. For mere sofistikerede strategier i den højere frekvenser ende vil dine færdigheder sandsynligvis omfatte Linux-kernemodifikation, C/C++, assemblerprogrammering og optimering af netværkslatenscyklus.
Hvis du er interesseret i at forsøge at skabe dine egne algoritmiske handelsstrategier, vil mit første forslag være at blive god til at programmere. Min præference er at bygge så meget af data grabber, strategi backtester og eksekveringssystem selv som muligt. Hvis din egen kapital er på spil, ville du så ikke sove bedre om natten, når du ved, at du har testet dit system fuldt ud og er klar over dets faldgruber og særlige problemer? Udlicitering af dette til en leverandør kan, selv om det potentielt sparer tid på kort sigt, være ekstremt dyrt på lang sigt.