Jakość danych rynkowych oznacza, że dane są odpowiednio aktualne, kompletne i spójne z instrumentem oraz sposobem działania strategii. Odpowiedź API „200 OK” albo aktywne połączenie nie wystarczają. System może otrzymywać stare notowania, ponownie przetwarzać ten sam rekord lub budować sygnał z niezamkniętej świecy.

Praktycznym rozwiązaniem jest osobna bramka jakości przed obliczeniem sygnału. Powinna określać, które dane można wykorzystać, które wymagają wyjaśnienia i kiedy trzeba zablokować zwiększanie ekspozycji. To warstwa kontroli procesu, a nie kolejny wskaźnik przewidujący cenę.

Najpierw ustal, co faktycznie otrzymujesz

Ten sam symbol może oznaczać inny kontrakt, rynek, walutę albo zakres sesji. Świeca może powstawać z transakcji, kwotowań lub cen środkowych. Dane mogą być rzeczywiste albo opóźnione, a ceny historyczne — surowe lub skorygowane.

Dlatego każdy zbiór potrzebuje kontraktu danych: identyfikatora instrumentu, źródła, strefy czasowej, interwału, zasad agregacji, zakresu sesji i sposobu korekt. Dla futures dochodzi termin wygaśnięcia i reguła przejścia na kolejny kontrakt. Więcej o tym problemie opisuje materiał o rolowaniu kontraktów futures.

Czas zdarzenia to nie czas otrzymania

Warto rozdzielać przynajmniej trzy momenty: czas zdarzenia rynkowego, czas przechwycenia go przez dostawcę i czas dotarcia do aplikacji. Databento udostępnia między innymi pola ts_event oraz ts_recv, opisujące różne etapy tego łańcucha. Ich dokładne znaczenie zależy od schematu i rynku.

Do kontroli świeżości potrzebna jest także poprawna synchronizacja zegara aplikacji. Różnica między „teraz” a czasem zdarzenia obejmuje więcej niż opóźnienie sieci. Z kolei nowy czas odbioru starego rekordu nie czyni ceny aktualną.

Heartbeat potwierdza żywotność połączenia. Nie potwierdza świeżości notowania konkretnego instrumentu.

Progi świeżości trzeba dostosować do płynności, sesji i horyzontu modelu. Brak transakcji przez minutę na mało płynnym instrumencie oznacza co innego niż zatrzymanie wszystkich kwotowań aktywnego rynku. Jeden globalny limit dla całego portfela będzie generował fałszywe alarmy albo przeoczy awarie.

Brak świecy nie zawsze oznacza utratę danych

Dokumentacja Massive wyjaśnia, że w przedziale bez kwalifikujących się transakcji agregat może w ogóle nie powstać. Nie należy automatycznie traktować takiej minuty jako awarii. Najpierw trzeba sprawdzić kalendarz sesji, status rynku, warunki kwalifikacji transakcji oraz kompletność pobrania, w tym paginację.

Uzupełnianie każdej luki ostatnią ceną tworzy pozornie kompletny szereg. Może jednak zaniżać mierzoną zmienność i sugerować możliwość wykonania transakcji po cenie, której nikt już nie oferuje. Jeżeli model potrzebuje regularnej siatki czasu, rekord syntetyczny powinien mieć oznaczenie i jawne reguły wykorzystania. Nie może udawać rzeczywistego obrotu.

Zamknięta świeca może zostać poprawiona

Alpaca opisuje kanał updatedBars, którym przesyła korekty minutowych świec po nadejściu spóźnionych transakcji. Taka aktualizacja może zmienić cenę zamknięcia i wolumen wcześniejszego przedziału. Sam fakt przekroczenia pełnej minuty nie daje więc gwarancji, że agregat nigdy już się nie zmieni.

Przykładowo świeca oznaczona początkiem przedziału 10:00 UTC może obejmować transakcje do 10:01 UTC. System powinien znać tę konwencję, ustalić moment dopuszczenia świecy do obliczeń i obsługiwać późniejsze wersje. Nie wolno zakładać, że timestamp zawsze oznacza koniec przedziału.

