En optionsbacktest kan ændre sig, uden at en eneste linje strategikode bliver ændret. En leverandør retter en forkert quote, tilføjer en forsinket handel, reviderer kontraktmetadata eller ændrer sit filter for krydsede markeder. Du kører de samme datoer igen og får et andet fill, en anden position, måske en anden Sharpe. Det skyldes ikke nødvendigvis en fejl i strategien. Det skyldes, at det datagrundlag, strategien blev testet på, har ændret sig.
For at gøre en optionsbacktest reproducerbar skal du behandle markedsdata som et versionsstyret input. Notér, hvilket snapshot du brugte, gem de rå observationer, der lå til grund for hver beslutning, og sammenlign ændrede resultater på kontrakt- og tidsstempleniveau, før du stoler på det nye samlede resultat.
Hvorfor ændrede min optionsbacktest sig, selvom koden var den samme?
Optionsdata er usædvanligt følsomme over for rettelser, fordi det afhænger af flere felter, om en kontrakt tilsyneladende kan handles: bid, ask, størrelser, underliggende pris, udløbsdato, strike og kontraktens multiplikator eller leverbare aktiv. En rettet quote kan forvandle en tilsyneladende mulighed til et krydset marked. En rettelse af metadata kan ændre betydningen af en positions multiplikator.
Forestil dig en strategi, der køber en call, når ask er under $2.00. Ved den første dataindlæsning er ask-kursen i quoten kl. 10:14 $1.95, bid-kursen $1.90 og størrelsen 5. En senere revision fra leverandøren ændrer ask-kursen til $2.05 efter afstemning af en forsinket børsmeddelelse. Én observation vender signalet. Hvis den kontrakt var strategiens eneste handel den dag, kan en beskeden datarettelse få stor indflydelse på dagens afkast.
Quote-filtrering har også betydning. Leverandører kan fjerne forældede quotes, udelukke krydsede markeder eller normalisere tidsstempler på forskellige måder. De valg kan være fornuftige, men de er en del af datasættets identitet. »SPY-optionsdata fra januar til marts« beskriver ikke en reproducerbar historik.
Hvad er en dataversion for optionsdata?
En dataversion er den præcise version af de historiske observationer, der var tilgængelig for en bestemt researchkørsel. Gem leverandørens og datasættets navn, tidspunktet for hentning, datointervallet, skemaversionen samt eventuelle regler for rensning og filtrering. Hvis leverandøren angiver snapshot-id'er eller revisionstidspunkter, skal du også gemme dem.
For hver simuleret beslutning skal du gemme nok information til at kunne svare på: Hvilken kontrakt blev overvejet, hvilken quote blev valgt, hvornår blev den quote offentliggjort eller modtaget, og hvilken regel gjorde den gyldig? Både den rå post og den afledte post er vigtige. En renset NBBO uden kildens tidsstempler kan skjule, om en quote var forældet eller først kom frem efter den simulerede beslutning.
| Post, der skal gemmes | Hvorfor det er vigtigt | Eksempel |
|---|---|---|
| Kildesnapshot | Identificerer den historik, kørslen brugte | Leverandørens revisions-id og hentetidspunkt |
| Quote-proveniens | Forklarer, hvilket marked der blev valgt | Børs, hændelsestidspunkt, modtagelsestidspunkt, bid/ask og størrelser |
| Kontraktvilkår | Definerer, hvad optionen repræsenterede | Strike, udløbsdato, multiplikator og leverbart aktiv |
| Rensningspolitik | Viser, hvilke observationer der blev udelukket | Grænse for forældede data og håndtering af krydsede quotes |
Hvordan tjekker jeg, om en leverandørrevision ændrede mine resultater?
Kør den samme strategi og konfiguration på begge snapshots. Sammenlign først antallet af gyldige observationer og kontrakter pr. dato. Sammenlign derefter beslutninger og fills: Hvilke signaler dukkede op eller forsvandt, hvilken quote ændrede sig, og ændrede den nye post den modellerede eksekveringspris?
Se ikke kun på det samlede afkast. Følg ændringer i antal handler, entry- og exitpriser, afviste signaler og andelen af P&L, der kommer fra handler, som kun findes i én dataversion. En kørsel kan have omtrent samme Sharpe, selvom de enkelte handler bliver udskiftet; nøgletallet afslører ikke, at den underliggende historik har flyttet sig.
Når du laver en brugbar gennemgang, skal strategi, gebyrer og antagelser om eksekvering være uændrede. Hvis flere ting ændrer sig på én gang, ved du ikke, om afvigelsen skyldes leverandørens rettelse eller dit eget eksperiment.
Skal jeg altid bruge den nyeste historik for optionsdata?
Brug den nyeste historik, når målet er at arbejde ud fra leverandørens bedste aktuelle rekonstruktion. Gem det gamle snapshot, når du skal reproducere et tidligere resultat eller forstå, hvilke oplysninger dit researchsystem havde på daværende tidspunkt. De besvarer forskellige spørgsmål.
Til point-in-time-research kan en rettet post være mere præcis i dag og stadig have været utilgængelig for strategien dengang. Gem om muligt tidspunkterne for offentliggørelse og modtagelse; ellers skal du tydeligt beskrive begrænsningen. En moderne rekonstruktion er ikke automatisk et historisk informationsgrundlag.
Når en optionsbacktest ændrer sig, bør det første spørgsmål være: »Hvilke observationer ændrede sig?« Spørgsmålet »Hvilken kørsel er rigtig?« kommer bagefter, når du kan svare på det.
Hvad skal jeg gemme sammen med hver backtest?
Gem et kort manifest sammen med resultaterne: dataleverandør og snapshot, hentetidspunkt, skema- og rensningsversioner, kilde til kontraktmetadata, strategiens commit, antagelser om eksekvering og kørselskonfiguration. Sørg for, at hver handel linker til de quote-poster, der begrundede den.
Den lille registrering gør en mystisk genkørsel til en diff, du kan undersøge. Historiske optionsdata vil fortsat blive rettet. Din researchproces bør gøre hver rettelse synlig, så et bedre arkiv forbedrer datagrundlaget uden i det skjulte at omskrive eksperimentet.
← Alle indlæg
