Cara mengevaluasi feed harga broker.

Mulailah dari harga, bukan daftar vendor

Pertanyaan pertama bukan “Berapa banyak sumber yang didukung?” Pertanyaannya adalah “Bagaimana harga untuk simbol ini seharusnya dibentuk?”

Pilih beberapa kasus yang representatif:

• instrumen sederhana dari satu sumber institusional;
• simbol yang memerlukan konsensus dari beberapa sumber;
• instrumen dengan urutan failover yang ketat;
• cross sintetis;
• simbol dengan penetapan harga khusus untuk akhir pekan atau sesi tertentu; dan
• pasar tempat satu tick buruk dapat menimbulkan kerugian besar.

Untuk setiap kasus, tuliskan hasil yang diharapkan dalam bahasa sederhana. Hasil tersebut menjadi dasar evaluasi yang jauh lebih baik daripada sekadar mencentang kotak dalam daftar konektor yang luas.

1. Evaluasi input

Tanyakan kategori sumber data pasar mana yang dapat digunakan dalam feed yang sama:

• likuiditas FIX institusional;
• data langsung dari bursa;
• pasar referensi independen;
• harga dari platform atau bridge milik Anda sendiri; dan
• sumber milik sendiri atau sumber di sisi klien.

Kemudian, tanyakan bagaimana identitas setiap sumber dipertahankan. Dapatkah satu simbol menggunakan median, sementara simbol lain menggunakan sumber utama dan cadangan yang telah ditentukan? Dapatkah instrumen yang sama dari suatu venue dipetakan ke nama simbol yang sudah digunakan oleh sistem Anda?

Pastikan pihak yang bertanggung jawab atas akun venue, kredensial, hak akses data pasar, dan ketersediaan instrumen. Keberadaan konektor tidak otomatis memberikan izin untuk menggunakan data dari suatu venue.

Lihat sumber data pasar untuk memahami pendekatan CoinPriceFeeds.

2. Evaluasi kendali penetapan harga

Tanyakan siapa yang dapat mengubah:

• prioritas atau agregasi sumber;
• markup;
• spread minimum dan maksimum;
• presisi dan pembulatan;
• daftar simbol yang dipublikasikan;
• jadwal berdasarkan hari atau sesi; dan
• kontrol pergerakan atau gap.

Cari tahu apakah setiap perubahan memerlukan tiket dukungan atau deployment perangkat lunak. Jika klien dapat melakukan perubahan sendiri, periksa cara sistem menangani input yang tidak valid dan memastikan konfigurasi valid sebelumnya tetap aktif.

Tanyakan juga cara tim memastikan aturan yang sedang aktif di setiap server. Revisi dalam lembar kerja bukan bukti yang berguna jika feed produksi memuat versi lain.

Baca tentang mesin penetapan harga yang dikendalikan klien .

3. Uji perilaku saat terjadi kegagalan

Demo dengan sumber yang sehat hanya membuktikan skenario termudah.

Minta penyedia menjelaskan:

1. Apa yang terjadi ketika sumber memublikasikan lompatan abnormal yang besar?
2. Apa yang terjadi ketika venue menarik kuotasi secara eksplisit?
3. Apa yang terjadi ketika koneksi tetap terbuka, tetapi harga berhenti diperbarui?
4. Apa yang terjadi ketika pembaruan lama tiba setelah pembaruan yang lebih baru?
5. Apa yang terjadi pada simbol sintetis atau agregat yang bergantung pada input yang gagal?
6. Dapatkah kuotasi bernilai nol atau negatif, tidak berupa angka hingga, atau memiliki bid di atas ask keluar dari sistem?
7. Bagaimana operator klien yang berwenang dapat melihat dan memulihkan status yang dilindungi?

Jawaban penyedia harus membedakan setiap skenario tersebut. Pernyataan “Kami memiliki failover” masih terlalu umum.

Tinjau perlindungan kuotasi sebelum merancang pengujian.

4. Evaluasi jalur pengiriman

Pilih protokol paling sederhana yang sesuai dengan sistem hilir.

Stream sederhana berbasis baris mungkin ideal untuk bridge yang Anda kendalikan. FIX mungkin lebih sesuai untuk platform atau alur kerja likuiditas yang sudah menggunakan sesi data pasar.

Pastikan:

• pihak yang memulai koneksi;
• cara kerja autentikasi dan rotasi kredensial;
• apakah langganan dikelola per konsumen;
• cara keepalive direpresentasikan;
• apakah satu konsumen yang lambat dapat menghambat konsumen lainnya;
• hal yang terjadi setelah koneksi tersambung kembali;
• jumlah konsumen yang diperkirakan terhubung secara bersamaan; dan
• apakah endpoint feed utama dan cadangan menunjukkan perilaku yang sama.

Jangan hanya mengandalkan klaim “mendukung platform.” Tanyakan apakah penyedia menawarkan plug-in native, terhubung ke bridge yang sudah ada, atau menyediakan protokol untuk diintegrasikan oleh tim Anda.

Lihat opsi pengiriman dan integrasi .

5. Pastikan redundansi dapat diuji

Nama host kedua saja tidak cukup.

Tanyakan apakah feed utama dan cadangan:

• berjalan secara bersamaan;
• menggunakan input efektif yang sama;
• menampilkan versi penetapan harga yang telah dimuat;
• dapat dibandingkan per simbol;
• mempertahankan status penetapan harga selama restart rutin;
• menggunakan jalur jaringan dan DNS yang cukup independen; dan
• diuji sebelum failover produksi.

Tentukan pihak yang menjalankan failover dan cara pengujiannya. Penyedia dapat menjaga kedua koneksi tetap siap, sementara bridge klien menentukan waktu peralihan.

Baca tentang desain feed redundan .

6. Lihat lebih jauh dari sekadar status “aktif”

Pemantauan feed yang bermanfaat seharusnya dapat menjawab:

• Apakah kuotasi dari sumber masuk?
• Apakah harga untuk klien dihasilkan?
• Kapan setiap feed terakhir kali mengirimkan data?
• Apakah konsumen terhubung?
• Apakah keterlambatan terjadi di sisi hulu, dalam pemrosesan, atau pada jalur pengiriman?
• Apakah sumber dinyatakan tidak valid?
• Apakah feed utama dan cadangan selaras?
• Apakah aktivitas terlalu rendah untuk waktu seperti ini dalam sepekan?

Tanyakan sinyal mana yang dapat diteruskan ke sistem pemantauan Anda dan sinyal mana yang hanya dapat dilihat oleh penyedia.

Lihat pemantauan dan verifikasi .

7. Tinjau akses klien dan batas perubahan

Identifikasi setiap orang yang perlu memeriksa feed dan setiap orang yang boleh mengubahnya.

Model yang tepat memisahkan pembaca dan penulis, melindungi tindakan di browser dari permintaan tidak sah, mencatat perubahan dengan hak istimewa, dan memungkinkan klien mencabut akses ketika terjadi perubahan staf.

Tanyakan apakah gangguan pada penyedia izin pihak ketiga dapat mengunci semua pengguna yang sudah memiliki akses, serta apakah sumber privat diisolasi antar-akun klien.

Baca gambaran umum keamanan dan akses .

8. Sepakati model operasional

Perjelas tanggung jawab kedua pihak:

Jangan menjadikan persentase uptime tanpa kualifikasi sebagai pengganti jawaban atas pertanyaan tersebut.

9. Minta bukti

Bukti yang bermanfaat meliputi:

• tampilan aturan yang representatif;
• tampilan dasbor dengan sumber yang dilindungi atau tidak valid;
• perbandingan konfigurasi feed utama dan cadangan;
• sampel kuotasi serentak dari kedua endpoint;
• aplikasi klien referensi yang menyelesaikan handshake sebenarnya;
• pengujian pemutusan dan pemulihan yang disengaja;
• contoh kegagalan validasi yang tetap mempertahankan aturan lama; dan
• log perubahan yang jelas setelah tindakan dengan hak istimewa.

Penyedia berkualitas seharusnya mampu menjelaskan arti bukti tersebut, bukan hanya menampilkan layar berwarna hijau.

10. Tentukan cakupan secukupnya—lalu berhenti

Tahap evaluasi harus memastikan kesesuaian produk. Ambang terperinci, pemetaan FIX, pengaturan koneksi, kredensial, dan susunan deployment disepakati selama onboarding teknis.

Batas ini melindungi kedua pihak: klien menerima detail yang diperlukan untuk melakukan integrasi, sementara informasi operasional yang sensitif dan khusus bagi klien tidak berubah menjadi panduan implementasi publik.