Cara kerja protokol FIX Maret 7, 2022 – Posted in: Forex trading

Pendahuluan

Sejarah perdagangan di pasar saham telah berubah secara dramatis sejak awal kemunculannya. Bursa saham pertama muncul sekitar empat ratus tahun yang lalu. Saat itu, transaksi dilakukan secara lisan, dan aturan perdagangan baru mulai terbentuk. Namun dunia tidak berhenti, dan seiring perkembangan zaman, bursa saham mengadopsi setiap alat teknis yang tersedia pada masanya.

Maka, pada pertengahan abad ke-19, order perdagangan dari lokasi yang jauh dari bursa dikirim melalui jalur telegraf. Kemudian telepon menggantikannya. Dan akhirnya tiba saatnya ketika permintaan trading pertama dari para trader dikirim melalui jaringan Internet.

Sejujurnya, trading melalui telepon terkadang masih terjadi di zaman modern pada beberapa broker. Dan bagi sebagian dari mereka, itu adalah satu-satunya cara yang terjamin untuk melakukan transaksi. Selain itu, sejak awal berdirinya bursa pertama hingga awal abad ke-21, transaksi langsung di lantai bursa dilakukan secara lisan. Lantai perdagangan seperti itu disebut stock pit dan merupakan pemandangan yang kita kenal dari film-film Hollywood bertema serupa.

Sejarah protokol FIX

Salah satu protokol trading digital tertua adalah protokol FIX. Singkatan dari “Financial Information Protocol” atau “FInancial eXchange protocol”, dan kedua definisi tersebut dapat ditemukan. Spesifikasi Protokol FIX dibuat pada 1992 untuk menyediakan informasi tentang perdagangan saham antara Fidelity Investments dan Salomon Brothers. Broker dan dana investasi ingin mempercepat proses perdagangan di bursa. Hasilnya adalah standar terbuka untuk mengirimkan informasi secara elektronik yang tidak dikendalikan oleh organisasi besar mana pun. Saat ini, FIX telah menjadi standar industri yang digunakan oleh pelaku pasar keuangan di berbagai negara untuk menghubungkan produk mereka.

Awalnya, protokol komunikasi ini hanya digunakan antara dua perusahaan yang disebutkan di atas, disebut SBX (Salomon Brothers Exchange), dan hanya digunakan untuk perdagangan saham. Kemudian, menurut ceritanya, para pemimpin perusahaan-perusahaan ini, menyadari pentingnya penemuan mereka, mengajak Goldman Sachs dan Putman untuk bergabung dalam pengembangannya. Sejak itu protokol ini mendapatkan namanya yang sekarang.

Awalnya, protokol ini hanya mendukung 17 jenis pesan dan 103 tag. Idenya begitu sukses sehingga pada 1995, lebih dari 70% dari seluruh perusahaan pialang di AS menggunakan protokol ini. Hal ini karena penghematan biaya, biaya yang lebih rendah, dan berkurangnya kesalahan trading. Bagaimanapun, faktor manusia sangat berpengaruh ketika trading melalui telepon. Seiring waktu, protokol ini berkembang secara signifikan. Dukungan untuk perdagangan derivatif, obligasi, dan mata uang ditambahkan. Spesifikasi FIX saat ini menjelaskan 168 pesan, 7,868 tag, dan mencakup semua kelas sekuritas. Pada 1998, pengembangan protokol FIX dan spesifikasinya, serta pengembangan teknologi terkait, dialihkan ke konsorsium FIX Protocol Ltd. Konsorsium ini kemudian berganti nama menjadi FIX Trading Community. Lebih dari 270 institusi keuangan terkemuka kini menjadi anggota organisasi tersebut.

Cara kerja protokol FIX

