Otomatisasi trading: EA, skrip MQL, cBot dan VPS

Otomatisasi memindahkan tugas berulang ke program, tetapi tanggung jawab atas perilakunya tetap pada Anda. Expert Advisor atau cBot memerlukan lingkungan eksekusi yang jelas: terminal, VPS atau layanan cloud. Kami menjelaskan perbedaannya, diagnosis kesalahan dan perlindungan akun setelah koneksi putus atau mulai ulang. Artikel ini juga membahas biaya hosting, latensi eksekusi dan pemeriksaan sebelum program berjalan pada akun yang menggunakan margin.

1. Tempat robot benar-benar berjalan — EA, terminal, server broker

Kesalahpahaman berulang dalam otomatisasi ritel berbunyi: “robot saya trading di broker”. Tidak demikian. Expert Advisor MetaTrader adalah program terkompilasi yang berjalan di dalam proses terminal. Terminal menerima aliran kuotasi dari server broker, menjalankan kode robot pada peristiwa berturut-turut dan mengirim permintaan transaksi yang sudah disiapkan. Broker memvalidasi permintaan lalu mengeksekusi atau menolaknya. Segala yang “diketahui” dan “diingat” robot berada di sisi lingkungan eksekusi.

Rantai yang perlu diingat dalam setiap analisis kegagalan adalah:

kode EA → terminal (lingkungan eksekusi) → server broker → validasi order → eksekusi atau penolakan → respons server → log dan keadaan EA

Setiap mata rantai dapat gagal sendiri dengan cara berbeda. Kesalahan logika berhenti pada mata rantai pertama. Menutup terminal menghentikan logika lokal dan permintaan baru; broker tetap menangani order yang sudah disimpan di servernya. Order ditolak merupakan masalah mata rantai keempat, meski terlihat sebagai “EA tidak membuka posisi”. Infrastruktur nyata broker dan penyedia hosting jauh lebih rumit — rantai ini model kerja, bukan diagram jaringan.

Peristiwa yang direspons kode. Pada MT4 dan MT5, program trading digerakkan peristiwa. OnInit() berjalan saat mulai — di sinilah parameter masukan perlu divalidasi dan keadaan disiapkan. OnTick() dipicu pada kuotasi berikutnya dari instrumen tempat robot dipasang. OnDeinit() berjalan ketika program dilepas dari grafik, parameter berubah atau terminal ditutup. OnTimer() untuk tindakan berkala dan OnChartEvent() untuk interaksi grafik tersedia pada kedua bahasa — dokumentasi MQL4 mencantumkan keduanya dengan signature lengkap, bersama OnInit(), OnTick() dan OnDeinit() [10]. Perbedaan lingkungan terletak pada lapisan trading: MT5 menambahkan peristiwa yang sama sekali tidak dimiliki MQL4 — OnTrade() dan OnTradeTransaction() untuk merespons perubahan keadaan akun [14]. Secara terpisah, di luar lapisan trading, MT5 juga memiliki OnBookEvent() — peristiwa data pasar yang dokumentasinya menjelaskan penanganan perubahan kedalaman pasar, yaitu order book [14]. Ia hanya bekerja jika kedalaman pasar memang tersedia: ketersediaan order book bergantung pada instrumen dan broker, dan pada akun forex ritel sering memang tidak ada. Ini bukan kursus pemrograman — hanya minimum yang diperlukan untuk memahami kapan kode Anda punya kesempatan bertindak.

Konsekuensi praktisnya tidak menyenangkan: OnTick() bukan jam. Jumlah pemanggilan bergantung pada kuotasi yang masuk dan pemrosesan antrean peristiwa. Di MQL5, peristiwa NewTick baru tidak ditambahkan ketika satu sudah mengantre atau sedang diproses[25]. Dua broker pada pasangan sama dapat memberikan jumlah tick yang jelas berbeda, karena menyaring aliran secara berbeda dan menggunakan sumber likuiditas berbeda. Logika yang mengasumsikan frekuensi pemanggilan “kurang lebih tetap” sebenarnya bergantung pada broker dan jenis akun — dan lebih sulit dipindahkan antarbroker daripada kesan yang diberikan kode identik.

Yang tersisa ketika terminal mati

Inilah perbedaan yang menyelamatkan akun, sekaligus tempat penyederhanaan keliru “di MT4 semuanya di sisi klien” terus muncul.

Level Stop Loss dan Take Profit pada posisi atau pending order disimpan di server broker dan bekerja terlepas dari terminal Anda berjalan atau tidak. Trailing stop bawaan antarmuka terminal MetaTrader justru bekerja sebaliknya: dihitung secara lokal pada kuotasi yang masuk, dan berhenti memindahkan stop begitu platform ditutup. Ini berlaku bagi MT4 maupun MT5, tetapi masing-masing dikonfirmasi sumber tersendiri: panduan MetaTrader 4 menjelaskan trailing stop bekerja di terminal klien, bukan server, dan berhenti ketika terminal dimatikan [8], sedangkan panduan MetaTrader 5 mengulang aturan yang sama: trailing stop dijalankan di platform, bukan di sisi server seperti Stop Loss [11]. Dua penjelasan diperlukan agar kalimat itu tidak keliru. Pertama, penutupan terminal menghentikan pergeseran level, tetapi tidak membatalkan perubahan terakhir yang berhasil dikirim — perubahan itu tetap di server dan terus melindungi posisi. Kedua, penjelasan ini tidak boleh diperluas ke semua platform. Mekanisme cTrader berbeda: panduan pembuat menyatakan “Semua perlindungan bekerja di seluruh aplikasi cTrader dan tetap aktif setelah sesi Anda berakhir” [22], dan halaman panel Trade Watch menyatakan tegas tentang fungsinya: “Trailing stop loss bekerja meskipun aplikasi cTrader ditutup atau terputus” [23]. Jadi, kondisi dipertahankan di luar aplikasi pengguna dan tidak memerlukannya berjalan. Nama fungsi sama, model operasi berbeda — itulah mengapa kebiasaan satu platform tidak boleh dibawa ke platform lain; batas antara order sisi server dan fungsi lokal dijelaskan lebih luas dalam artikel 11.4 [per 2026-08-22; konfirmasikan cakupan fungsi broker Anda dalam dokumentasinya sendiri].

Kasus ketiga berbahaya dan berulang dalam kode amatir: stop loss “virtual” yang hanya disimpan dalam variabel EA. Stop seperti itu tidak ada bagi broker. Jika proses terminal mati, posisi tidak memiliki perlindungan di luar mekanisme tingkat akun. Sebelum menyatakan punya stop loss, periksa di jendela posisi apakah level terlihat di sisi server — bukan sekadar pada grafik dan log robot. Level yang diizinkan serta jarak minimum SL dan TP berasal dari spesifikasi instrumen broker, sehingga kode sama bisa diterima pada satu akun dan ditolak pada akun lain.

Otomatisasi penuh dan parsial

Robot tidak harus memutuskan entri agar berguna. Otomatisasi parsial — memindahkan stop ke impas, mengelola ukuran posisi, menutup sebagian volume pada level tertentu — mencakup bagian proses yang tidak konsisten jika dilakukan manual. Kode lebih pendek, ruang kesalahan lebih kecil dan diagnosis lebih sederhana. Otomatisasi penuh dari sinyal hingga eksekusi merupakan proyek dengan tingkat tanggung jawab yang sama sekali berbeda.

Namun prasyaratnya sama untuk kedua varian: aturan harus dapat dinyatakan tanpa ambiguitas. Jika entri, keluar dan risiko memerlukan penilaian “kualitas” setup, Anda tidak memiliki sistem untuk diotomatisasi — Anda memiliki pendapat tentang pasar. Sistem otomatis akan menjalankan spesifikasi cacat sama konsistennya dengan spesifikasi baik, hanya lebih cepat dan tanpa jeda. Apakah aturan memiliki nilai harapan positif merupakan bahasan materi tentang keunggulan dan nilai harapan; di sini kita hanya membahas cara menjalankan spesifikasi tersebut dengan aman.

2. Indikator, skrip, EA dan cBot — empat kelas alat berbeda

