Jak testować systemy transakcyjne?

Rynki finansowe zmieniają się, to jest fakt. Na ten stan rzeczy ma wpływ wiele czynników jak choćby zmiany w prawie, zmieniający się klimat i wiele innych. Zatem jeśli chcesz otrzymać wyobrażenie na temat tego jak twój system będzie zachowywał się w przyszłym roku nie musisz go analizować na danych z 50 lat temu, jednak dane z przestrzeni roku lub dwóch to absolutne minimum. Dobrze jest też jeśli dysponujesz danymi z różnych okresów, gdy rynek spadał, gdy rynek rósł i to jeszcze przy różnych zmiennościach małej, średniej czy wręcz ekstremalnie wysokiej. Ja przystępując do testów zwykle zakładam, że kolejny rok będzie bardziej burzliwy i zmienny od poprzedniego, dlatego często na siłę nie poszukuje danych ze spokojnych rynków. Jednak pamiętaj to są moje przekonania.

W trakcie testów zwróć uwagę na kilka rzeczy:

  • błąd sięgania do danych z przyszłości (ang. look-ahead bias) – najczęściej popełniany przy testach na “sucho”. Przykładowo jeśli chcesz użyć ceny minimalnej z danego dnia i na tej podstawie wejść w transakcje, to nie wiesz tego w trakcie dnia, dopiero po zakończeniu sesji. Tego błędu łatwo uniknąć, gdybyś puścił swojego robota online na rachunku demo.
  • zbytnia optymalizacja (ang. data-snooping bias) – pamiętaj czym masz więcej parametrów w systemie i czym bardziej dopasujesz go do danych historycznych tym będzie gorzej działał w przyszłości. Jedna z ważniejszych zasad sprawdzających się w praktyce mówi tyle, że system czym prostszy (ale działający), tym lepszy. Czym mniej czasu poświęcisz na optymalizację dziesiątków parametrów, a czym więcej logiki będzie w doborze tych parametrów tym system będzie dłużej działął.
  • odpowiednia wielkość próby – dla większości testów statystycznych uznaje się, że liczba 30 jest minimalna by cokolwiek powiedzieć o próbie, czym większa ta liczba tym lepiej. To znaczy, jeśli twój system generuje 5 transakcji rocznie, to nawet nie próbuj na podstawie tak małej ilości danych prognozować czegokolwiek.
  • podział danych na części (ang. out-of-sample testing) – lekka optymalizacja parametrów w gruncie rzeczy nie jest niczym złym, ale w tym wypadku musisz być ostrożny. Czym więcej parametrów testujesz tym więcej danych musisz mieć do testów. Przykładowo chcesz optymalizować dwa parametry, a twój system generuje 100 handli w roku. Wtedy możesz dopasowywać w czasie testów system do danych z roku 2008 i zobaczyć jakie wyniki dają te poprawki na danych z 2009 roku. Jeśli poprawka dobrze wpływa na wyniki z obu lat wtedy warto ją zostawić.
  • koszty transakcyjne – okazuje się, że wiele systemów bez uwzględnienia kosztów transakcyjnych dają wyniki rewelacyjne. Wszystko się zmienia, gdy taki system puszczamy w rzeczywistych warunkach, a dodatnia wartość oczekiwana zamienia się w ujemną. Ten czynnik jest tym ważniejszy im krótszy jest horyzont naszych inwestycji. Koszty transakcyjne to nie tylko prowizje, ale także spready czy punkty SWAP.

Gdy dobrze przeprowadziłeś testy systemu powinieneś otrzymać rozkład prawdopodobieństwa dla tego systemu wyrażony w R. Jeśli nie do końca wiesz o czym mówię to zapraszam Cię do przeczytania moich poprzednich artykułów. Przypominam, że R to początkowe ryzyko każdej transakcji, a wynik transakcji to wielokrotność R. Dla przykładu 1.5R oznacza, że transakcja zakończyła się zyskiem półtora razy większym niż ryzyko początkowe, 3R – zarobiliśmy trzy razy więcej niż ryzykowaliśmy, -2R – strata wyniosła dwukrotność ryzyka początkowego (taka sytuacja może mieć miejsce, gdy np. na giełdzie jest panika i akcje za szybko rosną lub ceny otworzyły się z luką cenową itp.). Mając takie informacje wrzucamy je do testera strategii zamieszczonego na tej stronie (liczby powinny być oddzielone spacjami lub znakami końca wiersza, użyj kropki jako separatora dziesiętnego).