Cara Kerja Agregasi Likuiditas dalam Forex

Jawaban langsung

Agregasi likuiditas dalam forex adalah mekanisme struktur pasar di mana likuiditas dari berbagai sumber dikumpulkan dan disajikan untuk dieksekusi secara terpadu. Dalam praktiknya, ini berarti ketika seseorang menempatkan order, sistem eksekusi berupaya berinteraksi dengan peluang beli dan jual terbaik yang tersedia yang dapat diaksesnya, bukan hanya mengandalkan satu aliran kuotasi.

“Agregasi” tidak berarti satu harga atau hasil yang dijamin. Cara terbaik memahaminya adalah sebagai model operasional untuk menemukan dan menghubungkan likuiditas yang dapat dieksekusi, lalu menghasilkan fill yang bisa lengkap atau parsial tergantung pada apa yang benar-benar tersedia pada saat itu.

Mekanisme: model sederhana

Cara yang berguna untuk membayangkan agregasi likuiditas adalah sebagai tiga langkah: input, konsolidasi, dan eksekusi.

Input: likuiditas dan niat order

Sumber likuiditas dapat mencakup bid dan offer dari banyak lawan transaksi dan venue yang menyediakan harga dan ukuran yang dapat diperdagangkan.
Niat order adalah permintaan trader atau sistem: arah (beli/jual), ukuran, waktu, dan setiap batasan (misalnya instruksi yang memengaruhi urgensi atau seberapa besar slippage yang dapat diterima).

Ketidakpastian penting: sumber yang berbeda mungkin mendefinisikan “tersedia” secara berbeda. Satu venue mungkin menampilkan kuotasi yang dapat diperbarui dengan cepat; venue lain mungkin menyediakan likuiditas yang hanya dapat dijangkau dalam kondisi tertentu.

Konsolidasi: mengumpulkan apa yang bisa dieksekusi Lapisan agregasi (sering kali bagian dari sistem eksekusi) secara berkelanjutan mengumpulkan informasi harga yang dapat dieksekusi dari sumber likuiditas yang terhubung. Ia dapat:

menormalkan format kuotasi (misalnya menyelaraskan cara harga dan ukuran direpresentasikan),
mempertahankan tampilan internal tentang sumber mana yang dapat dijangkau untuk instrumen yang diberikan, dan
memperkirakan biaya efektif untuk berinteraksi dengan setiap sumber, yang dapat mencakup spread dan biaya trading lainnya.

Langkah ini bersifat “mekanis,” tetapi tidak sepenuhnya deterministik. Tampilan internal dapat berubah saat kuotasi diperbarui, konektivitas berubah, atau ukuran yang tersedia terserap.

Eksekusi: mencocokkan dengan likuiditas yang tersedia Ketika sebuah order masuk, sistem melakukan routing atau pencocokan sesuai aturan yang dimilikinya, dengan tujuan mencapai niat order menggunakan satu atau lebih sumber. Hasilnya meliputi:

full fill pada satu sumber,
partial fill di beberapa sumber,
re-quoting atau penolakan jika likuiditas tidak lagi dapat diakses,
waktu fill yang berbeda jika keputusan routing bergantung pada kecepatan dan pembaruan.

Poin kunci: agregasi menghasilkan eksekusi, bukan janji. Bahkan jika opsi “terbaik” terlihat menguntungkan pada saat routing direncanakan, fill aktual bergantung pada apa yang tersisa tersedia ketika order mencapai setiap sumber.

Bukti dan contoh logika yang dikerjakan (asumsi dinyatakan)

Karena kita mengasumsikan tidak ada data pasar real-time, anggaplah sebuah snapshot hipotetis dengan asumsi yang eksplisit.

Asumsi untuk contoh

Anda menempatkan order untuk membeli 1.0 lot.
Sistem eksekusi dapat mengakses dua sumber likuiditas, A dan B.
Setiap sumber menyediakan harga bid/ask saat ini dan ukuran yang tersedia.
Harga dan ukuran dapat berubah selama routing (latency), tetapi kita akan menganalisis terlebih dahulu kasus “tanpa perubahan” lalu kasus “perubahan”.

Langkah 1: snapshot likuiditas yang dapat dieksekusi

Sumber A menawarkan 1.0 lot pada harga ask 1.1000.
Sumber B menawarkan 0.4 lot pada harga ask 1.0998.

Jika sistem mengurutkan sumber berdasarkan harga eksekusi efektif, ia mungkin lebih memilih B untuk 0.4 lot pertama, lalu merutekan sisa 0.6 lot ke A.

