A backtesztelés legveszélyesebb időzítési hibája a tökéletes időbélyeg-ellenőrzést is túlélheti. Két esemény időbélyege egyaránt lehet 10:00:00.000, mégis olyan sorrendben történhettek, amelyet a szimulátor csak megtippelt.
Ez akkor számít, ha a stratégia nem csupán lezárt gyertyákra reagál, hanem például jegyzésfrissítésre, kötésre, finanszírozási értesítésre, tőzsdei állapotváltozásra vagy a saját megbízása visszaigazolására is. Az időbélyeg azt jelzi, mikorra van datálva egy esemény. Azt nem feltétlenül árulja el, hogy a stratégiád mikor reagálhatott rá.
Mit változtat az események sorrendje?
Képzeljünk el egy stratégiát, amely akkor vásárol, ha a legjobb eladási ár $100.00 alá esik. Ugyanabban a milliszekundumban az adatfolyam egy jegyzésfrissítést rögzít $99.99-es eladási árral és egy kötést $99.99-en. Ha a backteszt előbb a kötést, majd a jegyzést dolgozza fel, a stratégia már az új eladási árat látja, és megbízást küld. A fordított sorrend is megfelelő lehet, feltéve, hogy az esemény ténylegesen elérhető volt. De ha a kötés elhasználta a látható likviditást, mielőtt a megbízás beérkezett volna, a $99.99-es teljesülés fikció.
Ha csak időbélyeg szerint rendezzük a sorokat, az azonos időpontú események sorrendjét a szimulátor választja meg. A fájl sorrendje, a szimbólumok sorrendje vagy az adatbázis lekérdezési terve véletlenül végrehajtási szabállyá válhat. A tőkegörbe akkor is megváltozhat, ha az alapul szolgáló adatok nem változtak.
Jól látszik, mennyire önkényes lehet ez, ha az azonos idejű eseményeket érkezési sorrend helyett szimbólumnév szerint rendezzük. Egy többeszközös stratégia pusztán azért viselkedhet másként, mert az egyik ticker előrébb kerül a rendezésben.
Milyen időket érdemes nyilvántartani a backtesztben?
A piaci adatoknál és a megbízások kezelésénél gyakran többféle időponttal kell számolni. Őrizzük meg a forrás által megadott mezőket, és pontosan nevezzük meg, mit jelentenek. Sok adatfolyamnál a tőzsdei időbélyeg és a helyi fogadási időbélyeg is hasznos; egyik sem ad általános érvényű bizonyítékot arra, mit látott minden piaci szereplő.
| Időpont | Mit rögzít | Mit nem bizonyít önmagában |
|---|---|---|
| Tőzsdei eseményidő | Mikorra datálja a helyszín az eseményt | Milyen sorrendben észlelte egy másik adatfolyam vagy a folyamatod |
| Fogadási idő | Mikor kapta meg az üzenetet az adatgyűjtőd | Mikor fejezte be a stratégia az üzenet feldolgozását |
| Döntési idő | Mikor értékelte ki a kódod a jelzést | Hogy a jegyzett ár továbbra is elérhető volt |
| Megbízás beérkezési ideje | Mikor tudott a tőzsde intézkedni a megbízásról | Hogy létrejött-e kötés; ehhez a párosítási szabályoknak és a likviditásnak is alá kell támasztania |
Ha a történelmi adatokban nincs fogadási idő, írjuk le, mit feltételezünk. A backteszt feldolgozhatja a tőzsdei eseményeket sorrendben, és rögzített 5 ms-os késleltetést rendelhet a döntés és a megbízás tőzsdére érkezése közé. Ez modell, nem visszanyert múltbeli adat. Ha az azonos időbélyegű tőzsdei eseményekhez nincs sorszám, az események sorrendjét meghatározó szabályunk is feltételezés.
Hogyan modellezzem az azonos időpontú eseményeket?
Először őrizzük meg a forrás sorszámait, ha vannak ilyenek. A sorszám megbízhatóbban határozza meg a sorrendet egy adatfolyamon belül, mint az időbélyeg, de a különböző csatornák vagy termékek sorszámozása eltérhet.
Ezután tegyük egyértelművé a szimulátor feldolgozási szabályát. Minden eseménynél döntsük el, hogy frissítheti-e a stratégia információit, módosíthatja-e az elérhető likviditást, kiválthat-e egy megbízást, vagy visszaigazolhat-e egy megbízást. Ezek különböző műveletek; ha mindet egyetlen „sor feldolgozása” lépésbe vonjuk össze, lehetetlen kötések csúszhatnak be.
- Csak azokat a piaci információkat alkalmazzuk, amelyek a stratégia döntési időpontjáig beérkeztek.
- Hozzuk létre a megbízást, majd léptessük előre a modellezett tőzsdei beérkezési idejéig.
- Végrehajtást csak a beérkezés után, az adott megbízástípusra érvényes feltételek szerint vehető likviditás ellenében engedjünk.
- Minden szimulált kötésnél rögzítsük a bemeneti adatokat, az események sorrendjét és az alkalmazott késleltetést.
Gyertyákon alapuló stratégiánál ez több lehet annál, mint amit a kérdés megválaszolása igényel. Ha a jelzés lezárt 1 perces gyertyákat használ, a megbízások pedig a következő gyertya nyitásakor teljesülnek egy konzervatív költségmodellel, a milliszekundum alatti sorrend valószínűleg nem változtatja meg a kutatási következtetést. A lényeg, hogy az időzítés részletessége igazodjon ahhoz az állításhoz, amelyet a backteszt alátámaszt.
Megbízhatok a backtesztben fogadási időadatok nélkül?
Használhatjuk így is, de tartsuk szem előtt a korlátait. Ha a stratégia ritkán kereskedik és tág kockázati limiteket használ, néhány milliszekundum lényegtelen lehet. Ha múló jegyzésekre reagál, a sorban elfoglalt helyért versenyez, vagy a különböző tőzsdék közötti vezető-követő jelzésre épít, a hiányzó fogadási idők alapvetően befolyásolhatják az eredményt.
A kritikusoknak igazuk van abban, hogy a pontos eseményidőzítés hamis pontosság érzetét keltheti. A történelmi adatfolyamok hiányosak, az órák eltérhetnek, a tőzsdei időbélyegek pedig nem fednek fel minden hálózati szakaszt. Egy nanoszekundumos mezőket használó szimulátor is támaszkodhat durva kötési feltételezésekre.
Ezért bizonyosság állítása helyett vizsgáljuk meg az érzékenységet: játsszuk vissza az adatokat életszerű eseménysorrendekkel és megbízáskésleltetésekkel, majd hasonlítsuk össze az ügyletek számát, a teljesülési árat és a fennmaradó jelzéseket. Ha az eredmény olyan sorrendtől függ, amelyet az adatok nem tudnak igazolni, ezt a függőséget fel kell tüntetni a kutatási jelentésben. Tökéletlen órával is hasznos lehet egy backteszt. Csak azt kell elismernie, hogy valójában mit tud az időről.
← Összes bejegyzés
