Strategia przeszła testy. Potem giełda zmieniła krok notowania.

We wtorek o 08:00 UTC platforma kryptowalutowa zmieniła krok notowania kontraktu perpetual o średniej cenie. Nasza strategia bazowa tego nie zauważyła. Sygnał nadal widział ten sam spread między rynkiem spot a kontraktami futures, limity ryzyka pozostały bez zmian, a backtest wciąż pokazywał te same wyniki.

Paper trading to wychwycił. Adapter zleceń zaokrąglił kupno z limitem w dół do najbliższej dozwolonej ceny. Zlecenie znalazło się o 1 tick poniżej poziomu przyjętego w backteście. Rynek dotknął poprzedniej ceny, zlecenie symulowane zostało zrealizowane, a zlecenie w paper tradingu pozostało nietknięte. Do południa pozycja strategii była już nierównomiernie rozłożona.

Incydent wyglądał na drobny błąd zaokrąglania. W rzeczywistości problem leżał na granicy modelu: strategia znała ceny, ale backtest nie znał siatki cenowej platformy.

Handlowaliśmy na prostym sygnale bazowym: kupowaliśmy spot i sprzedawaliśmy kontrakt perpetual, gdy premia futures przekraczała próg. Zlecenia były pasywne, ponieważ oczekiwana przewaga z bazy była niewielka. Kilka ticków mogło przesądzić o tym, czy zysk z wejścia wystarczy na pokrycie opłat i późniejszego wyjścia.

Co się zmieniło wraz ze zmianą kroku notowania?

Przed aktualizacją kontrakt perpetual akceptował ceny ze skokiem co 0.01. Potem, w odpowiednim przedziale cenowym, akceptował ceny ze skokiem co 0.05. Sygnał wyliczył docelową cenę sprzedaży 42,318.03, prawidłową według poprzedniej zasady. Według nowej była nieprawidłowa.

Giełda odrzucała nieprawidłowe ceny, ale nasz adapter miał mechanizm awaryjny: zaokrąglał cenę sprzedaży w dół do 42,318.00. Ta cena również była nieprawidłowa. Drugi mechanizm awaryjny zaokrąglał ją ponownie, tym razem do 42,318.05. Ta cena była prawidłowa, ale dla sprzedającego mniej agresywna. Zlecenia nie dało się już sprzedać po cenie przyjętej w modelu. Ta ścieżka kodu powstała z myślą o innym rynku i po cichu zamieniała odrzucenie zlecenia w zmianę jego ceny.

To jedno zlecenie poruszyło dwie odrębne kwestie. Po pierwsze: jaką cenę platforma może zaakceptować? Po drugie: jak strategia powinna zareagować, gdy żądana cena nie mieści się w siatce? Na pierwsze pytanie odpowiada giełda. Na drugie musi odpowiedzieć strategia lub polityka realizacji.

Nie ma jednej, zawsze poprawnej zasady zaokrąglania. Zaokrąglenie ceny kupna w dół pozwala zachować limit ceny kupującego, ale może zmniejszyć szansę realizacji. Zaokrąglenie w górę może sprawić, że zlecenie będzie wykonalne od razu, co zmienia opłaty i wpływ na rynek. W przypadku naszego pasywnego wejścia na rynku bazowym cicha zmiana zlecenia była niewłaściwa. Strategia wybrała cenę docelową, a adapter zmienił jej ekonomikę.

Dlaczego backtest nadal wyglądał dobrze?

Nasz historyczny symulator zleceń traktował ceny z limitem jako wartości ciągłe. Jeśli minimum świecy osiągało cenę kupna albo maksimum świecy osiągało cenę sprzedaży, uznawał zlecenie za zrealizowane. To już samo w sobie dość optymistyczne przybliżenie dla zlecenia pasywnego, bo cena transakcji równa limitowi nic nie mówi o miejscu w kolejce. Zmiana kroku notowania ujawniła jednak bardziej podstawowy problem: takie zlecenie w ogóle nie mogło istnieć po tej cenie.

Odtworzyliśmy te same decyzje, stosując nową siatkę od chwili jej wejścia w życie. Kilka realizacji zniknęło. Część zleceń została zaokrąglona do cen przechodzących przez spread, przez co naliczono opłaty takera zamiast makera. W rezultacie zmieniła się ścieżka pozycji, a wraz z nią późniejsze zabezpieczenia i wyjścia. Zasada, która wyglądała na metadane, zmieniła całą sekwencję transakcji.

Aktualizacja nie była niespodzianką ukrytą na wykresie. Platforma opublikowała zmianę zasad dotyczących instrumentu z datą i godziną wejścia w życie. Starannie przechowywaliśmy dane rynkowe, ale metadane instrumentów znajdowały się w pamięci podręcznej odświeżanej przy uruchomieniu. Backtest odczytywał dzisiejsze zasady dla każdej daty historycznej, a paper trading korzystał z nieaktualnych zasad aż do ponownego uruchomienia procesu. Żadne z tych środowisk nie odzwierciedlało tego, na co platforma pozwalała w danym momencie.

Jak uwzględniać zmiany kroku notowania w backteście?

Wersjonuj zasady dotyczące instrumentów, określając przedziały ich obowiązywania, tak jak w przypadku innych danych dostępnych w danym momencie. Zachowuj co najmniej czas wejścia w życie oraz wartości potrzebne do weryfikacji zlecenia: krok notowania, krok ilości, minimalną ilość i wszelkie przedziały cenowe. Symulator powinien wczytywać zestaw zasad obowiązujący w chwili podejmowania symulowanej decyzji.

Jawnie określ też obsługę zleceń. Jeśli cena docelowa jest nieprawidłowa, odrzuć zlecenie, zaokrąglij cenę według udokumentowanej polityki albo przelicz cenę docelową tak, by mieściła się w siatce. Zapisuj, co się wydarzyło. Backtest, który automatycznie naprawia każde zlecenie, może pomóc w oszacowaniu wyników konkretnej polityki realizacji, ale nie powinien przedstawiać tej polityki jako realizacji giełdowej.

Dodaliśmy dwie kontrole. Pierwsza sprawdza każde wygenerowane zlecenie według zasad dotyczących instrumentu obowiązujących w danym momencie i zgłasza błąd, jeśli cena lub ilość są nieprawidłowe. Druga porównuje końcowe, znormalizowane zlecenie z backtestu i adaptera paper tradingu: stronę, cenę, ilość, czas obowiązywania i sposób naliczania opłat. Jeśli się różnią, uznajemy, że przebiegi nie są porównywalne.

Potem ponownie odtworzyliśmy wtorkową zmianę. Backtest przestał przypisywać realizacje po 42,318.03 po aktualizacji siatki. Paper trading i symulacja podejmowały tę samą decyzję w sprawie każdej nieprawidłowej ceny docelowej, nawet jeśli oznaczało to pominięcie zlecenia.

Sygnał się nie zepsuł. Zdezaktualizowały się jego założenia na temat instrumentu, którym można handlować. Strategia może przetrwać zmianę kroku notowania, ale tylko wtedy, gdy system badawczy uwzględnia zasady platformy jako część symulowanego rynku.