Protokol FIX berjalan di atas TCP. Saat ini, model protokol FIX didefinisikan pada dua tingkat – tingkat sesi atau kontrol (pembuatan sesi, pengiriman data), dan tingkat aplikasi (deskripsi isi data). Lapisan kontrol bertanggung jawab atas parameter dasar sesi FIX: membuka dan menutup koneksi, memulihkan pesan yang hilang. Lapisan aplikasi mengatur pengiriman dan penerimaan data: permintaan, eksekusi, penolakan, data pasar, dan permintaan informasi status. Protokol itu sendiri berbasis teks, yaitu menggunakan karakter dari tabel ASCII. Protokol ini dibagi menjadi 2 representasi – tradisional, dalam bentuk Tag=Value (Tag=Value atau Key=Value), dan representasi XML (FIXML). Versi terbaru saat ini adalah 5.0, tetapi yang paling umum adalah versi 4.2 dan 4.4. Broker dan bursa yang berbeda dapat menggunakan versi protokol yang berbeda, dan terkadang beberapa versi sekaligus.

Sintaks Tag=Value

Pesannya kurang lebih seperti berikut:

8=FIX.4.2 | 9=178 | 35=D | 34=1234567 | 49=TESTER | 56=PHLX | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 54=1 | 167=FUT | 55=MSFT | 38=15 | 40=2 | 44=15 | 59=0 | 10=128 |

Ini adalah string teks yang terdiri dari beberapa bagian yang dipisahkan oleh garis vertikal. Bagian-bagian ini disebut field. Selanjutnya, setiap bagian terdiri dari pasangan key-value yang dipisahkan oleh tanda sama dengan. Di sebelah kiri tanda adalah key, di sebelah kanan adalah value. Dalam spesifikasi FIX, key disebut tag. Tag selalu berupa bilangan bulat positif yang pada dasarnya merupakan penunjuk ke nama field. Semua nama field dan nilai-nilai yang mungkin dijelaskan dalam dokumentasi bursa tertentu. Sebagian besar field ini bersifat standar dan dapat ditemukan dalam spesifikasi bursa mana pun. Ada juga field kustom, yang didefinisikan dan hanya bermakna di bursa tertentu. Jika deskripsi field standar dapat ditemukan dalam spesifikasi umum protokol FIX, field kustom harus dijelaskan dalam spesifikasi protokol FIX bursa tersebut. Ada juga field wajib, opsional, dan wajib bersyarat (wajib tergantung pada keberadaan field lain tertentu dalam pesan). Simbol SoH (Start of Header) digunakan sebagai pemisah antar field. Simbol ini sebenarnya tidak terlihat, sehingga dalam contoh ini diganti dengan garis vertikal. Dalam pengodean UNICODE, karakter ini memiliki kode “\u0001”.

Selanjutnya, selain terbagi menjadi field, pesan juga terdiri dari 3 komponen lagi:

Header (Header Pesan)
Body (Isi Pesan)
Trailer Pesan (checksum)

Pada FIXT.1.1/FIX 5.0, header berisi 5 field wajib dan satu field opsional: 8 (BeginString), 9 (BodyLength), 35 (MsgType), 49 (SenderCompID), 56 (TargetCompID), dan 1128 (ApplVerID – jika ada, harus berada di posisi ke-6). Ada dua kelompok utama pesan – administratif dan aplikasi. Pesan administratif menangani dasar-dasar sesi FIX. Pesan ini memungkinkan Anda memulai dan mengakhiri sesi, serta memulihkan pesan yang terlewat. Pesan aplikasi berkaitan dengan pengiriman dan penerimaan informasi terkait trading, seperti permintaan order atau informasi tentang status terkini dan eksekusi order tersebut selanjutnya.

Kita akan menganalisis pesan ini:

