May Problema sa Orasan ang Backtest Mo, Kahit Tama ang Bawat Timestamp

Maaaring makalusot sa perpektong pagsusuri ng mga timestamp ang pinakamapanganib na problema sa timing sa isang backtest. Maaaring parehong 10:00:00.000 ang nakasaad sa 2 event, pero naganap pa rin ang mga ito sa pagkakasunod-sunod na hinulaan lang ng simulator mo.

Mahalaga ito tuwing tumutugon ang isang strategy sa higit pa sa mga nakumpletong bar: pagbabago sa quote, trade, abiso sa funding, pagbabago sa status ng exchange, o pagkilala sa sarili nitong order. Sinasabi ng timestamp kung kailan nilagyan ng label ang isang event. Maaaring hindi nito sabihin kung kailan ito nagawang aksyunan ng strategy mo.

Ano ang nababago ng pagkakasunod-sunod ng mga event?

Isipin ang isang strategy na bumibili kapag bumaba sa $100.00 ang pinakamagandang ask. Sa iisang millisecond, itinatala ng feed ang pagbabago ng ask sa $99.99 at isang trade sa $99.99. Kung trade muna ang iproseso ng backtest mo, saka ang quote, makikita ng strategy ang bagong ask at magsusumite ito ng order. Ayos din siguro kung quote muna ang ipoproseso, basta aktuwal nang available ang event. Pero kung naubos na ng trade ang nakadispley na liquidity bago dumating ang order, kathang-isip ang fill sa $99.99.

Kapag timestamp lang ang ginamit sa pag-aayos ng mga row, simulator na ang bahalang pumili ng pagkakasunod-sunod ng mga event na tabla ang oras. Maaaring maging di-sinasadyang tuntunin sa execution ang pagkakasunod-sunod sa file, ayos ng mga symbol, o plano ng database query. Maaaring magbago ang equity curve kahit hindi nagbago ang datos na pinagbabatayan.

May simpleng paraan para makita kung gaano ito ka-arbitraryo: ayusin ang mga event na pareho ang oras ayon sa pangalan ng symbol sa halip na ayon sa pagkakasunod ng pagdating. Dahil dito, maaaring umasal nang iba ang strategy na gumagamit ng maraming asset dahil lang mas nauuna sa ayos ang isang ticker kaysa sa iba.

Aling mga orasan ang dapat panatilihin ng backtest?

Kadalasang may ilang magkakaibang oras sa datos ng market at paghawak ng order. Panatilihin ang mga field na ibinibigay ng pinagmulan mo, at pangalanan nang wasto ang kahulugan ng bawat isa. Sa maraming feed, kapaki-pakinabang pareho ang timestamp ng exchange at ang lokal na timestamp ng pagtanggap; hindi ganap na katotohanan ang alinman tungkol sa nakita ng bawat kalahok.

Para sa makasaysayang datos na walang oras ng pagtanggap, ilahad ang ipinapalagay mo. Maaaring iproseso ng backtest ang mga event ng exchange ayon sa pagkakasunod-sunod at magtakda ng nakapirming 5 ms na pagkaantala mula sa pagpapasya hanggang sa pagdating ng order. Modelo ito, hindi kasaysayang nabawi mula sa datos. Kung wala kang sequence number para sa mga event ng exchange na pareho ang timestamp, palagay din ang tuntunin mo sa pagtukoy ng pagkakasunod-sunod.

Paano ko imomodelo ang mga event na tabla ang oras?

Una, panatilihin ang mga sequence number ng pinagmulan kung mayroon. Mas matibay na batayan ang sequence number kaysa timestamp sa pagtukoy ng pagkakasunod-sunod sa loob ng feed nito, bagaman maaaring magkakahiwalay ang sequence space sa iba't ibang channel o produkto.

Pagkatapos, gawing malinaw ang tuntunin ng simulator sa pagproseso. Para sa bawat event, pagpasyahan kung maaari nitong i-update ang impormasyong hawak ng strategy, baguhin ang available na liquidity, magpasimula ng order, o kumilala sa isang order. Magkakaibang aksyon ang mga ito; kapag pinagsama sa “iproseso ang row,” nakalulusot ang mga imposibleng fill.

1. Gamitin lang ang impormasyon ng market na dumating na pagsapit ng oras ng pagpapasya ng strategy.
2. Buuin ang order, saka isulong ito hanggang sa minodelong oras ng pagdating nito sa venue.
3. Payagan lang ang execution laban sa kwalipikadong liquidity pagdating ng order, batay sa mga palagay sa fill para sa uri ng order na iyon.
4. Itala ang mga input, pagkakasunod-sunod ng mga event, at pagkaantalang ginamit sa bawat ginayang fill.

Para sa strategy na nakabatay sa bar, maaaring mas maraming mekanismo ito kaysa sa kailangan ng tanong. Kung gumagamit ang signal ng mga nakumpletong 1-minute bar at napupunan ang mga order sa bukas ng susunod na bar gamit ang konserbatibong modelo ng gastos, malamang na hindi mababago ng pagkakasunod-sunod sa pagitan ng millisecond ang konklusyon ng pananaliksik. Ang mahalaga ay iangkop ang detalye ng timing sa pahayag na ginagawa ng backtest.

Mapagkakatiwalaan ko ba ang backtest na walang datos ng oras ng pagdating?

Magagamit mo pa rin ito, basta malinaw ang hangganan nito. Kung mabagal ang pag-trade ng strategy at maluwag ang mga limitasyon nito sa panganib, maaaring walang saysay ang ilang millisecond. Kung tumutugon ito sa panandaliang quote, nakikipag-unahan para sa puwesto sa pila, o umaasa sa signal na cross-venue lead-lag, maaaring mahalagang bahagi ng resulta ang nawawalang oras ng pagdating.

Tama ang mga kritiko na maaaring magmukhang mas tiyak kaysa sa totoo ang eksaktong timing ng event. Hindi kumpleto ang mga makasaysayang feed, lumilihis ang mga orasan, at hindi ipinakikita ng mga timestamp ng venue ang bawat pagtalon sa network. Kahit may field na nanosecond ang simulator, maaari pa rin itong gumamit ng magaspang na palagay sa fill.

Kaya subukan ang pagiging sensitibo ng resulta sa halip na mag-angkin ng katiyakan: ulitin ang replay gamit ang kapani-paniwalang mga paraan ng pagtukoy sa pagkakasunod ng mga event na tabla ang oras at mga pagkaantala ng order, saka ihambing ang dami ng trade, presyo ng fill, at kung aling mga signal ang nananatili. Kung nakasalalay ang resulta sa pagkakasunod-sunod na hindi matitiyak ng datos, dapat ilahad ang pag-asa sa pagkakasunod-sunod na iyon sa ulat ng pananaliksik. Magagamit ang backtest kahit hindi perpekto ang orasan. Kailangan lang nitong aminin kung anong oras talaga ang alam nito.