Mé workflow vývoje intradenních systémů
S tím, jak postupně do svého automatizovaného portfolia nasazuji i intradenní systémy, jsem si pro sebe definoval určité „workflow“, s nímž systémy tvořím. Zde jsou tipy, které mohou pomoci i vám.
Obsah článku:
- Jak na intradenní obchodní systémy?
- Vývoj systémů na denních datech
- Intradenní stop-lossy na denních datech
- Prototypování systémů vs. jemné testování
- Ukázka workflow
- Závěr
K příspěvku mě dovedl tento dotaz v Trading Room:
Jak na intradenní obchodní systémy?
Předně žádná cesta v rámci intradenního obchodování nebude bez práce. Tedy samozřejmě kromě té, kdy si koupíte nějaký zázračný software, kde vám po stisknutí tlačítka začne sám připravovat zaručeně robustní AOS.
Sám na podobné zázraky nevěřím, a tak nezbývá než investovat čas do ručního testování různých nápadů, ze kterých následně tvořím reálné „idea first“ obchodní systémy.
Potíž s intradenními systémy je především v tom, že pracujeme s ohromným množstvím dat. Bez ohledu na zvolený software je vše výrazně pomalejší, náročnější na hardware a do velké míry i na know-how. S jemnými intradenními daty lze vymýšlet násobně více taktik než na denních datech, což s sebou přináší i výrazně vyšší riziko přeoptimalizace, chyb v kódech či v následném automatizovaném obchodování.
Osobně se mi tak osvědčilo vyvíjet intradenní systémy na denních datech.
Vývoj systémů na denních datech
Denní data obsahují informace o otevírací a uzavírací ceně, denní minimální ceně a denní maximální ceně. S denními daty se proto pracuje velmi efektivně – za rok máme přibližně 250 úseček. Pracovat pak lze v programech, jejichž ovládání známe ze swingového obchodování (např. Amibroker).
Ovšem jak na denních datech vyvíjet intradenní systémy? Tím, že nevidíme „dovnitř“ denních úseček, tak pochopitelně můžeme vyvíjet jen určité typy intradenních systémů. Například jednoduché breakout či mean reversion systémy vycházející z denní otevírací ceny či jiného fixního bodu denních grafů.
Nemůžeme tak například vytvářet obchodní systém obchodující průlom např. 5minutového otevírací rozpětí popisovaného v článku Jak na první daytrading autotrader [včetně funkční strategie a kódu]. Z mé zkušenosti to ale tolik nevadí. Protože i jen na denních datech lze najít mnoho funkčních intradenních přístupů (sám jsem takto dříve vyvinul Finwin, který dnes obchoduji řadu let).
Intradenní stop-lossy na denních datech
Největším úskalím při vývoji intradenních obchodních systémů na denních datech jsou stop-lossy. Na denních datech nevidíme „dovnitř“ úseček a jen těžko se odhaduje, jestli byla u obchodu dříve zasažena úroveň stop-lossu, vstupu či výstupu.
Osobně tak začínám s vývojem strategií s velmi vzdáleným, nebo žádným stop-lossem. Ve svých systémech často pracuji s indikátorem ATR a jedním z typických příkladů vzdáleného stop-lossu je 1xATR. Takový už bývá spolehlivě identifikovatelný i na denních grafech.
Ve svých testech tak chci nacházet strategie, které relativně stabilně fungují i s velkými stop-lossy. A teprve až takovou strategii objevím, otestuji ji na intradenních datech.
Prototypování systémů vs. jemné testování
Svou práci tak můžu rozdělit do dvou základních kroků:
- Prototypování systému na denních datech
- Finální backtest hotového prototypu na intradenních datech
Pokud jste vývoj intradenního systému nikdy nezkoušeli, možná nevidíte v rozdělení práce do zmíněných bodů žádný zásadní benefit.
Pro mě tam rozdíl je – především v efektivitě. Nejsem programátor a s jakýmkoliv skriptováním bojuji. A skriptování na intradenních datech je pro mě násobně náročnější než na denních. Při hledání nových obchodních přístupů testuji průběžně řadu různých myšlenek. Mohu například zkoumat signály vycházející z korelace či divergencí trhů, sezonality, market internals a podobně. Podobné testy mám na denních grafech hotové velmi rychle.
A pokud vypadá nějaká myšlenka nadějně, tak teprve potom věnuji pozornost přípravě intradenního kódu, pro který nejčastěji používám TradeStation či Python. V momentě, kdy vím, co přesně potřebuji naskriptovat, už to nemusí být tolik složité.
Ve finálních testech s intradenními daty navíc první backtesty provádím se vzdáleným stop-lossem podobně, jako jsem to dělal ve fázi prototypování. A logicky bych měl dostávat podobné výsledky, čímž si ověřuji funkčnost svých kódů.
Ukázka workflow
Na denních datech testuji různé myšlenky. Jedním z dobrých směrů může být například intradenní breakout na akciovém indexu. Např. Nasdaq 100. Breakout systém má v principu jednoduchou konstrukci. Vezmeme nějaký počáteční bod – např. denní open, poslední close, nejvyšší high za posledních x dnů a podobně, přidáme k bodu určitou vzdálenost (sám rád pracuji s násobkem ATR), a pokud trh tuto úroveň překoná, zaznamenáme long breakout a držíme pozici do dosažení profitargetu či do konce dne. Pokud se trh obrátí, vystoupíme na stop-lossu. Jak jsem zmínil, u prototypů podobných systémů na denních grafech používám vzdálený stop-loss (např. 1xATR).
Testy na uvedené úrovni jsou např. v Amibrokeru velmi jednoduché s tím, že do popsané kostry systému budete chtít zakomponovat pravděpodobně ještě nějaký „filtr“. Bez toho nebude systém reálně obchodovatelný.
A takto může vypadat výsledek prototypu:
Pro ilustraci jsem zobrazil equity křivku prototypu „long intradenní breakout v Nasdaq 100“ vytvořenou pouze z denních úseček (modrá barva) vs. finální backtest s využitím intradenních dat (oranžová barva).
Equity křivky nejsou úplně stejné zejména proto, že v tomto případě intradenní backtest probíhal v Pythonu, kde se mi trochu jinak počítá ATR než v Amibrokeru. Podobné detaily nejsou z mé zkušenosti podstatné, protože ve finálním živém obchodování se do procesu živého obchodování na burze stejně dostává určitý prvek náhody.
Ale to podstatné je jistě patrné – prototyp se vzdáleným stop-lossem (1xATR) odpovídá finálnímu intradennímu backtestu.
Funguje to samozřejmě i na delší historii dat:
Finální myšlenku pak už ladím v samotném intradenním backtesteru. Zde zejména testuji jemnější práci s bližšími stop-lossy. Protože ty z mé zkušenosti nelze na denních datech používat – vedou k příliš optimistickým závěrům.
Dobře je to patrné na tomto screenshotu:
Zde jsem v prototypu na denních datech snížil stop-loss na 0,4x ATR (modrá linka) a následně provedl stejný backtest na intradenních datech (oranžová linka). Je zde patrné, že pokud bychom malý stop-loss použily už v prototypu pracujícím s denními daty, budou naše závěry z backtestu příliš optimistické.
Závěr
Dnešní tip ukazuje, že pokud budete určitý typ intradenních systémů prototypovat na denních datech, můžete se poměrně dobře na výsledky spolehnout za předpokladu, že budete pracovat se vzdálenějšími stop-lossy (např. 1xATR).
Pokud se tak chcete do vývoje intradenních systému pustit, můžete začít právě na denních datech. A teprve až budete mít hotový funkční prototyp (jakože najít obchodní systém trvá určitě týdny až měsíce), pak už není zas takový problém konkrétní jednu finální myšlenku převést do příslušného intradenního backtesteru (např. s použitím TradeStation).
Jinými slovy – není třeba se od počátku stresovat z potřeby ovládnutí dalšího softwaru. Ale je možné začít na stejném softwaru, který používáte pro analýzy denních grafů a teprve, až budete mít jasnou představu o potenciálním intradenním obchodním systému (podloženou funkčním prototypem) tak řešit, jak systém finálně otestovat na intradenních datech.
Petr Podhajský
Fulltime obchodník věnující se tradingu více než 20 let. Specializace na systematické strategie obchodované na futures a akciích. Oblíbený styl obchodování: stavba automatizovaných portfolio systémů, které využívá i při správě většího externího kapitálu.
-
3
-
3
