19 september 2026 · backtesting

Tickdata redt je backtest niet — voor de meeste strategieën maakt het die slechter

Tickdata redt je backtest niet — voor de meeste strategieën maakt het die slechter

Het standaardadvies luidt: als je een eerlijke backtest wilt, moet je tickdata verzamelen. Volgens mij klopt dat advies voor de meeste strategieën niet, en maakt opvolgen de backtest meestal slechter in plaats van beter. Niet omdat tickdata onnauwkeurig is — het is het nauwkeurigste wat je kunt krijgen — maar omdat de manier waarop de meeste mensen het gebruiken resolutie in de plaats stelt van grondigheid. Dat zijn twee verschillende dingen.

Zo gaat het mis. Een onderzoeker bouwt een strategie op 1-minuutbars, behaalt een Sharpe waar die tevreden mee is, en iemand — een mentor, een forumbericht of hun eigen knagende twijfel — vertelt dat de backtest niet eerlijk is omdat die op bars is gebaseerd. Dus bouwen ze de hele pipeline opnieuw op tickdata: elke trade, elke quote-update, tot op de microseconde voorzien van een tijdstempel. De backtest wordt trager, de code drie keer zo complex en de Sharpe... verandert nauwelijks, of beweegt in een richting die niemand kan verklaren. Toch brengen ze hem in productie, omdat tickdata grondiger aanvoelt. Grondig aanvoelen is niet hetzelfde als grondig zijn.

Wat tickresolutie je daadwerkelijk oplevert

Tickdata laat je de volgorde en prijs van elke trade zien en (als je ervoor betaalt) van elke update van het orderboek. Dat is echte informatie. Je kunt er je plek in de wachtrij mee reconstrueren, de vulkans op een bepaald prijsniveau mee inschatten en adverse selection mee zien — of de markt direct na je hypothetische fill tegen je in beweegt. Dat alles is enorm belangrijk als je posities seconden aanhoudt en je edge in fracties van een tick wordt gemeten.

Maar de meeste strategieën die we bij Stratmill zien — en de meeste strategieën die retail- en semiprofessionele onderzoekers daadwerkelijk gebruiken — houden posities minuten tot dagen aan. Op die horizon wordt de eerlijkheid van je backtest niet bepaald door de vraag of je de 40e trade binnen een bepaalde minuut hebt gemodelleerd. Het gaat erom of je de spread, funding rate, slippagecurve en het feit hebt meegenomen dat je limietorder achter de orders van anderen in de wachtrij staat. Je kunt alle vier verkeerd modelleren met tickdata en alle vier goed met 1-minuutbars. Resolutie en eerlijkheid staan los van elkaar.

~24Mtrades/dag, BTCUSDT-perpetual
1,4401-minuutbars op diezelfde dag
0.5–1 ticktypische bid-ask-bounce-ruis per transactie
3–5xengineeringtijd voor een correcte tickpipeline versus een barpipeline

Dat laatste cijfer wordt vaak onderschat. Een backtest op tickniveau is niet gewoon "dezelfde backtest met meer rijen". Trades komen op de meeste exchanges binnen in een andere volgorde dan hun ingestietijdstempel aangeeft, worden achteraf gecorrigeerd, verdeeld over meerdere matching-engine-shards en — bij verschillende venues waarvan we data hebben ingelezen — soms dubbel aangeleverd of helemaal niet tijdens een reconnect. Een tickpipeline bouwen die daadwerkelijk correcter is dan een goed gebouwde barpipeline, in plaats van alleen fijnmaziger, is een serieus systeemproject. De meeste teams voeren dat project niet uit. Ze voeren een backtester op een tickbestand van een leverancier af en noemen het klaar. Daarmee ruilen ze een bekende, gedocumenteerde verzameling benaderingen (OHLCV) in voor een onbekende, ongedocumenteerde verzameling: wat de reconciliatielogica voor ticks van die leverancier op een slechte dag toevallig doet.

De ruis die je erbij krijgt

