Haruskah Anda Membangun Backtester Anda Sendiri?

Tentang Pos Ini

Posting ini cocok untuk mereka yang baru memulai perdagangan kuantitatif serta mereka yang memiliki beberapa pengalaman dengan bidang ini. Posting ini membahas perangkap umum dari backtesting, serta beberapa yang tidak umum!

Ini juga melihat berbagai jenis mekanisme backtesting serta lanskap perangkat lunak yang menerapkan pendekatan ini. Kemudian kita membahas apakah layak membangun backtester Anda sendiri, bahkan dengan prevalensi alat open source yang tersedia saat ini.

Akhirnya, kami membahas seluk beluk sistem backtesting event-driven, topik yang sering saya bahas di QuantStart di posting sebelumnya.

Apa Itu Tes Belakang?

Sebuah backtest adalah penerapan aturan strategi perdagangan pada seperangkat data harga historis. Artinya, jika kita mendefinisikan seperangkat mekanisme untuk masuk dan keluar ke dalam portofolio aset, dan menerapkan aturan tersebut untuk data harga historis aset tersebut, kita dapat mencoba untuk memahami kinerja ini "strategi perdagangan" yang mungkin telah dicapai di masa lalu.

Pernah dikatakan bahwa Semua model adalah salah, tetapi beberapa berguna. Hal yang sama berlaku untuk backtest. Jadi apa tujuannya?

Backtest pada akhirnya membantu kita memutuskan apakah layak untuk berdagang secara langsung seperangkat aturan strategi. Ini memberi kita gambaran tentang bagaimana strategi mungkin telah berkinerja di masa lalu. Pada dasarnya memungkinkan kita untuk menyaring aturan strategi yang buruk sebelum kita mengalokasikan modal nyata.

Hal ini mudah untuk menghasilkan backtest. sayangnya hasil backtest tidak hasil perdagangan hidup. mereka sebaliknya adalah model realitas. model yang biasanya berisi banyak asumsi.

Ada dua jenis utama backtest perangkat lunak - for-loop dan event-driven sistem.

Ketika merancang perangkat lunak backtesting selalu ada trade-off antara akurasi dan kompleksitas implementasi.

Percobaan Belakang

Ada banyak perangkap yang terkait dengan backtesting. semuanya berkaitan dengan fakta bahwa backtesting hanyalah model realitas.

• In-Sample Testing - Ini terjadi ketika Anda menggunakan data yang sama untuk melatih model perdagangan Anda serta untuk menguji itu. Ini hampir selalu membesarkan kinerja strategi di luar yang akan terlihat dalam perdagangan langsung. Ini karena belum divalidasi pada data yang tidak terlihat, yang kemungkinan akan sangat berbeda dari data pelatihan. Pada dasarnya, ini adalah bentuk overfit.
• Survival Bias - Untuk indeks pasar saham seperti S&P500, proses periodik pencatatan dan de-listing terjadi, mengubah komposisi dari waktu ke waktu. Dengan gagal memperhitungkan komposisi yang berubah ini atas backtest, strategi perdagangan secara otomatis memilih pemenang karena mengabaikan semua perusahaan yang jatuh dari indeks karena kapitalisasi pasar yang rendah. Oleh karena itu selalu perlu menggunakan data bebas bias survival ketika melakukan backtest jangka panjang.
• Look-Ahead Bias - Data masa depan dapat menyelinap ke backtest dengan cara yang sangat halus. Pertimbangkan untuk menghitung rasio regresi linier selama jangka waktu tertentu. Jika rasio ini kemudian digunakan dalam sampel yang sama, maka kita secara implisit telah membawa data masa depan dan dengan demikian kemungkinan akan memiliki kinerja yang meningkat.
• Perubahan Rezim Pasar - Ini berkaitan dengan fakta bahwa pasar saham parameter tidak statis. Artinya, proses yang mendasari menghasilkan pergerakan saham tidak perlu memiliki parameter yang tetap konstan dalam waktu. Hal ini membuat sulit untuk menggeneralisasi model parameter (yang banyak strategi perdagangan adalah contohnya) dan dengan demikian kinerja cenderung lebih tinggi dalam backtest daripada dalam perdagangan langsung.
• Biaya transaksi - Banyak backtest For-Loop bahkan tidak memperhitungkan biaya transaksi dasar, seperti biaya atau komisi. Ini terutama berlaku dalam makalah akademik di mana backtest sebagian besar dilakukan tanpa biaya transaksi. Sayangnya terlalu mudah untuk menemukan strategi yang sangat menguntungkan tanpa biaya transaksi, tetapi membuat kerugian substansial ketika dikenakan pada pasar nyata. Biaya khas termasuk spread, dampak pasar dan slippage. Semua ini harus diperhitungkan dalam backtest yang realistis.

