Realizacja zleceń — jak mierzyć czas i jakość

Oddziel wysłanie, przyjęcie i wykonanie

Kliknięcie przycisku nie jest potwierdzeniem zawarcia transakcji. Komunikat dociera do brokera, przechodzi kontrole, a następnie może zostać wykonany, częściowo wykonany albo odrzucony. Informacja zwrotna dociera do platformy później. Czas widoczny u użytkownika i czas samego wykonania po stronie serwera opisują różne odcinki tego procesu.

Dlatego „20 ms” w reklamie wymaga definicji: od jakiego zdarzenia do jakiego, na jakiej próbie i dla których zleceń? Ping, czas akceptacji oraz czas do otrzymania potwierdzenia nie są zamiennymi miarami. Także informacja o serwerze w określonym centrum danych nie przesądza o cenie, płynności i pełnym czasie realizacji.

Tryb wykonania nie gwarantuje transakcji

Dokumentacja MetaTrader 5 rozróżnia m.in. Instant, Request, Market i Exchange Execution. W Instant broker może przyjąć żądaną cenę albo zaproponować nową. Market oznacza zgodę na cenę ustaloną w tym trybie bez ponownego uzgadniania. Nie oznacza jednak gwarancji wejścia: pozostają kontrole, dostępność rynku i warunki realizacji.

Nie wybierasz dowolnego trybu dla każdego instrumentu — dostępność wynika z ustawień brokera. Typ zlecenia i zasady częściowego wykonania także mają znaczenie. Przykładowo wymóg wykonania całego wolumenu może prowadzić do niewykonania, gdy dostępna wielkość jest niewystarczająca. Nie utożsamiaj „bez rekwotowań” z „bez poślizgu i odrzuceń”.

Pięć pipsów względem którego kursu?

Przykład hipotetyczny: wysyłasz kupno EUR/USD, gdy właściwy ask wynosi 1,08500. Kupno zostaje wykonane po 1,08550. Pogorszenie względem tego ask wynosi 0,00050, czyli 5 pipsów. Przy 100 000 EUR to 50 USD, a przy 10 000 EUR — 5 USD. Nie jest to szacunek typowego poślizgu podczas danych.

Dla sprzedaży korzystniejsza jest cena wyższa, więc znak oceny się odwraca. Cena odniesienia musi mieć określony moment: zobaczenie kwotowania, wysłanie zlecenia lub przyjęcie na serwerze. Różne momenty odpowiadają na różne pytania. Bez tego porównanie dwóch brokerów może mierzyć głównie różnice źródeł i zegarów.

Jak zbudować użyteczny pomiar?

Zachowaj identyfikator zlecenia, instrument, stronę, wolumen, typ, żądaną cenę, dostępne znaczniki czasu, status oraz wykonania. Sprawdź strefę czasową, dokładność i pochodzenie każdego czasu. Log terminala może rejestrować odebranie wiadomości zamiast momentu zawarcia transakcji na serwerze. Nie odejmuj bezrefleksyjnie czasów z różnych zegarów.

Rozdziel próby z innych godzin, instrumentów i rozmiarów. Obok mediany pokaż rozrzut i najwolniejsze przypadki; liczbę odrzuceń podziel przez wszystkie porównywalne żądania. Dane obejmujące wyłącznie wykonane transakcje ukrywają ważną część doświadczenia użytkownika. Zapisz też wersję platformy i ewentualne problemy połączenia.

Hipotetycznie 95 wykonanych zleceń z 100 daje 95% udziału wykonań, ale nie dowodzi dobrej jakości. Pozostałe pięć mogło dotyczyć najważniejszych wejść, a ceny pozostałych mogły być niekorzystne. Z kolei sama mediana 30 ms nie ujawnia kilku odpowiedzi trwających sekundy. Mierz kilka aspektów razem i nie uogólniaj z kilku dni.

Co oznacza najlepsza realizacja?

Artykuł 27 MiFID II uwzględnia cenę, koszty, szybkość, prawdopodobieństwo wykonania i rozliczenia oraz cechy zlecenia. Dla klienta detalicznego najlepszy wynik jest określany przez łączną cenę i koszty związane z wykonaniem. Nie jest to zasada jednakowej wagi wszystkich kryteriów ani obietnica najniższej możliwej ceny każdego zlecenia.

Konkretne instrukcje klienta mogą ograniczyć sposób wykonania w objętym nimi zakresie. Przeczytaj politykę brokera i rozdziel wymagania prawne od jego deklaracji marketingowych. W dokumentacji IC Markets EU proces oceny jakości obejmuje również odrzucenia i różnice wykonania; sama szybkość nie wyczerpuje porównania.

Demo, zlecenia oczekujące i VPS mają ograniczenia

Demo może pomijać poślizg i ograniczenia realizacji. Zlecenie oczekujące ogranicza potrzebę ręcznej reakcji, ale stop nie gwarantuje ceny wykonania, a limit nie gwarantuje realizacji. VPS może skrócić część opóźnienia lub utrzymać działanie programu, lecz nie zapewnia płynności. Każde narzędzie rozwiązuje tylko część problemu.

Wynik swing tradera także zależy od kosztów wykonania, nawet jeśli są one mniejsze względem celu. Większy planowany ruch nie uzasadnia ignorowania powtarzających się odchyleń. Więcej o ograniczeniach symulacji znajdziesz w porównaniu demo i live, a o składnikach kosztu w rachunku spreadu i prowizji.

Kiedy wyjaśniać problem z brokerem?

Przy powtarzalnych niezgodnościach zbierz logi i konkretne numery zleceń, a następnie poproś o wyjaśnienie ceny, czasu i przyczyny odrzucenia. Sama asymetria próby nie dowodzi manipulacji: znaczenie mają kierunki ruchu, rodzaje zleceń i sposób wyboru obserwacji. Nie oznacza też, że problem można z góry zignorować. Uporządkowane dane pomagają w reklamacji lepiej niż sam zrzut świecy.

Ujemne opóźnienie może wynikać z dwóch zegarów

Własny hipotetyczny zapis używa sekund od umownego początku pomiaru. Terminal wysyła zlecenie przy 100,000 i odbiera odpowiedź przy 100,070. Serwer zapisuje przyjęcie 99,970 i wykonanie 100,010. Jego zegar jest w tym modelu przesunięty o −40 ms względem terminala; nie opisujemy rzeczywistego brokera.

Odjęcie czasu wysłania od czasu przyjęcia dałoby −30 ms. To błąd łączenia zegarów, nie podróż komunikatu w przeszłość. Natomiast czas przetwarzania na jednym zegarze wynosi 40 ms, a pełny czas odpowiedzi na zegarze terminala 70 ms. Różnica 30 ms obejmuje łącznie pozostałe odcinki modelu, nie ujawnia oddzielnie drogi do serwera i z powrotem.

Po dodaniu znanego modelowego przesunięcia do znaczników serwera otrzymujemy przyjęcie 100,010 i wykonanie 100,050. Drogi komunikacji wynoszą wtedy 10 oraz 20 ms. Rzeczywistego przesunięcia nie wolno jednak dobierać tylko tak, aby wynik wyglądał wiarygodnie. RFC5905 rozróżnia przesunięcie zegara i opóźnienie komunikacji. Do reklamacji zapisz źródła znaczników oraz niepewność synchronizacji; gdy ich nie znasz, podawaj wyłącznie miary, które da się odtworzyć.