En backtest ga 20 % annualisert avkastning. Den brukte 8 års data, 1,640 handler og et ryddig walk-forward-splitt. Så erstattet vi leverandørens nåværende historikk med verdiene som var registrert på det aktuelle tidspunktet, og edgen falt til 3 %.
Det overraskende tallet var ikke den opprinnelige avkastningen. Det var de 17 prosentpoengene som var avhengige av reviderte data. Slik etterpåklokskap kan skjule seg i økonomiske publiseringer, selskapsregnskap, indeksmedlemskap og til og med tilsynelatende enkle markedsfelt. Historiske data viser hva kilden sier nå. Et punkt-i-tid-datasett viser hva strategien din kunne ha visst da.
Hvorfor kan historiske data endre seg etter hendelsen?
Noen verdier er først estimater og blir korrigert senere. En økonomisk statistikk som publiseres på fredag, kan bli revidert neste måned. Et selskap kan omarbeide et resultat. En dataleverandør kan rette en feilaktig observasjon, fylle et manglende intervall eller erstatte en foreløpig verdi med en endelig. En database som bare lagrer den nyeste verdien, får alle disse endringene til å se ut som om de alltid hadde vært riktige.
Det spiller en rolle når en strategi rangerer selskaper etter rapportert omsetning eller handler i et marked etter en planlagt datautgivelse. Hvis den ser det korrigerte tallet flere måneder for tidlig, har backtesten gitt den informasjon som ikke var tilgjengelig i markedet da beslutningen ble tatt. Signalkalkuleringen kan være feilfri; inndataene kommer likevel fra feil versjon av historikken.
Her er det lett å gå i en felle: et felt kalt date beskriver ofte perioden verdien gjelder, ikke når den ble tilgjengelig. En rad med kvartalsomsetning merket 31. mars ble kanskje ikke publisert før i mai. Merkingen gjelder virksomhetsperioden, ikke strategiens informasjonsgrunnlag.
Hvilket tidsstempel bør en backtest bruke?
Hold verdienes gyldighetsperiode og tilgjengelighetstidspunkt adskilt. Registrer også publiseringstidspunkt og mottakstidspunkt når det er mulig. En strategi kan først bruke en verdi etter at den er publisert og mottatt av systemet. Hvis tidspunktene er forskjellige, bruker du det seneste for en konservativ simulering.
| Tidsstempel | Hva det beskriver | Hva det brukes til |
|---|---|---|
| Gyldighetstidspunkt | Perioden eller hendelsen verdien viser til | Grupperer observasjoner etter det som måles |
| Publiseringstidspunkt | Når kilden publiserte denne versjonen | Hindrer at en publisering vises før den fant sted |
| Mottakstidspunkt | Når systemet ditt mottok versjonen | Fanger opp leveringsforsinkelser og sen etterfylling |
Tenk deg for eksempel at et selskaps kvartalssalg gjelder januar til mars, rapporteres 8. mai kl. 16:15 Eastern og kommer inn i forskningslageret ditt kl. 16:17. En strategi som tar beslutninger ved børsslutt 8. mai, kan ikke bruke rapporten hvis beslutningen ved børsslutt ble tatt kl. 16:00. En strategi som tar beslutninger neste morgen, kan bruke den. Kvartalssluttdatoen alene kan ikke besvare noen av spørsmålene.
Hvordan tester jeg om revisjoner driver resultatet?
Kjør samme strategi to ganger: én gang med dataversjonen som var tilgjengelig ved hvert historiske beslutningstidspunkt, og én gang med den sist reviderte historikken. Hold utførelsesforutsetninger, univers og kode fast. Forskjellen viser følsomheten for revisjoner; den er ikke en ny strategisammenligning.
Undersøk deretter hvor forskjellen kommer fra. Endres resultatene på publiseringsdager? Er de største avvikene konsentrert rundt noen få omarbeidede selskapsregnskap eller korrigerte observasjoner? Handler strategien før det relevante publiseringstidspunktet? En liten revisjon på hendelsesnivå forklarer ofte mer enn enda et diagram over kumulativ avkastning.
Disse tallene er et eksempel, ikke et universelt avslag. Det nyttige resultatet er en sammenligning for din egen strategi med samme handler og kostnader der det er mulig. Hvis den reviderte versjonen vinner med stor margin, finn ut hvilke felt og datoer som står for forskjellen før du stoler på hovedtallet fra backtesten.
Hva bør en revisjon av punkt-i-tid-data dokumentere?
Begynn med feltene strategien faktisk bruker. For hvert felt finner du kilden, hva tidsstempelet betyr, revisjonspolicyen og om tidligere versjoner kan hentes frem. Spør leverandøren hvordan korrigeringer representeres: overskrevne rader, nye versjonsrader eller en separat revisjonslogg. At et produkt omtales som «historisk» på en produktside, avgjør ikke dette.
- Lagre hver versjon med publiseringstidspunkt eller tidspunktet den først ble tilgjengelig.
- Koble funksjoner til beslutninger etter tilgjengelighetstidspunkt, ikke periodeetiketter.
- Behold et fryst øyeblikksbilde eller en kildeversjon for å kunne gjenskape kjøringer.
- Merk verdier som kommer sent, blir revidert eller mangler pålitelig historikk.
Hold også omfanget praktisk. Hvis strategien bare bruker handler og barer fra børsen, kan revisjoner av økonomiske data være irrelevante. Men bar-korrigeringer og etterfylling fra dataleverandøren kan fortsatt ha betydning, særlig når et signal avhenger av et tynt omsatt marked eller et presist hendelsesvindu.
Når punkt-i-tid-historikk ikke er tilgjengelig
Ikke behandle dagens verdi som om den var gårsdagens uten å si fra. Merk feltet som en begrensning, utelat det fra påstander som forutsetter historisk tilgjengelighet, eller legg inn en konservativ forsinkelse og vis hvor mye resultatet endres. En forsinket tilnærmingsverdi kan være nyttig i forskning, så lenge forsinkelsen er tydelig og begrensningen følger resultatet.
Backtestens oppgave er å rekonstruere en beslutning med informasjonsgrunnlaget som fantes på det aktuelle tidspunktet. Hvis dataene dine bare kan vise den nyeste versjonen, har det ærlige resultatet en grense: Det kan teste strategien mot dagens rekonstruerte historikk, men ikke fastslå nøyaktig hva en historisk aktør kunne ha sett.
← Alle innlegg