Ada beberapa masalah yang lebih halus dengan backtesting yang tidak sering dibahas, tetapi masih sangat penting untuk dipertimbangkan.

• Data OHLC - Data OHLC, yaitu jenis data harian yang diambil dari situs gratis seperti Yahoo Finance, seringkali merupakan penggabungan dari beberapa umpan pertukaran. Oleh karena itu tidak mungkin bahwa beberapa nilai yang lebih ekstrim yang terlihat (termasuk harga tinggi dan rendah hari itu) kemungkinan akan diperoleh oleh sistem perdagangan langsung.
• Pembatasan Kapasitas - Saat backtesting mudah untuk menggunakan pot uang tak terbatas. Namun, dalam kenyataannya, modal, serta margin, sangat terbatas. Perlu juga untuk memikirkan batas Volume Rata-rata Harian (ADV), terutama untuk saham dengan kapitalisasi kecil di mana mungkin perdagangan kita benar-benar dapat memindahkan pasar.
• Pilihan patokan - Apakah pilihan patokan terhadap strategi backtested yang diukur adalah yang baik? Misalnya jika Anda berdagang komoditas berjangka dan netral terhadap indeks ekuitas S&P500 AS, apakah benar-benar masuk akal untuk menggunakan S&P500 sebagai patokan Anda? Apakah keranjang dana perdagangan komoditas lainnya lebih masuk akal?
• Robusitas - Dengan memvariasikan waktu awal strategi Anda dalam backtest Anda apakah hasilnya berubah secara dramatis? seharusnya tidak masalah untuk strategi jangka panjang apakah backtest dimulai pada hari Senin atau Kamis. Namun, jika sensitif terhadap kondisi awal bagaimana Anda dapat secara andal memprediksi kinerja masa depan saat perdagangan langsung?
• Overfitting/Bias-Variance Tradeoff - Kami telah membahas ini sedikit di atas di In-Sample Testing point. Namun, overfitting adalah masalah yang lebih luas untuk semua metode pembelajaran mesin (dipantau). Satu-satunya cara nyata untuk memecahkan masalah ini adalah melalui penggunaan teknik cross-validation yang cermat. Bahkan kemudian, kita harus sangat berhati-hati bahwa kita tidak hanya menyesuaikan strategi perdagangan kita dengan kebisingan dalam set pelatihan.
• Toleransi Psikologis - Psikologi sering diabaikan dalam keuangan kuantitatif karena (kononnya) dihilangkan dengan menciptakan sistem algoritmik. Namun, itu selalu menyelinap masuk karena kuantitas memiliki kecenderungan untuk tinker atau override sistem setelah dikerahkan secara langsung. Selain itu, apa yang mungkin tampak dapat ditoleransi dalam backtest, mungkin terasa sakit perut dalam perdagangan langsung. Jika kurva ekuitas backtested Anda menunjukkan penurunan 50% pada suatu titik dalam sejarah perdagangan, bisakah Anda juga menjalankannya dalam skenario perdagangan langsung?

Banyak yang telah ditulis tentang masalah dengan backtesting.

Sistem Backtest For-Loop

For-Loop Backtester adalah jenis paling mudah dari sistem backtesting dan varian yang paling sering terlihat dalam posting blog kuantum, murni untuk kesederhanaan dan transparansi.

Pada dasarnya sistem For-Loop berulang setiap hari perdagangan (atau bar OHLC), melakukan beberapa perhitungan yang terkait dengan harga aset (s), seperti Moving Average dari penutupan, dan kemudian pergi panjang atau pendek aset tertentu (sering pada harga penutupan yang sama, tetapi kadang-kadang hari berikutnya).

Berikut adalah pseudo-kode untuk algoritma tersebut:

for each trading bar:
    do_something_with_prices();
    buy_sell_or_hold_something();
    next_bar();PythonCopy

Seperti yang Anda lihat, desain sistem semacam itu sangat sederhana. Hal ini membuatnya menarik untuk mendapatkan "tampilan pertama" pada kinerja aturan strategi tertentu.