Een tweede prijs heeft minder met engineering en meer met statistiek te maken. Afzonderlijke tradeprints wisselen tussen de bid en de ask — dat is de bid-ask bounce, een bekend verschijnsel in de literatuur over marktmicrostructuur sinds de jaren 1980. Als je signaal sneller werkt dan een paar seconden, kan backtesten op tickniveau je patronen laten zien in iets wat in werkelijkheid alleen de bounce is. Ik heb een onderzoeker een prachtig mean-reversionpatroon gevonden zien worden in trade-by-tradedata, dat meteen verdween zodra die data zelfs maar naar 5-secondenbars werd geaggregeerd. Het patroon was namelijk de bounce.

Een quant die ik ken — voormalig market maker, nu actief met een kleine cryptoboekhouding — verwoordde het zo: "Tickdata is een vergrootglas. Richt je het op je edge, prima. Richt je het op je ruis, dan ben je zes maanden bezig die ruis prachtig te modelleren." Hij backtest nu vrijwel alles op 1-seconde- of 1-minuutbars en gebruikt tickdata alleen voor de specifieke vraag: "was deze limietorder daadwerkelijk gevuld?" Dat is een vraag over vulkans, niet over signalen.

Dat onderscheid is de juiste aanpak, en het is precies wat de meeste voorstanders van tickdata overslaan. Tickdata eerlijk gebruiken betekent niet dat je je hele strategie erop draait. Je gebruikt het gericht voor de een of twee vragen waarop bardata echt geen antwoord kan geven.

Wanneer de critici gelijk hebben

Dat gezegd hebbende: voor sommige strategieën is tickdata onmisbaar. Het zou overdreven zijn te doen alsof dat niet zo is. Als je iets doet dat op market making lijkt — aan beide kanten quoten, je inventory tick voor tick beheren en letten op je plek in de wachtrij op een specifiek prijsniveau — kan bardata je probleem helemaal niet weergeven. De volledige economie van die strategie speelt zich binnen de minuut af, niet over meerdere minuten. Hetzelfde geldt voor latentiegevoelige statistische arbitrage tussen venues, waarbij de vraag letterlijk is "welke trade vond het eerst plaats?", en voor market making in opties met grote volumes, waarbij een paar honderd milliseconden adverse selection na een print het hele spel bepalen. In die situaties is backtesten op bars geen vereenvoudiging maar een categoriefout: je test geen versie van je strategie met een lagere resolutie, maar een andere strategie die toevallig dezelfde naam heeft als de echte.

StrategiehorizonWat bardata verbergtTickdata nodig?
Market making / op wachtrij gebaseerdVulkans, adverse selection, plek in de wachtrijJa — onmisbaar
Latentie / arbitrage tussen venuesTradevolgorde, welke venue als eerste bewoogJa
Intradaymomentum, mean reversion (minuten–uren)Filltiming binnen de bar, spreadkostenAlleen voor de vulkans, niet voor het signaal
Swing / meerdaags, directionele optiestrategieënVrijwel niets relevantsNee — bars volstaan en zijn vaak schoner
Kun je niet in één zin zeggen welke vraag tickdata voor jouw specifieke strategie beantwoordt die bars onbeantwoord laten, dan heb je tickdata nog niet nodig. Je hebt een beter fillmodel nodig voor de bars die je al hebt.

De stelling is dus niet dat tickdata slecht is. Het punt is dat er vaak naar grijpen een manier is om een lastigere, minder glamoureuze vraag uit de weg te gaan: klopt mijn kostenmodel? Klopt mijn aanname over fills? Zou deze order daadwerkelijk zijn gevuld, of ga ik uit van een fill tegen een prijs die het orderboek nooit echt bood? Als je eerlijk rekening houdt met je plek in de wachtrij en de spread, kun je die vragen beantwoorden met 1-minuut- of zelfs 1-secondebars. Met tickdata kun je preciezere antwoorden krijgen, tegen meerdere keren zo hoge engineeringkosten, voor strategieën waarbij die extra precisie niets aan de conclusie verandert. Besteed die extra moeite waar je horizon erom vraagt en laat haar elders achterwege. Dat is een betere besteding van de tijd van een onderzoeksteam dan standaard de fijnste dataresolutie kiezen omdat die grondiger aanvoelt.

tickdatamarktmicrostructuurbacktestingdata-engineeringcrypto-futures
← Alle artikelen