En backtest gav et annualiseret afkast på 20 %. Den brugte 8 års data, 1.640 handler og en ren walk-forward-opdeling. Så erstattede vi leverandørens aktuelle historik med de værdier, der var registreret på det pågældende tidspunkt, og edgen faldt til 3 %.
Det overraskende tal var ikke det oprindelige afkast. Det var de 17 procentpoint, der afhang af reviderede data. Den slags bagklogskab kan gemme sig i økonomiske offentliggørelser, selskabstal, indeksmedlemskab og selv tilsyneladende simple markedsfelter. Historiske data fortæller dig, hvad kilden siger nu. Et point-in-time-datasæt fortæller dig, hvad din strategi kunne have vidst dengang.
Hvorfor kan historiske data ændre sig efter begivenheden?
Nogle værdier er først estimater og bliver senere korrigeret. En økonomisk statistik, der offentliggøres fredag, kan blive revideret måneden efter. Et selskab kan omarbejde et resultat. En dataleverandør kan rette en fejlagtig kurs, udfylde et manglende interval eller erstatte en foreløbig værdi med en endelig. En database, der kun gemmer den seneste værdi, får alle disse ændringer til at se ud, som om de altid havde været sande.
Det har betydning, når en strategi rangerer selskaber efter rapporteret omsætning eller handler på et marked efter en planlagt dataoffentliggørelse. Hvis den ser det korrigerede tal flere måneder for tidligt, har backtesten givet den information, som ikke var tilgængelig på markedet, da beslutningen blev truffet. Signalet kan være beregnet fejlfrit; inputtet kommer stadig fra den forkerte historiske version.
Her er det let at gå i en fælde: Et felt kaldet date beskriver ofte den periode, en værdi dækker, ikke hvornår den blev tilgængelig. En række med kvartalsomsætning, der er mærket 31. marts, er måske først blevet offentliggjort i maj. Mærkaten handler om selskabets periode, ikke om strategiens informationsgrundlag.
Hvilket tidsstempel skal en backtest bruge?
Registrér værdiens gyldighedsperiode og tilgængelighedstidspunkt hver for sig. Gem også offentliggørelsestidspunkt og indlæsningstidspunkt, når det er muligt. En strategi kunne først bruge en værdi, efter at den var offentliggjort og modtaget af systemet; hvis tidspunkterne er forskellige, skal du bruge det seneste i en konservativ historisk afspilning.
| Tidsstempel | Hvad det beskriver | Hvad det bruges til |
|---|---|---|
| Gyldighedstidspunkt | Den periode eller begivenhed, værdien henviser til | Grupperer observationer efter det, der måles |
| Offentliggørelsestidspunkt | Hvornår kilden offentliggjorde denne version | Forhindrer, at en offentliggørelse dukker op, før den fandtes |
| Indlæsningstidspunkt | Hvornår dit system modtog versionen | Fanger leveringsforsinkelser og sene efterfølgende udfyldninger |
Forestil dig for eksempel, at et selskabs kvartalssalg dækker januar til marts, rapporteres 8. maj kl. 16:15 Eastern og ankommer til dit researchlager kl. 16:17. En strategi, der træffer beslutninger ved lukketid den 8. maj, kan ikke bruge rapporten, hvis beslutningen ved lukketid blev truffet kl. 16:00. En strategi, der træffer beslutning næste morgen, kan bruge den. Kvartalets slutdato kan ikke alene besvare nogen af spørgsmålene.
Hvordan tester jeg, om revisioner driver resultatet?
Kør den samme strategi to gange: først med den dataversion, der var tilgængelig på hvert historisk beslutningstidspunkt, og dernæst med den senest reviderede historik. Hold antagelser om eksekvering, univers og kode fast. Forskellen viser følsomheden over for revisioner; det er ikke en ny strategisammenligning.
Undersøg derefter, hvor forskellen kommer fra. Ændrer resultatet sig på offentliggørelsesdage? Er de største forskelle koncentreret i nogle få omarbejdede selskabstal eller korrigerede observationer? Handler strategien før det relevante offentliggørelsestidspunkt? En lille gennemgang på hændelsesniveau forklarer ofte mere end endnu et diagram over kumulative afkast.
Tallene er et eksempel, ikke en universel straf. Det nyttige resultat er en sammenligning af to kørsler af din egen strategi, med de samme handler og omkostninger, hvor det er muligt. Hvis den reviderede version klarer sig markant bedre, så find ud af, hvilke felter og datoer der forklarer forskellen, før du stoler på backtestens overskriftstal.
Hvad bør en point-in-time-datarevision registrere?
Begynd med de felter, din strategi faktisk bruger. Find for hvert felt kilden, tidsstemplets betydning, revisionspolitikken, og om tidligere versioner kan hentes. Spørg leverandøren, hvordan rettelser repræsenteres: som overskrevne rækker, nye versionsrækker eller en separat revisionslog. At et produkt kaldes »historisk« på en produktside afgør ikke sagen.
- Gem hver version med dens offentliggørelses- eller første tilgængelighedstidspunkt.
- Kobl features til beslutninger efter tilgængelighedstidspunkt, ikke periodeetiketter.
- Gem et fastfrosset øjebliksbillede eller en kildeversion, så kørsler kan genskabes.
- Markér værdier, der ankommer sent, bliver revideret eller mangler pålidelig historik.
Hold også omfanget praktisk. Hvis din strategi kun bruger handler og bars fra børsen, er revisioner af økonomiske data måske irrelevante. Men korrektioner af bars og efterfølgende udfyldninger fra dataleverandøren kan stadig have betydning, især når et signal afhænger af et illikvidt marked eller et præcist hændelsesvindue.
Når point-in-time-historik ikke er tilgængelig
Lad ikke stiltiende, som om dagens værdi var gårsdagens. Markér feltet som en begrænsning, udelad det fra påstande, der afhænger af historisk tilgængelighed, eller indfør en konservativ forsinkelse og vis, hvor meget resultatet ændrer sig. En forsinket tilnærmelse kan være nyttig i research, hvis forsinkelsen er tydelig, og begrænsningen følger med resultatet.
Backtestens opgave er at genskabe en beslutning ud fra det informationsgrundlag, der fandtes på det tidspunkt. Hvis dine data kun kan vise den seneste version, har resultatet en klar begrænsning: Det kan teste strategien mod nutidens rekonstruerede historik, men det kan ikke fastslå præcist, hvad en historisk agent kunne have set.
← Alle indlæg
