Get best of the week

Bagaimana tidak kehilangan semua uang dalam beberapa menit atau manajemen risiko dalam perdagangan algoritmik



Isi artikel


pengantar


Sekarang situasinya tidak sederhana baik di dunia maupun dalam perdagangan saham. Banyak pedagang tiba-tiba menjadi jutawan, sementara yang lain langsung kehilangan semua uang mereka. Volatilitas pasar yang tinggi memberikan peluang yang baik bagi pedagang algoritmik untuk menghasilkan. Dan untuk tidur nyenyak dan tidak bermimpi, angsa hitam perlu melindungi akun mereka dari robot yang ganas dan masalah lain dalam perdagangan algoritmik.

" Algotrader tertidur - perdagangan sedang berjalan! " - beberapa pedagang suka mengatakan. Tetapi kenyataannya tidak begitu sederhana. Di mana menurut Anda perdagangan algoritmik dimulai? Dari menghubungkan ke pertukaran atau menulis suatu algoritma? Untuk peserta profesional, perdagangan dimulai dengan pengembangan manajemen risiko .

Diyakini bahwa perdagangan algoritmik jauh lebih efektif daripada perdagangan klasik. Karena robot tidak memiliki solusi emosional, mereka siap bekerja 24/7, mereka tahu persis kapan harus membeli dan kapan harus menjual, mereka melakukan transaksi dengan kecepatan yang tidak dapat diakses oleh orang biasa. Namun, berdasarkan kekuatan super mereka, mereka menciptakan kelas risiko yang meningkat.
Misalnya, kasus terkenal yang turun dalam sejarah sebagai  "Pembalasan mobil" menyebabkan kerugian $ 460 juta, atau robot yang rusak menyebabkan kerugian $ 4,3 juta atau kegagalan di Bursa Moskowmenyebabkan pemberhentian dan kerugian bagi pedagang, dll Satu kejadian seperti itu sudah cukup dan akun perdagangan mungkin rusak tidak dapat diperbaiki. Ini terutama berlaku jika perdagangan bersifat marjinal, ketika harga kesalahan meningkat beberapa kali.

Seorang pedagang tidak bisa tahu berapa banyak yang akan ia hasilkan, tetapi ia harus tahu persis berapa banyak yang bisa ia hilangkan. Faktanya, perdagangan apa pun dilakukan untuk mengendalikan risiko, dan keuntungan adalah hadiah untuk mengamati mereka.

Dalam artikel ini, saya akan mencoba untuk mengungkapkan, jika mungkin, risiko potensial yang terkait dengan eksekusi algoritma perdagangan dalam perdagangan riil dan langkah-langkah untuk melindungi terhadap gangguan dalam sistem perdagangan. Pada saat yang sama, saya tidak akan menyentuh manajemen uang , diversifikasi portofolio perdagangan dan logika strategi perdagangan, ini adalah cerita yang berbeda.

1. Solusi arsitektur


Sebelum melanjutkan ke klasifikasi risiko, saya akan berbicara sedikit tentang solusi standar di bagian perdagangan perdagangan algoritmik.

Dari persyaratan hingga kecepatan eksekusi aplikasi, robot perdagangan dibuat dengan berbagai cara. Jika HFT ini (misalnya, arbitrage atau pembuatan pasar ) sensitif terhadap penundaan, maka mereka mencoba untuk meminimalkan jalur aplikasi dari algoritma ke pertukaran dan akun dalam penundaan dihabiskan dalam mikrodetik. Sebagai aturan, algoritma tersebut memiliki arsitektur spesifik dan dioptimalkan untuk strategi tertentu. Dalam hal ini, manajemen risiko terintegrasi langsung ke dalam strategi.

Pada dasarnya, strategi perdagangan berada dalam posisi dari beberapa menit hingga beberapa jam, dan semakin sedikit waktu algoritma dalam posisi, semakin mudah untuk mengendalikan risiko. Namun, dengan peningkatan frekuensi transaksi, biaya komisi meningkat, yang mengurangi profitabilitas algoritma. Jadi strategi perdagangan mencoba menemukan keseimbangan antara risiko dan keuntungan.

