Trading algorytmiczny — automatyzacja, backtesting i pułapki

W poprzednim artykule rozbieraliśmy mechanikę news tradingu — środowisko, w którym ludzki refleks przegrywa z latencją algorytmów. Naturalny wniosek: „skoro nie dam rady ręcznie, niech robi to bot". Ten wniosek jest poprawny — pod warunkiem, że rozumiesz, co naprawdę kupujesz. Trading algorytmiczny to nie „włączam EA i zarabiam". To programowanie, testowanie, walidacja, infrastruktura i ciągła konserwacja systemu, który — nawet jeśli działa — pewnego dnia przestanie, bo rynek zmieni reżim. Disclosure brokerów CFD pod reżimem ESMA/KNF regularnie pokazują, że 70–80% rachunków detalicznych traci pieniądze^[1]. Bot nie naprawia złego systemu. Przenosi tylko błąd z ręki tradera do kodu i potrafi egzekwować go szybciej, częściej i bez wahania. Jeśli system nie ma edge'u (art. 8.2), bot straci pieniądze szybciej i bardziej systematycznie niż człowiek.

1. Czym jest trading algorytmiczny

Trading algorytmiczny to nie magiczna drukarka pieniędzy. To outsourcing twojej dyscypliny do maszyny, która nie wybacza błędów logicznych w kodzie. Jeśli logika systemu jest zła, automat będzie egzekwował ten błąd szybciej, konsekwentniej i bez momentu zawahania. Spectrum jest szerokie:

• Prosty EA (Expert Advisor) — skrypt na MT4/MT5, który wykonuje regułę typu „kup, gdy MA(20) przetnie MA(50) w górę, SL 30 pip, TP 60 pip". To automatyzacja, ale nie sofistykacja.
• System systematyczny — zdefiniowane reguły wejścia, wyjścia, sizingu, filtrów reżimu — ale egzekucja ręczna lub półautomatyczna.
• Pełna automatyzacja — system handluje samodzielnie 24/5. Wymaga infrastruktury (VPS, monitoring), ale eliminuje emocje z egzekucji.
• HFT (High-Frequency Trading) — tysiące transakcji dziennie, co-location na serwerach giełdy, latencja w mikrosekundach. Nieosiągalne dla detalisty — wymaga milionów USD na infrastrukturę^[6].

Czym trading algorytmiczny NIE jest: ściągnięciem EA z forum, włączeniem go na demo i czekaniem na milion. Jeśli nie rozumiesz jednocześnie logiki strategii i zachowania kodu w egzekucji, jesteś zależny od kogoś innego. To wystarczy, żeby stracić kontrolę nad ryzykiem.

Typowy scenariusz: EA kupiony za 299 USD z opisem „40% monthly ROI, 2 years backtested". Pierwsze tygodnie na demo wyglądają dobrze. Na live — seria strat, EA otwiera 12 pozycji na skorelowanych parach, konto traci 60%. Kupujący nie wiedział, że EA podwajał pozycje po stracie (martingale) — bo nie umiał przeczytać kodu. Więcej o tym, jak weryfikować EA: sekcja 9.

2. Narzędzia — MQL, Python, cTrader, API

Wybór narzędzia zależy od tego, co chcesz zrobić, ile umiesz programować i u jakiego brokera handlujesz.

Jeśli handlujesz u brokera MT4-only i jesteś detalistą, MQL4 jest wyborem z przymusu, nie z wyboru — broker narzuca platformę. MQL5 ma lepszy backtester i architekturę. Python daje narzędzia statystyczne (walk-forward, Monte Carlo), których w MQL nie dostaniesz bez bólu. Wielu algo traderów używa obu: Python do research i walidacji, MQL do egzekucji. MQL4 i MQL5 to różne języki — EA z MT4 nie działa na MT5 bez przepisania. Wybór brokera determinuje dostępne narzędzia — sprawdź nasze porównanie kont ECN i standard, bo typ konta wpływa na model egzekucji i dostępność API.

3. Backtesting — fundament i największa pułapka

Backtesting to symulacja systemu na danych historycznych. Jest fundamentem algo tradingu — bez niego nie wiesz, czy twój pomysł ma szansę działać. Ale backtest to narzędzie do odrzucania złych pomysłów, nie maszyna do przewidywania przyszłości. Większość detalistów używa go odwrotnie: szuka potwierdzenia, że ich pomysł działa.

Co backtest powinien modelować