Pertanyaan “saya mencari skrip yang akan trading untuk saya” sering muncul dan biasanya maksudnya berbeda dari bunyinya. Skrip MetaTrader memang memiliki akses fungsi trading dan dapat mengirim banyak operasi dalam satu kali jalan, sehingga “skrip yang trading” sendiri bukan kontradiksi. Kontradiksinya ada di tempat lain: skrip memiliki satu titik masuk, OnStart(), dan berakhir bersama fungsi itu, sehingga tidak memiliki sarana mengawasi pasar selama seminggu. Tiga jenis program MetaTrader berbeda dalam siklus hidup dan cakupan akses; pada cTrader pembagiannya berbeda.

Pemisahan akses adalah keunggulan, tetapi jaminannya lebih sempit daripada yang biasa dinyatakan. Indikator tidak memiliki akses fungsi trading sehingga tidak mengirim order sendiri — hanya itulah kesimpulannya. Bukan berarti kesalahan indikator tidak berbahaya: jika EA membaca buffer dan mengambil keputusan darinya, nilai salah menjadi transaksi salah yang dikirim EA. Arsitektur yang bersih tetap sama: indikator menghitung lalu menyediakan hasil dalam buffer, EA membacanya lalu memutuskan transaksi. Analisis terpisah dari eksekusi dan setiap lapisan dapat diuji sendiri — asalkan isi buffer juga diuji, bukan hanya logika EA.

Pembagian cTrader berbeda dan tidak dapat dipetakan satu banding satu. Padanan EA adalah cBot, padanan indikator adalah indikator. Tidak ada kategori “skrip” tersendiri; operasi sekali jalan dilakukan cBot yang mengerjakan tugasnya pada metode start lalu menghentikan diri.

Tiga kesalahan yang menghabiskan waktu:

• Mengharapkan indikator melakukan trading. Indikator MetaTrader tidak memiliki akses fungsi trading. Produk yang diiklankan sebagai “indikator yang trading sendiri” bukan indikator, atau memiliki program terpisah di latar belakang — dan kode program itulah yang bertanggung jawab atas order Anda
• Menggunakan EA ketika skrip sudah cukup. Menutup semua posisi dalam satu kali jalan adalah tugas skrip. EA yang dipasang pada grafik akan tetap hidup, merespons kuotasi berikutnya dan memerlukan pengawasan
• Satu monolit alih-alih modul. Program yang sekaligus menjalankan lima strategi, mengawasi risiko akun, menggambar dan mengirim notifikasi lebih sulit didiagnosis. Sistem otomatis tersendiri untuk tiap strategi dan pengawas risiko terpisah memungkinkan penghentian sebagian demi sebagian

Sebelum menulis robot, tulis skrip informasi. Bukan karena latihan pemula, melainkan karena program yang sengaja tidak memuat satu pun pemanggilan trading memungkinkan pemeriksaan pembacaan lingkungan: simbol, kuotasi, biaya, dana tersedia. Jika pembacaan itu salah, setiap keputusan robot dibangun di atasnya.

Berikut ini bukan program untuk dikompilasi. Ini kerangka struktur: urutan pemeriksaan dan nama fungsi MQL4 untuk implementasi sendiri. Jangan tempel dan jalankan sebagai berkas siap pakai. Ia belum divalidasi melalui kompilasi atau pengujian akun broker. Kompilasi memeriksa sintaks, tetapi tidak dengan sendirinya mengonfirmasi pembacaan, izin atau perilaku pada lingkungan yang dipilih. Pertahankan urutannya, tulis implementasi lengkap lalu periksa hasil pada akun demo; catatan pengujian itulah yang memungkinkan penilaian perilaku program.

KERANGKA STRUKTUR - diagnosis lingkungan sebelum menulis robot
Notasi panduan untuk MQL4. Ini bukan kode lengkap yang dapat dikompilasi.

titik masuk: OnStart() - sekali jalan, berakhir bersama fungsi

1. symbol   := Symbol()
   Jangan tulis nama tetap - akhiran broker mengubahnya.

2. bid, ask := MarketInfo(symbol, MODE_BID / MODE_ASK)
   point    := MarketInfo(symbol, MODE_POINT)
   spread   := if point > 0 then (ask - bid) / point
               selain itu: pembacaan belum dapat dipastikan
   point nol berarti pembacaan spesifikasi gagal, bukan spread
   nol - kedua kasus harus menghasilkan catatan log berbeda.

3. lotMin   := MarketInfo(symbol, MODE_MINLOT)
   lotStep  := MarketInfo(symbol, MODE_LOTSTEP)
   Properti instrumen pada broker tertentu, bukan konstanta bahasa.

4. ke jurnal: symbol, bid, spread, lotMin, lotStep,
   OrdersTotal(), AccountFreeMargin()

5. tradePossible := IsTradeAllowed()
   Label log: trading dimungkinkan saat ini.
   Bukan: trading otomatis diizinkan - lihat paragraf berikut.

yang tidak ada dan tidak boleh ada dalam kerangka ini:
   tidak ada pemanggilan OrderSend, OrderClose atau OrderModify.

Tiga hal dari kerangka ini kembali pada setiap robot berikutnya: nama simbol dibaca dari lingkungan, bukan ditulis tetap; langkah volume dibaca dari spesifikasi instrumen; dan pemeriksaan eksplisit apakah trading dimungkinkan saat ini. Poin terakhir memerlukan koreksi atas penyederhanaan populer. IsTradeAllowed() tidak hanya menjawab pertanyaan izin otomatisasi — dokumentasi MQL4 menjelaskan pemeriksaan apakah “Expert Advisor diizinkan trading dan konteks trading tidak sibuk” [15]. Jadi hasil false dapat berarti ketiadaan izin atau konteks trading yang sibuk, yaitu keadaan sementara yang akan berlalu sendiri. Catat hasil fungsi dan penyebab yang ditentukan pemeriksaan tambahan secara terpisah; jika tidak, diagnosis “trading dinonaktifkan” akan diterapkan pada sesuatu yang sama sekali tidak dinonaktifkan. Bagian kegagalan produksi kembali merujuk ketiga pembacaan tersebut.

3. MQL4 dan MQL5 — dua lingkungan, bukan dua versi dari satu lingkungan

Penyederhanaan populer “MQL5 adalah MQL4 dengan lebih banyak fungsi” justru keliru di tempat yang penting dalam praktik: model order dan posisi. Mitos kedua juga perlu dihapus segera. MQL4 bukan bahasa prosedural murni — dokumentasi MetaQuotes menjelaskan kelas, pewarisan, fungsi virtual dan template [1]. Jadi perbedaannya bukan paradigma pemrograman, melainkan antarmuka trading, cara membaca indikator dan cara platform merepresentasikan eksposur terbuka.

Lapisan trading. Di MQL4, satu fungsi, OrderSend(), membuka posisi, sedangkan OrderSelect() mengalihkan konteks ke elemen berikutnya dalam daftar yang menempatkan pending order dan posisi terbuka berdampingan. Di MQL5 konsepnya terpisah: order, posisi dan transaksi historis berbeda. Pengiriman permintaan berarti mengisi struktur lalu memeriksa struktur balikan yang memuat kode respons server; kelas pustaka standar seperti CTrade adalah pembungkus praktis mekanisme itu, bukan mode operasi terpisah [2].

Lapisan data. Di MQL4 pemanggilan indikator mengembalikan nilai candle yang ditentukan. Di MQL5 pemanggilan yang sama mengembalikan handle yang dibuat sekali — biasanya dalam OnInit() — dan nilainya diambil ke array melalui fungsi penyalin buffer. Kode yang ditulis ulang secara harfiah membuat handle baru setiap kuotasi alih-alih memakai yang ada — compiler tidak melaporkannya, sebab kesalahan berada pada tempat pembuatan handle, bukan sintaks. Ini jebakan migrasi klasik justru karena tidak langsung terlihat.

Baris mode pencatatan perlu penjelasan tersendiri, karena kerap menimbulkan kegagalan mengejutkan. Netting berarti satu posisi bersih per instrumen: order berlawanan tidak membuka posisi kedua, tetapi mengurangi atau membalik yang ada. Robot pindahan MT4 yang mengasumsikan banyak posisi independen pada simbol sama akan mulai menutup entrinya sendiri dalam mode ini. Broker menetapkan mode akun, sehingga ini bukan “perilaku bawaan MT5” — melainkan sifat akun tertentu yang harus diperiksa sebelum penerapan, dan sebaiknya dibaca dalam kode.

