En opsjonsbacktest kan endre seg uten at en eneste linje med strategikode flyttes. En leverandør korrigerer en feilaktig kurs, legger til en forsinket handel, reviderer kontraktsmetadata eller endrer filteret for kryssede markeder. Du kjører de samme datoene på nytt og får en annen utførelse, en annen posisjon, kanskje en annen Sharpe. Det er ikke nødvendigvis en feil i strategien. Det betyr at grunnlaget strategien ble testet mot, har endret seg.
For å gjøre en opsjonsbacktest reproduserbar må du behandle markedsdata som en versjonert inndata. Registrer hvilket øyeblikksbilde du brukte, ta vare på råobservasjonene som lå til grunn for hver beslutning, og sammenlign endrede resultater på kontrakts- og tidsstempelnivå før du stoler på de nye samletallene.
Hvorfor endret opsjonsbacktesten seg når koden var uendret?
Opsjonsdata er særlig følsomme for korrigeringer fordi hvor omsettelig en kontrakt ser ut til å være, avhenger av flere felt som må ses i sammenheng: bid, ask, størrelser, underliggende pris, forfallsdato, innløsningskurs og kontraktens multiplikator eller leverbare verdipapirer. En korrigert kurs kan gjøre en tilsynelatende mulighet til et krysset marked. En retting av metadata kan endre betydningen av multiplikatoren for en posisjon.
Tenk deg en strategi som kjøper en call når ask er under $2.00. Ved første innlasting av data er ask-kursen klokken 10:14 $1.95, bid-kursen $1.90, og størrelsen er 5. En senere revisjon fra leverandøren endrer ask til $2.05 etter at en forsinket melding fra børsen er tatt med. Én observasjon snur signalet. Hvis den kontrakten var strategiens eneste handel den dagen, kan en moderat datakorrigering dominere dagens avkastning.
Kursfiltrering har også betydning. Leverandører kan fjerne utdaterte kurser, fjerne kryssede markeder eller normalisere tidsstempler på ulike måter. Slike retningslinjer kan være fornuftige, men de er en del av datasettets identitet. «SPY-opsjoner, januar til mars» beskriver ikke en reproduserbar historikk.
Hva er en datavintage for opsjoner?
En datavintage er den nøyaktige versjonen av de historiske observasjonene som var tilgjengelig for en bestemt forskningskjøring. Ta vare på leverandør- og datasettets navn, tidspunktet dataene ble hentet, datoperioden, skjemaversjonen og eventuelle regler for rensing eller filtrering. Hvis leverandøren tilbyr ID-er for øyeblikksbilder eller revisjonstidspunkter, bør du også lagre dem.
For hver simulert beslutning bør du bevare nok sporbarhet til å svare på følgende: hvilken kontrakt ble vurdert, hvilken kurs ble valgt, når ble kursen publisert eller mottatt, og hvilken regel gjorde den gyldig? Både rådataene og den bearbeidede posten er viktige. En renset NBBO uten kildens tidsstempler kan skjule om en kurs var utdatert eller kom inn etter den simulerte beslutningen.
| Post som bør bevares | Hvorfor det er viktig | Eksempel |
|---|---|---|
| Kildeøyeblikksbilde | Identifiserer historikken som ble brukt i kjøringen | Leverandørens revisjons-ID og tidspunkt for innhenting |
| Kursens proveniens | Forklarer hvilket marked som ble valgt | Børs, hendelsestidspunkt, mottakstidspunkt, bid/ask og størrelser |
| Kontraktsvilkår | Definerer hva opsjonen representerte | Innløsningskurs, forfallsdato, multiplikator og leverbare verdipapirer |
| Rensepolicy | Viser hvilke observasjoner som ble utelatt | Grense for foreldede data og håndtering av kryssede kurser |
Hvordan sjekker jeg om en revisjon fra leverandøren endret resultatene mine?
Kjør den samme strategien og konfigurasjonen mot begge øyeblikksbildene. Sammenlign først antallet gyldige observasjoner og kontrakter per dato. Sammenlign deretter beslutninger og utførelser: hvilke signaler dukket opp eller forsvant, hvilken kurs endret seg, og endret den nye posten den modellerte utførelsesprisen?
Ikke stopp ved totalavkastningen. Følg med på endringer i antall handler, inngangs- og utgangspriser, avviste signaler og andelen av P&L som kommer fra handler som bare finnes i én vintage. En kjøring kan beholde omtrent samme Sharpe selv om enkelte handler blir byttet ut; hovedtallet viser deg ikke at historikken under resultatet har flyttet på seg.
For en nyttig revisjon må du holde strategien, gebyrene og forutsetningene for utførelse faste. Hvis flere ting endres samtidig, vet du ikke om avviket skyldes leverandørens korrigering eller ditt eget eksperiment.
Bør jeg alltid bruke den nyeste opsjonshistorikken?
Bruk den nyeste historikken når målet er å ta utgangspunkt i leverandørens beste nåværende rekonstruksjon. Behold det gamle øyeblikksbildet når du trenger å gjenskape et tidligere resultat eller forstå hva forskningssystemet ditt visste på det tidspunktet. Det er ulike spørsmål.
I point-in-time-forskning kan en korrigert post være mer nøyaktig nå, men likevel ha vært utilgjengelig for strategien den gangen. Bevar publiseringstidspunkt og mottakstidspunkt der det er mulig; hvis ikke, beskriv begrensningen tydelig. En moderne rekonstruksjon er ikke automatisk et historisk informasjonsgrunnlag.
Når en opsjonsbacktest endrer seg, bør det første spørsmålet være «Hvilke observasjoner endret seg?» Spørsmålet «Hvilken kjøring er riktig?» kommer etter at du kan svare på det.
Hva bør jeg lagre for hver backtest?
Lagre et kompakt manifest sammen med resultatene: dataleverandør og øyeblikksbilde, tidspunkt for innhenting, versjoner av skjema og renseprosedyre, kilde for kontraktsmetadata, strategi-commit, forutsetninger for utførelse og kjøringskonfigurasjon. Knytt hver handel til kursregistrene som begrunnet den.
En slik liten oversikt gjør en mystisk ny kjøring om til en differanse du kan undersøke. Opsjonshistorikken vil fortsette å bli korrigert. Forskningsprosessen din bør gjøre hver korrigering synlig, slik at et bedre arkiv gir bedre grunnlag uten å skrive om eksperimentet i det stille.
← Alle innlegg