• Spread zmienny, nie stały — stały spread 0,5 pipsa na EUR/USD to fikcja. Realny spread zmienia się z godziny na godzinę, rozszerza się przy danych. Backtest z domyślnym spreadem MT4 zawyża wyniki.
• Slippage — na żywym rynku fill bywa gorszy niż cena zlecenia. Backtest bez modelowania slippage'u (nawet 0,5–1 pip na trade) zawyża expectancy.
• Prowizja — na rachunku ECN: 3–7 USD per round-turn lot. Na rachunku z markup — w spreadzie. Backtest musi to uwzględniać.
• Dane tickowe vs OHLC — backtest na danych OHLC pomija ruchy wewnątrz świec. Strategy Tester w MT5 oferuje tryb „Every tick based on real ticks" — używaj go^[8]. Ale uwaga: „real ticks" to lepsza symulacja, nie prawdziwa egzekucja. Nie odtwarza kolejek, dostępności płynności ani jakości filli.

Czego backtest nie odtworzy nawet na dobrych tickach

• Rejecty i partial fills — na żywym rynku LP może odrzucić twoje zlecenie (Last Look) lub zrealizować je częściowo. Backtest zakłada 100% fill rate po cenie zlecenia.
• Feed vs executable price — cena widoczna na wykresie nie musi być ceną, po której dostaniesz fill. W newsach widzisz tick, którego nie dało się realnie kupić.
• Slippage asymetryczny — na stopach slippage jest gorszy niż na limitach. Backtest tego nie modeluje, chyba że programujesz to ręcznie.
• Rollover i spread nocny — między 23:00 a 00:00 czasu serwera spready na crossach (np. GBP/NZD) mogą skoczyć z 3 do 40 pipsów. EA bez filtra blokującego handel w tej godzinie zostanie zmasakrowany przez fałszywe wycięcia SL.
• Broker changing LP stack — twój broker może zmienić dostawcę płynności w dowolnym momencie. Dane historyczne nie odzwierciedlają przyszłych warunków egzekucji.
• Mid-price bias — strategia testowana na mid-price (średnia bid/ask) może wyglądać lepiej niż na realnym bid/ask, szczególnie przy ciasnych targetach i krótkim horyzoncie. Jeśli TP wynosi 5 pipsów, a spread to 1,2 pipsa — backtest na mid zawyża expectancy o ~0,6 pipsa na stronę.

Nie wiesz, w jakim modelu broker obsługuje twoje flow i jak to wpływa na egzekucję? Sprawdź nasz ranking brokerów A-Book/ECN, gdzie testujemy realne spready i jakość filli na kontach live, a nie na wygładzonym demo.

Ważna uwaga o rynku: detalista na MT4/MT5 zwykle nie testuje i nie handluje centralnego rynku spot FX. Testuje i handluje feed oraz warunki konkretnego brokera CFD/OTC. Dane historyczne, spready, jakość filli, dostępność płynności — wszystko jest specyficzne dla twojego brokera. Backtest na danych brokera A nie gwarantuje wyników u brokera B.

Zanim przejdziesz do wyników backtesta, zweryfikuj dane wejściowe — szczegółowa checklist jakości danych w sekcji 8 pokazuje, co sprawdzić: źródło, strefę czasową, jakość ticków, luki i zgodność broker test/live.

Backtest vs live — dlaczego wyniki się różnią

Różnica między backtest a live to nie „mały margines". System z expectancy +8 pip na backteście, po uwzględnieniu realnych kosztów (spread zmienny +2 pip, slippage +1,5 pip, prowizja +0,7 pip = 4,2 pip dodatkowego kosztu per trade) ma realną expectancy +3,8 pip. Do przeliczenia kosztów na wartość pieniężną użyj kalkulatora wartości pipsa. Jeśli latencja dodaje kolejne 1–2 pip — zostajesz z +1,8–2,8 pip^[2].

4. Overfitting — wróg numer jeden

Większość retailowych systemów nie umiera dlatego, że rynek je „zaskoczył". Umiera dlatego, że były dopasowane do historii tak mocno, że na nowych danych nie miały już czego eksploatować. Im więcej parametrów optymalizujesz, tym lepiej system pasuje do danych — i tym gorzej radzi sobie na nowych danych^[3].

Jak wygląda overfitting w praktyce

1. Masz pomysł: „MA crossover na EUR/USD".
2. Testujesz MA(20) i MA(50) — wynik OK, expectancy +3 pip.
3. Optymalizujesz: testujesz wszystkie kombinacje MA(5–100) × MA(10–200). Najlepsza: MA(17) i MA(43) — expectancy +11 pip.
4. Dodajesz filtr RSI. Optymalizujesz. Expectancy: +18 pip.
5. Dodajesz filtr godzinowy. Expectancy: +24 pip.
6. Dodajesz filtr dnia tygodnia. Expectancy: +31 pip.

Na backteście wygląda idealnie. Problem: 6+ parametrów zoptymalizowanych na tych samych danych. System nie odkrył wzorca — nauczył się historii. Bailey i López de Prado wykazali, że przy typowej liczbie prób optymalizacyjnych (1000+) prawdopodobieństwo znalezienia „zyskownego" systemu przez przypadek jest bardzo wysokie — nawet na losowych danych^[4].

