Częste błędy z API brokerów

Co ludzie rozumieją źle w kwestii API brokera

API brokera to interfejs (zwykle programistyczny), który pozwala oprogramowaniu wysyłać żądania do brokera/miejsca wykonania i otrzymywać odpowiedzi, takie jak potwierdzenia zleceń, realizacje i aktualizacje związane z kontem. Częste błędy pojawiają się, gdy programiści traktują ten interfejs jak pojedynczy, w pełni niezawodny potok, a nie jak system z wyraźnymi stanami, czasem i możliwymi scenariuszami awarii.

Główne nieporozumienia, na które należy uważać:

• Mylenie „przyjęcia żądania” z „wykonaniem transakcji”. API może potwierdzić, że Twoja wiadomość została odebrana, podczas gdy ostateczny wynik zależy od reguł wykonania.
• Zakładanie, że znaczniki czasu i ceny są zsynchronizowane. Różne systemy mogą używać różnych zegarów, cykli aktualizacji lub reprezentacji.
• Pomijanie różnicy między danymi rynkowymi, które widzisz, a danymi rynkowymi, które miały znaczenie dla wykonania. Wykonanie może zależeć od spreadów, płynności i zmian w księdze zamówień w momencie, gdy broker przetwarza Twoje zlecenie.
• Zapominanie, że koszty istnieją i mogą się różnić: prowizje, efekty finansowania/nocne i inne opłaty mogą zmienić wyniki netto.
• Traktowanie błędów jako rzadkich wyjątków. W praktyce API może zwracać przekroczenia czasu, odrzucone zlecenia, częściowe realizacje lub brakujące aktualizacje.

Mechanika: skąd biorą się błędy

API brokerów zazwyczaj obejmuje następujące elementy:

1. Tworzenie żądania: generujesz zlecenia i wybierasz parametry (instrument, ilość, typ, ważność i identyfikatory).
2. Transport i przetwarzanie: Twoje żądanie przemieszcza się przez sieć, jest uwierzytelniane i przetwarzane przez usługi brokera.
3. Aktualizacje stanu: broker odpowiada potwierdzeniami, a następnie publikuje zmiany statusu (np. otwarte → częściowo zrealizowane → zrealizowane/anulowane/odrzucone).
4. Raportowanie wykonania: realizacje i powiązane szczegóły księgowe są dostarczane w momencie wykonania.

Częste błędy implementacyjne w ramach tych elementów:

• Brak stabilnych identyfikatorów (lub używanie ich niespójnie). Bez jasnego identyfikatora po stronie klienta i spójnych zasad ponawiania, ponowne próby mogą tworzyć duplikaty.
• Ignorowanie oczekiwań dotyczących idempotencji. Jeśli ponowisz próbę po przekroczeniu czasu, możesz nie wiedzieć, czy broker już zadziałał.
• Sztywne zakładanie cyklu życia zleceń. Niektóre zlecenia mogą zostać odrzucone po przyjęciu, częściowo zrealizowane wielokrotnie lub anulowane zgodnie z regułami miejsca wykonania.
• Mieszanie wartości „szacunkowych” i „potwierdzonych”. Jeśli Twój system loguje obliczenia na podstawie migawki, a później porównuje je z zrealizowanymi transakcjami, rozbieżności są oczekiwane.

Dowody i przykładowe kontrole, które możesz przeprowadzić

Ponieważ wyniki są różne i nie zakłada się tutaj żadnych danych w czasie rzeczywistym, najbezpieczniejszym podejściem jest weryfikacja zachowania za pomocą kontrolowanych testów:

• Audyt maszyny stanów: Dla próbki zleceń testowych zarejestruj każdy komunikat/zdarzenie i upewnij się, że Twoja aplikacja przechodzi przez każdy stan, który obserwujesz (przyjęte, otwarte, częściowa realizacja, stan końcowy). Jeśli obserwowany stan nie występuje w Twojej logice, znalazłeś prawdopodobny błąd.
• Test ponawiania i duplikacji: Zasymuluj przekroczenie czasu sieci tuż po wysłaniu żądania zlecenia. Następnie sprawdź, czy broker utworzył jedno zlecenie czy wiele, i potwierdź, jak zachowują się Twoje identyfikatory klienta przy ponowieniu.
• Kontrola spójności księgowej: Dla każdego zdarzenia realizacji, które otrzymujesz, porównaj swoje założenia dotyczące wartości brutto/opłat z tym, co broker raportuje jako wyniki zrealizowane. Jeśli API udostępnia osobne pola dla opłat lub sald, używaj tych potwierdzonych wartości zamiast szacunków.
• Kontrola czasu i sekwencji: Zaloguj czas lokalny wysłania żądań i znaczniki czasu raportowane przez brokera (jeśli są dostępne). Poszukaj różnic w kolejności: może być konieczne sortowanie według czasu zdarzenia, a nie czasu przybycia.

Te kontrole nie gwarantują przyszłych wyników, ale bezpośrednio testują, czy założenia Twojego oprogramowania odpowiadają obserwowalnemu zachowaniu API brokera.

Ograniczenia, istotne tryby awarii i ryzyka

Głównym ograniczeniem jest to, że API brokerów działają w warunkach rzeczywistego świata: opóźnienia sieciowe, przeciążenie usług, reguły miejsca wykonania i zmienna płynność. Nawet poprawny kod może dawać inne wyniki niż wcześniejsze uruchomienia.

Co najmniej jeden istotny tryb awarii, na który należy się przygotować:

• Częściowe realizacje i opóźniona ostateczność: Twój system może zakładać, że zlecenie kończy się natychmiast. W rzeczywistości realizacje mogą być rozłożone w czasie, a ostateczny status może dotrzeć później.

Inne tryby awarii, które często powodują szkody:

• Odrzucone zlecenia z brakującym kontekstem: Jeśli traktujesz odrzucenia jako ogólne błędy, możesz stracić kategorię przyczyny potrzebną do naprawienia problemów z parametrami.
• Nieaktualne lub niekompletne aktualizacje: Możesz otrzymywać aktualizacje konta/zleceń poza kolejnością. Bez starannej rekonsyliacji możesz błędnie obliczać pozycje.
• Nieprawidłowe obliczenia wyników netto: Jeśli ignorujesz opłaty, zasady zaokrąglania lub konwencje kontraktów/marży, Twój wewnętrzny „oczekiwany P&L” może odbiegać od tego, co raportuje broker.