Algoritma perdagangan jarang diperdagangkan satu per satu. Biasanya, ini adalah seluruh keluarga strategi yang dikumpulkan dalam portofolio untuk mendiversifikasi dan menstabilkan kurva Ekuitas . Pada saat yang sama, pertukaran data untuk algoritma perdagangan dapat berasal dari berbagai sumber, dan aplikasi dapat dikirim ke berbagai pertukaran. Inti dari sistem perdagangan adalah mesinyang merutekan dan mengoptimalkan data antara algoritma dan pertukaran (lihat Gambar 1). Biasanya ada mesin lain, misalnya, untuk bekerja dengan data historis atau backtesting, tetapi demi penyederhanaan saya tidak menunjukkannya.


Fig. 1. Skema arsitektur untuk server perdagangan.

2. Klasifikasi risiko secara umum


  • 2.1. Risiko infrastruktur
  • 2.2. Masalah koneksi ke bursa / broker
  • 2.3. Masalah dalam logika strategi perdagangan

2.1. Risiko infrastruktur


Bagian utama dari masalah di kelas ini terkait dengan server perdagangan. Untuk perdagangan algoritmik, bahkan PC yang sangat kuat tidak cocok karena berbagai alasan: peralatan yang tidak dapat diandalkan, koneksi internet yang tidak stabil, catu daya yang buruk, dll.

Risiko utama:

  • hilangnya kinerja server sepenuhnya / sebagian;
  • restart darurat sistem operasi;
  • kegagalan server fisik.

Kualitas menyelesaikan masalah ini, sebagai suatu peraturan, tergantung pada anggaran Anda dan persyaratan algoritma perdagangan Anda.

2.1.1. Opsi solusi


  • Tukar colocation. Pilihan ideal dan termahal. Biasanya digunakan dalam algoritma HFT yang sangat menguntungkan atau di perusahaan besar, misalnya, bank, di mana infrastruktur ini digunakan kembali untuk solusi perdagangan lainnya.
  • Penyewaan server virtual / khusus. Jika Anda bukan hedge fund besar atau pedagang swasta, maka Anda mungkin menggunakan opsi ini. Solusi sederhana, mudah disesuaikan dan terukur. Anda selalu dapat menemukan penyedia yang cocok dengan parameter harga / kualitas.
  • . . , / , .

2.1.2.


  • / . TIER III uptime 99,98% . .
  • . , . .
  • Cadangan daya setidaknya 40-50% (CPU, RAM, SSD) dibandingkan dengan mode perdagangan biasa. Sebagai aturan, pada pergerakan kuat di pasar, beban dalam aliran data meningkat dan algoritma mulai aktif melakukan transaksi. Pada saat genting ini, seharusnya tidak ada rem pada server Anda.

2.2. Masalah konektivitas


Di bursa dan broker, kegagalan teknis terjadi dari waktu ke waktu. Misalnya, operasi platform perdagangan Sberbank mengalami crash atau "underworked" di Bursa Moskow , pertukaran ditutup untuk makan siang , Bursa Moskow menghentikan perdagangan karena kegagalan , dll.

Risiko utama:

  • putus koneksi;
  • keterlambatan tinggi;
  • data yang salah;
  • kehilangan data sebagian.


2.2.1. Koneksi terputus


Informasi pemutusan koneksi dapat diperoleh dengan beberapa cara:

  • Connector Events API - Terhubung , terputus .
  • Menggunakan algoritma verifikasi koneksi seperti Detak Jantung , yang biasanya ada di API.
  • Secara tidak langsung. Dengan kurangnya data dalam aliran data.

Anda dapat mengkonfigurasi koneksi sehingga jika koneksi hilang / terputus, pertukaran akan menarik pesanan aktif atau menutup posisi. Namun, Anda harus berhati-hati dengan fungsi ini, karena jika terjadi istirahat pendek, penutupan posisi yang tidak direncanakan akan lebih cenderung mengarah pada kerugian dan lebih banyak bahaya daripada bantuan.

Selain itu, sering terjadi bahwa ketika sesuatu rusak, itu rusak sepenuhnya dan opsi pertama untuk peringatan tentang istirahat tidak berfungsi dan hanya secara tidak langsung berhasil mengetahui bahwa ada sesuatu yang salah.

2.2.2. Masalah data


Untuk memulai, pertimbangkan jenis utama data stok. Tergantung pada jenis konektor dan pertukaran, data ini tidak banyak berbeda, tetapi pada dasarnya plus atau minus adalah sama.

Perubahan yang masuk:

  • Tukar gelas / buku pesanan
  • Penawaran
  • Aplikasi
  • Item baris
  • Keseimbangan