Sygnały ostrzegawcze overfittingu

• System działa tylko na jednej parze, jednym interwale i jednym okresie.
• Mała zmiana parametru (np. MA z 17 na 19) drastycznie pogarsza wynik — „wyspy" rentowności.
• Wynik out-of-sample jest >50% gorszy niż in-sample.
• System ma dużo parametrów (jako regułę roboczą: powyżej 5–6 — ale to heurystyka, nie prawo fizyki).
• Equity curve na backteście jest „za gładka" — brak drawdownów to czerwona flaga.

5. Walk-forward analysis i Monte Carlo

Jeśli backtest to pytanie „czy system działał?", to walk-forward analysis (WFA) to pytanie „czy system działał na danych, których nie widział podczas optymalizacji?"^[5].

Procedura walk-forward

1. Podziel dane na okna — np. 12 miesięcy in-sample (IS), 3 miesiące out-of-sample (OOS).
2. Optymalizuj na IS — znajdź najlepsze parametry.
3. Testuj na OOS — uruchom system z tymi parametrami na danych, których nie widział.
4. Przesuń okno — następne IS: miesiące 4–15, OOS: 16–18. Powtórz.
5. Agreguj wyniki OOS — połącz wszystkie okresy OOS. To jest twój realny wynik.

Walk-forward efficiency (WFE) = (zysk OOS / zysk IS) × 100%. Reguła robocza (nie prawo fizyki): WFE powyżej 50% to warunek konieczny, nie wystarczający. Widziałem systemy z WFE 70%, które na live robiły –15% przez 6 miesięcy — bo walk-forward był przeprowadzony na jednym instrumencie w jednym reżimie rynku. WFE to filtr, nie gwarancja. WFE < 30% — prawdopodobnie overfitowany. WFE < 0% — system nie działa poza danymi treningowymi.

Anchored WFA vs rolling WFA

Rolling WFA (opisany wyżej) przesuwa okno: IS to zawsze ostatnie N miesięcy. Anchored WFA trzyma punkt startowy stały i rozszerza okno IS z każdym krokiem. Odpowiada na inne pytanie: „czy system jest stabilny, gdy widzi więcej danych?"

Jeśli rolling WFA daje WFE 60%, ale anchored WFA daje WFE 20% — system uczył się z przeszłości, nie adaptował do przyszłości. Parametry „pływały" z oknem zamiast stabilizować się. Ta różnica jest kluczowa: system z dobrym rolling WFE i słabym anchored WFE jest prawdopodobnie overfitowany do lokalnych reżimów. Oba testy powinny dawać zbliżone wyniki, zanim uznasz system za wart wdrożenia.

Monte Carlo — stress test expectancy

Monte Carlo to symulacja: bierzesz historyczne wyniki i losowo zmieniasz kolejność transakcji tysiące razy. Z 10 000 permutacji dostajesz rozkład: jaki jest najgorszy drawdown w 95% przypadków? Jaka jest minimalna expectancy?

Przykład: system ma 200 transakcji z WR 54%, średni zysk 18 pip, średnia strata –12 pip. Expectancy = 0,54 × 18 – 0,46 × 12 = +4,2 pip/trade. Po 10 000 permutacji Monte Carlo: w 95% scenariuszy max DD nie przekracza 22% konta, a expectancy nie spada poniżej +1,8 pip/trade. Jeśli na live DD zbliża się do 22% — system jest w strefie zagrożenia, ale jeszcze w zakresie. Jeśli przekroczył — degradacja jest prawdopodobna.

Matematyka Monte Carlo jest prosta do wdrożenia w Pythonie (biblioteka numpy, 15–20 linii kodu) lub Excelu (makro z losowaniem). Szczegóły metody: art. 8.2 — matematyka przewagi rynkowej.

6. Od backtesta do live — paper trading i infrastruktura

Po backteście i WFA nadal nie wiesz, jak system zachowa się na feedzie brokera, z realnym routingiem i realnymi błędami wykonania. Dlatego najpierw forward na demo, potem mikrolot na live.

Paper trading — test techniczny, nie prognoza

Demo jest użyteczne technicznie, ale nie odtwarza warunków egzekucyjnych live, więc nie nadaje się do oceny jakości edge'u netto. Feed „realny" — ale bez Last Look, bez LP-odrzutów, bez częściowych realizacji, bez rozszerzeń spreadu w momencie wyjścia. Demo nie kłamie — żyje w innej rzeczywistości płynnościowej. Traktuj demo jako test, czy kod działa technicznie (otwiera, zamyka, zarządza pozycjami). Minimum: 50–100 transakcji. Wyniki z demo nie prognozują wyników live.

Infrastruktura