Keuntungan

For-Loop backtesters mudah diimplementasikan dalam hampir semua bahasa pemrograman dan sangat cepat untuk dieksekusi.

Kelemahan

Kelemahan utama dengan backtesters For-Loop adalah bahwa mereka cukup tidak realistis. Mereka sering tidak memiliki kemampuan biaya transaksi kecuali ditambahkan secara khusus. Biasanya pesanan diisi segera di pasar dengan harga titik tengah.

Ada penggunaan ulang kode minimal antara sistem backtesting dan sistem perdagangan langsung. Ini berarti bahwa kode sering perlu ditulis dua kali, memperkenalkan kemungkinan lebih banyak bug.

For-Loop backtesters rentan terhadap Look-Ahead Bias, karena bug dengan pengindeksan.

For-Loop backtesters benar-benar harus digunakan semata-mata sebagai mekanisme penyaringan. Anda dapat menggunakannya untuk menghilangkan strategi yang jelas buruk, tetapi Anda harus tetap skeptis terhadap kinerja yang kuat. Penelitian lebih lanjut sering diperlukan. Strategi jarang tampil lebih baik dalam perdagangan langsung daripada di backtest!

Sistem Backtest yang Didorong Acara

Event-Driven Backtesters terletak di ujung lain dari spektrum. Mereka jauh lebih mirip dengan implementasi infrastruktur perdagangan langsung. Dengan demikian, mereka sering lebih realistis dalam perbedaan antara kinerja backtested dan perdagangan langsung.

Sistem semacam itu dijalankan dalam lingkaran while besar yang terus mencari event dari jenis yang berbeda dalam antrian event.

• Tick Events - Menunjukkan kedatangan data pasar baru
• Peristiwa sinyal - Generasi sinyal perdagangan baru
• Order Events - Order yang siap dikirim ke market broker
• Isi Event - Isi informasi dari broker pasar

Ketika peristiwa tertentu diidentifikasi, hal itu diarahkan ke modul yang sesuai di infrastruktur, yang menangani peristiwa dan kemudian berpotensi menghasilkan peristiwa baru yang kembali ke antrian.

Pseudo-kode untuk sistem backtesting Event-Driven adalah sebagai berikut:

while event_queue_isnt_empty():
    event = get_latest_event_from_queue();
    if event.type == "tick":
        strategy.calculate_trading_signals(event);
    else if event.type == "signal":
        portfolio.handle_signal(event);
    else if event.type == "order":
        portfolio.handle_order(event);
    else if event.type == "fill":
        portfolio.handle_fill(event)
    sleep(600);  # Sleep for, say, 10 minsPythonCopy

Seperti yang dapat Anda lihat ada ketergantungan berat pada modul pengelola portofolio. modul tersebut adalah hati dari sistem backtesting Event-Driven seperti yang akan kita lihat di bawah ini.

Keuntungan

Ada banyak keuntungan untuk menggunakan backtester Event-Driven:

• Penghapusan Bias Look-Ahead - Karena desainnya yang menyampaikan pesan, sistem yang didorong oleh acara biasanya bebas dari Bias Look-Ahead, setidaknya pada tingkat perdagangan.
• Code Re-Use - Untuk perdagangan langsung hanya perlu mengganti modul pengendali data dan pengendali eksekusi. Semua kode strategi, manajemen risiko / posisi dan pengukuran kinerja identik. Ini berarti biasanya ada jauh lebih sedikit bug yang harus diperbaiki.
• Tingkat portofolio - Dengan sistem Event-Driven jauh lebih mudah untuk berpikir di tingkat portofolio.
• Pengelolaan Risiko/Posisi yang Tepat - Dapat dengan mudah memodulasi manajemen risiko dan posisi. Dapat dengan mudah memperkenalkan leverage dan metodologi seperti Kriteria Kelly. Juga dapat dengan mudah menyertakan peringatan eksposur sektor, batas ADV, batas volatilitas dan peringatan illiquidity.
• Remote Deployment/Monitoring - Sifat modular dari kode memudahkan untuk menyebarkan di the cloud atau untuk menempatkan perangkat lunak di dekat pertukaran pada sistem virtual.

Kelemahan

Sementara keuntungannya jelas, ada juga beberapa kelemahan yang kuat untuk menggunakan sistem yang kompleks:

• Tricky to Code - Membangun sistem Event-Driven yang telah diuji sepenuhnya kemungkinan akan memakan waktu berminggu-minggu atau berbulan-bulan bekerja penuh waktu.
• Membutuhkan Object-Orientation - Desain modular memerlukan penggunaan prinsip-prinsip pemrograman berorientasi objek (OOP), dan dengan demikian bahasa yang dapat mendukung OOP dengan mudah.
• Teknik Perangkat Lunak - Lebih mungkin membutuhkan keahlian dan kemampuan teknik perangkat lunak yang baik seperti logging, pengujian unit, kontrol versi dan integrasi berkelanjutan.
• Slow Execution - Sifat kode yang melewati pesan membuatnya jauh lebih lambat untuk dieksekusi dibandingkan dengan pendekatan For-Loop vektor.

Perangkat Lunak

Dalam bagian ini kita akan mempertimbangkan perangkat lunak (baik open source dan komersial) yang ada untuk sistem For-Loop dan Event-Driven.

Untuk backtesters For-Loop, bahasa pemrograman / perangkat lunak utama yang digunakan termasuk Python (dengan perpustakaan Pandas), R (dan perpustakaan quantmod) dan MatLab. Ada banyak cuplikan kode yang dapat ditemukan di blog quant.

Pasar untuk sistem Event-Driven jauh lebih besar, karena klien/pengguna sering ingin perangkat lunak mampu melakukan backtesting dan perdagangan langsung dalam satu paket.

Penawaran komersial yang mahal termasuk Deltix dan QuantHouse. Mereka sering ditemukan di dana lindung nilai kuantitatif, kantor keluarga dan perusahaan perdagangan perlengkapan.

Sistem backtesting berbasis cloud dan live trading relatif baru. Quantopian adalah contoh dari setup berbasis web yang matang untuk backtesting dan live trading.

Perusahaan-perusahaan institusional juga sering membangun perangkat lunak mereka sendiri. hal ini disebabkan oleh campuran kendala peraturan, hubungan investor / pelaporan dan auditabilitas.

Quant ritel memiliki pilihan antara menggunakan pendekatan cloud+data dari Quantopian atau rolling their own menggunakan vendor cloud seperti Amazon Web Services, Rackspace Cloud atau Microsoft Azure, bersama dengan vendor data yang sesuai seperti DTN IQFeed atau QuantQuote.

Dalam hal perangkat lunak sumber terbuka, ada banyak perpustakaan yang tersedia. Mereka sebagian besar ditulis dalam Python (untuk alasan yang akan saya jelaskan di bawah ini) dan termasuk Zipline (Quantopian), PyAlgoTrade, PySystemTrade (Rob Carver / Investment Idiocy) dan QSTrader (Backtester QuantStart sendiri).

Salah satu aspek yang paling penting, bagaimanapun, adalah bahwa tidak peduli perangkat lunak mana yang Anda gunakan pada akhirnya, itu harus dipasangkan dengan sumber data keuangan yang sama kuat.

Bahasa Pemrograman

Sementara perangkat lunak mengurus detail untuk kita, ia menyembunyikan kita dari banyak detail implementasi yang seringkali penting ketika kita ingin memperluas kompleksitas strategi perdagangan kita.

Meskipun memiliki latar belakang sebagai pengembang perangkat lunak kuantitatif, saya tidak tertarik secara pribadi dengan perang bahasa.

Kita hanya harus tertarik pada apa yang berhasil. Berikut beberapa pesaing utama:

Python

Python adalah bahasa pemrograman yang sangat mudah dipelajari dan sering kali bahasa pertama yang dihadapi orang ketika mereka memutuskan untuk belajar pemrograman.

Ini memiliki beberapa pustaka kuantum / ilmu data / pembelajaran mesin (ML) yang luar biasa di NumPy, SciPy, Pandas, Scikit-Learn, Matplotlib, PyMC3 dan Statsmodels.

Ini sangat bagus untuk membangun sistem backtesting For-Loop dan Event-Driven. Bahkan, ini mungkin salah satu dari satu-satunya bahasa yang langsung memungkinkan penelitian end-to-end, backtesting, penyebaran, perdagangan langsung, pelaporan dan pemantauan.