Data keluar:

  • Aplikasi Pendaftaran

Data masuk dan keluar dapat berasal dari satu atau dari koneksi yang berbeda. Kebetulan salah satu utas dapat jatuh "diam-diam", sedangkan sisanya akan bekerja dalam mode normal. Bahkan jika data berasal dari sumber yang sama, Anda masih perlu memantau setiap aliran secara individual.

Masalah data biasanya diselesaikan dengan menerapkan algoritma pelacakan seperti WatchDog . Semua utas harus melewati modul ini. Lagu

WatchDogs :

  • frekuensi pembaruan data dalam aliran;
  • timestamp keterlambatan data dan waktu saat ini;
  • pada ketersediaan data menentukan keberadaan komunikasi dengan pertukaran.

Jika untuk waktu tertentu tidak ada data yang datang dari konektor atau keterlambatan melebihi batas maksimum yang diijinkan, maka peristiwa yang sesuai dihasilkan dan keputusan dibuat pada tindakan lebih lanjut.

Untuk perhitungan penundaan yang benar, sistem independen untuk sinkronisasi waktu sistem yang akurat harus diterapkan. Misalnya, dengan server NTP .

2.2.3. Opsi solusi


Jika masalah di atas terjadi, sistem harus segera memutuskan aliran data dari algoritma dan mencoba untuk terhubung kembali dengan frekuensi dan jumlah upaya yang diberikan. Harus diingat bahwa ada penyebab istirahat yang benar-benar dibenarkan, yang sebelumnya tidak terduga. Misalnya, karena sesi perdagangan yang diperpendek pada hari libur nasional atau pembaruan yang tidak terduga ke API dan skenario tidak masuk akal lainnya. Dalam setiap koneksi tertentu, koneksi ulang harus didekati secara individual. Jika tidak, jumlah upaya koneksi ulang yang berlebihan dapat dianggap oleh pertukaran sebagai serangan spam dan menyebabkan pemblokiran akun.

Setelah menyambung kembali dan mengunduh data yang hilang, perlu untuk memberi tahu algoritma perdagangan tentang pemulihan pekerjaan dan mentransfer data yang hilang kepada mereka. Algoritma harus menganalisis perubahan yang telah terjadi dan memutuskan apa yang harus dilakukan selanjutnya. Tetap di posisi saat ini, ubah atau tutup sepenuhnya. Logika ini harus diterapkan dalam setiap strategi perdagangan.

Urutan pemulihan pekerjaan:

  • hubungkan kembali;
  • unggah data yang hilang;
  • beri tahu algoritma pemulihan komunikasi;
  • mentransfer data yang hilang ke algoritma;
  • beralih aliran secara real time;
  • Logika perdagangan algoritma harus menormalkan posisi mereka dan menempatkan kembali pesanan.

Demikian pula, dalam kasus data bermasalah atau hilangnya sebagian fungsi, Anda harus terlebih dahulu memulihkan koneksi dan menormalkan aliran data. Tidak mungkin untuk berdagang dengan kapasitas kerja parsial, jelas bahwa ini tidak akan berakhir dengan sesuatu yang baik.

2.3. Masalah dalam logika strategi perdagangan


Masalah yang paling berbahaya, berbahaya dan tidak dapat diprediksi mengintai dalam logika strategi perdagangan yang terprogram. Tidak peduli seberapa bijaksana algoritma perdagangan, tidak mungkin untuk meramalkan semua skenario. Berbagai faktor dan kombinasinya dapat menimbulkan perilaku yang tidak terduga. Selain itu, beberapa kesalahan mungkin mengintai selama bertahun-tahun dan "muncul" pada saat yang paling tidak terduga.

2.3.1. Klasifikasi masalah


  1. Kesalahan dalam aplikasi:
    • Harga / volume negatif;
    • Arah terbalik;
    • Jenis yang salah, dll.
  2. Kesalahan API:
    • Tidak semua bidang diisi dalam transaksi;
    • Menggunakan versi API yang kedaluwarsa;
    • ..
  3. :
    • ;
    • ;
    • ;
    • « »;
    • .
  4. :
    • ;
    • ;
    • .
  5. :
    • ;
    • .
  6. :
    • ;
    • ;
    • ;
    • .
  7. :
    • ;
    • ;
    • Sejumlah besar aplikasi yang tidak mengarah pada transaksi.
  8. Kurangnya penanganan pengecualian dalam kode program strategi perdagangan

