Kedden 10:07-kor kutatási ügynökünk rövid távon emelkedő index-ETF-et jelző helyzetre hívta fel a figyelmünket. Az alapul szolgáló jelzés hétköznapi volt: az árfolyam visszakapaszkodott a 20 baros átlag fölé, a realizált volatilitás csökkent, a következő kereskedési napra pedig makrogazdasági adatközlés volt ütemezve. A javasolt ügylet egy körülbelül két hét múlva lejáró vételi spread volt.
A backtest kedvelte az ügyletet. A papírkereskedési stratégia viszont nem nyitotta meg. Amikor összevetettük a megbízásokat, a jelzések időbélyegei egyeztek, az alapul szolgáló eszköz árai pedig néhány centen belül voltak. A kontraktusok eltértek: a backtest a múltbeli opciós láncban legjobbnak tűnő pénteki lejáratot vette meg, a papírkereskedési folyamat pedig a következő jegyzett, egy héttel későbbi lejáratot választotta.
Az eltérést egy naptár-összekapcsolás okozta. A „lejáratig hátralévő napok” értéket egy dátum tulajdonságaként kezeltük, majd kiválasztottuk azt a kontraktust, amelynek lejárata a legközelebb esett a célhoz. A múltbeli adatokban szereplő lejárati naptár tartalmazott egy heti lejáratot, amelyet csak az általunk vizsgált dátum után vezettek be. A backtest a jövőből vett kontraktust használt, ami ártalmatlan kényelmi megoldásnak tűnt.
Először időzónahibára gyanakodtunk. Az opciók lejárati dátuma különösen alkalmas ilyen hibák előidézésére: a piaci kereskedés New Yorkban ér véget, az elszámolási időbélyegeket UTC-ben is tárolhatják, az éjfélhez kötődő dátum pedig eltolódhat, ha a feldolgozási folyamat figyelmetlenül konvertálja. Ellenőriztük. Az időbélyegek rendben voltak. Egyszerűen nem létezett az adott kontraktus abban a keddi múltbeli univerzumban.
Ebből született az első tanulság: a múltbeli opciós láncnak tartalmaznia kell az adott időpontra érvényes jegyzési univerzumot. A kontraktus lejárati dátuma megmutatja, mikor jár le. Azt viszont nem árulja el, mikor jegyezték be, mikortól volt kereskedhető, és hogy a rendszerünk kiválaszthatta-e az adott időpontban.
Újraépítettük a kiválasztási lépést úgy, hogy kizárólag a döntés időpontjában rendelkezésre álló információra támaszkodjon. Minden jelölt kontraktusnál megköveteltük, hogy a jegyzés időbélyege ne legyen későbbi a döntésnél, legyen érvényes, és ne legyen régebbi az adatok frissességi küszöbénél; emellett a stratégia számára megbízásküldésre alkalmas kereskedési szakaszban kellett lennie. A rangsorolás előtt a teljes jelölthalmazt is rögzítettük. Ez utóbbi fontos volt, mert a régi backtest csak a győztest őrizte meg: nem tudtuk megállapítani, hogy öt jogosult kontraktust hasonlított-e össze, vagy észrevétlenül egy még el sem érkezett naptárból választott.
Ezután megvizsgáltuk a spread árazásához használt ajánlati jegyzéseket. A backtest mindkét láb legfrissebb jegyzését külön-külön vette figyelembe. A vételi opció eladási ára 10:06:58-as volt, a rövid pozíciójú vételi opció vételi ára pedig 10:04:11-es. Mindkettő frissnek számított az általános adatszabályunk szerint, de a piac közben elmozdult. Az eltérő időpontokból származó lábak középárából számított spread olyan piacot írhat le, amely soha nem létezett.
Úgy módosítottuk a jegyzési szabályt, hogy a két láb időbélyege legfeljebb 2 másodperccel térhessen el egymástól, továbbá kizártuk a keresztezett vagy nulla méretű piacokat. Emiatt kevesebb múltbeli megfigyelés maradt használható. A megmaradt árak viszont hihetőbbek lettek. Ha nem volt szinkronizált jegyzés, a jelöltet nem elérhetőnek jelöltük, ahelyett hogy egy régi árral töltöttük volna ki a hiányt.
Ezután következett a rangsorolási szabály. Az ügynök azt a lejáratot választotta, amelynél a jegyzett spreadköltség a legalacsonyabb volt. Ez ésszerűnek hangzik, amíg a spread mindössze 1 kontraktusnyi méretű, a jegyzés pedig elavult. Pontosan meghatároztuk a célt: az elvárt hozam maximalizálása a definiált kockázat egységére vetítve, azon kontraktusok körében, amelyek megfelelnek a minimális jegyzési méretre, frissességre és jegyzésre vonatkozó ellenőrzéseknek. Ebben a példában a legközelebbi jogosult lejáratnál a két láb jegyzett ársávja 0,42 dollár volt, a későbbi lejáratnál pedig 0,31 dollár. Az olcsóbbnak tűnő opciónál a rövid lábon mindössze 1 kontraktus szerepelt a könyvben.
| Jelölt | Elérhető volt akkor a lejárat? | Jegyzés kora | A rövid lábon kijelzett méret | Döntés |
|---|---|---|---|---|
| Pénteki heti lejárat | Nem | Nem alkalmazható | Nem alkalmazható | Kizárás |
| Következő péntek | Igen | 1,4 másodperc | 18 kontraktus | Jogosult |
| Harmadik péntek | Igen | 9,8 másodperc | 1 kontraktus | Kizárás: elavult és szűk piac |
A szabályokkal újrajátszottuk az esetet. A backtest most ugyanazt a lejáratot választotta, mint a papírkereskedés, és rögzítette, miért utasította el a többi kontraktust. Az így kapott spreadbelépő 0,11 dollárral kedvezőtlenebb volt az eredeti múltbeli kötési árnál. Ez nem azt jelentette, hogy a stratégia értéktelen; azt jelentette, hogy a régi teljesítményadat olyan ügyletválasztást is tartalmazott, amelyet az élő folyamat nem tudott megismételni.
Egy apró kellemetlenség: a tőzsdei szimbólumok formátuma miatt a lejárati hibák adatminőségi hibának tűnhetnek. Találtunk egy adatszolgáltatói heti kódot, amely egyetlen karakterben különbözött a havi kódtól. Az auditnaplókban továbbra is az eredeti szimbólumot tárolom a normalizált kontraktuskulcs mellett. Nem elegáns, de megóvott attól, hogy túl hamar megbízzunk egy rendezettnek látszó összekapcsolásban.
Ha opciós backtestet építesz, mentsd el minden döntésnél a teljes jelölthalmazt, a kontraktusok jegyzési státuszával, a jegyzések időbélyegeivel és méretével, valamint az elutasítás indokával együtt. Ezután tedd a kontraktusválasztást az adott pillanatfelvételt determinisztikusan feldolgozó függvénnyé. A lejárat kiválasztása a stratégia része. Ha a backtest olyan kontraktust is lát, amelyet a papírkereskedés nem, akkor a jelzések összehasonlítása már azután kezdődik, hogy az eredmény megváltozott.
← Összes bejegyzés