Kapan migrasi masuk akal. Ketika lingkungan lama benar-benar membatasi pekerjaan: Anda memerlukan uji multivaluta, forward test dalam tester, model tick lebih akurat atau instrumen yang tidak ditawarkan broker di MT4. Sekadar platform “lebih baru” bukan alasan: lapisan trading dan cara membaca indikator ditulis ulang, sehingga kode yang tadinya bekerja mendapat kumpulan bug baru. Waktu yang diperlukan bergantung pada ukuran sistem otomatis — tidak ada angka yang dapat diberikan dengan jujur. Jika bermigrasi, bandingkan transaksi demi transaksi, bukan hasil agregat. Total sama dengan daftar transaksi berbeda berarti dua logika berbeda kebetulan memberi hasil mirip.

MT5 juga menawarkan optimasi terdistribusi berbayar dalam jaringan komputasi MetaQuotes. Namun tenaga lebih besar berarti lebih banyak kombinasi parameter diuji, yang langsung meningkatkan risiko pencocokan masa lalu. Metodologi pengujian — pembagian data, biaya, jumlah varian — dibahas dalam artikel tentang demo, backtesting dan forward testing dan dijelaskan di sana secara lengkap.

4. cTrader Algo — C#, Python, eksekusi lokal dan cloud

Di bagian ini paling mudah mengulang deskripsi produk usang, sebab materi lama menyebut lingkungan otomatisasi cTrader sebagai cAlgo atau cTrader Automate dan menggambarkannya hanya mendukung C# serta eksekusi lokal. Kedua klaim itu kini tidak benar.

Menurut dokumentasi resmi Spotware, lingkungan ini bernama cTrader Algo dan mendukung pembangunan algoritma dalam dua bahasa: C# dan Python [3]. cBot dapat dijalankan lokal atau di cloud; dokumentasi fungsi cloud menyatakan tegas cBot berjalan dalam lingkungan terisolasi yang disediakan cTrader, dan aplikasi pengguna — Windows, Mac, seluler maupun browser — tidak perlu tetap terbuka atau terhubung ke internet [4]. Ini mengubah seluruh perhitungan hosting yang dibahas kemudian dalam artikel.

Batas eksekusi cloud, per 2026-08-22. Dokumentasi menyatakan akun riil dapat menjalankan hingga sepuluh instans bersamaan yang bekerja terus-menerus, sedangkan akun demo satu instans yang berhenti otomatis paling lambat setelah tujuh hari. Dokumentasi juga menyebut aturan dapat berbeda menurut broker dan cBot yang memakai paket eksternal bekerja di cloud setelah memenuhi syarat tambahan [4]. Perlakukan angka itu sebagai status produk pada hari publikasi dan periksa ulang sebelum mendasarkan arsitektur padanya.

Struktur cBot. Program mewarisi kelas dasar robot. Metode saat mulai sepadan dengan inisialisasi MQL, penanganan kuotasi berikutnya sepadan dengan OnTick(), dan metode stop dengan deinisialisasi. Perbedaan praktisnya adalah dukungan asli peristiwa penutupan bar: di MetaTrader kondisi itu harus dideteksi sendiri dengan membandingkan waktu pembukaan candle saat ini dengan yang diingat.

Open API bukan REST. Ini perlu ditulis tepat, sebab penyederhanaan “cTrader memiliki REST API” beredar dalam materi sekunder. Dokumentasi Spotware menjelaskan pertukaran data Open API melalui objek JSON atau Google Protocol Buffers [5]. FIX API adalah layanan terpisah. Cakupan izin, ketersediaan dan syarat koneksi bergantung pada broker, sehingga rencanakan integrasi setelah membaca dokumentasi penyedia tertentu, bukan deskripsi umum platform.

Memilih lingkungan bukan memilih “platform terbaik”. Jika broker hanya menawarkan salah satunya, keputusan sudah dibuat. Jika keduanya tersedia, kriterianya praktis: bahasa yang memungkinkan Anda menulis dan memelihara kode yang perilakunya dipahami, dan cara menjaga kontinuitas operasi. Bahasa sendiri tidak menciptakan keunggulan. Ia mengubah biaya pemeliharaan serta jumlah kesalahan sepanjang jalan.

Webhook sebagai jembatan ke sistem lain

Jalur otomatisasi kedua tidak melewati kode di dalam platform: peristiwa sistem eksternal — misalnya alert platform grafik — mengirim permintaan HTTP ke alamat yang disepakati, baru aplikasi perantara mengubahnya menjadi pemanggilan API broker. Rantainya menjadi peristiwa → webhook → aplikasi perantara → API broker → validasi → order → respons server, dan webhook hanya bertanggung jawab atas satu mata rantai: pengiriman permintaan. Terkirim bukan berarti dieksekusi — webhook diterima dengan benar tidak menjelaskan apakah volume sesuai spesifikasi instrumen, akun memiliki margin bebas dan server broker menerima order. Setiap titik perantara menambah latensi serta mode kegagalan sendiri — termasuk pengulangan permintaan sama setelah koneksi pulih — dan alamat webhook perlu dilindungi. Namun mengetahui alamat tidak boleh menggantikan otorisasi: perantara harus memvalidasi pengirim, kebaruan permintaan dan pengenal uniknya. Konfigurasi alert di sisi platform grafik dibahas dalam artikel tersendiri; yang penting di sini hanya posisi jembatan itu dalam rantai eksekusi dan apa yang tidak dijaminnya.

5. Izin, kompilasi, log dan identifikasi posisi sendiri

“Robot tidak trading” adalah laporan lazim dalam otomatisasi ritel dan belum tentu berkaitan dengan logika strategi. Sebelum men-debug kondisi entri, periksa empat hal: program terkompilasi, terpasang pada grafik yang tepat, trading otomatis diizinkan di setiap tingkat, dan apa tepatnya yang dicatat jurnal.

Kompilasi dan tempat berkas berada

Kode sumber MetaEditor memiliki ekstensi teks, tetapi yang dipasang pada grafik adalah berkas terkompilasi. Berkas harus berada dalam folder data platform pada subfolder sesuai jenis program — jika tidak, platform tidak melihatnya. Buka folder data melalui menu platform; jangan menganggapnya folder instalasi, sebab biasanya berbeda. Setelah menyalin berkas, segarkan daftar program di jendela navigator. Baca peringatan compiler — pada kode trading, peringatan konversi tipe implisit dapat berarti volume terpotong menjadi nol.

Tiga tingkat izin trading otomatis

Izin trading otomatis bukan satu sakelar. Tingkat pertama adalah pengaturan seluruh platform — tombol trading algoritmik pada toolbar. Kedua adalah properti program tertentu saat ditambahkan ke grafik. Ketiga berada di luar kendali Anda: akun. Broker dapat memblokir trading otomatis untuk jenis akun tertentu atau membatasi seluruh trading, misalnya pada akun hanya baca. Robot yang tidak memeriksa kondisi ini hanya melaporkan order gagal tanpa penyebab.

Berikut kerangka struktur lain, bukan berkas untuk dikompilasi, kali ini untuk MQL5. Ia menunjukkan urutan pemeriksaan izin dan normalisasi volume, tetapi bukan implementasi yang tervalidasi. Kompilasi saja tidak menetapkan perilaku pada akun tertentu: periksa secara terpisah respons terminal, properti simbol dan izin saat terhubung ke broker. Artikel ini tidak menyajikan pengujian seperti itu. Gunakan kerangka sebagai dasar pemeriksaan sendiri, bukan modul trading siap pakai. Ia tidak memuat pemanggilan yang mengirim order.

KERANGKA STRUKTUR - pemeriksaan izin dan normalisasi volume
Notasi panduan untuk MQL5. Ini bukan kode lengkap yang dapat dikompilasi.

A. APAKAH TRADING DIIZINKAN - empat pembacaan, masing-masing dicatat

   TerminalInfoInteger(TERMINAL_TRADE_ALLOWED)
      false -> trading algoritmik dinonaktifkan pada platform
   MQLInfoInteger(MQL_TRADE_ALLOWED)
      false -> trading dinonaktifkan pada properti program
   AccountInfoInteger(ACCOUNT_TRADE_ALLOWED)
      false -> trading diblokir di sisi akun
   AccountInfoInteger(ACCOUNT_TRADE_EXPERT)
      false -> broker tidak mengizinkan trading otomatis di sini

   Trading diizinkan hanya jika keempat pembacaan bernilai true.
   Log harus menunjukkan mana yang gagal - jika tidak, diagnosis
   berhenti pada kalimat "robot tidak trading".

