Ett backtest av optioner kan förändras utan att en enda rad strategikod ändras. En leverantör korrigerar en felaktig offert, lägger till en sen affär, reviderar kontraktsmetadata eller ändrar sitt filter för korsade marknader. Du kör om samma datum och får en annan fill, en annan position, kanske en annan Sharpe. Det behöver inte betyda att det är fel på strategin. Det betyder att underlaget som strategin testades mot har förändrats.
Gör marknadsdata till en versionshanterad indata för att kunna reproducera ett optionsbacktest. Notera vilken ögonblicksbild du använde, spara råobservationerna som låg till grund för varje beslut och jämför ändrade resultat på kontrakts- och tidsstämpelnivå innan du litar på det nya totalresultatet.
Varför ändrades mitt optionsbacktest när koden var oförändrad?
Optionsposter är ovanligt känsliga för korrigeringar eftersom ett kontrakts skenbara handlingsbarhet beror på att flera fält hänger ihop: bid, ask, storlekar, underliggande pris, förfall, lösenpris och kontraktets multiplikator eller leveransvillkor. En korrigerad offert kan förvandla en skenbar möjlighet till en korsad marknad. En metadatakorrigering kan ändra vad en positions multiplikator innebär.
Tänk dig en strategi som köper en call när ask är under $2.00. Vid den första datainläsningen är offerten 10:14 ask $1.95, bid $1.90 och storlek 5. En senare revidering från leverantören ändrar ask till $2.05 efter att ett fördröjt börsmeddelande har stämts av. En enda observation vänder signalen. Om det kontraktet var strategins enda affär den dagen kan en liten datakorrigering få stor inverkan på dagens avkastning.
Offertfiltreringen spelar också roll. Leverantörer kan ta bort gamla offerter, rensa bort korsade marknader eller normalisera tidsstämplar på olika sätt. Sådana regler kan vara rimliga, men de är en del av datamängdens identitet. ”SPY-optioner, januari till mars” beskriver inte en historik som går att reproducera.
Vad är en dataversion för optionsdata?
En dataversion är den exakta versionen av de historiska observationer som fanns tillgängliga för en viss researchkörning. Spara leverantörens och datamängdens namn, hämtningstid, datumintervall, schemaversion samt eventuella regler för rensning och filtrering. Om leverantören tillhandahåller ID:n för ögonblicksbilder eller revisionstidsstämplar ska du spara även dem.
Spara tillräcklig spårbarhet för varje simulerat beslut för att kunna svara på följande: vilket kontrakt övervägdes, vilken offert valdes, när publicerades eller togs offerten emot och vilken regel gjorde den giltig? Både råposten och den härledda posten spelar roll. En rensad NBBO utan källans tidsstämplar kan dölja om en offert var gammal eller kom fram efter det simulerade beslutet.
| Post att spara | Varför den spelar roll | Exempel |
|---|---|---|
| Källögonblicksbild | Identifierar historiken som användes i körningen | Leverantörens revisions-ID och hämtningstid |
| Offertens ursprung | Förklarar vilken marknad som valdes | Börs, händelsetid, mottagningstid, bid/ask och storlekar |
| Kontraktsvillkor | Definierar vad optionen representerade | Lösenpris, förfall, multiplikator och leveransvillkor |
| Rensningsregler | Visar vilka observationer som uteslöts | Gräns för inaktualitet och hantering av korsade offerter |
Hur kontrollerar jag om en leverantörsrevision ändrade mina resultat?
Kör samma strategi och konfiguration mot båda ögonblicksbilderna. Jämför först antalet giltiga observationer och kontrakt per datum. Jämför sedan beslut och fills: vilka signaler dök upp eller försvann, vilken offert ändrades och ändrade den nya posten det modellerade exekveringspriset?
Stanna inte vid totalavkastningen. Följ förändringar i antal affärer, köp- och säljpriser, avvisade signaler och andelen av P&L som kommer från affärer som bara finns i en dataversion. En körning kan behålla ungefär samma Sharpe samtidigt som enskilda affärer byts ut; nyckeltalet visar inte att den underliggande historiken har ändrats.
Håll strategin, avgifterna och exekveringsantagandena oförändrade för att få en användbar granskning. Om flera saker ändras samtidigt vet du inte om avvikelsen beror på leverantörens korrigering eller ditt eget experiment.
Ska jag alltid använda den senaste optionshistoriken?
Använd den senaste historiken när målet är att utgå från leverantörens bästa aktuella rekonstruktion. Spara den gamla ögonblicksbilden när du behöver reproducera ett tidigare resultat eller förstå vad ditt researchsystem kände till då. De besvarar olika frågor.
För point-in-time-research kan en korrigerad post vara mer korrekt i dag och ändå ha varit otillgänglig för strategin då. Spara publicerings- och mottagningstider när det går; annars ska du tydligt beskriva begränsningen. En modern rekonstruktion är inte automatiskt samma informationsunderlag som fanns historiskt.
När ett optionsbacktest ändras bör den första frågan vara ”Vilka observationer ändrades?” Frågan ”Vilken körning är rätt?” kommer efter att du kan svara på det.
Vad bör jag spara med varje backtest?
Spara ett kort manifest tillsammans med resultaten: dataleverantör och ögonblicksbild, hämtningstid, schema- och rensningsversioner, källa för kontraktsmetadata, strategi-commit, exekveringsantaganden och körningskonfiguration. Länka varje affär till offertposterna som motiverade den.
Den här lilla dokumentationen gör en mystisk omkörning till en granskbar diff. Optionshistoriken kommer att fortsätta korrigeras. Din researchprocess bör synliggöra varje korrigering, så att ett bättre arkiv förbättrar underlaget utan att experimentet skrivs om i tysthet.
← Alla inlägg
