Poślizg: czym jest i co sprawdzić, zanim go zweryfikujesz
Poślizg to różnica między ceną, po której spodziewasz się zrealizować zlecenie, a ceną, po której jest ono faktycznie realizowane. W prostych słowach: jeśli zlecenie zostanie wypełnione gorzej niż oczekiwano, poślizg jest dodatni; jeśli zostanie wypełnione lepiej niż oczekiwano, poślizg może być ujemny. Weryfikacja zaczyna się od definicji, ponieważ „oczekiwana cena” może oznaczać różne rzeczy (na przykład notowanie w momencie wysłania, notowanie w chwili przyjęcia zlecenia albo pierwszą dostępną cenę, gdy zlecenie staje się możliwe do realizacji).
Aby zweryfikować informacje o poślizgu, najpierw spisz dokładne pola, których używasz: strona zlecenia (kup/sprzedaj), cena odniesienia dla „oczekiwanej”, faktyczne ceny wypełnienia oraz mapowanie czasu między nimi. Bez tego różne strony mogą wygenerować niekompatybilne liczby „poślizgu”, mimo że używają tego samego słowa.
Hierarchia źródeł, którą możesz zastosować do twierdzeń o poślizgu
Gdy widzisz stwierdzenie dotyczące poślizgu, możesz je zweryfikować, preferując bardziej konkretne dowody zamiast podsumowań:
- Pierwotne zapisy realizacji (najbardziej bezpośrednie): logi zleceń i transakcji zawierające oczekiwaną/cenę odniesienia, wykonane ceny, ilości oraz znaczniki czasu.
- Dokumentacja platformy lub dostawcy (stabilne definicje): wyjaśnienia, jak generowane są wypełnienia, jak rejestrowane są znaczniki czasu, co oznacza „quote” oraz jak obsługiwane są częściowe wypełnienia.
- Opisy metodologii (warstwa interpretacji): dokumenty lub wyjaśnienia definiujące, jak poślizg jest liczony na podstawie bazowych zapisów.
- Zagregowane podsumowania (najmniej bezpośrednie): pulpity lub średnie. Są przydatne jako kontekst, ale trudniej je zweryfikować, ponieważ szczegóły obliczeń mogą być ukryte.
Ta hierarchia ma znaczenie, ponieważ weryfikacja jest najłatwiejsza, gdy możesz zacząć od surowych logów i odtworzyć zgłoszone obliczenie poślizgu.
Kroki weryfikacji, które da się odtworzyć (bez danych w czasie rzeczywistym)
Postępuj według powtarzalnej checklisty, używając własnych zapisów lub dowolnego zestawu danych, który zawiera niezbędne pola.
1) Jawnie określ założenia
Wybierz i zapisz:
- Definicja oczekiwanej ceny: np. „notowanie w momencie złożenia zlecenia” albo „najlepsza możliwa do zrealizowania cena w chwili przyjęcia”.
- Którą cenę wykorzystać: dla zlecenia kup użyj ceny odniesienia wyprowadzonej z ask; dla zlecenia sell użyj ceny odniesienia wyprowadzonej z bid. Jeśli zestaw danych dostarcza pojedynczą wartość „oczekiwanej”, zachowaj jej użycie.
- Jednostka miary: bezwzględna różnica ceny albo punkty bazowe / procent oczekiwanej ceny.
Założenia nie są opcjonalne; są częścią tego, co weryfikujesz.
2) Licz poślizg dla każdego wypełnienia, a nie tylko dla zlecenia
Jeśli zlecenie może zostać wypełnione częściowo, oblicz poślizg dla każdego wypełnienia, a następnie zdecyduj, jak go zagregować (zwykle ważone ilością zrealizowaną). Typową przyczyną błędu jest porównywanie jednej oczekiwanej ceny z zagregowaną średnią ceną wypełnienia bez potwierdzenia metody uśredniania.
3) Sprawdź zgodność mapowania znaczników czasu
Upewnij się, że „oczekiwana” i „faktyczna” są porównywane przy użyciu spójnego czasu:
- Jeśli oczekiwana cena pochodzi z jednego zdarzenia czasowego, a cena realizacji z innego, opisz dokładną regułę mapowania.
- Jeśli zestaw danych ma różne źródła znaczników czasu (czas serwera vs. czas klienta), potraktuj to jako ograniczenie weryfikacji.
4) Sprawdź, czy zgłaszane liczby da się odtworzyć
Jeśli dostawca raportuje statystyki poślizgu, spróbuj je odtworzyć na podstawie bazowych zapisów:
- Przelicz każdą wartość poślizgu, używając podanego wzoru.
- Następnie ponownie policz statystykę zagregowaną (średnia, mediana, przedziały rozkładu) tą samą metodą.
Jeśli odtworzenie jest niemożliwe, jest to dowód na brakujące pola, inną definicję albo ukrytą transformację.
Ograniczenia i tryby awarii, których powinieneś się spodziewać
Nawet przy starannych krokach weryfikacja poślizgu może się nie udać z powodów, które wynikają z samej natury danych realizacyjnych i zachowania rynku:
- Ruch rynku: oczekiwana cena jest migawką; realizacja następuje później, więc zmiany ceny mogą powodować poślizg nawet przy identycznych warunkach operacyjnych.
- Niekompletne lub niespójne zapisy: niektóre strumienie mogą pomijać zdarzenia przyjęcia zlecenia albo nie zawierać „quote” użytego do oczekiwań.
- Częściowe wypełnienia i bias agregacji: uśrednianie wielu wypełnień może ukryć segmenty, w których poślizg się pogarsza, oraz te, w których się poprawia.
- Niezgodność znaczników czasu: różnice w sposobie rejestrowania czasu mogą zniekształcać porównania.
- Definicje specyficzne dla dostawcy: dwie strony mogą twierdzić, że mierzą „poślizg”, ale używają różnych punktów odniesienia.
Dodatkowo, relacje historyczne (na przykład „średni poślizg z ostatniego miesiąca”) opisują przeszłe wzorce realizacji. Nie ustanawiają one tego, co wydarzy się w przyszłych warunkach.
DOCUMENT END