B. NORMALISASI VOLUME KE KISI LANGKAH

   masukan: symbol, vol
   keluaran: kelipatan langkah, atau 0.0 yang berarti "jangan kirim"

   B1. if not MathIsValidNumber(vol) or vol <= 0.0
          -> catat kesalahan dan kembalikan 0.0
       Perbandingan biasa tidak andal menolak NaN. Validasi masukan
       berhingga secara eksplisit sebelum berhitung; jika tidak,
       hasil dapat tetap tidak valid.

   B2. baca spesifikasi memakai varian yang mengembalikan status:
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MIN,  vmin)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_MAX,  vmax)
          SymbolInfoDouble(symbol, SYMBOL_VOLUME_STEP, vstep)
       salah satu pembacaan false atau vstep <= 0.0
          -> catat _LastError dan kembalikan 0.0
       Varian yang hanya mengembalikan angka diam saat gagal dan
       memberi nol yang tidak dapat dibedakan dari nol nyata.

   B3. TOL   := 1e-8            toleransi pembagian biner
       steps := MathFloor(vol / vstep + TOL)
       result := NormalizeDouble(steps * vstep, 8)

       Pascakondisi yang dijanjikan fungsi ini - hanya ini:
         hasil merupakan kelipatan langkah yang bulat,
         hasil tidak melampaui masukan lebih dari
         TOL * vstep.
       Tidak dijanjikan bahwa hasil tidak pernah melebihi masukan.

   B4. if result > vmax
          -> result := NormalizeDouble(MathFloor(vmax / vstep + TOL) * vstep, 8)
       if result < vmin
          -> return 0.0
       Urutan penting: minimum dan maksimum diperiksa hanya pada
       nilai yang sudah berada pada kisi langkah.

Fungsi kedua ini tampak sepele, tetapi bertanggung jawab atas satu kelas penolakan. Langkah volume, minimum dan maksimum adalah properti instrumen di broker tertentu dan berbeda antar akun. Ukuran posisi hasil perhitungan risiko hampir tidak pernah tepat pada langkah yang diizinkan, dan server menolak volume tidak valid, bukan membulatkannya untuk Anda.

Dua rincian fungsi ini perlu dijelaskan tersendiri karena termasuk kelas kesalahan yang sama dengan peringatan compiler: kode berjalan, tetapi hasil diam-diam berbeda dari perhitungan. Pertama, volume dihasilkan dengan menghitung langkah bulat lalu mengalikannya kembali dengan langkah, bukan membulatkan ke jumlah desimal tetap. Pembulatan dua desimal membuat volume 0,003 menjadi nol pada instrumen berlangkah 0,001 — tersedia pada akun sen dan beberapa kontrak CFD — sedangkan menentukan jumlah desimal dari logaritma langkah gagal bila langkah bukan pangkat sepuluh: pada langkah 0,25, volume 1,75 dibulatkan menjadi 1,8, yaitu bukan kelipatan langkah, sehingga server menolaknya seperti volume yang sama sekali belum dinormalisasi. Kedua, pembagian floating-point dapat sedikit di bawah bilangan bulat, sehingga tanpa nilai koreksi kecil, pembulatan ke bawah diam-diam mengurangi satu langkah — 0,3 dibagi 0,1 menghasilkan nilai di bawah tiga dan posisi masuk lebih kecil dari perhitungan risiko. Karena itu minimum dan maksimum diperiksa paling akhir, setelah nilai berada pada kisi langkah: pembulatan ke bawah dapat menjatuhkan nilai di bawah minimum yang tadinya terpenuhi, dan pemangkasan ke maksimum harus tetap pada kisi yang sama.

Namun nilai koreksi itu memiliki sisi kedua yang harus dinyatakan eksplisit, bukan menjanjikan lebih dari fungsi. Karena kita menambahkan sesuatu sebelum membulatkan ke bawah, hasil dapat sedikit melebihi masukan: untuk volume 0,2999999995 dengan langkah 0,1, fungsi mengembalikan 0,3, yaitu lima per sepuluh miliar lot lebih besar dari masukan. Pada ukuran langkah contoh ini, perbedaannya dapat diabaikan — tetapi pernyataan harus sesuai kenyataan: hasil adalah kelipatan langkah dan tidak melampaui masukan lebih dari toleransi yang diterima. Batas ini dipilih sengaja, sebab tanpanya kode yang sama kehilangan satu langkah penuh pada volume 0,3. Dua hal yang mudah terlupakan harus dihentikan terpisah: masukan yang bukan bilangan berhingga yang tidak ditolak secara andal oleh perbandingan biasa, serta kegagalan pembacaan spesifikasi. Karena itu kerangka memakai MathIsValidNumber() pada masukan dan varian SymbolInfoDouble() yang mengembalikan status, bukan hanya angka — varian angka mengembalikan nol ketika gagal, tidak dapat dibedakan dari nol nyata.

Log — jejak diagnosis dasar setelah kegagalan

Platform memiliki jurnal terpisah dan pemisahan itu berguna. Tab jurnal program memuat cetakan kode serta pesan inisialisasi dan pelepasannya. Jurnal platform mencatat peristiwa infrastruktur: masuk, koneksi terputus dan tersambung ulang, permintaan dikirim serta respons server. Strategy tester memiliki jurnal sendiri. Salinan ditulis ke berkas folder data sehingga bertahan setelah mulai ulang — hanya karena itulah kegagalan malam hari dapat direkonstruksi.

Minimum yang perlu dicatat robot sendiri: waktu keputusan beserta harga dan spread, parameter permintaan yang dikirim, kode respons server, harga eksekusi sebenarnya, setiap perubahan level dan setiap aktivasi mekanisme perlindungan. Tanpa catatan harga dan kode respons, Anda tidak dapat membedakan kesalahan logika dari penolakan broker, padahal keduanya masalah yang sama sekali berbeda.

Satu perbedaan perlu dipastikan sekarang karena kembali muncul pada bagian kegagalan. Jurnal adalah jejak diagnosis dasar: menjelaskan apa yang dilakukan dan dilihat program pada saat tertentu. Namun sumber kebenaran eksekusi adalah keadaan akun dan riwayat transaksi di server broker. Perbedaannya tidak lagi akademis ketika diperlukan: saat koneksi putus, log robot dapat berakhir pada kesalahan pengiriman padahal server sudah mengeksekusi transaksi. Ketika keduanya bertentangan, server menentukan.

Mengidentifikasi posisi sendiri

Robot harus bisa menjawab “apakah posisi ini milik saya”. Dalam akun dapat bersamaan ada transaksi manual, robot lain dan strategi yang sama pada simbol berbeda. Untuk itu digunakan pengenal numerik yang diberikan pada order ketika dikirim — dalam kedua lingkungan MetaTrader disebut magic number — ditambah kolom komentar. Aturan praktis sederhana: setiap loop posisi menyaring sekaligus berdasarkan pengenal dan simbol, jangan pernah hanya simbol.

Konsekuensi melewatkan filter itu menyakitkan. Robot tanpa filter menutup posisi manual. Dua robot dengan pengenal sama mengubah level satu sama lain. Pada akun netting lebih rumit, sebab posisi bersih tidak punya pemilik tunggal — robot harus memiliki catatan sendiri tentang eksposur yang dialokasikan kepadanya dan memulihkannya setelah mulai ulang dari riwayat transaksi, bukan keadaan saat ini.

6. Katalog kegagalan produksi — dari koneksi ulang hingga perubahan spesifikasi simbol

Sebagian kegagalan otomatisasi menyangkut lingkungan eksekusi, bukan aturan strategi. Backtest standar tidak mereproduksi setiap keadaan; sebagian perlu pengujian kegagalan tersendiri. Daftar berikut bukan hal eksotis — inilah yang harus disiapkan ketika menjaga robot berjalan selama beberapa bulan.

Skenario untuk direproduksi sendiri: order ganda setelah koneksi ulang

Skenario ini dijelaskan terpisah sebab tidak dapat dipicu kapan saja dengan satu klik. Tim redaksi tidak mereproduksinya — uraian berikut tidak memuat hasil pengukuran atau catatan lingkungan tempat pengukuran dilakukan. Yang ada adalah mekanisme dan petunjuk untuk memeriksanya sendiri.

Kondisi. Robot menemukan kondisi entri lalu mengirim permintaan membuka posisi. Sambil menunggu respons, koneksi putus. Order sebenarnya tiba di server dan dieksekusi, tetapi respons tidak kembali ke terminal. Robot mencatat kesalahan dan menyimpulkan tidak ada posisi.