W backteście finalna, skorygowana historia może różnić się od pierwszej wersji dostępnej w czasie rzeczywistym. Jeżeli korekta wpływa na sygnał, trzeba zapisać czas jej dostępności. Inaczej walidacja poza próbą nadal może korzystać z informacji, której wtedy nie było.

Duplikaty i kolejność wymagają znajomości strumienia

Po ponownym połączeniu dostawca może odtworzyć fragment danych już zapisanych lokalnie. Ponowne dodanie tych samych transakcji zawyży wolumen, deltę i tempo aktywności. Klucz deduplikacji powinien wykorzystywać identyfikatory dostępne w konkretnym źródle, z uwzględnieniem instrumentu, kanału i sesji.

Sam timestamp nie jest wystarczającym identyfikatorem: wiele prawidłowych zdarzeń może mieć ten sam czas. Numer sekwencyjny także nie musi być globalnie unikalny. Korekty i anulowania trzeba obsługiwać zgodnie z dokumentacją, zamiast bezwarunkowo usuwać każdy rekord podobny do wcześniejszego.

Osobnym testem jest kolejność. Zdarzenie starsze od ostatnio przetworzonego może być spóźnionym komunikatem, korektą albo objawem problemu. Odpowiedzią powinna być zdefiniowana polityka buforowania i uzgadniania stanu, nie ciche przestawienie czasu w bazie.

Minimalny zestaw kontroli przed sygnałem

  • Tożsamość: właściwy instrument, waluta, kontrakt i źródło.
  • Świeżość: wiek ostatniego zdarzenia i czas ostatniego odbioru, osobno dla każdego wymaganego strumienia.
  • Kompletność: oczekiwane dane w kontekście sesji i specyfikacji dostawcy.
  • Unikalność: brak ponownego naliczania tych samych zdarzeń po reconnect.
  • Spójność OHLC: maksimum nie mniejsze od otwarcia i zamknięcia, minimum nie większe od nich, nieujemny wolumen.
  • Semantyka: prawidłowa skala cen, jednostki, znaczniki korekt i wartości brakujące.

Nie każdy test może być uniwersalny. Na przykład cena ujemna nie jest automatycznie błędem dla każdego instrumentu. Nietypowy skok wymaga kontroli statusu rynku i zdarzeń korporacyjnych, a nie mechanicznego przycięcia wartości do „normalnego” zakresu.

Co zrobić po wykryciu problemu?

Przydatny jest prosty podział na dane dopuszczone, podejrzane i niedostępne. Dla każdego stanu trzeba określić wpływ na działanie strategii. Brak wymaganych danych może blokować nowe sygnały, lecz nie powinien wyłączać niezależnego monitoringu istniejących pozycji. Postępowanie z ryzykiem otwartych transakcji wymaga osobnej, wcześniej ustalonej procedury.

Po przywróceniu połączenia system powinien uzupełnić brakującą historię, usunąć powtórzenia i przeliczyć wymagany stan wskaźników. Jeden nowy tick nie dowodzi, że cały model jest gotowy. Powrót do pracy powinien zależeć od przejścia kontroli jakości i uzgodnienia stanu.

Najważniejsze wnioski

Wiarygodne dane to nie tylko poprawne liczby, lecz także wiedza o tym, skąd pochodzą, co oznaczają i kiedy były dostępne. Kontrola powinna obejmować zarówno historię używaną do badań, jak i strumień produkcyjny.

Warto przechowywać dane surowe, wersję po normalizacji i raport odrzuceń z przyczyną. Dzięki temu można odtworzyć decyzję oraz rozdzielić błąd modelu od awarii wejścia. Im bardziej automatyczny proces inwestycyjny, tym ważniejsza jest jawna zgoda na użycie danych przed wygenerowaniem sygnału.

Źródła

Dokumentację sprawdzono 20 października 2026 r. Opisane zachowania dostawców są przykładami; reguły należy potwierdzić dla własnego rynku i strumienia.

Zastrzeżenie edukacyjne: materiał ma charakter wyłącznie edukacyjny i informacyjny. Nie stanowi rekomendacji inwestycyjnej, porady finansowej ani oferty nabycia lub sprzedaży instrumentów finansowych. Kontrola jakości danych nie eliminuje ryzyka rynkowego, modelowego ani operacyjnego.