Datele tick nu-ți salvează backtestul — pentru majoritatea strategiilor, îl înrăutățesc

Sfatul standard este: dacă vrei un backtest onest, obține date tick. Eu cred că sfatul acesta este greșit pentru majoritatea strategiilor și, de regulă, dacă îl urmezi, backtestul devine mai slab, nu mai bun. Nu pentru că datele tick ar fi inexacte — sunt cele mai exacte date pe care le poți obține — ci pentru că majoritatea oamenilor le folosesc ca să înlocuiască rigoarea cu rezoluția, iar cele două nu sunt același lucru.

Iată cum se ajunge aici. Un cercetător construiește o strategie pe bare de 1 minut, obține un Sharpe care îi place, iar cineva — un mentor, o postare pe un forum sau propriile îndoieli persistente — îi spune că backtestul nu e onest fiindcă se bazează pe bare. Așa că reconstruiește întregul flux de lucru pe date tick: fiecare tranzacție, fiecare actualizare a cotațiilor, cu marcaje temporale la nivel de microsecundă. Backtestul rulează mai lent, codul devine de trei ori mai complex, iar Sharpe-ul... abia se schimbă sau se mișcă într-o direcție pe care nimeni n-o poate explica. Totuși, îl lansează, fiindcă datele tick par mai riguroase, iar impresia de rigoare nu e același lucru cu rigoarea.

Ce îți oferă, de fapt, rezoluția tick

Datele tick îți arată succesiunea și prețul fiecărei tranzacții și, dacă plătești pentru ele, fiecare actualizare a registrului de ordine. Asta înseamnă informații reale. Poți reconstitui poziția în coadă, estima probabilitatea de execuție la un anumit nivel de preț și observa selecția adversă — dacă piața se mișcă împotriva ta imediat după execuția ipotetică. Toate acestea contează enorm dacă perioada ta de deținere se măsoară în secunde, iar avantajul tău în fracțiuni de tick.

Dar majoritatea strategiilor pe care le vedem la Stratmill — și majoritatea celor folosite efectiv de cercetătorii retail și semi-profesioniști — mențin pozițiile de la câteva minute la câteva zile. La acest orizont, onestitatea backtestului nu depinde de modelarea celei de-a 40-a tranzacții dintr-un anumit minut. Depinde de modelarea spreadului, a ratei de funding, a curbei de slippage și a faptului că ordinul tău limită stă în coadă în spatele ordinelor altora. Poți greși toate cele patru lucruri folosind date tick și le poți modela corect pe bare de 1 minut. Rezoluția și onestitatea sunt independente.

Ultima cifră este cea pe care oamenii o subestimează. Un backtest la nivel tick nu înseamnă doar „același backtest, cu mai multe rânduri”. Pe majoritatea burselor, tranzacțiile ajung în altă ordine decât cea indicată de marcajele temporale de ingestie, sunt corectate retroactiv, sunt împărțite între mai multe fragmente ale motorului de potrivire și — pe câteva platforme de la care am ingerat date — uneori sunt duplicate sau dispar complet la reconectare. Să construiești un flux tick care să fie cu adevărat mai corect decât un flux de bare bine construit, nu doar mai granular, este un proiect serios de sisteme. Majoritatea echipelor nu fac acest proiect. Îndreaptă un backtester spre fișierul tick al unui furnizor și consideră treaba încheiată. Astfel, înlocuiesc un set cunoscut și documentat de aproximări (OHLCV) cu unul necunoscut și nedocumentat: orice face logica furnizorului pentru reconcilierea datelor tick într-o zi proastă.

Zgomotul pe care îl cumperi

Există și un al doilea cost, care ține mai puțin de inginerie și mai mult de statistică. Execuțiile individuale oscilează între bid și ask — acesta este fenomenul bid-ask bounce, un artefact cunoscut în literatura despre microstructura pieței încă din anii 1980. Dacă semnalul tău operează la un interval mai scurt de câteva secunde, backtestingul la nivel tick te poate face să vezi o structură care nu e, de fapt, decât acest efect de oscilație. Am văzut un cercetător descoperind un tipar superb de revenire la medie în datele tranzacție cu tranzacție, care a dispărut imediat ce a agregat datele în bare de numai 5 secunde, fiindcă tiparul era doar efectul bid-ask bounce.

Un quant pe care îl cunosc — fost market maker, acum administrează un portofoliu crypto mic — mi-a spus-o așa: „Datele tick sunt o lupă. Dacă o îndrepți spre avantajul tău, grozav. Dacă o îndrepți spre zgomot, vei petrece șase luni modelându-ți impecabil zgomotul.” Acum face backtest aproape pentru orice pe bare de 1 secundă sau 1 minut și trece la date tick doar pentru întrebarea precisă „s-ar fi executat, de fapt, ordinul meu limită?”, care ține de probabilitatea de execuție, nu de semnal.

Această delimitare este instinctul corect și e tocmai lucrul pe care majoritatea susținătorilor datelor tick îl ignoră. Folosirea onestă a datelor tick nu înseamnă să rulezi întreaga strategie pe ele, ci să le folosești punctual pentru una sau două întrebări la care datele pe bare chiar nu pot răspunde.

Când criticii au dreptate

Acestea fiind spuse, există strategii pentru care datele tick sunt obligatorii, iar dacă aș pretinde contrariul, aș exagera. Dacă faci ceva asemănător cu market making — cotezi ambele părți, gestionezi inventarul tick cu tick și te interesează poziția în coadă la un anumit nivel de preț — datele pe bare nu pot reprezenta deloc problema ta. Întreaga economie a strategiei se desfășoară în interiorul minutului, nu de la un minut la altul. La fel și în arbitrajul statistic sensibil la latență între platforme, unde întrebarea este literalmente „care tranzacție a avut loc prima”, și în market making-ul pe opțiuni cu volume mari, unde câteva sute de milisecunde de selecție adversă după o execuție fac toată diferența. În aceste situații, backtestingul pe bare nu este o simplificare, ci o eroare de categorie: nu testezi o versiune cu rezoluție mai mică a strategiei tale, ci o altă strategie care doar poartă același nume ca cea reală.

Așadar, afirmația nu este că „datele tick sunt proaste”. Ci că recurgerea la ele este adesea o modalitate de a evita o întrebare mai dificilă și mai puțin spectaculoasă: este corect modelul meu de costuri? Este corectă presupunerea privind execuția? Ordinul acesta chiar s-ar fi executat sau presupun că am obținut un preț pe care registrul de ordine nu mi l-a oferit niciodată cu adevărat? Poți găsi răspunsuri la aceste întrebări folosind bare de 1 minut sau chiar de 1 secundă, dacă ții cont cu onestitate de poziția în coadă și de spread. Datele tick permit răspunsuri mai precise, cu un cost de inginerie de câteva ori mai mare, în cazul strategiilor pentru care precizia în plus nu schimbă concluzia. Investește efortul suplimentar acolo unde orizontul chiar îl cere și renunță la el în rest — e o folosire mai bună a timpului unei echipe de cercetare decât să alegi implicit datele cu cea mai mare granularitate doar fiindcă par mai riguroase.