Backtest opcij se lahko spremeni, ne da bi spremenili eno samo vrstico kode strategije. Ponudnik popravi napačno kotacijo, doda pozno sklenjen posel, spremeni metapodatke pogodbe ali spremeni filter za prekrižane trge. Znova zaženemo iste datume in dobimo drugačno izvršitev, drugačno pozicijo, morda drugačen Sharpe. To ni nujno napaka v strategiji. Spremenili so se podatki, na podlagi katerih smo strategijo testirali.
Da bo backtest opcij ponovljiv, tržne podatke obravnavajmo kot različico vhodnih podatkov. Zabeležimo uporabljeni posnetek, ohranimo surova opazovanja, ki so vplivala na vsako odločitev, in preden zaupamo novemu skupnemu rezultatu, primerjajmo spremembe na ravni pogodb in časovnih žigov.
Zakaj se je moj backtest opcij spremenil, čeprav je koda ostala enaka?
Zapisi o opcijah so zaradi popravkov še posebej občutljivi, saj je navidezna možnost trgovanja s pogodbo odvisna od več polj, ki se spreminjajo skupaj: nakupne in prodajne cene, količine, cene osnovnega instrumenta, datuma zapadlosti, izvršilne cene ter množitelja ali predmeta izročitve pogodbe. Popravljena kotacija lahko navidezno priložnost spremeni v prekrižan trg. Popravek metapodatkov lahko spremeni pomen množitelja pri poziciji.
Predstavljajmo si strategijo, ki kupi nakupno opcijo, ko je prodajna cena pod $2.00. Ob prvem nalaganju podatkov je prodajna cena kotacije ob 10:14 $1.95, nakupna cena $1.90, količina pa 5. Poznejši popravek ponudnika spremeni prodajno ceno na $2.05, ko ta uskladi zakasnjeno sporočilo borze. En sam podatek spremeni signal. Če je bila ta pogodba edini posel strategije tisti dan, lahko že majhen popravek podatkov prevlada nad donosom celotnega dne.
Pomembno je tudi filtriranje kotacij. Ponudniki lahko odstranijo zastarele kotacije in prekrižane trge ali drugače poenotijo časovne žige. Te politike so lahko smiselne, vendar so del identitete podatkovnega nabora. »Opcije SPY, od januarja do marca« ne določa ponovljive zgodovine.
Kaj je različica podatkov o opcijah?
Različica podatkov je natančna različica zgodovinskih opazovanj, ki je bila na voljo pri določeni raziskovalni analizi. Zabeležimo ponudnika in ime podatkovnega nabora, čas pridobitve, časovno obdobje, različico sheme ter vsa pravila čiščenja in filtriranja. Če ponudnik omogoča ID-je posnetkov ali časovne žige popravkov, shranimo tudi te.
Za vsako simulirano odločitev ohranimo dovolj podatkov o izvoru, da lahko odgovorimo na naslednja vprašanja: katera pogodba je bila upoštevana, katera kotacija je bila izbrana, kdaj je bila objavljena ali prejeta in po katerem pravilu je bila upravičena do izbire? Pomembna sta tako surovi kot izpeljani zapis. Očiščen NBBO brez izvornih časovnih žigov lahko prikrije, ali je bila kotacija zastarela ali pa je prispela po simulirani odločitvi.
| Zapis, ki ga je treba ohraniti | Zakaj je pomemben | Primer |
|---|---|---|
| Izvorni posnetek | Določa, katera zgodovina je bila uporabljena pri zagonu | ID različice ponudnika in čas pridobitve |
| Izvor kotacije | Pojasni, kateri trg je bil izbran | Borza, čas dogodka, čas prejema, nakupna in prodajna cena ter količini |
| Pogoji pogodbe | Določajo, kaj je opcija predstavljala | Izvršilna cena, datum zapadlosti, množitelj in predmet izročitve |
| Politika čiščenja | Prikaže, katera opazovanja so bila izločena | Prag zastarelosti in obravnava prekrižanih kotacij |
Kako preverim, ali je sprememba pri ponudniku spremenila moje rezultate?
Zaženimo isto strategijo in konfiguracijo na obeh posnetkih. Najprej primerjajmo število upravičenih opazovanj in pogodb po datumih. Nato primerjajmo odločitve in izvršitve: kateri signali so se pojavili ali izginili, katera kotacija se je spremenila in ali je novi zapis spremenil modelirano izvršilno ceno.
Ne ustavimo se pri skupnem donosu. Spremljajmo spremembe števila poslov, vstopnih in izstopnih cen, zavrnjenih signalov ter deleža dobička ali izgube iz poslov, ki obstajajo le v eni različici podatkov. Sharpe lahko ostane podoben, čeprav se posamezni posli zamenjujejo; glavna statistika nam ne pove, da se je spremenila zgodovina, ki je pod njo.
Za uporabno revizijo ohranimo strategijo, provizije in predpostavke o izvrševanju nespremenjene. Če se hkrati spremeni več stvari, ne bomo vedeli, ali je do odstopanja prišlo zaradi popravka ponudnika ali našega lastnega preizkusa.
Ali naj vedno uporabim najnovejšo zgodovino opcij?
Najnovejšo zgodovino uporabimo, kadar želimo izhajati iz trenutno najboljše rekonstrukcije ponudnika. Stari posnetek ohranimo, kadar moramo ponoviti prejšnji rezultat ali razumeti, katere podatke je naš raziskovalni sistem takrat poznal. Gre za odgovora na različni vprašanji.
Pri raziskavah na podlagi podatkov, ki so bili znani v določenem trenutku, je popravljeni zapis danes lahko natančnejši, a strategiji takrat še ni bil na voljo. Kjer je mogoče, ohranimo čase objave in prejema; sicer jasno označimo omejitev. Sodobna rekonstrukcija ni samodejno enaka zgodovinskemu naboru informacij.
Ko se backtest opcij spremeni, bi se morali najprej vprašati: »Katera opazovanja so se spremenila?« Šele ko znamo odgovoriti, sledi vprašanje: »Kateri zagon je pravilen?«
Kaj naj shranim ob vsakem backtestu?
Ob rezultatih shranimo kratek manifest: ponudnika podatkov in posnetek, čas pridobitve, različici sheme in čiščenja, vir metapodatkov pogodb, različico kode strategije, predpostavke o izvrševanju in konfiguracijo zagona. Vsako sklenitev posla povežimo z zapisi kotacij, ki so jo utemeljili.
Ta kratek zapis skrivnostni ponovni zagon spremeni v primerjavo, ki jo lahko pregledamo. Zgodovina opcij se bo še naprej popravljala. Naš raziskovalni proces mora poskrbeti, da je vsak popravek viden, da boljši arhiv izboljša podatke, ne da bi tiho prepisal poskus.
← Vse objave
