Co to jest Last Look i jak to ująć w mierzalnych kategoriach
Last Look w Forexie to mechanizm, w którym zlecenie może zostać wstępnie zaakceptowane do realizacji, ale później odrzucone (lub niezrealizowane) po krótkiej weryfikacji przez dostawcę płynności. Aby to mierzyć, przekładasz tę koncepcję na obserwowalne zdarzenia i rejestrowalne pola. Takie podejście oddziela stosunkowo stabilne mechaniki (jakie decyzje zapadają i kiedy) od zmiennych warunków (ruch rynku, koszty i decyzje implementacyjne).
Praktyczny sposób zdefiniowania tego pod pomiar to śledzenie każdego podjętego zlecenia jako zdarzenia z co najmniej tymi polami:
- Znacznik czasu zlecenia (t_order): kiedy uważasz, że wysłano żądanie.
- Znacznik czasu wyceny lub podstawy ceny (t_quote): kiedy obserwowano cenę używaną do żądania.
- Wynik decyzji: accepted/executed lub rejected/not executed.
- Opóźnienie decyzji (Δt): czas między odpowiednią podstawą ceny a ostatecznym wynikiem.
- Cena realizacji i prowizje/opłaty (jeśli zrealizowane): ostateczna cena wypełnienia oraz wszelkie koszty, które możesz bezpośrednio przypisać.
Jeśli nie możesz obserwować wszystkich tych pól z własnych logów, powinieneś mierzyć tylko to, co jesteś w stanie zweryfikować, i wyraźnie zaznaczyć, czego brakuje.
Jak mierzyć to za pomocą akceptacji, czasu i metryk jakości ceny
Typowym celem pomiaru jest ilościowe określenie zarówno częstotliwości, jak i czasu/jakości.
1) Wskaźniki akceptacji i odrzucenia
Dla próby podjętych zleceń możesz obliczyć:
- Acceptance rate = zrealizowane zlecenia / łączna liczba podjętych zleceń
- Rejection rate = odrzucone zlecenia / łączna liczba podjętych zleceń
Potrzebne założenie: definiujesz „podjęte” w sposób spójny (na przykład: każde zlecenie, które dotarło do dostawcy, a nie zostało anulowane lokalnie przed wysłaniem). Bez tego wskaźniki mogą wprowadzać w błąd.
2) Rozkład opóźnień
Dla wyników zrealizowanych i/lub odrzuconych oblicz opóźnienie na podstawie pól, którym ufasz:
- Decision latency (Δt) = t_outcome − t_quote (albo − t_order, zależnie od tego, co możesz uzasadnić)
Następnie podsumuj to za pomocą percentyli (na przykład: mediana, 90. percentyl, 99. percentyl). To mierzy, czy decyzje skupiają się wokół krótkich interwałów, czy wydłużają się w określonych warunkach.
Potrzebne założenie: t_quote i t_outcome muszą pochodzić z porównywalnych zegarów i etapów przetwarzania. Jeśli znaczniki czasu są generowane przez różne systemy z różnymi opóźnieniami, Twoje Δt nie będzie dokładnym odzwierciedleniem wewnętrznego sprawdzania dostawcy.
3) Porównanie jakości ceny w momencie decyzji
Aby mierzyć „jakość ceny” bez zakładania przyszłej przewidywalności, porównuj, jak cena realizacji (gdy zrealizowane) odnosi się do podstawy ceny użytej w momencie wprowadzenia danych do decyzji.
Jeden z przykładów metryki to:
- Price difference = execution_price − reference_price
Potrzebne założenie: reference_price jest zdefiniowane i rejestrowane w sposób spójny (ten sam typ wyceny, ten sam moment i te same reguły zaokrąglania). Ponieważ rynek porusza się w sposób ciągły, nawet poprawna referencja może być przestarzała o milisekundy; Twoja metryka mierzy relację między realizacją a wybraną przez Ciebie referencją, a nie „uczciwą wartość” dostawcy.
4) Porównania warunkowe
Aby zmniejszyć ryzyko, że ruch rynku wpływa na wszystko, grupuj zdarzenia według mierzalnych warunków, takich jak:
- okno czasowe (przykład: przed/po określonej sesji rynkowej)
- proxy zmienności, które obliczasz na podstawie własnego feedu cenowego
- koszyki wielkości zlecenia (jeśli je rejestrujesz)
Wymóg podobieństwa: każdy koszyk powinien zawierać wystarczającą liczbę zdarzeń, a Twoje koszyki muszą używać tych samych definicji czasu referencyjnego i wyników.
Dowody i tryby awarii: co może zepsuć pomiar
Pomiar może się nie udać na kilka istotnych sposobów. Co najmniej jedno częste ograniczenie to brakujące lub niespójne znaczniki czasu.
Ograniczenie: możesz nie obserwować tego samego zegara decyzji
Jeśli t_quote pochodzi z feedu, a t_outcome z systemu zarządzania zleceniami, mogą występować opóźnienia w obie strony. Wtedy Twoje mierzone Δt odzwierciedla opóźnienia w pipeline i oprogramowaniu, a nie czas decyzji Last Look po stronie dostawcy.
Ograniczenie: „odrzucenie” może mieć wiele znaczeń
Pozorne odrzucenie może wynikać z:
- decyzji Last Look
- lokalnego anulowania z powodu przekroczenia czasu
- odrzucenia z powodu ograniczeń realizacji lub testów ryzyka, których nie modelowałeś
Aby traktować odrzucenia jako wyniki Last Look, musisz rozdzielić je na podstawie definicji z własnych logów (na przykład: odrębne kody statusu). W przeciwnym razie wskaźniki akceptacji/odrzucenia mieszają różne mechanizmy.
Ograniczenie: warunki rynkowe dominują na krótkich horyzontach
Nawet przy poprawnych znacznikach czasu i jasnych definicjach, wyniki na krótkim horyzoncie różnią się w zależności od warunków rynkowych, kosztów transakcyjnych i miejsc realizacji. Historyczne wskaźniki akceptacji oraz rozkłady różnic cen nie ustanawiają przyszłych wyników.
Weryfikacja i kolejne pytanie, aby pomiar był wiarygodny
Niezależna weryfikacja wynika z audytu Twoich definicji i odtworzenia osi czasu zdarzeń.