Standardrådet lyder slik: Hvis du vil ha en ærlig backtest, må du skaffe tickdata. Jeg mener rådet er feil for de fleste strategier, og at det som regel gjør backtesten dårligere, ikke bedre. Ikke fordi tickdata er unøyaktige – det er de mest nøyaktige dataene du kan få – men fordi de fleste bruker dem til å erstatte grundighet med oppløsning. Det er ikke det samme.
Slik går det galt. En analytiker bygger en strategi på 1-minuttsbarer, får en Sharpe de liker, og så sier noen – en mentor, et foruminnlegg eller deres egen gnagende tvil – at backtesten ikke er ærlig fordi den bygger på barer. Dermed bygger de hele datapipelinen på nytt med tickdata: hver handel, hver oppdatering av ordreboken, tidsstemplet ned til mikrosekundet. Backtesten går tregere, koden blir tre ganger mer kompleks, og Sharpe ... endrer seg knapt, eller beveger seg i en retning ingen kan forklare. Likevel setter de den i produksjon, fordi tickdata føles grundigere. Men følelsen av grundighet er ikke det samme som grundighet.
Hva tickoppløsning faktisk gir deg
Tickdata forteller deg rekkefølgen og prisen på hver handel og (hvis du betaler for det) hver oppdatering av ordreboken. Det er reell informasjon. Den lar deg rekonstruere køposisjonen, anslå sannsynligheten for å få en ordre fylt på et gitt prisnivå og se negativ seleksjon – om markedet beveger seg mot deg rett etter den hypotetiske utførelsen. Alt dette betyr svært mye hvis du holder posisjoner i sekunder og måler fordelen din i brøkdeler av et tick.
Men de fleste strategiene vi ser hos Stratmill – og de fleste strategiene som faktisk brukes av private og semiprofesjonelle analytikere – holder posisjoner i minutter til dager. På den tidshorisonten handler det ikke om hvorvidt du modellerte den 40. handelen i løpet av et gitt minutt. Det handler om hvorvidt du modellerte spreaden, finansieringsrenten, slippage-kurven og det faktum at limitordren din står bak andres ordre i køen. Du kan bomme på alle fire med tickdata og treffe på alle fire med 1-minuttsbarer. Oppløsning og ærlighet er uavhengige av hverandre.
Det siste tallet undervurderer folk. En backtest på ticknivå er ikke bare «den samme backtesten med flere rader». Handler på de fleste børser kommer inn i en annen rekkefølge enn tidspunktene da de registreres, blir korrigert i ettertid, fordeles på flere matching engine-sharder og – på flere handelsplasser vi har hentet data fra – av og til dupliseres eller faller helt bort ved gjenoppkobling. Å bygge en tickpipeline som faktisk er mer korrekt enn en godt bygget barpipeline, og ikke bare mer detaljert, er et reelt systemutviklingsprosjekt. De fleste team gjennomfører ikke det prosjektet. De kobler en backtester til en tickfil fra en leverandør og kaller det ferdig. Dermed bytter de ut et kjent og dokumentert sett med tilnærminger (OHLCV) mot et ukjent og udokumentert sett (det leverandørens logikk for avstemming av tickdata tilfeldigvis gjør på en dårlig dag).
Støyen du kjøper deg
En annen kostnad handler mindre om ingeniørarbeid og mer om statistikk. Enkeltstående handler veksler mellom bid- og ask-prisen – dette kalles bid-ask-sprett, og har vært et kjent fenomen i litteraturen om markedsmikrostruktur siden 1980-tallet. Hvis signalet ditt opererer raskere enn med noen sekunders mellomrom, kan backtesting på ticknivå få deg til å se mønstre i noe som egentlig bare er denne spretten. Jeg har sett en analytiker finne et vakkert mønster for gjennomsnittstilbakegang i data for hver enkelt handel. Det forsvant så snart dataene ble aggregert til selv 5-sekundersbarer, fordi mønsteret bare skyldtes spretten.
En kvantitativ analytiker jeg kjenner – tidligere market maker, nå med en liten kryptolommebok – sa det slik til meg: «Tickdata er et forstørrelsesglass. Retter du det mot fordelen din, flott. Retter du det mot støyen, bruker du seks måneder på å modellere støyen din på utsøkt vis.» Nå backtester han nesten alt på 1-sekunds- eller 1-minuttsbarer og går bare ned på ticknivå for å svare på det konkrete spørsmålet «ville denne limitordren faktisk ha blitt fylt?». Det handler om sannsynligheten for å få ordren fylt, ikke om signalet.
Det er riktig måte å tenke på, og det er nettopp dette de fleste som taler for tickdata overser. Den ærlige bruken av tickdata er ikke å kjøre hele strategien på dem, men å bruke dem målrettet for å besvare ett eller to spørsmål som bardata faktisk ikke kan svare på.
Når kritikerne har rett
Når det er sagt, finnes det strategier der tickdata er helt nødvendig, og jeg ville overdrevet argumentet om jeg lot som noe annet. Hvis du driver med noe som ligner market making – stiller priser på begge sider, håndterer beholdningen tick for tick og følger med på køposisjonen din på et bestemt prisnivå – kan ikke bardata beskrive problemstillingen din i det hele tatt. Hele økonomien i strategien utspiller seg i løpet av minuttet, ikke fra minutt til minutt. Det samme gjelder arbitrasje mellom handelsplasser der latenstid er avgjørende, og spørsmålet bokstavelig talt er «hvilken handel skjedde først», samt market making i opsjoner med store posisjoner, der noen hundre millisekunder med negativ seleksjon etter en handel avgjør alt. I slike situasjoner er backtesting på barer ikke en forenkling, men en kategorifeil. Du tester ikke en versjon av strategien med lavere oppløsning; du tester en annen strategi som tilfeldigvis har samme navn som den virkelige.
| Strategiens tidshorisont | Det bardata ikke viser | Kreves tickdata? |
|---|---|---|
| Market making / købasert | Sannsynlighet for utførelse, negativ seleksjon, køposisjon | Ja – helt nødvendig |
| Latenstid / arbitrasje på tvers av handelsplasser | Rekkefølgen på handler, hvilken handelsplass som beveget seg først | Ja |
| Intradag-momentum, gjennomsnittstilbakegang (minutter–timer) | Tidspunkt for utførelse innenfor baren, spreadkostnad | Bare for spørsmålet om sannsynlighet for utførelse, ikke signalet |
| Swing / flere dager, retningsbasert opsjonshandel | Nesten ingenting av betydning | Nei – barer er tilstrekkelige og ofte ryddigere |
Påstanden er altså ikke «tickdata er dårlig». Poenget er at det å gripe til tickdata ofte er en måte å unngå et vanskeligere og mindre glamorøst spørsmål på: Er kostnadsmodellen min riktig? Er antakelsene mine om utførelse riktige? Ville denne ordren faktisk blitt fylt, eller antar jeg at den ble fylt til en pris ordreboken aldri egentlig tilbød? Disse spørsmålene kan besvares med 1-minutts- eller til og med 1-sekundsbarer hvis du tar høyde for køposisjon og spread. Tickdata lar deg besvare dem mer presist, til flere ganger så høy ingeniørkostnad, i strategier der den ekstra presisjonen ikke endrer konklusjonen. Bruk den ekstra innsatsen der tidshorisonten faktisk krever det, og dropp den ellers. Det er en bedre bruk av forskningsteamets tid enn å velge de mest finkornede dataene som finnes, bare fordi høyere oppløsning føles grundigere.
← Alle innlegg
