Waarom vervangt mijn backtest steeds de optiesdata?

Een backtest van opties kan veranderen zonder dat er ook maar één regel strategiecode wijzigt. Een dataleverancier corrigeert een foutieve quote, voegt een late transactie toe, herziet contractmetadata of past het filter voor crossed markets aan. Je voert dezelfde datums opnieuw uit en krijgt een andere fill, een andere positie, misschien een andere Sharpe. Dat hoeft geen bug in de strategie te zijn. Het betekent dat het bewijs waartegen de strategie is getest, is veranderd.

Om een backtest van opties reproduceerbaar te maken, behandelen we marktdata als een versiegebonden invoer. We leggen vast welke snapshot we hebben gebruikt, bewaren de ruwe waarnemingen die aan elke beslissing ten grondslag lagen en vergelijken gewijzigde resultaten op contract- en tijdstempelniveau voordat we het nieuwe totaalresultaat vertrouwen.

Waarom veranderde mijn backtest van opties terwijl de code gelijk bleef?

Optiegegevens zijn bijzonder gevoelig voor correcties, omdat de schijnbare verhandelbaarheid van een contract afhangt van meerdere velden die samen veranderen: bid, ask, volumes, de prijs van de onderliggende waarde, expiratiedatum, strike en de multiplier of het leverbare effect van het contract. Een gecorrigeerde quote kan een schijnbare kans veranderen in een crossed market. Een correctie van de metadata kan de betekenis van de multiplier van een positie veranderen.

Stel je een strategie voor die een call koopt wanneer de ask lager is dan $2.00. Bij de eerste datalading is de quote om 10:14 een ask van $1.95, een bid van $1.90 en een volume van 5. Een latere revisie van de dataleverancier verandert de ask in $2.05 na verwerking van een vertraagd beursbericht. Eén waarneming laat het signaal omslaan. Als dat contract die dag de enige transactie van de strategie was, kan een kleine datacorrectie het dagrendement domineren.

Ook quote-filtering speelt een rol. Dataleveranciers kunnen verouderde quotes verwijderen, crossed markets uitsluiten of tijdstempels anders normaliseren. Dat kunnen verstandige beleidskeuzes zijn, maar ze maken deel uit van de identiteit van de dataset. “SPY-opties, januari tot en met maart” legt geen reproduceerbare geschiedenis vast.

Wat is een vintage van optiegegevens?

Een datavintage is de exacte versie van de historische waarnemingen die voor een bepaalde onderzoeksrun beschikbaar was. Bewaar de naam van de leverancier en dataset, het ophaaltijdstip, de datumbereik, de schemaversie en eventuele opschonings- of filterregels. Als de leverancier snapshot-ID's of revisietijdstempels aanbiedt, sla die dan ook op.

Bewaar voor elke gesimuleerde beslissing voldoende herkomstinformatie om deze vragen te beantwoorden: welk contract kwam in aanmerking, welke quote is geselecteerd, wanneer is die quote gepubliceerd of ontvangen en volgens welke regel kwam die in aanmerking? Zowel het ruwe record als het afgeleide record is van belang. Een opgeschoonde NBBO zonder de oorspronkelijke tijdstempels kan verhullen of een quote verouderd was of pas na de gesimuleerde beslissing binnenkwam.

Hoe controleer ik of een revisie van de leverancier mijn resultaten heeft veranderd?

Voer dezelfde strategie en configuratie uit op beide snapshots. Vergelijk eerst per datum het aantal in aanmerking komende waarnemingen en contracten. Vergelijk daarna beslissingen en fills: welke signalen verschenen of verdwenen, welke quote veranderde en of het nieuwe record de gemodelleerde uitvoeringsprijs heeft veranderd.

Kijk niet alleen naar het totaalrendement. Houd veranderingen bij in het aantal transacties, de instap- en uitstapprijzen, afgewezen signalen en het aandeel van de P&L dat afkomstig is van transacties die slechts in één vintage voorkomen. Een run kan een vergelijkbare Sharpe behouden terwijl individuele transacties worden vervangen; de kernstatistiek laat niet zien dat de onderliggende geschiedenis is verschoven.

Houd voor een bruikbare audit de strategie, kosten en uitvoeringsaannames gelijk. Als er meerdere dingen tegelijk veranderen, weet je niet of de afwijking door de correctie van de leverancier komt of door je eigen experiment.

Moet ik altijd de nieuwste optiegeschiedenis gebruiken?

Gebruik de nieuwste geschiedenis als je wilt uitgaan van de beste reconstructie die de leverancier op dit moment biedt. Bewaar de oude snapshot als je een eerder resultaat wilt reproduceren of wilt begrijpen wat je onderzoekssysteem destijds wist. Die snapshots beantwoorden verschillende vragen.

Voor point-in-time-onderzoek kan een gecorrigeerd record nu nauwkeuriger zijn, terwijl het toen nog niet beschikbaar was voor de strategie. Bewaar waar mogelijk de publicatie- en ontvangsttijden; benoem anders duidelijk de beperking. Een moderne reconstructie is niet automatisch een historische informatieset.

Als een backtest van opties verandert, moet de eerste vraag zijn: “Welke waarnemingen zijn veranderd?” De vraag “Welke run klopt?” komt pas daarna, wanneer je die eerste vraag kunt beantwoorden.

Wat moet ik bij elke backtest bewaren?

Bewaar naast de resultaten een beknopt manifest met de dataprovider en snapshot, het ophaaltijdstip, de schema- en opschoningsversies, de bron van de contractmetadata, de strategiecommit, de uitvoeringsaannames en de runconfiguratie. Bewaar voor elke transactie een verwijzing naar de quote-records die eraan ten grondslag lagen.

Met dat kleine dossier wordt een raadselachtige rerun een diff die je kunt inspecteren. Optiegeschiedenis blijft correcties ondergaan. Je onderzoeksproces moet elke correctie zichtbaar maken, zodat een beter archief het bewijs verbetert zonder het experiment stilzwijgend te herschrijven.