Namun, beberapa kesalahan dapat menimbulkan kesalahan lainnya. Misalnya, menghentikan algoritme karena kesalahan kotor akan menyebabkan pelanggaran posisi dan, sebagai akibatnya, pelanggaran batas.

2.3.2. Opsi solusi


Solusi untuk masalah ini bermuara pada pengontrolan aplikasi dan batasan strategi perdagangan (lihat bagian 3). Selain itu, pengecualian apa pun dalam kode program harus mengarah pada penghentian segera algoritma bermasalah dan penarikan semua aplikasi aktifnya.

3. Memantau aplikasi dan batasan strategi perdagangan


Mungkin ini adalah cara paling penting untuk mengelola risiko sistem perdagangan. Kesalahan apa pun pada akhirnya akan menyebabkan penyimpangan dalam posisi, aplikasi dan uang tunai. Tugasnya adalah memperhatikan perubahan ini secepat mungkin dan segera mengambil tindakan.

Cek dapat dibagi menjadi dua jenis:
3.1. Verifikasi dasar aplikasi
3.2. Batasi analisis dan kontrol

3.1. Verifikasi aplikasi dasar


Semua permintaan keluar harus diperiksa untuk:

  • kesalahan besar;
  • kebenaran dan kecukupan data untuk API;
  • kepatuhan dengan spesifikasi instrumen yang diperdagangkan;
  • kepatuhan dengan peraturan penawaran, dll.

Pemeriksaan ini dilakukan sebelum mengirim aplikasi ke bursa. Semakin cepat kesalahan ditemukan, semakin mudah untuk menghilangkan konsekuensinya. Jangan menunggu kesalahan yang jelas datang dari konektor. Lebih baik menyelesaikan masalah sebelum masalah itu muncul. Selain itu, mengirimkan transaksi yang salah dapat menimbulkan berbagai sanksi oleh bursa.

3.2. Kontrol batas


Untuk mengontrol batas, berikut ini diperiksa:
3.2.1. Ubah keseimbangan dan posisi sebelum mengajukan permintaan
3.2.2. Ubah saldo dan posisi saat ini
3.2.3. Harga dan volume aplikasi
3.2.4. Perilaku Aplikasi

3.2.1. Analisis perubahan keseimbangan dan posisi sebelum menempatkan aplikasi


Sebelum mengirimkan aplikasi untuk pendaftaran, potensi perubahan dalam keseimbangan dan posisi dalam hal pelaksanaan aplikasi diperiksa. Jika ada kelebihan dari batas untuk algoritma ini, maka pesanan tidak dikirim, dan pesan kesalahan dikirim ke strategi perdagangan.

3.2.2. Analisis perubahan keseimbangan dan posisi saat ini


Batas terbentuk pada perubahan volume yang diperdagangkan dan posisi pada instrumen untuk periode waktu: 15 detik, 30 detik, 1 menit, 5 menit, 15 menit, 1 jam, 1 hari. Pemantauan konstan perubahan selama periode waktu akan memungkinkan Anda untuk melihat penyimpangan dalam perilaku dan menghentikan perdagangan, sampai saat ketika penyimpangan menjadi kritis.

Itu terjadi bahwa masalah dengan algoritma tidak segera muncul. Dia dapat mulai "bergabung" secara perlahan dan tanpa melanggar batas waktu singkat. Anda dapat bangun di pagi hari dan menemukan kekurangan yang signifikan karena satu tidak banyak "rusak" algoritma. Apakah kita membutuhkannya? Kami tidak membutuhkannya.

3.2.3. Analisis harga dan volume


Sebelum mengirim aplikasi untuk pendaftaran, batas melebihi volume maksimum dan minimum dalam aplikasi diperiksa. Sayangnya, tidak ada yang membatalkan kesalahan aritmatika dalam rumus dan perhitungan.

Penting, jika mungkin, untuk memeriksa penyimpangan harga penawaran dari harga pasar rata-rata. Untuk melakukan ini, periksa harga dari sumber lain untuk instrumen perdagangan serupa. Pemeriksaan ini sangat relevan jika perdagangan dilakukan pada pertukaran tidak likuid atau volatilitas tinggi yang tidak normal diamati untuk instrumen yang diperdagangkan.

