Tickdata redder ikke din backtest — for de fleste strategier gør den den værre

Standardrådet lyder sådan: Hvis du vil have en retvisende backtest, skal du skaffe tickdata. Jeg mener, at det råd er forkert for de fleste strategier, og at det som regel gør backtesten værre, ikke bedre. Ikke fordi tickdata er upræcise — det er det mest præcise, du kan få — men fordi de fleste bruger dataene til at erstatte grundighed med opløsning, og det er ikke det samme.

Sådan går det galt. En researcher bygger en strategi på 1-minute bars og får en Sharpe, de er tilfredse med. Så siger nogen — en mentor, et forumindlæg eller deres egen nagende tvivl — at backtesten ikke er retvisende, fordi den bygger på bars. Så genopbygger de hele pipelinen med tickdata: hver eneste handel, hver eneste opdatering af ordrebogen, tidsstemplet ned til mikrosekundet. Backtesten bliver langsommere, koden bliver tre gange så kompleks, og Sharpe... ændrer sig knap nok eller bevæger sig i en retning, ingen kan forklare. Alligevel sender de den i produktion, fordi tickdata føles mere grundigt, og følelsen af grundighed er ikke det samme som grundighed.

Hvad tickopløsning faktisk giver dig

Tickdata fortæller dig rækkefølgen og prisen på hver handel og (hvis du betaler for det) hver opdatering af ordrebogen. Det er reel information. Den lader dig rekonstruere din plads i køen, estimere sandsynligheden for at blive fyldt på et givet prisniveau og se adverse selection — om markedet bevæger sig imod dig lige efter dit hypotetiske fill. Alt det betyder enormt meget, hvis din holdingperiode måles i sekunder, og din edge måles i brøkdele af et tick.

Men de fleste strategier, vi ser hos Stratmill — og de fleste strategier, som private og semi-professionelle researchere faktisk kører — holder positioner i minutter til dage. På den tidshorisont afhænger backtestens troværdighed ikke af, om du modellerede den 40. handel i løbet af et givet minut. Det afhænger af, om du modellerede spreadet, fundingraten, slippagekurven og det faktum, at din limitordre står bag andres ordrer i køen. Du kan få alle fire ting forkert med tickdata og alle fire rigtigt med 1-minute bars. Opløsning og troværdighed er uafhængige af hinanden.

Det sidste tal undervurderer folk. En backtest på tickniveau er ikke bare "den samme backtest med flere rækker". Handler på de fleste børser ankommer i en anden rækkefølge end deres modtagelsestidspunkter tilsiger, bliver rettet med tilbagevirkende kraft, fordeles på flere matching engine-shards og — på flere handelsplatforme, vi har hentet data fra — bliver af og til duplikeret eller helt tabt ved genoprettelse af forbindelsen. At bygge en tickpipeline, som faktisk er mere korrekt end en veldesignet barpipeline og ikke bare mere detaljeret, er et reelt systemprojekt. De fleste teams gennemfører ikke det projekt. De peger en backtester mod en tickfil fra en leverandør og kalder det færdigt. Dermed har de skiftet et kendt, dokumenteret sæt tilnærmelser (OHLCV) ud med et ukendt, udokumenteret sæt (hvad leverandørens logik til at afstemme tickdata nu engang gør på en dårlig dag).

Den støj, du betaler for

Der er også en anden omkostning, som handler mindre om teknik og mere om statistik. Enkeltstående handler skifter mellem bid- og askprisen — det er bid-ask-bounce, et velkendt fænomen i litteraturen om markedsmikrostruktur siden 1980'erne. Hvis dit signal reagerer hurtigere end hvert par sekunder, kan backtesting på tickniveau få dig til at se mønstre i det, der i virkeligheden bare er dette prishop. Jeg har set en researcher finde et smukt mean-reversion-mønster i data for hver enkelt handel, som forsvandt, så snart dataene blev aggregeret til bare 5-second bars, fordi mønsteret skyldtes prishoppene.

En quant, jeg kender — tidligere market maker, nu med en lille kryptobog — formulerede det sådan for mig: "Tickdata er et forstørrelsesglas. Retter du det mod din edge, er det godt. Retter du det mod din støj, bruger du seks måneder på at modellere støjen på smukkeste vis." Nu backtester han næsten alt på 1-second eller 1-minute bars og går kun ned på tickniveau for at besvare det konkrete spørgsmål: "Ville den her limitordre faktisk være blevet fyldt?" Det handler om sandsynligheden for et fill, ikke om signalet.

Den skelnen er rigtig tænkt, og den overser de fleste, der anbefaler tickdata. Den fornuftige brug af tickdata er ikke at køre hele strategien på den — det er at bruge den målrettet til de enkelte spørgsmål, som barbaserede data reelt ikke kan besvare.

Hvornår kritikerne har ret

Når det er sagt, findes der strategier, hvor tickdata er uundværlige, og det ville være at overdrive min pointe at lade, som om det ikke er tilfældet. Hvis du laver noget, der minder om market making — stiller priser på begge sider, styrer beholdningen tick for tick og går op i din plads i køen på et bestemt prisniveau — kan barbaserede data slet ikke beskrive dit problem. Strategiens økonomi udspiller sig i løbet af minuttet, ikke over flere minutter. Det samme gælder arbitrage på tværs af handelsplatforme, hvor latenstiden betyder noget, og spørgsmålet bogstaveligt talt er "hvilken handel fandt sted først", samt market making med optioner i stor størrelse, hvor nogle få hundrede millisekunders adverse selection efter en handel er hele spillet. I de situationer er backtesting på bars ikke en forenkling, men en kategorifejl: Du tester ikke en version af din strategi med lavere opløsning; du tester en anden strategi, der tilfældigvis har samme navn som den rigtige.

Pointen er altså ikke, at "tickdata er dårlige". Det er, at vi ofte griber til dem for at undgå et sværere og mindre glamourøst spørgsmål: Er min omkostningsmodel rigtig? Er min antagelse om fills rigtig? Ville denne ordre faktisk være blevet fyldt, eller antager jeg, at den blev fyldt til en pris, som ordrebogen aldrig reelt tilbød mig? De spørgsmål kan besvares med 1-minute eller endda 1-second bars, hvis du tager højde for pladsen i køen og spreadet. Tickdata gør det muligt at besvare dem mere præcist, til flere gange så høje tekniske omkostninger, for strategier hvor den ekstra præcision ikke ændrer konklusionen. Brug den ekstra indsats dér, hvor tidshorisonten faktisk kræver det, og lad den ligge alle andre steder — det er en bedre brug af et researchteams tid end automatisk at vælge de mest detaljerede data, fordi finere opløsning føles mere grundig.