Definisikan likuiditas scalping sebelum mengujinya
Likuiditas scalping bukanlah satu angka tunggal. Dalam praktiknya, ini menggambarkan apakah Anda bisa secara andal mengeksekusi trading berukuran kecil dengan horizon waktu singkat, dengan biaya transaksi yang dapat diterima dan pergerakan harga yang merugikan secara terbatas antara saat pengajuan order dan saat order terisi.
Cara yang berguna untuk membuat pengujian ini dapat diuji adalah dengan menerjemahkan “likuiditas” menjadi hasil eksekusi yang terukur:
- Probabilitas terisi (fill probability): seberapa sering order (dalam jendela waktu yang Anda pilih) terisi.
- Spread realisasi / biaya efektif: seberapa jauh harga eksekusi dari referensi yang dipilih (sering kali bid/ask yang berlaku pada saat pengajuan, jika Anda bisa mengukurnya).
- Slippage: selisih antara harga pada saat keputusan (atau mid) dan harga saat terisi.
- Pergerakan merugikan antar order: apakah pasar bergerak melawan Anda dengan cepat selama jendela eksekusi Anda.
Dengan mendefinisikan outcome ini sejak awal, Anda menghindari pencampuran mekanisme pasar yang stabil dengan faktor yang berubah seperti kecepatan eksekusi, penanganan order, atau routing yang spesifik dari penyedia.
Nyatakan hipotesis yang dapat dipatahkan dan baseline
Sebuah uji bekerja paling baik ketika memiliki hipotesis yang jelas dan baseline yang mewakili “tidak ada keunggulan khusus.” Misalnya, hipotesis umum bisa jadi:
- Hipotesis (likuiditas yang dapat ditradasikan): “Dalam kondisi yang didefinisikan, eksekusi horizon pendek memiliki biaya realisasi yang stabil dan dapat diterima dibandingkan dengan referensi baseline.”
Baseline seharusnya tidak mengasumsikan strategi trading tertentu. Sebaliknya, baseline harus mewakili referensi eksekusi yang netral, seperti:
- harga referensi benchmark pada saat pengajuan (mis., bid/ask atau mid, tergantung apa yang bisa Anda catat),
- perbandingan antara fill dan non-fill di bawah batasan yang identik,
- atau perbandingan antar rezim pasar (tenang vs aktif) sambil menjaga aturan eksekusi tetap sama.
Jika Anda tidak bisa mengukur bid/ask pada saat pengajuan, pengujian Anda tetap bisa dilakukan, tetapi Anda harus menyatakan bahwa referensi Anda bersifat perkiraan (misalnya, menggunakan last traded price sebagai proksi). Keterbatasan itu harus dinyatakan secara eksplisit dalam asumsi Anda.
Rancang pembagian data: mekanisme stabil vs kondisi yang bervariasi
Likuiditas berubah seiring waktu dan kondisi, jadi Anda perlu beberapa irisan data. Pisahkan dataset Anda minimal dengan tiga cara:
- Waktu dalam sehari dan hari dalam seminggu: kualitas eksekusi bisa berbeda antar sesi.
- Rezim pasar: misalnya, kategorikan berdasarkan volatilitas atau apakah harga berubah besar vs kecil. Gunakan aturan yang konsisten agar Anda bisa mereproduksinya.
- Ukuran order / agresivitas: uji order kecil vs lebih besar, dan uji tipe order yang berbeda (sejauh data Anda memungkinkan) karena konsumsi kedalaman dan perilaku antrian bisa berubah.
Lalu, tentukan jendela evaluasi untuk likuiditas scalping. Misalnya, Anda bisa memilih jendela eksekusi yang singkat (menit, bukan jam) dan mengukur apakah order terisi dalam jendela tersebut serta pada biaya efektif berapa.
Tentukan asumsi dan sertakan biaya secara eksplisit
Setiap “uji likuiditas” menjadi tidak berarti jika biaya dihilangkan atau dimodelkan secara tidak konsisten. Bahkan dengan informasi umum, Anda tetap bisa membuat uji Anda dapat diverifikasi secara independen dengan menuliskan asumsi.
Sertakan setidaknya:
- Biaya transaksi yang akan Anda perlakukan sebagai bagian dari kualitas eksekusi (mis., komisi atau fee jika itu bagian dari kerangka pengukuran Anda).
- Referensi spread dan cara Anda menghitung effective spread. Jika Anda menggunakan midpoint, nyatakan itu dengan jelas.
- Asumsi penanganan order (mis., jika Anda mengasumsikan Anda bisa mengamati bid/ask pada saat pengajuan, atau jika Anda mengandalkan snapshot).
- Aturan jendela eksekusi (apa yang terjadi ketika sebuah order tidak terisi sebelum jendela berakhir).
Jika Anda tidak memiliki data order book secara live, Anda tetap bisa menguji outcome realisasi dari trade prints yang memang Anda amati, tetapi Anda harus membedakan:
- Fill dan harga yang teramati (data yang benar-benar Anda miliki), vs.
- Mikrostruktur yang tidak teramati (hal-hal yang Anda infer tetapi tidak bisa konfirmasi, seperti posisi antrian).
Pemisahan ini membantu mencegah melebih-lebihkan apa yang benar-benar diukur oleh pengujian.
Pendekatan bukti atau contoh: ukur kualitas eksekusi, bukan sinyal
Karena Anda ingin menguji likuiditas scalping, bukan sinyal trading, susun bukti sebagai metrik kualitas eksekusi.
Contoh desain praktis (konseptual, tidak terikat pada harga riil) bisa seperti ini:
- Pilih seperangkat aturan eksekusi scalping yang berfokus pada timing order dan batasan, bukan pada memprediksi arah.
- Untuk setiap irisan (waktu/rezim/ukuran), lakukan simulasi atau evaluasi eksekusi dengan aturan yang sama.
- Hitung metrik:
- fill rate dalam jendela eksekusi,
- median dan biaya efektif pada ekor (tail),
- distribusi slippage.
- Bandingkan hasil dengan baseline referensi di seluruh irisan.
Poin kunci: “bukti” adalah apakah outcome eksekusi tetap berada dalam rentang yang dapat diterima secara konsisten di berbagai kondisi, bukan apakah Anda bisa menciptakan satu skenario yang terlihat menguntungkan. Laporan Anda harus mencakup variabilitas, seperti bagaimana biaya berperilaku pada rezim yang tertekan atau bergerak cepat.
Biaya dan robustness checks
Untuk mencegah sebuah uji menangkap keanehan sesaat, jalankan robustness checks yang mengubah satu pilihan pemodelan pada satu waktu.
Robustness checks yang umum meliputi:
- Sensitivitas harga referensi: ulangi perhitungan menggunakan referensi bid/ask vs proksi midpoint (jika diizinkan) dan lihat apakah kesimpulannya tetap cocok secara kualitatif.
- Sensitivitas jendela eksekusi: uji jendela eksekusi yang lebih pendek dan lebih panjang untuk melihat seberapa cepat “likuiditas yang dapat ditradasikan” memburuk.
- Sensitivitas definisi rezim: ubah aturan ambang rezim sedikit (mis., cutoff volatilitas yang berbeda) dan amati apakah hasil tetap stabil.
- Sensitivitas model biaya: jika biaya tidak pasti, jalankan skenario di mana fee atau komponen biaya bervariasi dalam rentang yang wajar dan periksa apakah peringkat kondisi berubah.
Checks ini membantu Anda memisahkan “perilaku likuiditas yang sebenarnya” dari artefak pengukuran dan asumsi.
Keterbatasan dan risiko: di mana uji likuiditas bisa gagal
Setidaknya satu keterbatasan material harus diakui dalam setiap uji likuiditas scalping:
- Mekanisme eksekusi yang tidak bisa Anda observasi: jika data Anda tidak memiliki kedalaman order book atau informasi antrian, Anda mungkin keliru menganggap likuiditas yang tampak sebagai likuiditas yang benar-benar dapat ditradasikan.
- Perbedaan penyedia dan routing: dua implementasi yang menggunakan data pasar publik yang sama bisa menghasilkan outcome realisasi yang berbeda karena kecepatan eksekusi dan penanganan order.
- Non-stasioneritas: hubungan yang terlihat stabil secara historis bisa gagal ketika rezim volatilitas bergeser.
- Tail risk: rata-rata bisa terlihat dapat diterima sementara kejadian langka (spike cepat, penarikan kedalaman sementara) menciptakan slippage yang besar.
Perhatikan juga keterbatasan umum: hubungan historis tidak menetapkan hasil masa depan. Bahkan analisis kualitas eksekusi bergaya backtest yang kuat pun mungkin tidak mereplikasi di bawah kondisi operasional yang berbeda.
Terakhir, yurisdiksi dan lingkungan regulasi dapat memengaruhi kewajiban pelaporan dan praktik eksekusi. Jika Anda membutuhkan tingkat kepastian itu, andalkan sumber primer yang terkini, bukan asumsi statis.
Verifikasi dan pertanyaan berikutnya
Untuk memverifikasi uji likuiditas scalping Anda secara independen, pastikan pekerjaan Anda mencakup: