A backtest gyakran úgy számolja az ügyleteket, mintha a jelzés közvetlenül pozícióvá alakulna. A papírkereskedésben közéjük ékelődik egy megbízás. Ez a megbízás várakozhat, részben teljesülhet, visszavonható vagy elutasítható, de a jelzés változása után is aktív maradhat. Ha a szimulált stratégiád kihagyja ezt az életciklust, az ügyletek száma és a kitettség alig hasonlíthat arra, amit a papírszámla rögzít.
A gyakorlati megoldás, hogy a megbízásokat állapotokkal és időbélyegekkel rendelkező, tartós objektumként kezeljük. A jelzés utasítás arra, hogy megpróbáljunk kereskedni; önmagában nem bizonyítja, hogy ügylet is történt.
Miért van kevesebb ügylet a papírstratégiámban, mint a backtestemben?
Kezdjük azokkal a megbízásokkal, amelyek sosem teljesültek. A backtest feltételezheti, hogy minden limitmegbízás teljesült, amint a piac elérte az árát. Élő piacon az ár érintése nem árulja el, hogy a megbízásod a sor elején állt-e, kereskedtek-e elegendő volumennel, vagy az ajánlat még elérhető volt-e, amikor a megbízásod eljutott a tőzsdére.
Vegyünk egy stratégiát, amely $100-os vételi limitáras megbízást ad be, majd 30 másodperc után visszavonja. A piacon $100.00-os kötés születik, de ott csak kis mennyiség cserél gazdát, és más megbízások elsőbbséget élveznek. A megbízásod részben teljesülhet, vagy egyáltalán nem. Az árérintés-alapú backtest teljes pozíciót rögzít. A sorban állási feltételezéseket követő papírszámla viszont akár egyetlen teljesülést sem jelezhet.
A piaci megbízásoknál más jellegű az eltérés. A backtest a teljes mennyiséget a következő gyertya nyitóárán teljesítheti, míg a papírkereskedés elutasíthat olyan mennyiséget, amely megsérti a tőzsde valamelyik korlátozását, vagy részletekben teljesítheti, miközben változik a könyv. A gyertya a kötések összefoglalója; nem garantálja, hogy a teljes megbízásod egyetlen áron teljesülhetett volna.
Mit tegyen a backtest, ha a jelzés megváltozik, mielőtt a megbízás teljesülne?
A régi megbízás maradjon aktív, amíg a szimulátor meg nem kapja és fel nem dolgozza a visszavonást. Ha vételi megbízás várakozik, miközben a jelzés megfordul, a stratégia vissza akarhatja vonni, és eladási megbízást küldhet be. Ez a szándék nem törli el azonnal a vételi megbízást. Az még teljesülhet, miközben a visszavonás folyamatban van, így a számla éppen akkor kerülhet nettó vételi pozícióba, amikor az új jelzés már nettó eladást jelez.
Modellezzük ezt eseménysorozatként: megváltozik a jelzés, a stratégia visszavonási kérelmet küld, a tőzsde visszaigazolja a visszavonást vagy teljesülést jelez, és a stratégia csak ezután tudja meg a megbízás végleges állapotát. Már egy egyszerű, rögzített késleltetés is feltárhat olyan versenyhelyzeteket, amelyeket az azonnali visszavonást feltételező backtest elfed.
Egy szándékosan egyszerű modellben az 1 másodperces visszavonási késleltetés és a következő eseménykor történő feldolgozás informatívabb lehet annál, mintha úgy tennénk, hogy a visszavonás azonnali. A megfelelő késleltetés a tőzsdétől és a rendszertől függ; a lényeg, hogy egyáltalán számoljunk késleltetéssel. Ha a megbízásod piaci megbízás, amelynél nincs visszavonási időablak, a részleges teljesülések és a későn érkező jelentések miatt ugyanez a kérdés továbbra is fontos.
Milyen megbízási állapotokat rögzítsen a papírkereskedési szimulátor?
Használjunk egyszerű állapotgépet, és minden átmenetet őrizzünk meg az időpontjával együtt. A tőzsdéken használt pontos kifejezések eltérhetnek, de az alapvető különbségek ugyanazok:
- Új vagy függőben: beküldve, de még nincs visszaigazolva.
- Nyitott: elfogadva, és továbbra is teljesülhet.
- Részben teljesült: a mennyiség egy része elkelt; a fennmaradó rész továbbra is nyitott lehet.
- Teljesült: nincs fennmaradó mennyiség.
- Visszavonás függőben: a visszavonási kérelem feldolgozás alatt van; a megbízás még teljesülhet.
- Visszavonva, elutasítva vagy lejárt: ezzel a megbízással már nem lehet további mennyiséget kötni.
A teljesült mennyiséget a kért mennyiségtől külön rögzítsük, a teljesülési árakkal és díjakkal együtt. A részben teljesült megbízás egyszerre jelent ügyletet és a fennmaradó részre vonatkozó élő kötelezettséget. Ha egyszerűen csak nyitottnak vagy lezártnak tekintjük, elveszítjük a stratégiának a következő lépés méretezéséhez szükséges információkat.
| Megbízási esemény | Mit kell tudnia a stratégiának? | Gyakori backtestes egyszerűsítés |
|---|---|---|
| Részleges teljesülés | Teljesült mennyiség, fennmaradó mennyiség, átlagár | A teljes megbízás teljesültnek jelölése egyetlen áron |
| Visszavonási kérelem | A kérelem időpontja és a végleges visszavonási vagy teljesülési visszaigazolás | A megbízás azonnali eltávolítása |
| Elutasítás | Az ok, és hogy érvényes próbálkozni újra | A kért ügylet megtörténtének feltételezése |
| Lejárat | Az időpont, amikor a megbízás már nem teljesülhetett | Nyitva hagyás egy későbbi árérintésig |
Hogyan hasonlítsam össze méltányosan a backtest ügyleteit a papírkereskedéssel?
Először a megbízási eseményeket, aztán a pozíciókat, végül a P&L-t hasonlítsuk össze. Ha a backtest teljesítettnek vett egy megbízást, amely a papírszámlán sosem teljesült, a későbbi P&L-különbség következmény, nem ott kell keresni a hiba okát.
Minden tervezett megbízást párosítsunk a két futásban egy stabil stratégiai döntésazonosító vagy megbízásazonosító alapján. Ezután vizsgáljuk meg a beküldés időpontját, a kért árat és mennyiséget, az érvényességi időt, a teljesüléseket, visszavonásokat, elutasításokat, díjakat és a végső pozíciót. A szimulált nem teljesülés okát is rögzítsük: az ár nem érte el a limitet, nem ürült ki a feltételezett előttünk álló sor, vagy lejárt a megbízás.
Egy rövid példa jól megmutatja a folyamatot. A jelzés 10 egységet kér. Mindkét rendszer 10:00:00-kor küldi be a megbízást. A backtest 10:00:01-kor teljes teljesülést feltételez. A papírkereskedés 10:00:01-kor 4 egységet teljesít, 10:00:02-kor visszavonási kérelem érkezik, majd a visszavonás 10:00:03-as visszaigazolása előtt további 2 egység teljesüléséről küld jelentést. A korrekt összehasonlítás: 6 teljesült egység a 10-hez képest, 4 egység pedig visszavonva. Ha mindezt egyetlen „ügyletbe” átlagoljuk, eltűnik a tényleges kitettség, amelyet a stratégia vállalt.
Szükségem van teljes tőzsdei szimulátorra ahhoz, hogy ezt jól modellezzem?
Nem. A backtest néhány egyértelmű feltevéssel is indulhat: elegendő-e a limitár érintése, mekkora forgalomnak kell az áron átkereskednie ahhoz, hogy a feltételezett előttünk álló sor kiürüljön, mennyi ideig maradjanak nyitva a megbízások, és hogyan működjenek a visszavonási késleltetések. Futtassuk a stratégiát több, életszerű beállítással. Ha a teljesítmény azon múlik, hogy minden várakozó limitmegbízás teljes egészében teljesüljön, hasznosat tudtunk meg a modellről.
A papírkereskedés sem jelent valós végrehajtási minőséget. Használhat szimulált teljesüléseket, és figyelmen kívül hagyhatja a valós sorban állást. Itt szűkebb a szerepe: megmutatja, hogy a stratégia és a megbízáskezelő ugyanúgy kezeli-e a függő mennyiséget, a visszavonást, a pozíciót és az újrapróbálkozást, ahogy az események idővel beérkeznek.
Ennek a munkának van egy apró öröme: egy jó megbízási napló egy egyébként rejtélyes eltérést is unalmassá tehet. „A második gyermekmegbízás a visszavonási kérelem után teljesült” sokkal jobb, mint az, hogy „furcsán viselkedik a papírkereskedés”. Ha a backtest és a papírszámla nem egyezik, a jelzés módosítása előtt kövessük végig a megbízás életciklusát.
← Összes bejegyzés