8=FIX.4.2 – BeginString. Versi protokol yang digunakan. Memberi tahu program trader aturan mana yang harus diterapkan untuk mengurai field pesan ini.
9=178 – BodyLength. Panjang isi pesan adalah 178 byte, termasuk header. Dihitung sebagai jumlah karakter dari tag 35 (inklusif) hingga tag 10 (eksklusif). Pemisah SoH juga ikut dihitung.
35=D – MsgType. Jenis pesan. Dalam hal ini, D berarti menempatkan permintaan trading. Misalnya, field 35=V menunjukkan bahwa data pasar diperoleh untuk instrumen tersebut.
34=1234567 – MsgSeqNum. Nomor pesan. Jika MsgSeqNum pesan dalam urutan yang dikirim tidak berselisih 1, server akan mengembalikan error dan tidak memproses pesan tersebut.
49=TESTER – SenderCompID. ID pengirim. Diterbitkan oleh bursa. Ini dapat berupa nama pengguna, atau nama broker jika pesan dikirim oleh broker.
56=PHLX – TargetCompID. ID penerima tujuan pengiriman. Juga diterbitkan oleh bursa.
52=20071123-05:30:00.000 – SendingTime. Tanggal dan waktu pesan dikirim.
11=ATOMNOCCC9990900 – ClOrdID. Nomor order dalam sistem trading broker.
54=1 – Side. Tindakan pembelian aset
167=FUT – SecurityType. Asetnya adalah futures
55=MSFT – Symbol. Saham Microsoft. Ticker dapat berbeda dari satu bursa ke bursa lainnya.
38=15 – OrderQty. Volume transaksi adalah 15 lot atau kontrak.
40=2 – OrdType. Pembelian dengan harga terbatas, Limit Order.
44=15 – Price. Harga pembelian – 15
59=0 – TimeInForce. Batas waktu order adalah akhir hari kerja.
10=128 – CheckSum. Checksum pesan. Selalu menjadi field terakhir dalam pesan. Dihitung menggunakan rumus khusus yang dijelaskan dalam spesifikasi protokol. Nilainya ditetapkan dengan menjumlahkan nilai ASCII semua karakter dalam pesan kecuali karakter field checksum. Nilai tersebut kemudian dibagi 256 dan sisa pembagiannya diambil. Checksum harus selalu terdiri dari tiga karakter. Jadi, jika hasil modulusnya 22, maka angka nol ditambahkan di depannya – “022”.

Jika dijelaskan secara umum, pesan ini adalah tindakan untuk membeli futures saham Microsoft sebanyak 15 kontrak pada harga batas 15, dengan masa berlaku hingga akhir hari.

Untuk memberikan fleksibilitas lebih pada FIX, protokol ini memuat apa yang dikenal sebagai field yang ditentukan pengguna, User Defined Fields. Field ini digunakan untuk transfer data antar organisasi keuangan yang bekerja sama. Nomor tag dari 5000 hingga 9999 dicadangkan untuk field kustom, yang dapat dipesan di situs web resmi standar tersebut. Nomor-nomor ini kemudian habis digunakan, sehingga dialokasikan interval baru, dari 20,000 hingga 39,999.

Sintaks FIXML

Pengerjaan sintaks ini dimulai pada 1998, dan versi pertamanya dirilis pada 1999. Secara semantik setara dengan pesan yang dikodekan dengan tag, tetapi menggunakan teknologi parsing XML. Order baru untuk operasi dalam format FIXML adalah sebagai berikut:

<FIXML>

<Order ClOrdID=”123456″ Side=”2″ TransactTm=”2001-09-11T09:30:47-05:00″ OrderTyp=”2″ Px=”93.25″

Acct=”26522154″>

</Order>

</FIXML>

Dalam format XML, blok kode tertentu dibingkai dalam apa yang disebut tag (tag lain, bukan yang digunakan oleh protokol itu sendiri). Misalnya, ada tag tingkat atas <FIXML>. Setiap tag membuka potongan kode atau pesan tertentu dan menutupnya dengan tag yang sama, tetapi di bagian dalam tepi kirinya terdapat karakter garis miring. Dengan demikian, tag yang disebutkan akan menutup blok sebagai berikut: </FIXML>.

Selanjutnya, di dalam tag ini, kita melihat tag berikut:

<Order ClOrdID=”123456″ Side=”2″ TransactTm=”2001-09-11T09:30:47-05:00″ OrderTyp=”2″ Px=”93.25″

Acct=”26522154″>.

Di sini kita melihat nama tag – Order, dan di dalam kurung terdapat informasi tambahan (field yang sama, pasangan key=value seperti pada sintaks Tag=Value).

Dalam hal ini:

ClOrdID=”123456″ – id order dalam sistem trading broker

Side=”2″ – Order Jual

TransactTm=”2001-09-11T09:30:47-05:00″ tanggal dan waktu transaksi

OrdTyp=”2″ – Jenis Order – Limit Order

Px=”93.25″ – Harga aset untuk dibeli atau dijual

Acct=”26522154″ – nomor akun pengguna

Seperti tag XML sebelumnya, tag XML ini ditutup dengan garis miring – </Order>

Konten di antara tag XML pembuka dan penutup disebut body tag. Dengan demikian, tag Order adalah body dari tag FIXML. Di dalam tag Order sebagai body, terdapat dua tag lagi: Instrmt dan OrdQty.

Tag berikutnya:

Di sini kita dapat melihat bahwa tag ini sekaligus membuka dan menutup, di ujungnya terdapat garis miring. Ini terjadi jika tag tidak memiliki body, sehingga tidak ada gunanya membuat tag pembingkai terpisah. Tag ini berisi informasi tentang ticker instrumen, id-nya, dan sebagainya.

Pada tag <OrdQty Qty=”1000″/> kita dapat melihat informasi tentang volume transaksi, dan ini juga merupakan tag penutup tanpa body.

FIXML biasanya digunakan untuk aplikasi back-office dan kliring, bukan untuk trading.

Lapisan sesi FIX

Contoh-contoh sebelumnya menjelaskan lapisan aplikasi. Spesifikasi mendefinisikan jenis field khusus yang bertanggung jawab atas tingkat sesi antara klien dan bursa:

35=A – Logon. Digunakan untuk mengautentikasi pengguna ke sistem bursa saat terhubung. Pesan ini dikirim pertama kali, dan memberi sinyal kepada bursa tentang dimulainya sesi data. Pesan balasan diterima jika pengiriman berhasil. Jika koneksi gagal, error akan dikembalikan.
35=5 – Logout. Pesan ini digunakan untuk melepas otorisasi dari server dan menutup sesi trading dengan bursa.
35=0 – Heartbeat. Detak jantung, atau denyut. Pesan ini dikirim dari kedua sisi koneksi satu sama lain dan menunjukkan bahwa kedua sisi siap menerima dan mengirim pesan. Frekuensi heartbeat ditetapkan dalam pesan Logon pertama.
35=1 – Test Request. Pesan ini adalah pesan uji dan dikirim ketika pihak lawan tidak mengirimkan pesan heartbeat dalam periode yang ditentukan. Sesi akan ditutup jika pesan ini tetap tidak dijawab.
35=2 – Resend Request. Pesan ini adalah permintaan untuk mengirim ulang pesan jika ada informasi yang terlewat.
35=3 – Reject, atau penolakan. Dikirim oleh pihak lawan jika pesan sebelumnya salah format atau tidak dapat dieksekusi.
35=4 – Sequence Reset, atau reset urutan pengiriman pesan. Pesan ini dapat memiliki dua bentuk.

– 123=”Y” – Terdapat tag GapFillFlag dengan nilai yang ditentukan. Menunjukkan permintaan untuk mengabaikan pesan administratif jika pesan tersebut dikirim ulang.

– digunakan untuk mengembalikan penghitung MsgSeqNum ke nol

Penerapan FAST sebagai Penyempurnaan FIX API

