10 november 2026 · data

Je backtest heeft een datamutatielog nodig, niet alleen een datasnapshot

Je backtest heeft een datamutatielog nodig, niet alleen een datasnapshot

Een bevroren snapshot van marktdata is niet genoeg om een backtest betrouwbaar te maken. Je kunt er hetzelfde antwoord mee reproduceren, terwijl verborgen blijft dat de leverancier de input heeft gewijzigd waarmee dat antwoord tot stand kwam.

Bewaar de snapshot. Houd daarnaast een mutatielog bij die vertelt wat er veranderde, wanneer dat gebeurde en of de strategie daar gevoelig voor was. Dit is vooral belangrijk als je onderzoek gebruikmaakt van gecorrigeerde transacties, herziene fundamentele gegevens, gereconstrueerde funding of een geschiedenis die de leverancier stilletjes heeft bijgewerkt.

Waarom kan een reproduceerbare backtest je toch misleiden?

Stel dat je maandag vijf jaar aan uurbars downloadt en een strategie uitvoert. Op vrijdag heeft de leverancier een foutieve transactie hersteld, een corporate action aangepast of een gat opgevuld. Je opgeslagen bestand levert nog steeds precies het resultaat van maandag op. Dat is reproduceerbaar. Maar als je de huidige historie bij de leverancier opnieuw ophaalt, krijg je mogelijk een ander resultaat en heb je geen verslag van de reden.

Het probleem beperkt zich niet tot grote correcties. Eén gewijzigde high kan een stop activeren; een herziene close kan een indicator over zijn drempel duwen. In een brede beleggingsuniversum kan een wijziging in de historie van één symbool de rangschikking veranderen en een ander activum uit de portefeuille drukken. De uiteindelijke Sharpe kan verschuiven, ook als de strategiecode en configuratie identiek zijn.

Een bestandshash vertelt je dat twee bestanden verschillen. Hij vertelt niet of een splitcorrectie 40 jaar aan prijzen heeft veranderd, een leverancier drie transacties heeft gecorrigeerd of een parser een leeg veld in nul heeft omgezet.

Wat hoort er in een mutatielog voor marktdata?

Leg wijzigingen vast op het kleinste bruikbare niveau, met genoeg context om het betrokken onderzoek opnieuw uit te voeren. Voor een barfeed betekent dat meestal het instrument, interval, tijdstip van de gebeurtenis, oude en nieuwe waarden, bron en het tijdstip waarop je de update hebt waargenomen. Bewaar de oorspronkelijke payload als de leverancier die aanlevert.

VastleggenWaarom bewarenVoorbeeld
Bronversie of ophaaltijdIdentificeert de gebruikte versie van de leveranciersdataSnapshot opgehaald op 2026-11-02 08:15 UTC
Gewijzigd veld en oude/nieuwe waardenToont wat er daadwerkelijk veranderdeETHUSDT 1h high: 3,412.10 → 3,418.60
Classificatie van de wijzigingOnderscheidt reparaties van transformatiesCorrectie van late transactie, splitcorrectie, backfill
Versie van pipeline en schemaMaakt onderscheid tussen wijzigingen aan de bron en je eigen verwerkingNormalizer v7, schema voor aangepaste bars v3

Sla voor grote datasets onveranderlijke snapshots op, samen met een compact manifest met hun checksums, bronversies en ophaaltijden. Voeg rijdiffs toe voor gewijzigde partities. Zo krijg je een praktisch midden: volledige replay blijft mogelijk zonder elke ongewijzigde rij naar een tweede audit-tabel te schrijven.

Hoe meet ik of een correctie ertoe doet?

Stop niet na het tellen van gewijzigde rijen. Voer de betrokken strategie opnieuw uit met de oude en nieuwe data, met dezelfde code, parameters, kosten en uitvoeringsaannames. Vergelijk de beslissingen en het verloop naar het resultaat.

  1. Bepaal aan de hand van de diff welke instrumenten en tijdstippen van gebeurtenissen zijn geraakt.
  2. Zoek uit welke features, signalen, orders of portefeuillewegingen deze records gebruiken.
  3. Speel het kleinste geldige tijdvenster opnieuw af, inclusief eventuele lookback en de status van open posities.
  4. Vergelijk orders, fills, exposure, turnover, drawdown en uiteindelijke prestaties.

Een leverancierscorrectie die bijvoorbeeld een high van een 1-minuutbar met $0.02 wijzigt, kan een miljoen rijen raken zonder enig effect te hebben op een dagelijkse momentumstrategie. Eén gecorrigeerde bar op een stopniveau kan meer uitmaken. Meet het effect op beslissingen; het aantal gewijzigde records is daarvoor een slechte maatstaf.

Houd twee vragen uit elkaar: “Kan ik het resultaat reproduceren met de data die ik heb opgeslagen?” en “Was deze dataversie destijds beschikbaar voor de strategie?” Een mutatielog helpt beide te beantwoorden, maar voor de tweede vraag heb je ook beschikbaarheidsgegevens op het juiste tijdstip nodig.

Wat kost dit en wanneer is het de moeite waard?

Mutaties bijhouden kost opslagruimte en werk voor data-inname, en vraagt om operationele keuzes. Leveranciers bieden mogelijk geen stabiele versies aan, en sommige historische feeds worden periodiek opnieuw opgebouwd zonder duidelijke melding van correcties. Je kunt een wijziging die je nooit waarneemt niet vastleggen.

Begin met data waarvan herzieningen de onderzoeksconclusies kunnen veranderen: bars die voor stoplogica worden gebruikt, aandelen gecorrigeerd voor corporate actions, fundamentele gegevens op het juiste tijdstip en reeksen voor funding of open interest die worden gereconstrueerd. Voor brede, stabiele datasets kan een dagelijks manifest met checksums per partitie genoeg zijn. Voeg diffs op veldniveau toe waar updates vaak voorkomen of handelsbeslissingen gevoelig zijn voor afzonderlijke records.

Critici hebben gelijk dat een volledig, permanent archief van elke reactie van een leverancier duur kan worden en nog steeds niet hoeft vast te leggen wat de bron destijds wist. Baken de audit daarom af tot de data en beslissingen die ertoe doen en documenteer de hiaten. Met een snapshot kun je een experiment opnieuw uitvoeren. Met een mutatielog kun je uitleggen waarom het antwoord van het experiment is veranderd.

data-engineeringbacktestingreproduceerbaarheidkwantitatief onderzoek
← Alle artikelen