Mungkin kelemahan terbesarnya adalah bahwa itu cukup lambat untuk dijalankan bila dibandingkan dengan bahasa lain seperti C ++. Namun, pekerjaan sedang dilakukan untuk memperbaiki masalah ini dan dari waktu ke waktu Python menjadi lebih cepat.

R

R adalah lingkungan pemrograman statistik, bukan bahasa pemrograman kelas satu (meskipun beberapa orang mungkin berpendapat sebaliknya!).

Hal ini banyak digunakan untuk backtesting For-Loop, sering melalui perpustakaan quantmod, tetapi tidak sangat cocok untuk sistem Event-Driven atau perdagangan langsung.

C++

C++ memiliki reputasi untuk sangat cepat. Hampir semua komputasi berkinerja tinggi ilmiah dilakukan baik di Fortran atau C++. Ini adalah keuntungannya utama. Oleh karena itu jika Anda mempertimbangkan perdagangan frekuensi tinggi, atau bekerja pada sistem warisan di organisasi besar, maka C++ kemungkinan akan menjadi suatu keharusan.

Sayangnya sangat menyakitkan untuk melakukan penelitian strategi. Karena diketik secara statis, sangat sulit untuk dengan mudah memuat, membaca dan memformat data dibandingkan dengan Python atau R.

Meskipun relatif tua, baru-baru ini telah dimodernisasi secara substansial dengan pengenalan C ++ 11 / C ++ 14 dan penyempurnaan standar lebih lanjut.

Orang lain?

Anda mungkin juga ingin melihat Java, Scala, C #, Julia dan banyak bahasa fungsional. Namun, rekomendasi saya adalah tetap dengan Python, R dan / atau C ++, karena komunitas perdagangan kuantum jauh lebih besar.

Haruskah Anda Menulis Backtester Anda Sendiri?

Jawaban: Ya!

Ini adalah pengalaman belajar yang hebat untuk menulis sistem backtesting Event-Driven Anda sendiri. pertama, itu memaksa Anda untuk mempertimbangkan semua aspek infrastruktur perdagangan Anda, bukan hanya menghabiskan berjam-jam bermain-main pada strategi tertentu.

Bahkan jika Anda tidak akhirnya menggunakan sistem untuk perdagangan langsung, itu akan memberikan Anda dengan sejumlah besar pertanyaan yang harus Anda tanyakan kepada Anda komersial atau FOSS backtesting vendor.

Misalnya: Bagaimana sistem hidup Anda saat ini berbeda dari simulasi backtest Anda dalam hal:

• Eksekusi algoritma dan routing perintah?
• Spread, biaya, slippage dan dampak pasar?
• Manajemen risiko dan ukuran posisi?

Sementara sistem Event-Driven tidak cepat atau mudah ditulis, pengalaman akan membayar dividen pendidikan besar di kemudian hari dalam karir perdagangan kuantum Anda.

Desain Backtest yang Didorong Acara 101

Bagaimana Anda menulis sistem seperti itu?

Cara terbaik untuk memulai adalah dengan mengunduh Zipline, QSTrader, PyAlgoTrade, PySystemTrade dll dan mencoba membaca melalui dokumentasi dan kode.

Saya juga telah menulis banyak artikel tentang desain backtest Event-Driven, yang dapat Anda temukan di sini, yang memandu Anda melalui pengembangan setiap modul sistem.

Ingatlah bahwa Anda tidak perlu menjadi ahli pada hari # 1. Anda dapat mengambilnya perlahan-lahan, hari demi hari, modul demi modul. Jika Anda membutuhkan bantuan, Anda selalu dapat menghubungi saya atau blogger kuant lainnya yang bersedia. Lihat akhir artikel untuk email kontak saya.

Saya sekarang akan membahas modul yang sering ditemukan dalam banyak sistem backtesting Event-Driven. Meskipun bukan daftar yang lengkap, ini harus memberi Anda rasa bagaimana sistem tersebut dirancang.

Database Master Sekuritas

Ini adalah tempat semua data harga historis disimpan, bersama dengan riwayat perdagangan Anda, sekali hidup.

Sebagai gantinya, kami menggunakan kelas pertama database atau sistem file, seperti PostgreSQL, MySQL, SQL Server atau HDF5.

Idealnya, kita ingin mendapatkan dan menyimpan data tingkat tik karena itu memberi kita gambaran tentang spread perdagangan.

Kita harus selalu sadar menangani tindakan perusahaan (seperti pembagian saham dan dividen), bias kelangsungan hidup (penghapusan daftar saham) serta melacak perbedaan zona waktu antara berbagai bursa.