• VPS — system musi działać 24/5 bez przerw. VPS blisko serwera brokera: latencja 1–10 ms zamiast 50–200 ms z domu. Koszt: 15–50 USD/miesiąc.
• Monitoring — alert SMS/email/Telegram, gdy system padnie, drawdown przekroczy próg lub pozycja zawiśnie. Bez monitoringu dowiesz się o awarii po powrocie z pracy.
• Kill switch — automatyczne zamknięcie wszystkich pozycji, gdy dzienny DD przekroczy próg. Fail-safe na disconnect, max pozycji jednocześnie, max DD.

Sizing startowy i checklist forward/live

Pierwszy miesiąc na live: minimalne loty. Cel nie jest zarabianie — jest walidacja. Jeśli po 30–50 transakcjach wyniki odbiegają znacząco od backtesta — wróć do diagnostyki. Checklist metryki do śledzenia:

1. Średni spread per godzina/sesja — czy broker daje to, co reklamuje, o 3:00 w nocy?
2. Slippage per typ zlecenia — stop vs limit. Czy asymetria istnieje?
3. Odsetek rejectów — ile zleceń broker odrzucił? Na demo: zero. Na live: bywa kilka procent.
4. Odsetek filli gorszych niż X — ile razy fill był gorszy niż 2 pipsy od ceny zlecenia?
5. Expectancy: test vs forward vs live — trzy liczby. Jeśli live jest poniżej 50% backtesta — coś jest nie tak z egzekucją.
6. Latencja z VPS do serwera brokera — pinguj regularnie. Jeśli rośnie — broker mógł zmienić infrastrukturę.
7. Średni swap per trade i per para — swapy zmieniają się w czasie (zależą od stóp procentowych i polityki brokera). Monitoruj koszt przetrzymania pozycji: średni swap per trade, różnicę swapów long vs short na tej samej parze, zmiany swap rate w ujęciu miesięcznym. Jeśli swap rośnie — zysk systemu overnight maleje bez zmiany logiki.

Sizing z uwzględnieniem slippage — pseudokod

Artykuł mówi „modeluj slippage" — ale gdzie go wpisać? Poniższy przykład jest uproszczeniem poglądowym, nie gotowcem produkcyjnym. W praktyce przeliczenie lota musi uwzględniać specyfikę symbolu, liczbę miejsc po przecinku (3/5-digit pricing), wielkość ticka i walutę rachunku. Logika jest prosta — szczegóły implementacji nie:

// Schemat poglądowy — sizing z uwzględnieniem slippage i prowizji
double slippage_pips   = 1.5;      // empiryczny średni slippage [pipsy]
double commission_pips = 0.7;      // prowizja przeliczona na pipsy
double nominal_SL      = 25.0;     // nominalny SL w pipsach

double adjusted_SL_pips = nominal_SL + slippage_pips + commission_pips;
// adjusted_SL_pips = 25 + 1.5 + 0.7 = 27.2 pipsa

double risk_amount = AccountInfoDouble(ACCOUNT_EQUITY) * 0.01;  // 1% konta

// Wartość 1 pipsa dla 1 lota (zależy od symbolu i waluty rachunku)
// Zweryfikuj ręcznie dla swojego instrumentu!
double pip_value_per_lot = /* np. ~10 USD dla EUR/USD przy koncie USD */;

double lot_size = risk_amount / (adjusted_SL_pips * pip_value_per_lot);

Bez korekty o slippage i prowizję: ryzyko per trade wynosi 1% × (27,2/25,0) = 1,09% konta zamiast planowanego 1%. Na 200 transakcjach ta różnica kumuluje się. Uwaga: SYMBOL_TRADE_TICK_VALUE w MQL5 zwraca wartość jednego ticka (nie pipsa) i bywa zdradliwe dla instrumentów z niestandardową liczbą miejsc po przecinku lub dla par denominowanych w walutach innych niż waluta rachunku. Ręcznie zwaliduj logikę zarządzania wielkością pozycji w swoim kodzie, używając naszego kalkulatora wartości lota i pipsa.

Kiedy nie odpalać systemu — filtr sesyjności

7. Koszty i realia prowadzenia algo

Trading algorytmiczny ma koszty, o których mało kto mówi — bo nie są widoczne na equity curve.

Koszty twarde

• VPS — 15–50 USD/miesiąc. Tanich VPS za 5 USD unikaj — niestabilne łącze, high latency.
• Dane tickowe — Dukascopy (bezpłatne z ograniczeniami). Profesjonalne: TickData, TrueFX — 100–500 USD/rok.
• Narzędzia — Python bezpłatny. Profesjonalne platformy (MultiCharts, TradeStation): 50–200 USD/miesiąc.
• Spread i prowizja — 10 transakcji/dzień × 1,5 pip kosztu × 22 dni × 12 miesięcy = 3960 pipsów/rok. Na locie 0,10 = ~396 USD/rok czysto na friction. Różnica spreadu między brokerami to 0,3–0,8 pip na majorsach — na 2640 transakcjach rocznie to 800–2100 pipsów. Porównaj realne spready w naszym rankingu brokerów ECN.