Data FIX dalam jumlah besar mengalami penundaan pemrosesan yang signifikan, sehingga menyulitkan trader untuk mengembangkan strategi trading yang efektif. Tak lama setelah masalah tersebut disadari, langkah-langkah pertama untuk memperbaiki situasi pun diambil. Tujuan protokol FAST adalah memungkinkan transmisi data dalam jumlah besar tanpa penundaan dalam memperoleh informasi. FAST (FIX Adapted for STreaming, yang berarti FIX yang disesuaikan untuk streaming) adalah standar teknologi yang dikembangkan oleh FIX Protocol Ltd. yang dirancang khusus untuk mengoptimalkan representasi data di jaringan. Pada dasarnya ini adalah format biner dari protokol FIX dan memungkinkan transfer informasi dalam jumlah besar tentang transaksi dan kondisi pasar dalam bentuk yang ringkas. Hal ini memungkinkan penggunaannya dalam sistem trading berkecepatan tinggi yang memerlukan penundaan transmisi rendah. Fast dikembangkan di California Institute of Technology di Pasadena. Saat ini, versi terbaru adalah FAST 1.2. Penerapan yang paling umum – koneksi langsung ke bursa, melewati sistem trading broker. Protokol FAST adalah protokol distribusi informasi pasar yang terstandardisasi dan paling populer di dunia. Sebelumnya, seluruh lalu lintas Internet didasarkan pada sistem Transmission Control Protocol (TCP), yang dikembangkan pada tahun tujuh puluhan abad lalu. TCP adalah koneksi socket yang memerlukan konfirmasi pengiriman paket. TCP memecah file dan pesan besar menjadi paket berukuran 1500 byte, masing-masing berisi alamat sumber dan tujuan paket. Pengirim menunggu konfirmasi bahwa paket yang dikirim berhasil diterima, dan baru kemudian mengirim paket berikutnya. Jika pengiriman gagal atau sinyal pengiriman tidak tiba dalam batas waktu yang ditentukan, paket dikirim ulang, tetapi dengan kecepatan yang lebih rendah. Dan hal ini dapat berlangsung selama apa pun, dengan kecepatan yang turun secara eksponensial, hingga sinyal bahwa pengiriman berhasil diterima. Menjadi jelas bahwa masalah kecil pada jalur pun dapat sangat memengaruhi kecepatan data, karena setiap pengiriman yang gagal berarti kehilangan milidetik yang berharga. Oleh karena itu, FAST memperkenalkan solusi alternatif – sistem terus memantau paket dan pesan yang diterima untuk memastikan pengiriman yang baik guna mendeteksi masalah pada jalur dengan segera dan menetapkan pengiriman berikutnya pada kecepatan yang stabil, meskipun sedikit berkurang. Pendekatan ini menghilangkan kebutuhan untuk mengirim ulang paket dalam sebagian besar kasus, karena tidak perlu waktu untuk menguji kinerja yang lambat. Di beberapa bursa, antarmuka koneksi diimplementasikan melalui dua jenis koneksi: UDP dan TCP. Mengirim semua data melalui socket UDP tidak masuk akal, karena koneksi semacam itu tidak memerlukan konfirmasi pengiriman, dan paket dapat hilang begitu saja tanpa diketahui oleh kedua pihak. Oleh karena itu, sebagian besar data dikirim melalui socket UDP, dan hanya kumpulan data yang tidak terkirim yang dikirim melalui TCP. Di pasar yang bergerak cepat, penundaan akibat transmisi ulang sering kali tidak diinginkan, karena menyebabkan hilangnya peluang atau transaksi yang buruk.

Cara kerja FAST

Seperti yang sudah kita ketahui, protokol FIX adalah rangkaian field yang masing-masing terdiri dari pasangan key=value. Selain format string yang pada dasarnya redundan, Anda mungkin memperhatikan bahwa setiap pesan memiliki elemen yang berulang, seperti nama field dan karakter “=”. FAST menghilangkan redundansi dengan menggunakan template yang menjelaskan seluruh struktur pesan. Metode ini disebut implicit tagging. Karena tag FIX dalam data yang dikirim hanya “tersirat”, sintaks Tag = Value berubah sebagai berikut:

Template menjelaskan kumpulan field yang terstruktur beserta operatornya;
Urutan field dalam pesan sesuai dengan urutan tag dalam template;
Hanya perubahan data yang dikirim dalam pesan.