Jika perubahan melebihi batas yang ditentukan, maka aplikasi ditolak sebelum dikirim ke bursa.

3.2.4. Analisis Perilaku Aplikasi


Diperiksa di sini:

  • jumlah aplikasi yang tidak mengarah pada transaksi;
  • jumlah aplikasi aktif;
  • frekuensi aplikasi untuk periode 1 detik, 3 detik, 5 detik, 15 detik, 30 detik, 1 menit.

Pertukaran memiliki batas mereka sendiri pada jumlah pesanan aktif dan frekuensi pengiriman mereka, jika mereka melebihi akses ke perdagangan, mereka dapat ditangguhkan. Dan akan mungkin untuk menormalkan posisi hanya secara manual.

Salah satu situasi paling berbahaya dan berisiko adalah ketika robot perdagangan mulai membeli dan menjual tanpa kendali, menempatkan sejumlah besar pesanan per detik. Sebelum robot mengambil posisi besar atau menghasilkan komisi, perlindungan ini harus bekerja. Paling tidak, ia harus memberi waktu ekstra agar mekanisme perlindungan lain dapat bekerja.

Pemeriksaan ini dilakukan pada beberapa tingkatan:

1. Pada tingkat konektor.Perlindungan konektor aplikasi "melambat" ketika frekuensi paparan mendekati maksimum. Ini diperlukan agar tidak kehilangan akses ke bursa. Langkah-langkah ini ekstrem, jadi penting untuk menghitung dengan benar beban pada konektor terlebih dahulu.

2. Pada tingkat strategi perdagangan. Jika algoritma melebihi batas pada frekuensi aplikasi pengarsipan, maka secara paksa dihentikan dengan kesalahan. Dalam hal ini, semua aplikasi aktif yang dikirimkan sebelumnya dihapus.

4. Integrasi manajemen risiko ke dalam solusi arsitektur


Integrasi manajemen risiko dapat dibagi menjadi dua bagian utama (lihat Gambar. 2):

  • PRE-TRADE termasuk kontrol dasar pesanan, kontrol harga dan volume pesanan, kontrol perubahan keseimbangan dan posisi sebelum pesanan diajukan, perilaku pesanan juga dianalisis di sini.
  • POST-PERDAGANGAN termasuk pemeriksaan untuk istirahat koneksi dan kebenaran data pasar, pemantauan konstan perubahan keseimbangan dan posisi saat ini dilakukan, perilaku pesanan juga dianalisis di sini.



Ara. 2. Skema integrasi manajemen risiko dalam solusi arsitektur untuk server perdagangan.

5. Pencatatan dan pelaporan


Jangan lupa bahwa situasi non-standar juga terjadi dan hari ini mereka tidak dapat melakukannya tanpa campur tangan manusia bahkan dalam sistem yang sangat otomatis. Oleh karena itu, jika terjadi kesalahan, Anda harus segera memberi tahu semua pihak yang berkepentingan (pedagang, pengembang, manajer) dengan secara otomatis mengirim pesan melalui surat, sms, telegram, atau dengan cara lain yang nyaman. Idealnya, selalu ada pedagang yang memantau kinerja sistem perdagangan.

Jika terjadi kegagalan, Anda harus segera menemukan masalah, memperbaikinya, dan mengembalikan sistem perdagangan agar berfungsi. Untuk melakukan ini, penting untuk memelihara perdagangan terperinci dan log sistem, terutama dalam sistem yang sangat banyak dengan aliran aplikasi yang besar. Jika penyebab kegagalan tidak ditemukan, maka kegagalan selanjutnya bisa berakibat fatal. Pertukaran, sebagai suatu peraturan, tidak memaafkan kesalahan dan segera menghukum rubel.

Kesimpulan


Biasanya, mereka mulai "mempercepat" manajemen risiko ke algoritma perdagangan pada gilirannya terakhir, ketika beberapa insiden telah terjadi dan pemahaman telah datang bahwa seseorang tidak dapat melakukannya tanpanya.

Sama seperti langkah-langkah keamanan ditulis dalam darah, sehingga manajemen risiko dalam perdagangan algoritmik ditulis dalam margin call dan akun gabungan.

Namun, jika Anda benar membangun sistem perdagangan dan mengatur manajemen risiko, Anda dapat tidur nyenyak dan yakin bahwa " Algotrader tertidur - perdagangan aktif! " Perdagangan baik untuk

semua orang!

More articles:


All Articles