Koszty ukryte

• Czas developmentu — 100 godzin na budowę? Tyle zajmuje postawienie środowiska i ogarnięcie składni. Większość czasu zabiera nie pisanie kodu, tylko walidacja danych, debugowanie, analiza logów i odrzucanie pomysłów, które nie przechodzą testu live. Realistycznie: 300–500 godzin w pierwszym roku na budowę, testowanie i iterację jednego systemu. A wynik po kosztach może okazać się gorszy niż pasywny ETF na indeks. Twój czas ma cenę — licz go jako koszt alternatywny.
• Swapy dla systemów overnight — system swing na D1 z 5 transakcjami tygodniowo trzyma pozycje 2–5 dni. Swapy na crossach (np. GBP/JPY) mogą zjadać orientacyjnie 1–3 pipsy dziennie (zależy od brokera i różnicy stóp). Na systemie z expectancy +8 pip per trade i średnim trzymaniem 3 dni — swapy to dodatkowe 3–9 pipsów kosztu, o których backtest wie tylko jeśli uruchomisz go z poprawnymi danymi historycznymi swapów. Większość brokerów nie udostępnia historii zmian swap rate.
• Konserwacja — minimum 5–10 godzin/miesiąc. Zmiana parametrów brokera, aktualizacje, weryfikacja edge'u.
• Koszt błędów implementacyjnych — bug w sizingu, źle obliczona prowizja, zły warunek wyjścia. Jeden błąd logiczny może działać przez tygodnie, zanim go zauważysz.
• Koszt zmiany brokera — nowy spread, nowy LP stack, nowa latencja. System zoptymalizowany pod jednego brokera może nie działać u drugiego.
• Koszt „martwego kapitału" — pieniądze na rachunkach testowych, u zapasowych brokerów, na VPS. Capital tied up, który nie pracuje.

8. Kiedy algo przestaje działać — regime change

Każdy system algorytmiczny kiedyś przestaje działać. Pytanie: kiedy to zauważysz i co zrobisz.

Dlaczego systemy degradują się

• Regime change — system trend-following z 2020–2021 (silne trendy dolarowe) może nie działać w 2024 (ranging). Reżim rynku (art. 8.7) się zmienia, parametry systemu są dostrojone do starego reżimu.
• Crowding — jeśli strategia jest popularna, coraz więcej uczestników ją gra. Edge maleje, bo rynek szybciej arbitrażuje sygnał.
• Zmiany mikrostrukturalne — broker zmienia LP stack, spread się zmienia. System zoptymalizowany pod stary spread może nie działać pod nowy.

Sygnały degradacji

