A stratégia 10:00-kor limitáras megbízást ad be. A jelzése 10:03-kor megváltozik. A backtest csendben lecseréli a megbízást 10:04-kor, majd 10:05-kor teljesülést számol el. Papírkereskedésben az eredeti megbízás még mindig várakozhat a tőzsdén. Ha akkor teljesül, amikor a csere-megbízás is aktív, a stratégiának két megbízása van, miközben a pozíciómodell úgy tesz, mintha csak egy lenne.
A nyitott megbízásoknak saját állapot és időzítő kell. A backtestnek tudnia kell, mikor adták be az egyes megbízásokat, mikor lehetett őket törölni, eljutott-e a törlési kérés a tőzsdére, és mi történik, ha a teljesülés és a törlés versenyhelyzetbe kerül. 3 gyakori egyszerűsítés rendszeresen eltünteti ezeket a tényeket.
1. hiba: az új jelzést azonnali törlésnek venni
Sok backtest minden gyertyánál újraszámolja a célpozíciót, majd felülírja a függő megbízást azzal, amit a legfrissebb jelzés kíván. Így a megbízás pontosan akkor tűnik el, amikor a stratégia meggondolja magát. A valós tőzsdék nem így működnek. A törlési kérés feldolgozása időbe telik, és a megbízás teljesülhet, mielőtt a tőzsde feldolgozza a kérést.
Tegyük fel, hogy van egy 100 részvényre szóló vételi limitáras megbízásunk 50,00 dolláron. 10:03-kor gyengül a jelzés, ezért a stratégia törlést kér. 10:03:00.080-kor 60 részvényre teljesül a megbízás; a törlést 10:03:00.110-kor visszaigazolják. A fennmaradó 40 részvényt törlik, a pozícióban viszont már 60 részvény van. Egy 10:03-kor a megbízást törlő, gyertyaalapú backtest nullát mutathat. Ha pedig az azonnali törlést feltételezi, mégis későbbi teljesülést számol el, ellenkező irányú kitettséget talál ki.
Kövesd nyomon kifejezetten a megbízás életciklusát: beküldve, visszaigazolva, részben teljesült, törlés függőben, törölve vagy teljesen teljesült. Tartsd meg a törlés visszaigazolása előtt bekövetkező teljesüléseket. Durva, gyertyaalapú szimulációnál válassz konzervatív sorrendi szabályt arra az esetre, ha mindkét esemény megtörténhet a gyertyán belül, és ismertesd azt.
2. hiba: a függő megbízást korlátlan ideig érvényesnek tekinteni
Egy 10:00-kor, jelzés alapján beárazott limitáras megbízás akkor is elavulhat, ha a jelzéshez nincs kifejezett kilépési szabály. Változik az ajánlati könyv, módosul a volatilitás, és elmozdulhat az instrumentum piaci értéke. Ha viszont egy szimulátor a teljesülésig aktívan hagyja a megbízást, akár hónapokkal későbbi teljesülést is olyan elképzelés javára írhat, amely már nem is létezik.
Válassz a stratégiához illő érvényességi időt. Egy 1 perces jelzéshez 30 másodperces lejárat illhet; egy napi újrasúlyozásnál a megbízás a zárásig maradhat aktív. Ezek stratégiai döntések, nem általános alapértékek. Ha a stratégia minden gyertyánál újraáraz, modellezd a törlés és az új megbízás beadásának folyamatát ahelyett, hogy a megbízás varázsütésre az új árra ugrana.
| Megbízási szabály | Jellemző alkalmazás | Backtestkérdés |
|---|---|---|
| Azonnali vagy törlés | A rendelkezésre álló likviditás igénybevétele, majd leállás | A beadáskor mekkora mennyiség teljesülhetett volna? |
| Rövid lejárat | Gyors jelzés rövid végrehajtási időablakkal | Érvényes volt még a megbízás, amikor az ár visszatért? |
| A kereskedési szakasz végéig | Lassú újrasúlyozás vagy záró aukcióra szánt megbízás | Támogatja a tőzsde ezt az érvényességi időt? |
3. hiba: minden árszintérintést teljesülésnek számolni
Ha egy gyertya mélypontja eléri a vételi limitárat, attól a megbízás még nem feltétlenül teljesült. Lehettek előtte mások a sorban, az adott áron alacsony lehetett a forgalom, vagy az ár csak egy pillanatra érintette a szintet, még a megbízás beérkezése előtt. Egy elavult megbízásmodell gyakran mindhárom hibát elköveti: túl sokáig tartja aktívan a megbízást, feltételezi, hogy elsőként állt a sorban, majd teljes teljesülést számol el az árszint érintésekor.
Legalább azt akadályozd meg, hogy a megbízás beérkezése előtti teljesüléseket számolj el, és korlátozd a szimulált mennyiséget a limitáron valószínűsíthető forgalomra. Azoknál a stratégiáknál, amelyeknél számít a sorban elfoglalt hely, használj kötési és ajánlatikönyv-adatokat vagy szándékosan konzervatív sorbanállási modellt. Az árszintérintésen alapuló teljesülési modell gyors előszűréshez továbbra is hasznos lehet, de jelöld optimista közelítésként, és hasonlítsd össze egy szigorúbb feltételezéssel.
Egy praktikus ellenőrzés: naplózd minden megbízás létrehozásának időpontját, aktív időablakát, a törlési kérést és annak visszaigazolását, a teljesülés idejét, a teljesült mennyiséget és a fennmaradó mennyiséget. Ezután játssz vissza néhány ügyletet a jelzés irányváltásai körül. Ha nem tudod megmagyarázni, miért volt még aktív az egyes megbízás a teljesülésekor, dolgoznod kell a backtest teljesülésszámításán.
Azt a megbízást modellezd, amellyel papírkereskedni akarsz
A megbízás állapota köti össze a stratégia szándékát a tényleges kitettséggel. A pozíciónak a teljesülésekkel kell változnia, nem a jelzés célértékeivel vagy a törlési kérésekkel. A cserékről maradjon ellenőrizhető nyom, a részleges teljesülések pedig számítsanak a következő döntésnél is. Ettől körülményesebb lesz a backtest, de a papírkereskedéssel való összehasonlítás is értelmet nyer: a két rendszer végrehajtási eltéréseinek azonosítható okai lesznek.
Ha a megbízásmodell bizonytalan, az eredményben is jelenítsd meg ezt a bizonytalanságot. Futtass rövid és hosszú érvényességű megbízásokat, változtasd a törlési késleltetést, és mutasd meg, mennyire függ a teljesítmény az optimista sorbanállási feltételezésektől. Lehet, hogy a stratégiával minden rendben. Az is lehet, hogy a látszólagos előny csupán annak a megbízásnak a kamata, amelyet az éles rendszer már órákkal korábban törölt volna.
← Összes bejegyzés