Individu/retail quants dapat bersaing di sini karena banyak teknologi basis data berkualitas produksi yang matang, bebas dan open source.

Masih ada banyak pasar dan strategi yang terlalu kecil untuk dana besar yang tertarik.

Strategi Perdagangan

Modul strategi perdagangan dalam sistem Event-Driven umumnya menjalankan beberapa jenis mekanisme prediktif atau penyaringan pada data pasar baru.

Modul ini TIDAK dirancang untuk menghasilkan kuantitas, yang dilakukan melalui modul ukuran posisi.

95% dari diskusi quant blog biasanya berkisar pada strategi trading. Saya pribadi percaya seharusnya lebih seperti 20%. Ini karena saya pikir jauh lebih mudah untuk meningkatkan pengembalian yang diharapkan dengan mengurangi biaya melalui manajemen risiko yang tepat dan ukuran posisi, daripada mengejar strategi dengan lebih banyak alpha.

Manajemen Portofolio & Pemesanan

"Jantung" dari backtester Event-Driven adalah sistem Portfolio & Order Management.

Tujuan dari sistem ini adalah untuk pergi dari portofolio saat ini ke portofolio yang diinginkan, sambil meminimalkan risiko dan mengurangi biaya transaksi.

Modul ini menghubungkan kemampuan strategi, risiko, ukuran posisi dan eksekusi order dari sistem.

Keuntungan utama menggunakan sistem yang kompleks adalah bahwa hal itu memungkinkan berbagai instrumen keuangan untuk ditangani di bawah satu portofolio. Ini diperlukan untuk portofolio gaya institusional dengan lindung nilai. Kompleksitas seperti itu sangat rumit untuk kode dalam sistem backtesting For-Loop.

Manajemen Risiko & Posisi

Memisahkan manajemen risiko ke dalam modulnya sendiri dapat sangat menguntungkan. modul dapat memodifikasi, menambahkan atau memveto perintah yang dikirim dari portofolio.

Secara khusus, modul risiko dapat menambahkan lindung nilai untuk menjaga netralitas pasar. Ini dapat mengurangi ukuran pesanan karena eksposur sektor atau batas ADV. Ini dapat sepenuhnya memveto perdagangan jika spread terlalu luas, atau biaya terlalu besar relatif terhadap ukuran perdagangan.

Modul ukuran posisi yang terpisah dapat mengimplementasikan perkiraan volatilitas dan aturan ukuran posisi seperti leverage Kelly.

Topik-topik seperti itu tidak terwakili dengan baik di blogosfer kuantum. Namun, ini mungkin perbedaan terbesar antara bagaimana institusi dan beberapa pedagang ritel berpikir tentang perdagangan mereka. Mungkin cara termudah untuk mendapatkan pengembalian yang lebih baik adalah dengan mulai menerapkan manajemen risiko dan ukuran posisi dengan cara ini.

Penanganan Eksekusi

Dalam kehidupan nyata kita tidak pernah dijamin untuk mendapatkan isian pasar di titik tengah!

Kita harus mempertimbangkan masalah transaksi seperti kapasitas, spread, biaya, slippage, dampak pasar dan masalah eksekusi algoritmik lainnya, jika tidak, pengembalian backtesting kita kemungkinan akan sangat berlebihan.

Pendekatan modular dari sistem Event-Driven memungkinkan kita untuk dengan mudah beralih keluar BacktestExecutionHandler dengan LiveExecutionHandler dan menyebarkan ke server jarak jauh.

Kita juga dapat dengan mudah menambahkan beberapa broker menggunakan konsep OOP inheritance. Ini tentu saja mengasumsikan bahwa broker tersebut memiliki antarmuka pemrograman aplikasi (API) yang sederhana dan tidak memaksa kita untuk menggunakan antarmuka pengguna grafis (GUI) untuk berinteraksi dengan sistem mereka.

Salah satu masalah yang perlu diketahui adalah trust dengan perpustakaan pihak ketiga. Ada banyak modul seperti itu yang memudahkan untuk berbicara dengan broker, tetapi perlu untuk melakukan pengujian Anda sendiri. Pastikan Anda benar-benar puas dengan perpustakaan ini sebelum melakukan modal yang luas, jika tidak Anda bisa kehilangan banyak uang hanya karena bug dalam modul ini.