Setiap nilai tag memiliki panjang tetap dalam byte. Dengan mengetahui panjang field tertentu dan urutan penempatan field dalam pesan, tidak sulit untuk mengidentifikasi nilai field tersebut dalam pesan. Oleh karena itu, template memungkinkan hanya data itu sendiri yang dikirim secara langsung, tanpa perlu mentransfer karakter yang redundan. Pengodean ini disebut simple binary encoding, atau SBE. Dengan demikian, pengodean dan dekode pesan memiliki latensi yang jauh lebih rendah daripada protokol berbasis karakter, karena data tidak perlu diterjemahkan ke dalam format yang dapat digunakan komputer. Karena field yang bersangkutan berada pada posisi tetap dalam pesan, jauh lebih mudah mengakses nilai yang diinginkan. Anda hanya perlu mengetahui offset-nya relatif terhadap awal pesan, dan panjang nilainya. Tidak seperti format tag dan FIXML, pesan SBE tidak mendeskripsikan dirinya sendiri. Hanya data dengan header minimal yang dikirim melalui jaringan untuk mengidentifikasi template yang mengatur pesan tersebut. Metadata (template) yang menjelaskan struktur pesan dipertukarkan di luar saluran komunikasi utama. Setelah menerima template yang diperlukan, server trading mengetahui format pengiriman data kepada klien dalam kerangka sesi yang terhubung tersebut. Dengan demikian, sebelum mentransfer data, sistem-sistem tersebut terlebih dahulu menyepakati cara berkomunikasi satu sama lain ke depannya. Skema pesan biasanya dikirim dalam format XML. Skema ini dapat berisi sejumlah template pesan. Template menjelaskan field yang menyusun pesan. Selain itu, skema menyediakan daftar tipe data sederhana dan kompleks yang dapat digunakan kembali di sejumlah field.

Implementasi terbuka untuk berbagai bahasa untuk protokol FIX

Java – QuickFIX/J – http://www.quickfixj.org/

.NET/C# – QuickFIX/N – http://quickfixn.org/

Parser online gratis untuk pesan FIX – FIX Parser – https://fix.aprics.net/

Implementasi Bahasa Terbuka untuk FAST

Untuk C – Implementasi referensi dari FPL – www.fixprotocol.org/fastdownload

Untuk C# – Implementasi referensi dari FPL – www.fixprotocol.org/fastdownload

Untuk Java – OpenFAST – www.openfast.org

www.sourceforge.net/projects/openfastdotnet/

Untuk C++ – QuickFAST – www.quickfast.org

Untuk Golang – goFAST – www.github.com/co11ter/goFAST

Pengodean Lain untuk Protokol FIX

Komunitas FIX juga mengembangkan pemetaan standar antara protokol FIX dan protokol serialisasi data lainnya seperti:

JSON
Google (Protocol buffers)

|ASN.1

Area Penerapan Protokol FIX/FAST

Biasanya, singkatan ini muncul bersamaan sebagai dua kata. Digunakan untuk memperoleh berbagai informasi keuangan dari bursa: tabel instrumen keuangan (harga, volume, dan lain-lain), kuotasi, semua transaksi, indeks, serta informasi tentang semua order anonim. Kumpulan data yang diperoleh dapat berbeda tergantung pada bursa. Pengguna utama FIX/FAST adalah:

Trader perorangan untuk trading [Trading Forex dengan FIX API]
Programmer yang membuat produk berdasarkan teknologi ini. Seperti – platform trading FIX API, konektor ke berbagai bursa, sistem trading, sistem pengumpulan data, dan statistik.
Pertukaran informasi antar bursa
Memperoleh data paling mutakhir untuk berbagai kantor berita

Penggunaan yang paling umum adalah oleh trader frekuensi tinggi untuk memperoleh keunggulan atas pemain pasar lainnya melalui Direct Market Access (DMA). Protokol ini dapat diintegrasikan ke dalam ekosistem trading oleh bursa saham, bank, dan broker forex. Bursa mata uang kripto, menurut data yang umum diketahui, tidak menggunakan teknologi ini. Secara historis, bursa-bursa ini sebagian besar menggunakan koneksi WebSocket untuk memperoleh informasi pasar dan koneksi HTTP REST API untuk melakukan operasi trading guna menyediakan koneksi langsung ke server trading para trader. Jika teknologi WebSocket masih sebanding kecepatannya dengan koneksi TCP, maka HTTP REST API jauh tertinggal. Pelajari tentang SharpTrader Easy FIX API