• Hit rate spada — z 55% (ostatnie 500 trade'ów) do 42% (ostatnie 100). Patrz na rolling hit rate, nie na ostatni drawdown. (Te same metryki, które monitorujesz od startu — checklist z sekcji 6 — stają się z czasem sygnałami degradacji.)
• Rolling expectancy per trade maleje systematycznie — nie jeden zły tydzień, ale trend w dół na 3–4 tygodnie.
• Drawdown przekracza 95. percentyl Monte Carlo.
• Średni czas w pozycji rośnie — system nie łapie ruchów, które łapał wcześniej.

Nie czekaj na okrągłą liczbę transakcji, żeby zacząć diagnozować. System mean reversion na H1 robi 3–5 transakcji tygodniowo — na „statystycznie istotną" próbkę czekasz miesiącami. W tym czasie broker mógł zmienić LP stack, rynek mógł zmienić reżim. Patrz na rolling metryki z tygodnia na tydzień: hit rate, expectancy, slippage, średni czas w pozycji. Trend w dół na 3–4 tygodnie to sygnał — nie czekaj, aż stanie się pewnością.

Kiedy wyłączyć vs normalny drawdown

Brzmi racjonalnie na papierze: „wyłącz, gdy DD przekroczy 95. percentyl Monte Carlo". Teraz zrób to w praktyce: system jest na DD 22%, Monte Carlo mówi granica to 23%. Tracisz 2200 USD z konta 10 000 USD. Każda następna transakcja może być tą, która przebija granicę. Albo może cofnąć DD do 18% i okaże się, że wyłączyłeś system w granicach normalnej zmienności. Decyzja procesowa wygląda łatwo w arkuszu. Przy otwartych pozycjach wygląda inaczej. Ustal z góry drawdown trigger: 1,5× max DD z backtesta lub 95. percentyl Monte Carlo — i trzymaj się tego bez negocjacji.

Regime detection — wbudowany filtr EA

Artykuły edukacyjne opisują regime change jako zewnętrzne zagrożenie. Systematyczny trader buduje filtr reżimu bezpośrednio w system:

• ADX jako przełącznik — ADX < 20 = rynek w range, system trend-following wyłączony. ADX > 25 = trend aktywny, system mean reversion wyłączony. To jedno z prostszych i praktycznych podejść do filtrowania reżimu.
• Zmienność vs średnia — porównanie 20-dniowego ATR do 200-dniowej średniej ATR. Jeśli ATR(20) jest 2× wyższy niż średnia — reżim się zmienił, parametry systemu mogą nie pasować.
• COT jako filtr tła — nie jako trigger wejścia, ale jako kontekst tygodniowy. Ekstremalny COT (>90 percentyl) w kierunku zgodnym z systemem = mniejszy edge, bo crowding. Ekstremalny COT przeciwko = potencjalny squeeze, system trend-following może mieć dodatkową siłę. (Art. 6.6)

Mechanika wdrożenia COT w EA: CFTC publikuje raport COT w piątek o 15:30 ET, ale dane dotyczą pozycji z poprzedniego wtorku — opóźnienie wynosi 3 dni robocze. To oznacza, że COT nie nadaje się jako trigger intraday ani nawet jako sygnał dziennego wejścia. Jedyny rozsądny sposób użycia: tygodniowy sygnał kontekstowy na D1 lub W1 — filtr „czy pozycjonowanie rynku jest skrajne?" sprawdzany raz w tygodniu po publikacji. Jeśli COT jest ekstremalny (>90 percentyl netto long/short), system zmniejsza sizing lub pauzuje sygnały w kierunku zgodnym z tłumem. Dane COT w EA: parsuj CSV z CFTC ręcznie lub przez API (np. Quandl/NASDAQ Data Link).

Robustness testing — system odporny vs system kruchy

System, który „działa" to za mało. System musi przetrwać warunki gorsze niż te, na których go testowałeś. Test robustness to celowe pogarszanie warunków i sprawdzanie, czy system nadal daje dodatnią expectancy:

• Spread +50% — jeśli system zarabia przy spreadzie 1,0 pip, czy nadal zarabia przy 1,5 pip? Jeśli nie — jest zbyt wrażliwy na koszt wejścia.
• Opóźnienie +200 ms — dodaj sztuczny delay do backtesta. Czy wynik spada o 10% czy o 60%? System scalping zwykle nie przeżywa — swing zwykle tak.
• Różne feedy / brokerzy — uruchom ten sam system na danych tickowych z 2–3 różnych źródeł. Jeśli wyniki różnią się o >30% — system handluje artefaktami feedu, nie wzorcem rynkowym.
• Przesunięcie wejścia o 1 bar — opóźnij sygnał wejścia o jedną świecę. Jeśli system się sypie — edge zależy od precyzji, której na live nie dostaniesz.
• Swap +50% — dla systemów overnight: podnieś koszt swapu o połowę. Jeśli system z D1 traci rentowność — jest zależny od taniego finansowania, nie od wzorca.
• Plateau parametrów — nie szukaj najlepszego punktu. Szukaj regionu, w którym cała okolica parametrów daje zysk. Jeśli parametr musi być MA(17) a nie MA(19) — to overfitting, nie robustness.

W Pythonie: biblioteka vectorbt pozwala stosunkowo szybko parametryzować spread, slippage i opóźnienie wejścia oraz uruchamiać wiele wariantów w pętli. W MQL: Strategy Tester pozwala ręcznie ustawić spread i slippage per test — żmudne, ale wykonalne.

Wrażliwość systemu na egzekucję — zależy od stylu

Kolumna „Scalping" w tabeli nie jest zaproszeniem — jest ostrzeżeniem. Detalista na MT4/MT5 u brokera CFD nie kontroluje latencji ani priorytetu routingu w stopniu, który pozwala zbudować zyskowny scalper na dłuższą metę. Wyjątki istnieją — ale są rzadsze niż sądzi większość traderów, którzy właśnie odkryli M1.

Checklist jakości danych

Trzy razy zbudowałem system, który „działał" na backteście i „nie działał" na live — zanim nauczyłem się, że moje dane z brokera miały błędną strefę czasową po zmianie DST. Filtr godzinowy, który miał blokować handel między 23:00 a 00:00, blokował 22:00–23:00. System handlował przez rollover. Problem z danymi, nie z logiką. Sprawdzaj dane przed systemem:

• Źródło danych — broker (zanieczyszczone) vs niezależne (Dukascopy, TickData). Porównaj OHLC na losowym tygodniu.
• Strefa czasowa — UTC, GMT+2, GMT+3? Zmiana DST zmienia godzinę świec — i zachowanie systemu z filtrem godzinowym.
• Jakość ticków — ile ticków na minutę? Dane z <10 ticków/min na EUR/USD to interpolacja, nie rynek.
• Luki — weekendy, święta, disconnect. Czy backtest poprawnie obsługuje luki, czy liczy je jako świece z zerowym wolumenem?
• Sposób agregacji świec — broker A liczy świece od bid, broker B od mid. Na M1/M5 to robi różnicę.
• Zgodność broker test/live — czy dane w backteście pochodzą od tego samego brokera, u którego handlujesz na live? Jeśli nie — testujesz inny rynek.

9. EA z marketu i social trading — co kupujesz

MQL5 Market, ZuluTrade, PAMM, copy trading — obietnica: „nie musisz się uczyć, ktoś inny będzie handlował za ciebie". Rzeczywistość jest mniej różowa.

MQL5 Market — ranking zwycięzców bez pełnej historii przegranych

Tysiące EA do kupienia, rankingowane po wynikach. Rankingi EA premiują to, co jeszcze nie eksplodowało. Kupujący widzi wynik, ale zwykle nie widzi pełnej dystrybucji ryzyka, historii zmian parametrów ani warunków, pod które system był ustawiony. EA, które straciły 80% konta, znikają z rankingu. To jest klasyczny survivor bias^[7].

Typowe tricki vendorów:

• Martingale — podwajanie po stracie. Equity curve idealna do momentu, gdy jedna seria strat zniszczy konto. Track record 12 miesięcy bez DD nie oznacza dobrego systemu — oznacza, że martingale jeszcze nie trafił na czarny łabędź.
• Grid bez SL — pozycje co X pipsów bez stop lossa. Działa w range'u. Jeden trend i konto zerowe.
• Cherry-picked backtest — vendor pokazuje najlepszy okres. Nie pokazuje walk-forward.
• Demo jako „live proof" — konto demo z idealnym fillem nazwane „live results".

Due diligence przed zakupem EA — 7 kroków

Social trading i copy trading

ZuluTrade, eToro CopyTrader, PAMM — kopiujesz „top tradera". Żadne pytanie due diligence nie ochroni cię przed tym, że „top trader" na ZuluTrade handluje kontem z lewarem 1:400 u brokera na Vanuatu, używa martingale zamaskowanego jako „averaging", a jego DD 4% na papierze oznacza, że jedna czarna seria go wyzeruje. Zanim skopiujesz — sprawdź, gdzie broker tego tradera trzyma pieniądze i jakie ma zabezpieczenia klientów. Odpowiedź często kończy rozmowę.

10. Algo dla detalisty — realistyczne oczekiwania

Co jest osiągalne

• Swing/position algo na D1/H4 — mean reversion lub trend-following. 3–8 transakcji/tydzień. 10–30% CAGR brzmi dobrze na papierze. Ale górny koniec tego zakresu osiąga niewielka część detalistów budujących własne systemy, a DD 25% to psychologicznie coś zupełnie innego niż DD 25% w arkuszu. Przy koncie 10 000 USD to 2 500 USD, które znikają. Większość traderów wyłącza system przy DD 12% — zanim system ma szansę odrobić. I uwaga: zjedzą cię ujemne swapy i rozszerzenia spreadu o północy (rollover). Jeśli backtest nie uwzględnia brutalnego kosztu przetrzymania pozycji przez noc, papierowe +15% zamieniają się w realny minus.
• Hybrydowe podejście: algo + discretionary — system generuje sygnały, trader decyduje o egzekucji na podstawie kontekstu (dane makro, reżim, COT — dział 7). Często skuteczniejsze niż czysty algo.
• Automatyzacja zarządzania ryzykiem — zarządzanie ryzykiem to nie wstawienie sztywnego SL na 30 pipsów. Prawdziwe algo dynamicznie skaluje pozycję do zmienności (ATR) i wycina ryzyko z rynku, gdy spread u brokera rozszerza się do poziomu, przy którym system traci ekonomiczny sens. Nawet bez automatyzacji wejść — automatyczny sizing, trailing i kill switch eliminują najgorsze decyzje emocjonalne.

Co NIE jest osiągalne

• HFT bez colocation — wymaga latencji w mikrosekundach i milionów USD. Na VPS za 30 USD z MT4 nie zrobisz HFT^[6].
• Stałe 10% miesięcznie — żaden system nie daje stałych zwrotów. Kto obiecuje „stałe X% miesięcznie" — albo kłamie, albo używa martingale.
• „Set and forget" — system wymaga ciągłego monitoringu i rekalibracji.

Algo nie skraca drogi do przewagi. Zmienia źródło błędów: mniej decyzji pod wpływem emocji, więcej błędów w logice, danych i egzekucji. Zamiast tracić przez emocje, częściej tracisz przez błędy w logice, danych albo egzekucji, które wychodzą dopiero po czasie^[10].

A-Book, B-Book i dlaczego twój EA musi to rozumieć

Nie możesz pisać algo na Forex/CFD bez zrozumienia, że detalista zwykle nie handluje na „rynku" — handluje w modelu egzekucji brokera (art. 2.7).

• B-Book — broker internalizuje flow (może, ale nie musi być bezpośrednią drugą stroną transakcji). Gdy EA zaczyna systematycznie zarabiać, broker może zmienić sposób obsługi tego konta — przenieść je do A-Book, zmienić priorytety routingu lub zmodyfikować warunki egzekucji. Toxic flow detection — systemy identyfikujące konta generujące konsekwentne straty dla brokera — to udokumentowany mechanizm rynkowy, choć jego zakres i częstotliwość stosowania różnią się między brokerami.
• A-Book — broker przekazuje zlecenia do LP. Brak konfliktu interesów, ale slippage zależy od głębokości booka LP i czasu routingu.
• Hybryda — większość brokerów detalicznych. Część flow internalizowana, część przekazywana. Nie wiesz, do której kategorii trafia twoje zlecenie.

Ta sama strategia może być zyskowna u jednego brokera i martwa u drugiego — nie dlatego, że „rynek się zmienił", tylko dlatego, że zmieniły się warunki egzekucji, filtracja flow albo polityka kwotowania. Jeśli twój EA jest zyskowny przez 3–6 miesięcy u brokera B-Book — monitoruj, czy warunki egzekucji nie pogarszają się wraz ze zmianą profilu twojego flow. Jak to zdiagnozować: analiza fill quality w czasie (rolling slippage per direction — czy systematycznie gorszy w jedną stronę?). Sprawdź nasze porównanie brokerów i ranking kont A-Book/ECN.

Fill quality analysis — jak mierzyć, czy broker cię karze

Transaction Cost Analysis (TCA) dla algo tradera detalicznego: po 50+ transakcjach porównaj requested price z fill price dla pozycji długich i krótkich osobno. Jeśli slippage jest systematycznie gorszy w jednym kierunku — masz problem strukturalny, nie rynkowy. MyFxBook ma „Trade Analysis" z kolumną entry/exit efficiency — ale większość traderów nie wie, jak to interpretować. Do przeliczenia kosztów egzekucji na pieniądze użyj naszych kalkulatorów kosztów, pipsów i spreadu.

Korelacje i ekspozycja — pułapka „12 pozycji na skorelowanych parach"

EA, który jednocześnie trzyma long EUR/USD, short USD/CHF i long GBP/USD, nie ma trzech pozycji — ma jedną: zakład na słabość dolara w trzech opakowaniach. Jeśli dolar się umocni, wszystkie trzy tracą jednocześnie.

EA musi mieć filtr ekspozycji walutowej. Zamiast arbitralnego limitu „max N pozycji" — mierz ekspozycję netto na każdą walutę bazową: sumuj notional (wielkość pozycji × kierunek) dla każdej waluty osobno. Jeśli sumaryczna ekspozycja na USD przekracza np. 3% konta — nowe pozycje z dominacją USD są blokowane. Uproszczona metoda: policz, ile twoich otwartych pozycji ma tę samą walutę po tej samej stronie. 3× short USD w różnych parach = jedna duża pozycja short USD w trzech opakowaniach. Więcej o korelacjach i ekspozycji walutowej: dział 7 — analiza międzyrynkowa.

Od pomysłu do live — mapa procesu

Każdy krok to brama — jeśli system nie przechodzi kryterium, wraca do kroku wcześniejszego. Większość pomysłów odpada na kroku 2 lub 3. To nie jest wada procesu — to jest jego cel.

Jarosław Wasiński

Redaktor naczelny MyBank.pl • Analityk finansowy i rynkowy

mgr Jarosław Wasiński — niezależny analityk i praktyk z ponad 20-letnim doświadczeniem w sektorze finansowym. Twórca i redaktor naczelny portalu MyBank.pl, dostarczającego rzetelną wiedzę o finansach osobistych, bankowości i inwestycjach od 2004 roku.

• Bankowość i produkty finansowe: porównania kont osobistych i firmowych, analiza taryf opłat, testy aplikacji mobilnych, recenzje kredytów, lokat i kart kredytowych — z naciskiem na realne koszty i ukryte opłaty.
• Rynki finansowe i makroekonomia: analiza fundamentalna rynków walutowych (Forex) i makroekonomicznych od 2007 roku, zarządzanie ryzykiem kapitału, struktura rynków OTC.
• Kryptowaluty: analiza rynku kryptowalut, mechanizmów blockchain i tokenizacji aktywów w kontekście portfela inwestycyjnego.

Autor setek komentarzy rynkowych, analiz porównawczych produktów bankowych i materiałów edukacyjnych. Zwolennik transparentności — każdy ranking i recenzja na MyBank.pl opiera się na jawnej metodologii i zweryfikowanych źródłach (taryfy banków, regulaminy promocji, dane NBP).

Treści mają charakter edukacyjny i informacyjny — nie stanowią porady inwestycyjnej, rekomendacji ani oferty. Decyzje finansowe podejmuj na podstawie własnej analizy i konsultacji z doradcą.