Co sprawdzić przy ocenie Market Data API?

Definicja i sposób działania

Market Data API to interfejs programistyczny, który dostarcza informacje rynkowe (na przykład kwotowania, transakcje lub świece) z jednego lub wielu źródeł danych do Twojej aplikacji. Przed oceną dostawców rozdziel stabilną mechanikę (jak API reprezentuje i przesyła dane) od zmiennych warunków (jak zachowuje się rynek bazowy, co dostawca decyduje się publikować i jak często docierają aktualizacje). Pomoże Ci to uniknąć mylenia „API coś dostarczyło” z „dane są odpowiednie do Twojego celu”.

Typowe przepływy żądań/odpowiedzi obejmują uwierzytelnianie, wybór punktu końcowego, wybór identyfikatorów instrumentów, określenie zakresu czasu lub subskrypcji oraz otrzymywanie pakietów danych zawierających pola i metadane (często znaczniki czasu i wskaźniki statusu). Załóż, że obsługa czasu ma znaczenie: to samo zdarzenie może pojawić się w różnych momentach w zależności od zegarów dostawcy, opóźnień w przetwarzaniu i sposobu definiowania znaczników czasu.

Lista kontrolna dowodów: co zweryfikować

Użyj listy kontrolnej due diligence i zbierz dowody, które możesz przejrzeć na piśmie.

1. Zakres danych i identyfikatory

• Które instrumenty są dostępne (i jak są identyfikowane)? Skorzystaj z dokumentacji dostawcy, aby potwierdzić mapowania i obsługiwane formaty.
• Czy wszystkie wymagane typy pól są obecne dla Twojego przypadku użycia (na przykład bid/ask, ostatnia transakcja, wolumen, świece OHLC, serie skorygowane o działania korporacyjne)?

2. Definicje pól i normalizacja

• Potwierdź precyzyjne definicje każdego pola. Na przykład określ, co oznacza „ostatnia” w feedzie dostawcy i czy świece są oparte na transakcjach, czy na kwotowaniach.
• Sprawdź, jak dostawca normalizuje symbole, miejsca dziesiętne, kody walut i jednostki.

3. Znaczniki czasu, strefy czasowe i kolejność

• Zweryfikuj, co reprezentuje każdy znacznik czasu (czas zdarzenia vs. czas przetwarzania) oraz jaki standard strefy czasowej jest używany.
• Przetestuj kolejność: czy aktualizacje przychodzą w nieprawidłowej kolejności podczas obciążenia i jak API to sygnalizuje?

4. Częstotliwość aktualizacji i tryb dostarczania

• Określ, czy API jest oparte na odpytywaniu (request/response), czy na strumieniowaniu (subskrypcja). Te tryby zachowują się inaczej przy zmienności sieci.
• Zweryfikuj oczekiwaną częstotliwość aktualizacji i praktyczne zachowanie pod obciążeniem, korzystając z własnych logów testowych.

5. Niezawodność i tryby awarii Należy zidentyfikować i przetestować co najmniej jeden istotny tryb awarii:

• Braki danych lub luki podczas przerw w działaniu.
• Ponowne próby powodujące duplikaty zdarzeń.
• Ograniczenia szybkości prowadzące do częściowego pokrycia danych.
• Odpowiedzi błędów, które nie zachowują kontekstu żądania.

6. Limity zapytań, limity i czynniki kosztowe Nawet bez twierdzeń o danych w czasie rzeczywistym możesz zweryfikować czynniki kosztowe:

• Limity zapytań na klucz i czy istnieją osobne limity dla różnych punktów końcowych.
• Rozmiar pakietu (liczba instrumentów na żądanie, granularność świec) i wpływ na przepustowość.
• Wszelkie ograniczenia licencyjne lub dotyczące użytkowania, które ograniczają redystrybucję lub przechowywanie.

7. Uzupełnianie danych historycznych i powtarzalność Jeśli potrzebujesz serii historycznych, zweryfikuj, czy możesz później odtworzyć ten sam zestaw danych:

• Czy uzupełnianie danych jest obsługiwane dla zakresu czasu?
• Czy możliwe są korekty danych, a jeśli tak, to w jaki sposób komunikowane są zaktualizowane wartości?

8. Bezpieczeństwo i kontrola integralności danych

• Potwierdź wymagania dotyczące metody uwierzytelniania (bez zakładania, że są wystarczające dla Twojego środowiska).
• Zweryfikuj sygnały integralności w odpowiedziach (na przykład sumy kontrolne lub flagi statusu, jeśli są dostępne) i loguj wszystkie metadane odpowiedzi.

Ograniczenia, ryzyka i podejście „czerwonej flagi”

Problemy z jakością danych rynkowych często wynikają z rozbieżności między tym, co zakładasz, a tym, co publikuje dostawca.

• Niespójność czasu: Historyczne lub rzeczywiste znaczniki czasu mogą nie być zgodne z zegarami Twojego systemu, co prowadzi do błędnego sekwencjonowania lub okien czasowych.
• Interpretacja feedu dostawcy: Semantyka pól może się różnić w zależności od źródła (na przykład sposób konstruowania świec). Zależności historyczne mogą zawieść, ponieważ przyszłe zachowanie rynku się zmienia, a feed może odzwierciedlać różne typy zdarzeń w czasie.
• Ryzyko operacyjne: Limity zapytań, zmienność sieci lub przerwy w działaniu usługi mogą powodować luki, duplikaty lub opóźnione aktualizacje. Mogą one zniekształcić obliczenia downstream, jeśli traktujesz nadejście danych jako to samo, co wystąpienie zdarzenia.
• Luka w weryfikacji: Sama dokumentacja nie jest dowodem dla Twojego środowiska. Przeprowadź kontrolowane testy: porównaj przykładowe wyniki z niezależnym źródłem referencyjnym, jeśli to możliwe, i zarejestruj rozbieżności.

Ważnym kryterium jest to, że możesz wyjaśnić swój potok danych, używając jawnych założeń: jaką definicję czasu stosujesz, jak obsługujesz brakujące wartości, jak usuwasz duplikaty i co robisz, gdy limity zapytań zostaną przekroczone.

Weryfikacja i kolejne pytania do zadania

Aby ocenić niezależnie, wybierz mały zestaw reprezentatywnych instrumentów i okien czasowych, a następnie zweryfikuj te punkty we własnych logach:

• Czy znaczniki czasu spełniają Twoje wymagania dotyczące sekwencjonowania? - Czy przy realistycznym wolumenie zapytań występują zauważalne luki, duplikaty lub serie błędów?