Konsekuensi yang diharapkan. Jika kondisi entri tetap terpenuhi setelah koneksi pulih, robot mengirim permintaan lagi. Pada akun hedging akan terbentuk dua posisi alih-alih satu, dan risiko sebenarnya dua kali rencana. Pada akun netting pencatatan berbeda, tetapi eksposur tetap meningkat: posisi bersih membesar, sementara robot tetap melihatnya sebagai satu entri. Ini kesimpulan dari mekanisme di atas, bukan hasil pengujian yang telah dilakukan.

Cara memeriksa sendiri. Mematikan kartu jaringan manual “tepat setelah mengirim” bukan prosedur, melainkan lotre. Anda tidak mengendalikan apakah permintaan sempat tiba; jika tidak, kasus yang direproduksi berbeda — order gagal biasa. Di akun demo, aturan firewall atau alat diagnosis dapat memutus koneksi secara terkendali, tetapi konfirmasi pengiriman bukan bukti eksekusi. Skenario ini baru terjadi jika riwayat server mengonfirmasi eksekusi sementara terminal tidak menerima respons. Strategy tester tidak mereproduksinya, sehingga percobaan manual — dan justru harus dicatat. Tulis seluruh hal berikut; tanpa salah satunya hasil tidak memastikan apa pun dan tidak bisa dibandingkan dengan percobaan kedua:

• platform, versi terminal dan nomor build — dibaca dari jendela informasi program, bukan ingatan
• broker, nomor akun demo, server tempat terminal terhubung dan jenis akun: hedging atau netting — sebab konsekuensinya bergantung padanya
• simbol dengan akhiran broker lengkap, volume permintaan dan mode eksekusi instrumen
• tanggal dan waktu percobaan menurut waktu server broker, bukan waktu lokal
• cara pemutusan koneksi dan saat berlakunya relatif terhadap pengiriman permintaan — satu-satunya parameter yang menentukan apakah Anda mereproduksi kasus ini atau kasus yang sama sekali berbeda
• hasil: catatan lengkap jurnal robot dibanding riwayat transaksi di sisi server. Riwayatlah yang menentukan apakah order tiba — jurnal terminal saja tidak cukup, sebab ketidaktahuannya itulah fenomena yang sedang dipelajari
• jumlah pengulangan percobaan dan berapa kali menghasilkan hal sama; satu kali tidak membuktikan apa pun

Hal kedua perlu dikoreksi karena sering diulang sebagai resep siap pakai. Magic number mengidentifikasi strategi, bukan satu niat order: dua permintaan robot sama memiliki nomor identik, sehingga tidak cukup sendiri untuk menjawab “apakah order khusus ini sudah dikirim”. Diperlukan pengenal persisten satu keputusan, diberikan dan dicatat sebelum permintaan berangkat, serta disimpan di luar memori proses. Hanya itu yang memungkinkan pembedaan saat rekonsiliasi keadaan antara “saya belum mengirim” dan “saya sudah mengirim tetapi tidak tahu hasilnya”. Kolom komentar tempat alami membawanya ke order, tetapi server kadang memotong atau menimpanya — jadikan petunjuk dan dasarkan penyelesaian pada pembandingan catatan sendiri dengan riwayat server.

Perlindungannya. Aturannya sederhana dan tidak nyaman: sumber kebenaran adalah keadaan akun, bukan memori robot. Setelah setiap permintaan gagal atau hasilnya belum terkonfirmasi, sebelum mencoba lagi, program harus membaca posisi terkini serta transaksi historis terbaru dan memeriksa apakah ordernya sudah ada — dengan filter pengenal sendiri. Kunci waktu antara pengiriman berturut-turut pada simbol sama adalah tambahan murah, tetapi tidak cukup sendiri.

Prinsip sama menutup kelas kecelakaan kedua: robot yang tidak memeriksa eksposur lalu mengirim permintaan pada setiap pemanggilan saat pasar cepat. Hasilnya banjir order dan, dalam kasus ekstrem, pembatasan akses server oleh broker. Pemeriksaan keadaan sebelum mengirim dan batas jumlah operasi per satuan waktu adalah dua syarat sebelum robot diizinkan keluar dari akun demo.

7. Kontinuitas operasi: komputer, VPS, hosting platform — dan perhitungan biaya

Sistem otomatis klasik MetaTrader memerlukan terminal berjalan. Itulah satu-satunya alasan hosting dibahas — bukan kecepatan atau “profesionalisme”, melainkan proses mati tidak menghitung apa pun. Pengecualiannya jalur cloud cTrader Algo di atas: cBot yang memenuhi syarat cloud mungkin tidak memerlukan VPS eksternal sama sekali. Batasan ini penting karena ekosistem sama juga memungkinkan eksekusi lokal — yang mengembalikan seluruh persoalan hosting. Batas jumlah instans bergantung pada jenis akun dan broker, dan cBot dengan paket eksternal hanya bekerja di cloud setelah syarat tambahan terpenuhi.

Yang dibawa komputer rumah ke perhitungan. Listrik padam, mulai ulang setelah pembaruan, koneksi penyedia internet gagal, sistem membeku. Masing-masing mematikan lingkungan eksekusi dan seluruh logika robot. Yang tidak mati adalah level SL dan TP di server broker — batas inilah yang harus dipahami untuk menilai berapa banyak yang hilang saat gangguan.

Yang tidak dilakukan VPS. VPS tidak memperbaiki strategi. Tidak menghapus slippage atau penolakan. Tidak melindungi dari kegagalan broker maupun sambungan broker ke penyedia likuiditasnya. Tidak menjamin kontinuitas — ketersediaan layanan yang dinyatakan adalah komitmen kontrak, bukan hukum fisika. Yang dibeli satu hal: menghapus perangkat keras dan koneksi sendiri dari daftar penyebab kegagalan.

Dua produk berbeda dengan satu nama

Kata “VPS” digunakan untuk dua solusi yang cara administrasinya sama sekali berbeda.

Server virtual dengan sistem operasi lengkap disewa seperti komputer biasa di pusat data. Anda tersambung lewat desktop jarak jauh, memasang platform sendiri, dan mengawasi pembaruan sistem, autostart, pemantauan serta cadangan konfigurasi sendiri. Kebebasan penuh — dapat menjalankan beberapa platform, skrip pengawasan dan alat diagnosis sendiri — disertai tanggung jawab penuh atas pemeliharaan, termasuk keamanan akses jarak jauh.

Hosting terintegrasi platform bekerja berbeda. Pada MetaTrader, layanan MetaTrader VPS diluncurkan dari platform, lalu lingkungan dimigrasikan dengan satu perintah; layanan meng-host sistem otomatis yang berjalan dan langganan penyalinan sinyal tanpa memerlukan administrasi Windows atau koneksi desktop jarak jauh [6]. Kemudahan punya harga: Anda tidak bisa memasang sembarang perangkat lunak dan bekerja dengan sumber daya yang dibatasi.

Perhitungan biaya infrastruktur dengan contoh eksplisit

Saya memakai angka harga di atas agar contoh dapat diperiksa, bukan sekadar ilustrasi. Dengan tagihan tahunan, biaya adalah 12 × 10 USD = 120 USD per tahun. Dengan tagihan bulanan, 12 × 15 USD = 180 USD per tahun.

Kesimpulan saya terbatas pada contoh ini. Pada akun sekitar 2.000 USD, hosting saja memakan beberapa persen modal setahun sebelum spread dan komisi — dan bersaing dengan hasil yang realistis diharapkan. Pada akun sepuluh kali lebih besar, layanan sama menjadi sepersepuluh persentase modal tersebut. Ini tidak menyimpulkan VPS “layak” atau “tidak layak” bagi orang lain; hanya bahwa biaya infrastruktur harus dihitung terhadap modal sendiri, bukan harga di halaman penyedia.

Memilih parameter dan menerapkan

Kebutuhan robot yang hanya trading cukup sederhana — beban berasal dari optimasi dalam tester, yang dapat dikerjakan di tempat lain. Catatan pembatas tabel di bawah lebih penting daripada isinya. Angka bersifat ilustratif: bukan hasil pengukuran untuk artikel ini atau persyaratan pembuat, hanya menunjukkan parameter yang perlu diperiksa. Ukur sendiri — jalankan konfigurasi sasaran di akun demo, baca penggunaan puncak memori dan prosesor proses platform melalui task manager setelah beberapa hari, baru pilih mesin berdasarkan itu.

