Backtestin vaarallisin ajoitusvirhe voi jäädä huomaamatta, vaikka aikaleimat tarkistettaisiin täydellisesti. Kahdessa tapahtumassa voi lukea 10:00:00.000, vaikka ne silti tapahtuivat järjestyksessä, jonka simulaattorisi vain arvasi.
Tällä on merkitystä aina, kun strategia reagoi muuhunkin kuin sulkeutuneisiin kynttilöihin: noteerauksen päivitykseen, kauppaan, rahoitusmaksuilmoitukseen, pörssin tilamuutokseen tai oman toimeksiannon kuittaukseen. Aikaleima kertoo, milloin tapahtuma on merkitty tapahtuneeksi. Se ei välttämättä kerro, milloin strategiasi olisi voinut reagoida siihen.
Mitä tapahtumien järjestys muuttaa?
Kuvitellaan strategia, joka ostaa, kun paras myyntihinta laskee alle 100,00 dollarin. Samalla millisekunnilla syötteeseen tallentuu myyntihinnan päivitys tasolle 99,99 dollaria ja kauppa hinnalla 99,99 dollaria. Jos backtestisi käsittelee ensin kaupan ja sitten noteerauksen, strategia näkee uuden myyntihinnan ja lähettää toimeksiannon. Noteerauksen käsittely ensin voi toimia sekin, jos tapahtuma oli oikeasti saatavilla. Mutta jos kauppa käytti näytetyn likviditeetin ennen toimeksiannon saapumista, toteutus hinnalla 99,99 dollaria on kuvitelmaa.
Kun rivit järjestetään vain aikaleiman perusteella, simulaattori saa valita tasan samalla ajalla olevien tapahtumien järjestyksen. Tiedoston järjestys, symbolien järjestys tai tietokannan kyselysuunnitelma voi vahingossa muuttua toteutussäännöksi. Osakekäyrä voi muuttua, vaikka pohjana oleva data pysyy samana.
Tämän mielivaltaisuuden näkee helposti, kun tasan samalla ajalla olevat tapahtumat järjestetään symbolin nimen eikä saapumisjärjestyksen mukaan. Usean omaisuuserän strategia voi silloin toimia eri tavalla vain siksi, että yksi ticker sijoittuu aakkosjärjestyksessä ennen toista.
Mitkä kellonajat backtestissä kannattaa säilyttää?
Markkinadataan ja toimeksiantojen käsittelyyn liittyy usein useita erillisiä aikoja. Säilytä lähteen tarjoamat kentät ja nimeä niiden merkitykset täsmällisesti. Monissa syötteissä sekä pörssin aikaleima että paikallinen vastaanottoaika ovat hyödyllisiä; kumpikaan ei ole yleispätevä totuus siitä, mitä kaikki markkinaosapuolet näkivät.
| Kello | Mitä se kirjaa | Mitä se ei yksinään todista |
|---|---|---|
| Pörssin tapahtuma-aika | Milloin kauppapaikan mukaan tapahtuma sattui | Missä järjestyksessä toinen syöte tai prosessisi havaitsi sen |
| Vastaanottoaika | Milloin datankerääjäsi vastaanotti viestin | Milloin strategiasi sai sen käsittelyn valmiiksi |
| Päätöksentekohetki | Milloin koodisi arvioi signaalin | Että noteerattu hinta oli yhä saatavilla |
| Toimeksiannon saapumisaika | Milloin kauppapaikka pystyi toimimaan toimeksiannon perusteella | Toteutusta, elleivät täsmäytyssäännöt ja likviditeetti sitä tue |
Jos historiallisessa datassa ei ole vastaanottoaikoja, kerro, mitä oletat. Backtestissä voidaan käsitellä pörssin tapahtumat järjestyksessä ja asettaa kiinteäksi viiveeksi 5 ms päätöshetkestä toimeksiannon saapumiseen. Se on malli, ei historiasta palautettu tieto. Jos samalla pörssin aikaleimalla oleville tapahtumille ei ole järjestysnumeroita, myös niiden järjestämissääntö on oletus.
Miten tasan samalla ajalla olevat tapahtumat mallinnetaan?
Säilytä ensin lähteen järjestysnumerot, jos niitä on. Järjestysnumero kertoo syötteen sisäisen järjestyksen luotettavammin kuin aikaleima, vaikka järjestysnumerot voivat olla kanava- tai tuotekohtaisia.
Määrittele sitten simulaattorin käsittelysääntö selkeästi. Päätä jokaisen tapahtuman kohdalla, voiko se päivittää strategian tietoja, muuttaa saatavilla olevaa likviditeettiä, käynnistää toimeksiannon vai kuitata toimeksiannon. Nämä ovat eri toimintoja; niiden niputtaminen yhteen ”käsittele rivi” -vaiheeseen päästää mahdottomat toteutukset livahtamaan mukaan.
- Päivitä strategian käytettävissä olevat markkinatiedot vain sellaisilla tiedoilla, jotka ovat saapuneet päätöshetkeen mennessä.
- Luo toimeksianto ja siirrä se sitten mallinnettuun saapumisaikaansa kauppapaikalle.
- Salli toteutus vain saapumisen jälkeen saatavilla olevaa likviditeettiä vastaan ja kyseisen toimeksiantotyypin toteutusoletusten mukaisesti.
- Kirjaa jokaisen simuloidun toteutuksen syötteet, tapahtumien järjestys ja käytetty viive.
Kynttilädataan perustuvassa strategiassa tämä voi olla tarpeettoman monimutkaista sen tutkimuskysymyksen kannalta. Jos signaali käyttää sulkeutuneita 1 minuutin kynttilöitä ja toimeksiannot toteutetaan seuraavan kynttilän avauksessa varovaisella kulumallilla, millisekunnin murto-osien tapahtumajärjestys tuskin muuttaa tutkimuksen johtopäätöstä. Olennaista on sovittaa ajoituksen tarkkuus siihen väitteeseen, jonka backtest esittää.
Voiko backtestiin luottaa ilman saapumisaikadataa?
Sitä voi silti käyttää, kunhan rajoitus pidetään näkyvissä. Jos strategia käy kauppaa harvakseltaan ja sen riskirajat ovat väljät, muutaman millisekunnin erolla ei ehkä ole merkitystä. Jos se reagoi hetkellisiin noteerauksiin, kilpailee jonosijasta tai riippuu pörssien välisestä johtava-seuraava-signaalista, puuttuvat saapumisajat voivat olla tuloksen kannalta ratkaisevia.
Kriitikot ovat oikeassa siinä, että tapahtumien ajoituksen tarkkuus voi muuttua näennäistarkkuudeksi. Historialliset syötteet ovat puutteellisia, kellot käyvät eri tahtiin eivätkä kauppapaikkojen aikaleimat paljasta kaikkia verkon välitysvaiheita. Simulaattorin nanosekuntikentät eivät estä karkeita toteutusoletuksia.
Testaa siis tuloksen herkkyyttä sen sijaan, että väittäisit varmuutta: toista simulaatio uskottavilla tasatilanteiden järjestyssäännöillä ja toimeksiantoviiveillä, ja vertaa kauppojen määrää, toteutushintaa ja mukana pysyviä signaaleja. Jos tulos riippuu tapahtumajärjestyksestä, jota data ei pysty todentamaan, riippuvuus kuuluu tutkimusraporttiin. Backtestistä voi olla hyötyä epätäydelliselläkin kellolla. Sen on vain kerrottava, minkä ajankohdan se oikeasti tuntee.
← Kaikki kirjoitukset
