Cea mai periculoasă eroare de sincronizare dintr-un backtest poate trece neobservată chiar și după un audit perfect al marcajelor de timp. Două evenimente pot indica ambele 10:00:00.000 și totuși să se fi produs într-o ordine pe care simulatorul tău a presupus-o.
Acest lucru contează ori de câte ori o strategie reacționează la mai mult decât bare încheiate: o actualizare a cotației, o tranzacție, o notificare de finanțare, o schimbare a stării bursei sau confirmarea propriului ordin. Un marcaj de timp îți spune când este etichetat un eveniment. S-ar putea să nu-ți spună când putea acționa strategia ta.
Ce schimbă ordinea evenimentelor?
Imaginează-ți o strategie care cumpără când cel mai bun preț ask scade sub $100.00. În aceeași milisecundă, fluxul de date înregistrează o actualizare a prețului ask la $99.99 și o tranzacție la $99.99. Dacă backtestul procesează mai întâi tranzacția și apoi cotația, strategia vede noul preț ask și trimite un ordin. Și procesarea cotației mai întâi poate fi în regulă, cu condiția ca evenimentul să fi fost disponibil în acel moment. Dar dacă tranzacția a consumat lichiditatea afișată înainte ca ordinul să ajungă, o execuție la $99.99 este fictivă.
Dacă sortezi rândurile doar după marcajul de timp, simulatorul trebuie să aleagă o ordine pentru evenimentele simultane. Ordinea din fișier, ordinea simbolurilor sau planul de execuție al unei interogări la baza de date pot deveni reguli accidentale de execuție. Curba capitalului propriu se poate schimba chiar dacă datele de la bază au rămas aceleași.
Iată o modalitate bună de a vedea cât de arbitrar poate deveni totul: sortează evenimentele cu aceeași oră după numele simbolului, în loc să le sortezi după ordinea sosirii. O strategie cu mai multe active se poate comporta atunci diferit doar pentru că un simbol bursier apare înaintea altuia la sortare.
Ceasurile pe care ar trebui să le păstreze un backtest
Datele de piață și gestionarea ordinelor implică adesea mai multe momente distincte. Păstrează câmpurile furnizate de sursa ta și denumește-le cu precizie. Pentru multe fluxuri de date, marcajul de timp al bursei și marcajul de timp local al recepției sunt ambele utile; niciunul nu reprezintă un adevăr universal despre ceea ce a văzut fiecare participant.
| Ceas | Ce înregistrează | Ce nu poate dovedi de unul singur |
|---|---|---|
| Ora evenimentului la bursă | Când spune platforma de tranzacționare că a avut loc un eveniment | Ordinea în care l-a observat un alt flux de date sau procesul tău |
| Ora recepției | Când a primit colectorul tău mesajul | Când a terminat strategia ta de procesat mesajul |
| Ora deciziei | Când codul tău a evaluat semnalul | Că prețul cotat era încă disponibil |
| Ora sosirii ordinului | Când putea bursa să acționeze asupra ordinului | O execuție, decât dacă regulile de matching și lichiditatea o susțin |
Pentru datele istorice fără ore de recepție, precizează ce presupui. Un backtest poate procesa evenimentele bursei în ordine și poate impune o întârziere fixă de 5 ms între decizie și sosirea ordinului. Acesta este un model, nu o reconstituire a istoricului. Dacă nu ai numere de secvență pentru marcajele de timp simultane de la bursă, și regula ta de departajare este tot o presupunere.
Cum modelez evenimentele simultane?
Mai întâi, păstrează numerele de secvență ale sursei, dacă există. Un număr de secvență oferă o ordine mai sigură în cadrul fluxului său decât un marcaj de timp, deși spațiile de secvență pot fi separate între canale sau produse.
Apoi, definește explicit regula de procesare a simulatorului. Pentru fiecare eveniment, decide dacă poate actualiza informațiile strategiei, modifica lichiditatea disponibilă, declanșa un ordin sau confirma un ordin. Acestea sunt acțiuni diferite; dacă le reduci la „procesează rândul”, se strecoară execuții imposibile.
- Aplică doar informațiile de piață care au sosit până la momentul deciziei strategiei.
- Generează ordinul, apoi avansează-l până la momentul modelat al sosirii la bursă.
- Permite execuția doar împotriva lichidității eligibile de după sosire, conform ipotezelor de execuție pentru tipul respectiv de ordin.
- Înregistrează datele de intrare, ordinea evenimentelor și întârzierea folosite pentru fiecare execuție simulată.
Pentru o strategie bazată pe bare, acest nivel de detaliu poate fi mai complex decât cere întrebarea. Dacă semnalul folosește bare încheiate de 1-minute, iar ordinele se execută la deschiderea barei următoare, cu un model conservator al costurilor, ordinea evenimentelor la nivel de submilisecundă probabil nu va schimba concluzia cercetării. Ideea este să potrivești nivelul de detaliu temporal cu afirmația pe care o face backtestul.
Pot avea încredere într-un backtest fără date despre ora sosirii?
Îl poți folosi în continuare, dar ține cont de limitele lui. Dacă strategia tranzacționează lent și are limite de risc largi, câteva milisecunde pot fi neglijabile. Dacă reacționează la cotații efemere, concurează pentru poziția în coadă sau depinde de un semnal lead-lag între burse, lipsa orelor de sosire poate fi esențială pentru rezultat.
Criticii au dreptate că sincronizarea precisă a evenimentelor poate crea o falsă impresie de precizie. Fluxurile istorice sunt incomplete, ceasurile se decalibrează, iar marcajele de timp ale bursei nu dezvăluie fiecare salt prin rețea. Un simulator cu câmpuri la nivel de nanosecundă poate face totuși presupuneri grosiere despre execuții.
Așadar, testează sensibilitatea în loc să pretinzi că ai certitudini: reia simularea cu reguli plauzibile de departajare a evenimentelor și întârzieri ale ordinelor, apoi compară numărul de tranzacții, prețul de execuție și semnalele care rămân valide. Dacă rezultatul depinde de o ordine pe care datele nu o pot stabili, include această dependență în raportul de cercetare. Un backtest poate fi util chiar și cu un ceas imperfect. Trebuie doar să recunoască ce știe cu adevărat despre timp.
← Toate articolele