Pasar penyedia terbagi tiga kategori, berbeda bukan pada harga melainkan siapa menanggung biaya pemeliharaan. Hosting broker kadang ditawarkan dengan syarat istimewa pada tingkat aktivitas tertentu — nyaman tetapi mengikat ke satu broker. Penyedia khusus hosting trading menaruh server di pusat data yang digunakan broker FX. Cloud publik umum menyerahkan seluruh konfigurasi kepada Anda. Saya sengaja tidak menyebut nama perusahaan: ketersediaan, lokasi dan ketentuan berubah lebih cepat daripada artikel, dan daftar penyedia dalam teks pendidikan terlalu mudah berubah menjadi rekomendasi.

Checklist penerapan hosting:

1. Jalankan seluruh konfigurasi di akun demo, bukan selama jumlah hari tetap tetapi sampai mengalami tiga peristiwa: mulai ulang paksa mesin, koneksi hilang lalu pulih, serta pasar akhir pekan tutup lalu buka. Baru setelah itu ganti akun
2. Tetapkan jadwal pembaruan sistem di luar jam trading dan periksa setelah mulai ulang paksa
3. Atur platform mulai otomatis dan pemulihan kumpulan grafik bersama program terpasang
4. Periksa terpisah apakah trading otomatis kembali aktif setelah mulai ulang — platform berjalan tidak menjaminnya
5. Jalankan pemantauan independen ketersediaan mesin, dan secara terpisah proses platform; ping saja tidak mendeteksi aplikasi membeku
6. Nonaktifkan pemadaman layar dan tidur, atur rotasi log dan awasi ruang disk
7. Amankan akses jarak jauh dengan kata sandi kuat dan unik serta autentikasi multifaktor jika penyedia menawarkan; batasi akses berdasarkan alamat bila mungkin
8. Cadangkan template grafik dan set parameter. Jangan simpan kredensial akun dalam berkas konfigurasi atau catatan — gunakan pengelola kata sandi
9. Rencanakan prosedur kehilangan mesin: dari mana konfigurasi dipulihkan dan dalam berapa lama

Poin terakhir sering dilewati. Hosting belum menjadi perlindungan sebelum Anda tahu berapa lama membangun ulang lingkungan setelah kehilangan — dan pernah mengujinya sekali dalam keadaan tenang.

8. Latensi — apa tepatnya yang diukur dan apa yang tidak dijelaskan pengukuran

“Ping 2 ms” tidak berarti “order dieksekusi dalam 2 ms”. Kalimat itu layak dibaca dua kali, sebab penjualan infrastruktur trading bertumpu pada pengaburan perbedaannya. Latensi rantai eksekusi terdiri dari beberapa segmen yang diukur terpisah dengan alat dan tingkat ketelitian berbeda.

Klaim penyedia hosting hampir selalu menyangkut segmen pertama atau kedua. Ketika MetaQuotes menyatakan akses dari MetaTrader VPS ke 96% server broker di bawah 10 ms [6], yang dijelaskan adalah segmen jaringan. Itu tidak menyimpulkan berapa lama broker benar-benar menyelesaikan transaksi Anda — sebab bergantung pada kebijakan eksekusi, likuiditas tersedia dan beban server saat itu.

Satu-satunya pengukuran yang menyangkut akun Anda berasal dari data sendiri. Catat tiga cap waktu dan dua harga dalam log: saat keputusan beserta harga yang dilihat robot, saat permintaan dikirim, serta waktu dan harga eksekusi yang dibaca dari respons server. Setelah rangkaian transaksi cukup panjang, Anda memiliki distribusi, bukan satu angka halaman penyedia. Lihat distribusi, bukan rata-rata: eksekusi lambat sesekali saat rilis data atau likuiditas tipis lebih berpengaruh daripada median tenang.

Satu batasan menentukan apakah pengukuran bermakna. Dua waktu pertama berasal dari jam mesin Anda, sedangkan waktu transaksi riwayat akun berasal dari jam server broker. Mengurangkannya mencampur dua jam dan menambah offset tak diketahui yang tidak tampak dalam angka. Karena itu ukur pulang-pergi secara lokal dengan satu penghitung resolusi tinggi: dari pemanggilan fungsi pengirim order hingga respons kembali. Catat waktu transaksi riwayat server di sampingnya sebagai besaran terpisah, bukan ujung lain segmen yang sama. Lama permintaan di dalam infrastruktur broker tetap tidak diketahui tanpa telemetrinya — Anda dapat mengukur keseluruhan dan membandingkan antarperiode, tetapi tidak membaginya per tahap.

Untuk menilai sensitivitas logika tersedia strategy tester MetaTrader 5, yang memungkinkan emulasi latensi eksekusi dan berbagai model pembangkitan tick, termasuk tick nyata dari broker [7]. Itu bukan pengukuran koneksi Anda — melainkan pemeriksaan apakah strategi mampu bertahan dalam keadaan eksekusi lebih buruk. Metodologi lengkap pengujian dibahas dalam artikel tentang pengujian strategi.

Kapan hal itu penting

Jawabannya berasal dari aritmetika, bukan keyakinan. Untuk biaya tertentu, porsinya membesar saat rata-rata transaksi mengecil. Nilai berikut ilustratif — saya mengasumsikan total biaya satu transaksi 2,0 pip, terdiri dari spread, komisi yang dikonversi ke pip dan slippage lazim. Baca biaya sebenarnya dari spesifikasi akun dan transaksi sendiri. Latensi tidak masuk jumlah itu dan memang tidak bisa: bukan biaya dalam pip, melainkan parameter model eksekusi. Jadi tabel berikut tidak mengukur atau menyimpulkan apa pun tentang latensi.

Untuk sistem otomatis dengan target beberapa puluh pip, contoh ini menyarankan pemeriksaan apakah latensi berpengaruh material sebelum membayar pengurangannya. Jika target beberapa pip, latensi dan slippage adalah masalah strategi, bukan hosting — server mana pun tidak memperbaikinya.

Parameter yang melindungi dari kondisi eksekusi buruk

Dua mekanisme harus ada dalam kode robot. Pertama filter spread: sebelum setiap keputusan, bandingkan spread dengan ambang dan tahan pembukaan posisi ketika terlampaui. Nyatakan ambang sebagai kelipatan spread khas instrumen pada jam trading Anda, bukan konstanta dalam kode — ambang sama tidak masuk akal pada simbol dan broker lain.

Yang kedua sering disebut batas universal harga eksekusi — padahal bukan. Deviasi harga maksimum saat mengirim order hanya berlaku pada satu mode eksekusi. Panduan MetaTrader 4 merangkumnya dalam satu kalimat: “Deviasi harga saat menempatkan order hanya digunakan pada mode instant execution” [18]. Halaman sama juga menjelaskan kerja kolom itu — berkebalikan dengan sebutan umum “perlindungan slippage”: “jika deviasi di bawah atau sama dengan parameter yang ditentukan, order dieksekusi pada harga baru tanpa pemberitahuan tambahan. Jika tidak, broker mengembalikan harga baru untuk eksekusi order” [18]. Jadi perubahan dalam batas dieksekusi pada harga baru tanpa notifikasi tambahan, sedangkan requote — harga baru dikirim untuk dikonfirmasi — hanya terjadi di luar batas. Pada mode market kolom itu sama sekali tidak ada: panduan MetaTrader 5 menjelaskan parameter untuk Instant Execution dan menyatakan kebalikannya tentang Market Execution — “Dalam mode ini, broker menentukan harga eksekusi tanpa diskusi tambahan dengan trader” — lalu menegaskan: “Mengirim order dalam mode ini berarti persetujuan terlebih dahulu atas eksekusi pada harga tersebut” [11]. Di situ broker menetapkan harga, pengiriman order merupakan persetujuan sebelumnya dan formulir menampilkan Fill Policy di tempat itu, bukan deviasi.

Broker menetapkan mode eksekusi terpisah per simbol, sehingga pertanyaan pertama bukan “berapa nilai yang diisi” melainkan “apakah kolom ini berlaku untuk instrumen saya” — periksa spesifikasinya. Jika berlaku, Anda memilih dua biaya: batas lebih sempit berarti requote lebih sering dan permintaan gagal pada percobaan pertama; lebih longgar berarti lebih sedikit requote tetapi lebih banyak eksekusi pada harga berbeda dari saat keputusan. Perlakukan nilai ini sebagai elemen strategi, bukan pengaturan teknis. Jika tidak berlaku, yang tersisa hanya catatan log selisih harga keputusan dan eksekusi sebenarnya. Catatan itu berguna pada kedua kasus.

