Jakie opłaty i spready sprawdzić przy dostępie API (i jak zweryfikować je niezależnie)

Bezpośrednia odpowiedź

W przypadku dostępu API należy sprawdzić (1) co dostawca publikuje jako koszty transakcyjne i koszty dostępu oraz (2) co może się zmienić między kwotowaniem, które widzisz, a ostatecznym kosztem ponoszonym przy realizacji zleceń. Kluczowa idea polega na oddzieleniu stabilnych, opublikowanych zasad cenowych (opłaty, tabele prowizji, zasady finansowania) od zmiennych wyników wykonania zależnych od warunków rynkowych, płynności i sposobu kierowania zleceń przez dostawcę.

Mechanizm lub definicja

Dostęp API oznacza, że Twój system transakcyjny wysyła zlecenia i otrzymuje informacje cenowe za pośrednictwem interfejsu programistycznego aplikacji. W takiej konfiguracji „spread” zwykle odnosi się do różnicy między cenami bid i ask w strumieniu danych lub kwotowań. „Opłaty” to koszty, które mogą zostać naliczone za korzystanie z usługi, takie jak:

• Prowizja lub opłata transakcyjna: opublikowany koszt zależny od wolumenu, typu zlecenia lub planu konta.
• Opłaty za dostęp lub platformę/API: opłaty za łączność, subskrypcje lub użytkowanie (jeśli występują).
• Koszty nietransakcyjne związane z pozycjami: na przykład koszty zależne od czasu utrzymywania pozycji (często opisywane jako finansowanie lub rolowanie).

Kluczowe rozróżnienie dotyczy opublikowanych zasad cenowych i zrealizowanych kosztów wykonania. Opublikowane zasady są na tyle stabilne, że można je odczytać z dokumentacji (na przykład „prowizja wynosi X za jednostkę”). Zrealizowane koszty zależą od tego, czy Twoje zlecenie zostanie wykonane po oczekiwanej cenie, jaka część zlecenia zostanie zrealizowana oraz jaki jest związek efektywnego bid/ask użytego do wykonania z kwotowaniami, które zaobserwowałeś.

Dowód lub przykład

Praktycznym sposobem sprawdzenia opłat i spreadów jest zbudowanie prostego modelu kosztów opartego na założeniach, a następnie przypisanie każdego składnika do czegoś, co można zweryfikować na podstawie dokumentacji i zaobserwowanych realizacji.

Przykładowe założenia (należy je jasno określić):

• Wielkość zlecenia (jednostki lub loty).
• Czy strategia wykorzystuje zlecenia rynkowe, zlecenia z limitem, czy oba typy.
• Okno czasowe wykonania i oczekiwany reżim płynności (bez korzystania z danych w czasie rzeczywistym).
• Czy kwotowania z API są orientacyjne, czy gwarantowane do wykonania.

Następnie podziel koszty na składniki:

1. Składnik spreadu: oszacuj koszt przy użyciu spreadu dostępnego w strumieniu danych w momencie wykonania.
2. Składnik opłat: dodaj udokumentowaną prowizję za wykonany wolumen.
3. Składnik czasu utrzymania pozycji (jeśli dotyczy): uwzględnij opublikowane zasady finansowania/rolloveru, jeśli plan zakłada utrzymywanie pozycji.
4. Składnik implementacji: dodaj rezerwę na różnice w wykonaniu (na przykład częściowe realizacje lub ruch ceny podczas kierowania zlecenia).

Ograniczeniem jest to, że spread obliczony na podstawie danych kwotowań może nie być równy efektywnemu spreadowi uwzględnionemu w realizacjach. Ta luka jest właśnie powodem, dla którego należy weryfikować, porównując udokumentowane formuły cenowe z zaobserwowanymi realizacjami w kontrolowanym teście, przy zachowaniu stałych założeń.

Ograniczenia i ryzyka

Istotne tryby awarii, które należy wziąć pod uwagę:

• Niezgodność między kwotowaniem a wykonaniem: bid/ask pobierany z API może mieć charakter orientacyjny. Cena wykonania może się różnić z powodu opóźnień, zmian rynkowych lub kierowania zleceń.
• Częściowe realizacje i efekty poślizgu: jeśli zlecenie zostanie zrealizowane tylko częściowo, średnia efektywna cena w całym procesie wykonania może różnić się od spreadu w pojedynczym momencie kwotowania.
• Wrażliwość na czas i płynność: jakość wykonania może się szybko zmieniać, gdy płynność rynkowa maleje lub rośnie zmienność.
• Niejednoznaczne warunki uruchamiania opłat: niektóre opłaty mogą zależeć od warunków (progi wolumenu, typ zlecenia, status konta lub wystąpienie określonych zdarzeń związanych ze zleceniem). Jeśli nie odwzorujesz dokładnie tych warunków, Twój model kosztów może być błędny.

Ponadto zależności historyczne nie gwarantują przyszłych wyników, więc unikaj zakładania, że wcześniejszy wzorzec spreadu lub wcześniejsze zachowanie opłat się utrzyma.

Weryfikacja lub kolejne pytanie

Aby zweryfikować, co ma znaczenie dla dostępu API, możesz skorzystać z dwupoziomowej listy kontrolnej:

1. Poziom dokumentacji (stabilne zasady): znajdź opublikowane tabele opłat oraz wszelkie zasady dotyczące opłat transakcyjnych i kosztów nietransakcyjnych. Potwierdź jednostki opłat (za lot, za jednostkę, za transakcję) oraz warunki aktywujące każdą opłatę.
2. Poziom wykonania (zmienne wyniki): w środowisku testowym lub w kontrolowanej konfiguracji porównaj zaobserwowane wyniki wykonania (średnia cena realizacji i łączne opłaty) z założeniami z arkusza kalkulacyjnego.

Kolejne pytanie, które powinieneś sobie zadać: Czy opublikowane ceny i definicje kwotowań API jasno wyjaśniają, co jest wykonywalne, a co orientacyjne, oraz jakie typy zdarzeń aktywują każdą opłatę? Jeśli to odwzorowanie jest niejasne, nie będziesz w stanie wiarygodnie przeliczyć spreadów z kwotowań na całkowity zrealizowany koszt.