Langkah 2: kasus “tanpa perubahan” (diidealkan)

Rute 0.4 ke B pada 1.0998.
Rute 0.6 ke A pada 1.1000.
Hasil: sebuah fill lengkap, yang terdiri dari dua fill.

Langkah 3: kasus “likuiditas berubah selama routing” (ketidakpastian realistis) Sekarang anggap setelah sistem mengirim routing ke B, ukuran yang tersedia di B turun dari 0.4 lot menjadi 0.1 lot, atau ask bergerak.

Kemungkinan hasil

Partial fill di B (0.1 lot), lalu sisanya dirutekan ke A.
Sisa tersebut mungkin terisi pada harga efektif yang lebih buruk jika likuiditas yang dapat diakses A juga berubah.
Pada beberapa desain, sistem dapat membatalkan atau mencoba ulang routing tergantung instruksi order.

Logika ini mengilustrasikan perbedaan antara tampilan statis (apa yang dipikirkan agregasi sebagai tersedia) dan realitas dinamis (apa yang benar-benar tersedia ketika setiap leg dieksekusi).

Input dan output: apa yang bisa Anda periksa secara independen

Bahkan tanpa menyebut vendor tertentu, konsep ini dapat diverifikasi dengan melihat perilaku eksekusi yang teramati dan output sistem.

Input yang bisa Anda periksa

Instruksi order: ukuran, urgensi, dan apakah sistem akan membagi fill.
Feed likuiditas yang dapat diakses: berapa banyak sumber yang terhubung dan apakah kuotasi diperbarui dengan cepat.
Biaya: spread efektif dan biaya tambahan terkait eksekusi yang mengubah “harga” eksekusi sebenarnya.

Output yang bisa Anda amati

Komposisi fill: apakah satu order menjadi satu fill atau beberapa fill.
Waktu fill: apakah bagian-bagian order selesai pada waktu yang berbeda.
Penyimpangan dari harga yang diharapkan: apakah rata-rata harga eksekusi yang terealisasi sesuai dengan snapshot yang digunakan untuk routing.

Pemeriksaan ini tidak membuktikan desain tertentu, tetapi memungkinkan Anda menguji apakah “agregasi” berfungsi sebagai model eksekusi multi-sumber.

Keterbatasan dan mode kegagalan

Agregasi likuiditas membantu menemukan likuiditas yang dapat dieksekusi, tetapi beberapa keterbatasan penting.

Latency dan kuotasi yang sudah usang Jika kuotasi dan ukuran yang tersedia berubah dengan cepat, sistem eksekusi dapat merutekan berdasarkan informasi yang menjadi tidak akurat. Hasilnya bisa berupa harga eksekusi yang terealisasi lebih buruk atau partial fills yang tidak terduga.
Partial fills dan fragmentasi Meskipun sistem dapat mengakses beberapa sumber, membagi order dapat meningkatkan fragmentasi. Order dapat terisi di berbagai venue/provider dengan cara yang memengaruhi rata-rata harga dan timing yang terealisasi.
Ekspektasi yang tidak sesuai tentang harga “terbaik” “Terbaik” bergantung pada apa yang dioptimalkan oleh sistem (misalnya spread minimum, total biaya minimum, atau kecepatan). Jika kriteria optimasi berbeda dari yang Anda asumsikan, hasil yang terealisasi dapat berbeda dari ekspektasi Anda.
Perubahan konektivitas dan ketersediaan Akses likuiditas dapat dipengaruhi oleh konektivitas, kebijakan routing, atau ketersediaan sumber. Agregasi tidak dapat menggunakan likuiditas yang tidak dapat dijangkaunya.
Variasi yurisdiksi dan aturan eksekusi Perilaku trading dan eksekusi dapat berbeda di berbagai kerangka regulasi dan operasional. Ini memengaruhi bagaimana order ditangani dan perlindungan apa yang ada, sehingga verifikasi apa pun harus mencakup aturan lokal dan dokumentasi platform.

Verifikasi dan apa yang perlu ditanyakan selanjutnya

Untuk memverifikasi secara independen bagaimana agregasi likuiditas bekerja untuk pengaturan tertentu, fokus pada mekanisme eksekusi daripada istilah pemasaran.

Pertanyaan konkret

Apakah satu order sering terpecah menjadi beberapa fill? - Bagaimana perbandingan harga rata-rata eksekusi yang terealisasi dengan snapshot sebelum eksekusi yang Anda amati?