Mekanisme ketiga berbasis waktu dan paling sederhana: jendela ketika robot tidak membuka posisi baru. Jam rollover harian dan rilis data terpenting adalah saat spread melebar dan likuiditas menipis. Memblokir entri hanya perlu beberapa baris kode — asalkan memakai waktu server broker, bukan waktu lokal mesin, dan perilakunya sudah diuji pada batas perubahan waktu.

9. Kill switch, batas dan standar minimum penerapan

Robot tanpa mekanisme penghentian memiliki potensi kerugian tak terbatas dalam margin yang tersedia. Bukan karena kode buruk, tetapi karena tidak ada kondisi penghentian. Kill switch bukan fitur tambahan. Itulah prasyarat menyebut sistem terkelola, bukan program yang dibiarkan sendiri.

Batas yang harus dimiliki setiap sistem otomatis di akun riil:

1. Batas penurunan ekuitas. Setelah penurunan dari puncak ekuitas melampaui batas, robot menutup posisi sendiri, membaca akun untuk memastikan tidak ada tersisa, baru berhenti; jika masih ada, robot harus tetap aktif dan membunyikan alarm. Besarnya ambang mengikuti rencana risiko — metode penentuannya dibahas dalam materi risiko; yang penting di sini ambang ada dalam kode dan diperiksa sebelum logika strategi
2. Batas rugi harian. Penghitung diatur ulang pada jam server tertentu, dipulihkan dari riwayat transaksi setelah mulai ulang, bukan hanya disimpan dalam memori
3. Batas jumlah posisi terbuka. Batas atas tegas, independen dari logika entri
4. Batas ukuran satu posisi. Batas atas diterapkan pada hasil perhitungan ukuran posisi, agar kesalahan hitung tidak menjadi order bervolume tidak proporsional
5. Filter spread dan — jika mode eksekusi simbol mendukungnya — deviasi harga maksimum. Keduanya dijelaskan bagian sebelumnya
6. Filter jam. Jendela ketika robot tidak membuka posisi baru
7. Respons terhadap masalah koneksi. Setelah mendeteksi koneksi putus atau kuotasi usang, robot menahan posisi baru tetapi tidak menutup yang ada membabi buta — menutup berdasarkan harga usang kadang lebih buruk daripada menunggu

Urutan pemeriksaan penting. Kondisi keselamatan ditempatkan di awal event handler sebelum logika entri. Saat dilanggar, program tidak boleh membuka atau meningkatkan eksposur — hanya boleh menutup posisi sendiri dan mencatat kejadian. Kembali bekerja memerlukan keputusan sadar manusia, jangan pernah melanjutkan otomatis setelah penundaan.

kondisi penghentian: ekuitas saat ini < puncak ekuitas × (1 − penurunan yang diizinkan) → tulis log → tutup posisi sendiri → hitung ulang eksposur sendiri → hapus program hanya jika posisi nol dan kesalahan penutupan nol → jika tidak, bunyikan alarm dan tetap aktif

Berikut kerangka struktur terakhir dan satu-satunya yang menyentuh fungsi penutupan posisi. Karena itu terdapat dua gerbang keselamatan, keduanya pada nilai bawaan, bukan komentar. Pertama, mode dry-run aktif secara bawaan — program tidak mengirim operasi, hanya mencatat apa yang akan ditutup. Kedua, sebelum kuotasi pertama, program membaca jenis akun dan menolak inisialisasi pada akun selain demo hingga pembaca memberi konfirmasi eksplisit terpisah. MQL4 menyediakan pembacaan melalui AccountInfoInteger(ACCOUNT_TRADE_MODE), dan dokumentasinya membedakan akun demo, kontes dan riil [16]. Kalimat peringatan dalam komentar bukan perlindungan; perlindungannya adalah nilai bawaan yang harus diubah dengan sadar agar sesuatu terjadi.

KERANGKA STRUKTUR - kill switch berdasarkan penurunan ekuitas
Notasi panduan untuk MQL4. Ini bukan kode lengkap yang dapat dikompilasi.

PENGATURAN MASUKAN - dua yang pertama menentukan keselamatan

   DryRun := TRUE                            nilai bawaan
      Program tidak mengirim operasi. Jurnal mencatat apa yang
      akan ditutup: nomor order, volume dan harga acuan.
      Agar benar-benar menutup, pengaturan ini harus diubah
      secara manual.

   LiveAccountConsent := FALSE                nilai bawaan
      Tanpanya, program menolak mulai pada akun selain demo.
      Persetujuan ini tidak dapat diberikan tanpa sengaja.

   MagicNumber    - pengenal posisi sendiri
   MaxDrawdownPct - penurunan yang diizinkan dari puncak ekuitas
   MaxDeviation   - hanya bekerja pada satu mode eksekusi,
                    lihat paragraf di bawah kerangka

MULAI - OnInit()

   mode := AccountInfoInteger(ACCOUNT_TRADE_MODE)
   if mode != ACCOUNT_TRADE_MODE_DEMO
         and not LiveAccountConsent:
      tulis log: akun bukan demo, persetujuan belum ada
      akhiri inisialisasi dengan kesalahan (INIT_FAILED) - selesai
   peak       := AccountEquity()
   stopped    := FALSE
   lastAlert  := 0          waktu alert terakhir

SETIAP KUOTASI - OnTick()

   if stopped:
      remaining := CountOwnPositions()
      if remaining > 0
            and TimeCurrent() - lastAlert >= 3600:
         tulis log: keadaan berhenti, remaining
         kirim alert kepada manusia
         lastAlert := TimeCurrent()
      akhiri penanganan kuotasi ini
         program tidak mencoba menutup ulang sendiri - percobaan
         berikutnya adalah keputusan manusia, secara manual
   equity := AccountEquity()
   if equity > peak: peak := equity
   threshold := peak * (1 - MaxDrawdownPct / 100)

   if equity >= threshold:
      cabang ini kosong - kerangka hanya mengawasi ambang
      dan tidak memuat logika entri sama sekali

   selain itu:
      stopped := TRUE
      tulis log: equity, threshold, peak, timestamp
      errors    := CloseOwnPositions()
      remaining := CountOwnPositions()
      if remaining == 0 and errors == 0 and not DryRun:
         ExpertRemove()          dilepas hanya setelah berhasil
      selain itu:
         tulis log: errors, remaining
         kirim alert kepada manusia
         lastAlert := TimeCurrent()
         JANGAN lepaskan program - tetap aktif, tidak membuka
         apa pun, mengulang alert dan menunggu manusia

PENUTUPAN - CloseOwnPositions() mengembalikan jumlah kesalahan

   errors := 0
   for i from OrdersTotal() - 1 down to 0:

      if not OrderSelect(i, SELECT_BY_POS, MODE_TRADES):
         errors := errors + 1
         tulis log: posisi i, GetLastError()
         lanjut ke berikutnya            jangan diam di sini

      if OrderType() > OP_SELL: skip
                                     pending order terpisah
      if OrderMagicNumber() != MagicNumber
            or OrderSymbol() != Symbol(): skip
                                     biarkan posisi lain dan manual

      RefreshRates()
      price := MarketInfo(OrderSymbol(),
                          MODE_BID for OP_BUY, MODE_ASK for OP_SELL)
      if price <= 0:
         errors := errors + 1
         tulis log: tidak ada kuotasi, GetLastError()
         lanjut ke berikutnya

      ticket := OrderTicket()
      volume := OrderLots()

      if DryRun:
         tulis log: AKAN MENUTUP order, volume, price
         lanjut ke berikutnya         tidak ada yang dikirim ke server

      if not OrderClose(ticket, volume, price, MaxDeviation):
         errors := errors + 1
         tulis log: nomor order, GetLastError()

   return errors

KONFIRMASI - CountOwnPositions()

   Telusuri daftar lagi dan kembalikan jumlah posisi dengan
   MagicNumber sendiri pada simbol ini, melewati pending order
   seperti loop di atas. Ini pembacaan keadaan akun, bukan
   memori program - hanya inilah yang menentukan apakah
   program boleh selesai.