Kinerja & Pelaporan

Kanta ritel dapat dan harus meminjam teknik pelaporan canggih yang digunakan oleh kanta institusional. Alat-alat tersebut termasuk live dashboard dari portofolio dan risiko yang sesuai, backtest equity vs live equity perbedaan atau delta, bersama dengan semua metrik biasa seperti biaya per perdagangan, distribusi pengembalian, tanda air tinggi (HWM), penarikan maksimum, latensi perdagangan rata-rata serta alfa / beta terhadap patokan.

Perbaikan bertahap yang konsisten harus dilakukan pada infrastruktur ini. Ini benar-benar dapat meningkatkan pengembalian dalam jangka panjang, hanya dengan menghilangkan bug dan meningkatkan masalah seperti latensi perdagangan. Jangan hanya menjadi terobsesi pada peningkatan strategi terbesar dunia (WGS).

WGS pada akhirnya akan terkikis karena alpha decay. Yang lain pada akhirnya akan menemukan keunggulan dan akan melakukan arbitrase pengembalian. Namun, infrastruktur perdagangan yang kuat, pipa penelitian strategi yang solid dan pembelajaran berkelanjutan adalah cara yang bagus untuk menghindari nasib ini.

Optimalisasi infrastruktur mungkin lebih "membosankan" daripada pengembangan strategi tetapi menjadi jauh lebih tidak membosankan ketika pengembalian Anda meningkat!

Penyebaran & Pemantauan

Penyebaran ke server jarak jauh, bersama dengan pemantauan ekstensif dari sistem jarak jauh ini, sangat penting untuk sistem tingkat institusional.

Sebuah sistem yang kuat harus digunakan dari jarak jauh di the cloud atau berlokasi di dekat pertukaran. home broadband, catu daya dan faktor lain berarti bahwa menggunakan desktop / laptop rumah terlalu tidak dapat diandalkan. sering hal gagal tepat pada waktu terburuk dan menyebabkan kerugian yang besar.

Masalah utama ketika mempertimbangkan penyebaran jarak jauh termasuk; pemantauan perangkat keras, seperti CPU, RAM / swap, disk dan jaringan I / O, ketersediaan tinggi dan redundansi sistem, yang dipikirkan dengan baik melalui cadangan DAN rencana pemulihan, log ekstensif dari semua aspek sistem serta integrasi terus menerus, pengujian unit dan kontrol versi.

Ingat Hukum Murphy - Jika itu bisa gagal itu akan gagal.

Ada banyak vendor yang menawarkan penyebaran cloud yang relatif mudah, termasuk Amazon Web Services, Microsoft Azure, Google dan Rackspace.

Pikiran Akhir

Sayangnya tidak ada "perbaikan cepat" dalam perdagangan kuantitatif. Ini melibatkan banyak kerja keras dan belajar untuk menjadi sukses.

Mungkin batu tersandung utama bagi pemula (dan beberapa kuantitas menengah!) adalah bahwa mereka terlalu berkonsentrasi pada strategi terbaik. Strategi semacam itu selalu akhirnya menyerah pada peluruhan alfa dan dengan demikian menjadi tidak menguntungkan. Oleh karena itu perlu terus-menerus meneliti strategi baru untuk ditambahkan ke portofolio. Pada dasarnya, strategi pipa harus selalu penuh.

Hal ini juga layak menginvestasikan banyak waktu dalam infrastruktur perdagangan Anda. Luangkan waktu pada masalah seperti penyebaran dan pemantauan. Selalu mencoba dan mengurangi biaya transaksi, karena profitabilitas adalah tentang mengurangi biaya seperti itu tentang mendapatkan pendapatan perdagangan.

Saya merekomendasikan menulis sistem backtesting Anda sendiri hanya untuk belajar. Anda dapat menggunakannya dan terus meningkatkannya atau Anda dapat menemukan vendor dan kemudian bertanya kepada mereka semua pertanyaan yang telah Anda temukan ketika Anda membangun Anda sendiri.

Akhirnya, selalu membaca, belajar dan meningkatkan. Ada banyak buku teks, jurnal perdagangan, jurnal akademik, blog kuantitatif, forum dan majalah yang membahas semua aspek perdagangan. Untuk ide strategi yang lebih maju saya merekomendasikan SSRN dan arXiv - Keuangan Kuantitatif.

Lebih banyak