Bug waktu paling berbahaya dalam backtest bisa lolos meski audit timestamp sempurna. Dua peristiwa bisa sama-sama mencatat waktu 10:00:00.000, tetapi urutan kejadiannya bisa berbeda dari tebakan simulator Anda.
Ini penting setiap kali strategi bereaksi terhadap hal selain bar yang sudah selesai: pembaruan quote, transaksi, pemberitahuan funding, perubahan status bursa, atau konfirmasi order milik Anda sendiri. Timestamp memberi tahu kapan suatu peristiwa diberi label waktu. Namun, timestamp belum tentu memberi tahu kapan strategi Anda bisa bertindak berdasarkan peristiwa itu.
Apa dampak urutan peristiwa?
Bayangkan strategi yang membeli saat ask terbaik turun di bawah $100.00. Pada milidetik yang sama, feed mencatat pembaruan ask menjadi $99.99 dan transaksi pada harga $99.99. Jika backtest memproses transaksi lebih dulu, lalu quote, strategi melihat ask baru dan mengirim order. Memproses quote lebih dulu juga mungkin tepat, asalkan peristiwa itu memang sudah tersedia. Namun, jika transaksi menghabiskan likuiditas yang ditampilkan sebelum order tiba, fill pada harga $99.99 hanyalah fiksi.
Mengurutkan baris hanya berdasarkan timestamp membuat simulator memilih sendiri urutan untuk peristiwa yang waktunya sama. Urutan dalam file, urutan simbol, atau rencana kueri database bisa tanpa sengaja menjadi aturan eksekusi. Kurva ekuitas dapat berubah meskipun data dasarnya tidak berubah.
Ada cara sederhana untuk melihat betapa sembarangnya hal ini: urutkan peristiwa dengan waktu sama berdasarkan nama simbol, bukan urutan kedatangannya. Strategi multi-aset kemudian bisa berperilaku berbeda hanya karena satu ticker diurutkan sebelum ticker lain.
Jam apa saja yang perlu dicatat backtest?
Data pasar dan penanganan order sering melibatkan beberapa waktu yang berbeda. Simpan kolom yang disediakan sumber data Anda dan beri nama sesuai maknanya. Untuk banyak feed, timestamp bursa dan timestamp penerimaan lokal sama-sama berguna; keduanya bukan kebenaran mutlak tentang apa yang dilihat setiap pelaku.
| Jam | Yang dicatat | Yang tidak dapat dibuktikannya sendiri |
|---|---|---|
| Waktu peristiwa bursa | Kapan bursa menyatakan suatu peristiwa terjadi | Urutan pengamatan feed lain atau proses Anda terhadapnya |
| Waktu penerimaan | Kapan pengumpul data Anda menerima pesan | Kapan strategi Anda selesai memprosesnya |
| Waktu keputusan | Kapan kode Anda mengevaluasi sinyal | Bahwa harga yang dikutip masih tersedia |
| Waktu kedatangan order | Kapan bursa dapat bertindak atas order | Fill, kecuali aturan pencocokan dan likuiditas mendukungnya |
Untuk data historis tanpa waktu penerimaan, jelaskan asumsi Anda. Backtest dapat memproses peristiwa bursa secara berurutan lalu menerapkan jeda tetap 5 ms dari waktu keputusan hingga order tiba di bursa. Itu adalah model, bukan rekonstruksi sejarah. Jika tidak ada nomor urut untuk timestamp bursa yang sama, aturan pemecah seri Anda juga merupakan asumsi.
Bagaimana cara memodelkan peristiwa dengan waktu sama?
Pertama, pertahankan nomor urut dari sumber jika tersedia. Nomor urut memberi dasar pengurutan yang lebih kuat dalam feed-nya daripada timestamp, meski rentang nomor urut bisa berbeda antar-kanal atau produk.
Lalu, nyatakan aturan pemrosesan simulator secara jelas. Untuk setiap peristiwa, tentukan apakah peristiwa itu dapat memperbarui informasi strategi, mengubah likuiditas yang tersedia, memicu order, atau mengonfirmasi order. Semua ini tindakan yang berbeda; meleburkannya menjadi “proses baris” adalah cara fill yang mustahil menyelinap masuk.
- Terapkan hanya informasi pasar yang telah tiba sebelum waktu keputusan strategi.
- Buat order, lalu majukan waktunya hingga waktu kedatangan yang dimodelkan di bursa.
- Izinkan eksekusi hanya terhadap likuiditas yang memenuhi syarat setelah order tiba, sesuai asumsi fill untuk jenis order tersebut.
- Catat input, urutan peristiwa, dan jeda yang digunakan untuk setiap fill simulasi.
Untuk strategi berbasis bar, mekanisme ini mungkin lebih rumit daripada yang dibutuhkan. Jika sinyal menggunakan bar 1 menit yang sudah selesai dan order terisi pada pembukaan bar berikutnya dengan model biaya konservatif, urutan sub-milidetik kemungkinan tidak akan mengubah kesimpulan riset. Intinya adalah menyesuaikan detail waktu dengan klaim yang dibuat backtest.
Bisakah saya memercayai backtest tanpa data waktu kedatangan?
Anda tetap bisa menggunakannya, tetapi jelaskan batasannya. Jika strategi bertransaksi lambat dan batas risikonya longgar, beberapa milidetik mungkin tidak berarti. Namun, jika strategi bereaksi terhadap quote yang cepat lenyap, bersaing untuk posisi antrean, atau bergantung pada sinyal lead-lag lintas bursa, ketiadaan waktu kedatangan bisa sangat memengaruhi hasil.
Para pengkritik benar bahwa ketepatan waktu peristiwa bisa berubah menjadi presisi semu. Feed historis tidak lengkap, jam bisa meleset, dan timestamp bursa tidak mengungkap setiap lompatan jaringan. Simulator dengan kolom nanodetik pun masih bisa menggunakan asumsi fill yang kasar.
Jadi, uji sensitivitas alih-alih mengklaim kepastian: putar ulang dengan beberapa pemecah seri peristiwa dan jeda order yang masuk akal, lalu bandingkan jumlah transaksi, harga fill, dan sinyal mana yang tetap bertahan. Jika hasil bergantung pada urutan yang tidak dapat dipastikan oleh data, cantumkan ketergantungan itu dalam laporan riset. Backtest tetap berguna meski jamnya tidak sempurna. Yang penting, nyatakan waktu apa yang benar-benar diketahuinya.
← Semua artikel