Yang tidak dilakukan kerangka ini — sama pentingnya dengan yang dilakukan. Tidak menghapus pending order. Tidak menangani penutupan parsial. Tidak bertahan setelah mulai ulang: flag berhenti dan puncak ekuitas hidup dalam memori, sehingga program menghitung dari awal setelah platform dimulai ulang. Juga tidak mencoba menutup ulang — pilihan sadar, bukan kekosongan. Setelah penutupan gagal, kerangka memasuki keadaan berhenti dan tetap di sana: tidak membuka hal baru, menghitung ulang posisi sendiri pada setiap kuotasi berikutnya, dan selama masih ada satu posisi terbuka, mengulang catatan jurnal serta alert paling sering sekali sejam. Percobaan penutupan berikutnya dilakukan manusia — manual melalui terminal atau aplikasi broker. Perilaku ini lengkap: percobaan ulang otomatis memang tidak ada dan tidak menunggu dilengkapi. Namun satu keputusan tegas: program hanya dilepas setelah menghitung ulang posisi sendiri, tidak ada yang tersisa dan tidak ada kesalahan penutupan. Urutannya lebih penting daripada terlihat: program yang selalu melepas diri setelah penutupan gagal meninggalkan eksposur terbuka dan catatan log, tanpa pihak dalam sistem untuk mencoba menutupnya. Karena itu, pada kesalahan atau posisi tersisa, kerangka tetap aktif dan membunyikan alarm.

Satu hal di tengah jalan tampak sebagai praktik baik, padahal bukan. RefreshRates() mengembalikan boolean, tetapi memperlakukan false sebagai kesalahan justru keliru: dokumentasi MQL4 menyatakan fungsi mengembalikan true jika data disegarkan, lalu menjelaskan “satu-satunya alasan data tidak dapat disegarkan adalah karena data tersebut merupakan data terkini terminal klien” [17]. Jadi False berarti data memang sudah terkini. Yang perlu diperiksa berbeda — apakah harga setelah penyegaran benar-benar angka positif. Harga nol menandakan pembacaan spesifikasi gagal atau kuotasi tidak ada, dan permintaan penutupan pada harga itu akan ditolak.

Tersisa parameter deviasi, dan batasannya lebih penting daripada nilainya sendiri. MaxDeviation bukan batas universal harga eksekusi: hanya berlaku pada mode Instant Execution, dan dalam batas yang ditetapkan berarti eksekusi pada harga baru tanpa notifikasi tambahan — baru di luar batas server mengirim harga baru untuk dikonfirmasi. Mekanisme serta kutipan sumber dijelaskan dalam bagian latensi, dan lebih luas dalam artikel tentang platform; yang penting di sini satu konsekuensi. Nilai sekitar tiga point, yaitu 0,3 pip pada akun lima digit, disalin dari contoh tanpa dipikir ulang dan dipilih untuk entri tenang, bukan penutupan darurat. Penutupan darurat justru terjadi saat spread dan slippage besar, sehingga batas sesempit itu membuat server mengirim harga baru alih-alih mengeksekusi — dan program yang tidak menangani requote tertinggal dengan posisi terbuka dan catatan kesalahan. Jadi deviasi keluar darurat harus jelas lebih longgar daripada entri — dan pelonggaran harus disebut sesuai artinya. Ini bukan peningkatan perlindungan, melainkan persetujuan sebelumnya untuk menutup pada harga lebih buruk daripada saat keputusan, demi peluang lebih tinggi permintaan berhasil sama sekali. Pilihannya harga lebih buruk atau eksposur terbuka, bukan keselamatan atau risiko. Jika simbol memakai Market Execution, kolom itu tidak ada: broker menentukan harga, permintaan merupakan persetujuan sebelumnya, dan yang tersisa catatan log seberapa jauh harga penutupan dari harga keputusan.

Ketidaksimetrian kedua tidak bergantung mode eksekusi dan menyangkut cakupan. Ambang dihitung dari AccountEquity(), yaitu ekuitas seluruh akun, sedangkan penutupan hanya mencakup posisi simbol saat ini. Sistem sama di tiga grafik, ketika ambang terlampaui, hanya menutup instrumen tempat kuotasi kebetulan tiba — instans lain terus menghitung puncaknya sendiri. Dalam banyak grafik, pengawasan risiko seluruh akun harus dipisahkan ke program tersendiri. Setiap celah ini keputusan desain terpisah yang harus dibuat sadar sebelum kode menyentuh akun uang riil.

Tiga lapisan perlindungan

Tidak satu lapisan pun cukup, sebab masing-masing gagal pada skenario berbeda.

1. Kode robot. Batas di atas. Bekerja hanya ketika program berjalan
2. Server broker. Level SL dan TP pada posisi, margin call dan penutupan otomatis pada stop-out. Bekerja independen dari lingkungan Anda — itulah mengapa setiap posisi sistem otomatis perlu level perlindungan di sisi itu, bukan hanya variabel kode
3. Manusia. Notifikasi ponsel tentang pembukaan, penutupan, penghentian dan kesalahan, serta kemampuan yang telah diuji untuk menutup manual melalui aplikasi broker. Lapisan terakhir ketika dua sebelumnya gagal

Ketergantungan antarlapisan konkret. Level server saja tidak menghentikan rentetan rugi kecil yang masing-masing sesuai risiko tetapi bersama menguras akun — itulah tugas batas drawdown ekuitas dalam kode. Batas kode tidak membantu ketika mesin terminal mati — saat itu hanya lapisan broker yang bekerja. Notifikasi tanpa dua lapisan pertama hanya menceritakan perkembangan kerugian.

Perlindungan juga harus diuji

Mekanisme perlindungan yang tidak pernah dipicu masih asumsi, bukan perlindungan. Pengujian di akun demo memiliki dua tahap karena tahap pertama memeriksa kebenaran lebih murah. Pertama, aktifkan dry-run dan set ambang cukup rendah agar terlampaui dalam satu jam. Program tidak mengirim apa pun, tetapi menulis posisi mana dianggap miliknya dan rencana tindakan. Jika daftar tidak cocok — kadang pada percobaan pertama karena filter pengenal atau simbol terlalu luas — Anda mengetahuinya tanpa menutup apa pun. Kedua, baru ketika daftar cocok, matikan dry-run dan ulangi. Periksa terpisah tiga hal: hanya posisi sendiri tertutup, peristiwa tercatat di jurnal, dan program baru berhenti setelah memastikan tidak ada tersisa. Pengujian terpisah adalah koneksi putus: matikan jaringan beberapa menit lalu periksa setelah pulih — apakah robot merekonsiliasi keadaan dengan riwayat akun, atau mulai dari awal dan membuka posisi kedua.

Standar minimum penerapan adalah: program terkompilasi dengan seperangkat batas, izin diperiksa pada ketiga tingkat, keputusan ditulis ke berkas, bekerja pada lingkungan sasaran di akun demo yang mencakup mulai ulang paksa, koneksi putus dan lintasan akhir pekan, baru kemudian, jika rencana risiko mengizinkan, akun riil dengan volume minimum sebelum mempertimbangkan peningkatan eksposur. Jumlah transaksi dan hasil yang mengizinkan tahap berikut adalah topik validasi strategi tersendiri — di sini hanya kesiapan operasional.

Sistem otomatis siap pakai dari pihak luar

Satu kalimat tentang produk pasar perangkat lunak karena menyangkut keselamatan operasional. Berkas yang dijual sudah terkompilasi, sehingga logikanya tidak terbaca: Anda tidak dapat memeriksa keberadaan batas drawdown, level perlindungan server atau pertambahan volume setelah rentetan rugi. Menilai strategi memerlukan alat dalam materi pengujian; dari perspektif artikel ini berlaku aturan lebih sederhana — sistem yang perilakunya saat gagal tidak dapat diprediksi tidak dapat diawasi dengan aman, apa pun bentuk kurva kinerja yang ditampilkan.

Menulis robot sering bagian termudah. Memeliharanya lebih sulit: tinjauan log mingguan untuk penolakan dan waktu eksekusi tidak lazim, pemeriksaan drawdown sesuai asumsi, serta jawaban jujur apakah keadaan pasar masih menyerupai kondisi pengujian. Otomatisasi memindahkan eksekusi ke kode dan menghapus sebagian kesalahan manusia pada eksekusi. Tidak memindahkan tanggung jawab — tetap pada Anda, bersama kewajiban menghentikan sistem tepat waktu.