Skip to content
← All Skills
📡

FIX Protocol

Fintech / TradingOfficial Site ›

Financial Information eXchange — standard protocol สำหรับ electronic trading, order management, market data

What I Can Do

  • Implement FIX connectivity สำหรับ trading platforms เชื่อมต่อกับ exchanges
  • ออกแบบ order management flow ผ่าน FIX messages (NewOrderSingle, ExecutionReport)
  • Handle session management — logon, heartbeat, sequence number recovery
  • Parse และ construct FIX messages ทั้ง standard และ custom tags
  • Debug FIX sessions จาก log files วิเคราะห์ปัญหา connectivity

FIX Protocol Overview

FIX (Financial Information eXchange) เป็น standard protocol สำหรับ electronic trading — ใช้กันทั่วโลกในตลาดหุ้น, forex, crypto exchanges ข้อความเป็น tag=value format คั่นด้วย SOH delimiter (|)

text
8=FIX.4.4|9=148|35=D|49=SENDER|56=TARGET|34=2|52=20240115-10:30:00.000|
11=ORD001|21=1|55=BTC/USDT|54=1|60=20240115-10:30:00.000|38=1.5|40=2|44=42000|10=128|

Message Structure

ทุก FIX message มี 3 ส่วน:

  • Header — 8 (BeginString), 9 (BodyLength), 35 (MsgType), 49 (SenderCompID), 56 (TargetCompID), 34 (MsgSeqNum), 52 (SendingTime)
  • Body — fields เฉพาะของ message type นั้นๆ
  • Trailer — 10 (CheckSum) สำหรับ integrity check

Common Message Types (Tag 35)

Session-level:

  • A (Logon) — เริ่ม session, authenticate
  • 0 (Heartbeat) — keep-alive ทุก 30 วินาที
  • 1 (TestRequest) — เช็คว่าอีกฝั่งยังอยู่
  • 2 (ResendRequest) — ขอ messages ที่หายไป
  • 4 (SequenceReset) — reset sequence number
  • 5 (Logout) — ปิด session

Application-level:

  • D (NewOrderSingle) — ส่ง order ใหม่
  • F (OrderCancelRequest) — ขอยกเลิก order
  • G (OrderCancelReplaceRequest) — ขอแก้ไข order
  • 8 (ExecutionReport) — แจ้งผล order (fill, partial fill, reject)
  • 9 (OrderCancelReject) — แจ้งว่ายกเลิก/แก้ไขไม่ได้
  • W (MarketDataSnapshotFullRefresh) — market data snapshot
  • X (MarketDataIncrementalRefresh) — market data update

Session Management

FIX session ทำงานบน TCP — ต้อง manage connection lifecycle:

  1. Logon (A) — ส่ง credentials, ตกลง HeartBtInt (heartbeat interval)
  2. Heartbeat (0) — ส่งทุก interval เพื่อ keep connection alive
  3. TestRequest (1) — ส่งเมื่อไม่ได้รับ heartbeat ตาม interval
  4. Logout (5) — graceful disconnect

Session มี 2 roles: Initiator (client ที่เชื่อมต่อ) และ Acceptor (server ที่รับ connection)

Sequence Numbers

ทุก message มี MsgSeqNum (tag 34) — เพิ่มขึ้นทีละ 1 ต่อ direction, ใช้ detect message loss

  • ถ้าได้รับ sequence number สูงกว่าที่คาดไว้ → ส่ง ResendRequest (2) ขอ messages ที่หาย
  • ถ้าได้รับ sequence number ต่ำกว่าที่คาดไว้ → possible duplicate, ตรวจ PossDupFlag (tag 43)
  • Reset sequence numbers ด้วย SequenceReset (4) หรือตกลงกันว่า reset ตอน Logon

Order Flow

ส่ง Order

Client ส่ง NewOrderSingle (D) → Exchange ตอบ ExecutionReport (8)

Fields สำคัญใน NewOrderSingle:

  • 11 (ClOrdID) — unique order ID จาก client
  • 55 (Symbol) — instrument เช่น BTC/USDT
  • 54 (Side) — 1=Buy, 2=Sell
  • 38 (OrderQty) — จำนวน
  • 40 (OrdType) — 1=Market, 2=Limit
  • 44 (Price) — ราคา (สำหรับ Limit order)
  • 59 (TimeInForce) — 0=Day, 1=GTC, 3=IOC, 4=FOK

Execution Report

Exchange ตอบ ExecutionReport (8) บอกสถานะ order:

  • 150 (ExecType) — 0=New, 1=PartialFill, 2=Fill, 4=Canceled, 8=Rejected
  • 39 (OrdStatus) — สถานะปัจจุบันของ order
  • 14 (CumQty) — จำนวนที่ fill แล้ว
  • 151 (LeavesQty) — จำนวนที่ยังเหลือ
  • 31 (LastPx) — ราคาที่ fill ล่าสุด
  • 32 (LastQty) — จำนวนที่ fill ล่าสุด

Cancel / Replace

  • OrderCancelRequest (F) — ยกเลิก order ด้วย OrigClOrdID (tag 41) อ้าง order เดิม
  • OrderCancelReplaceRequest (G) — แก้ไข price/qty ของ order ที่ยังไม่ fill
  • ถ้า exchange ปฏิเสธจะตอบ OrderCancelReject (9) พร้อม CxlRejReason

Market Data

Snapshot (W)

Full refresh ของ order book — ได้ทั้ง bid/ask levels ใน message เดียว ใช้ตอนเริ่ม subscribe หรือ recovery

Incremental (X)

Update ทีละ entry — เร็วกว่า snapshot, ใช้สำหรับ real-time price feed, client ต้อง maintain local order book แล้ว apply updates

  • 268 (NoMDEntries) — จำนวน entries
  • 269 (MDEntryType) — 0=Bid, 1=Offer, 2=Trade
  • 270 (MDEntryPx) — ราคา
  • 271 (MDEntrySize) — จำนวน
  • 279 (MDUpdateAction) — 0=New, 1=Change, 2=Delete

FIX Engine Libraries

  • QuickFIX (C++/Java/Python/.NET) — open-source, mature, ใช้กันแพร่หลาย
  • QuickFIX/Go — Go port ของ QuickFIX
  • QuickFIX/J — Java version
  • Custom implementation — สำหรับ low-latency ที่ต้องควบคุมทุก layer

FIX Versions

  • FIX 4.2 — ยังใช้กันเยอะ, stable
  • FIX 4.4 — เพิ่ม features สำหรับ multi-leg orders, allocations
  • FIX 5.0 + FIXT 1.1 — แยก transport layer ออกจาก application layer
  • ส่วนใหญ่ exchanges รองรับ FIX 4.2 หรือ 4.4 — ตรวจ spec ของแต่ละ exchange

Custom Tags

Exchanges มักเพิ่ม custom tags (5000+) สำหรับ features เฉพาะ — เช่น custom order types, fee tiers, account identifiers ต้องอ่าน spec ของแต่ละ exchange เพื่อ implement ให้ถูก

Logging & Monitoring

  • Log ทุก FIX message ทั้ง incoming/outgoing พร้อม timestamp
  • Monitor sequence number gaps — สัญญาณว่ามี message loss
  • Track heartbeat intervals — ถ้าขาดหาย connection อาจมีปัญหา
  • Alert เมื่อ session disconnect หรือ logon fail
  • เก็บ FIX logs แยกจาก application logs — ใช้ debug trading issues

ปัญหาที่เจอบ่อย & วิธีแก้

Sequence number mismatch — session เชื่อมต่อไม่ได้

Logon ไม่สำเร็จเพราะ sequence number ไม่ตรงกันระหว่าง client กับ server

สาเหตุ: restart application แล้ว sequence number reset เป็น 1 แต่อีกฝั่งยังจำ sequence เดิม, หรือ recovery หลัง crash ไม่ถูกต้อง

วิธีแก้:

  • persist sequence numbers ลง disk/database — ไม่ใช่เก็บแค่ใน memory
  • ใช้ ResetOnLogon=Y ถ้าทั้งสองฝั่งตกลง reset sequence ทุกครั้งที่ logon
  • ส่ง SequenceReset-GapFill (4) เพื่อ skip ช่วงที่หายไป
  • ติดต่อ exchange support ขอ reset sequence ถ้า mismatch รุนแรง

Message rejected — tag missing หรือ invalid value

Exchange ตอบ Reject (3) หรือ BusinessMessageReject (j)

สาเหตุ: ส่ง message ที่ขาด required tags, ค่า tag ไม่ตรงกับที่ exchange กำหนด (เช่น OrdType ที่ไม่รองรับ), หรือ message format ผิด

วิธีแก้:

  • อ่าน Text (tag 58) และ RefTagID (tag 371) ใน reject message — บอกว่า tag ไหนมีปัญหา
  • ตรวจ FIX spec ของ exchange ให้ครบ — แต่ละ exchange มี required fields ต่างกัน
  • ใช้ FIX message validator ตรวจ message ก่อนส่ง
  • Log ทุก rejected message พร้อม reason เพื่อ debug

Heartbeat timeout — connection drop บ่อย

Session disconnect ทุกไม่กี่นาที

สาเหตุ: network latency สูงทำให้ heartbeat ไปไม่ทัน, HeartBtInt ตั้งสั้นเกินไป, firewall/NAT timeout ตัด idle TCP connections

วิธีแก้:

  • เพิ่ม HeartBtInt (เช่น 30 → 60 วินาที) ถ้า network ไม่เสถียร
  • ตรวจ firewall/load balancer timeout — ต้องยาวกว่า HeartBtInt
  • ใช้ TCP keepalive ที่ OS level ป้องกัน NAT timeout
  • implement reconnection logic — auto reconnect เมื่อ session drop พร้อม sequence recovery

Order stuck — ส่งแล้วไม่ได้ ExecutionReport กลับ

ส่ง NewOrderSingle แล้วไม่มี response กลับมา

สาเหตุ: message ส่งไปแล้วแต่ sequence number ไม่ตรงทำให้อีกฝั่งไม่ process, network issue ทำให้ message ไม่ถึง, หรือ exchange queue เต็ม

วิธีแก้:

  • implement timeout สำหรับทุก order — ถ้าไม่ได้ ExecutionReport ภายใน X วินาที ให้ alert
  • ส่ง OrderStatusRequest (H) ถามสถานะ order ตรงๆ
  • ตรวจ FIX log ว่า message ถูกส่งจริงหรือไม่ (outgoing log)
  • มี manual intervention workflow สำหรับ stuck orders — สำคัญมากใน production trading

Duplicate orders — ส่ง order ซ้ำโดยไม่ตั้งใจ

Order เดียวกันถูกส่งหลายครั้ง ทำให้ position ผิด

สาเหตุ: retry logic ส่ง NewOrderSingle ซ้ำเมื่อไม่ได้ response, reconnect แล้ว resend messages ที่ส่งไปแล้ว, PossDupFlag ไม่ถูก set

วิธีแก้:

  • ใช้ unique ClOrdID (tag 11) ทุก order — exchange จะ reject ถ้า duplicate
  • set PossDupFlag (tag 43) = Y เมื่อ resend messages หลัง recovery
  • อย่า retry NewOrderSingle ตรงๆ — ส่ง OrderStatusRequest ก่อนเพื่อตรวจว่า order แรกถึงหรือไม่
  • มี reconciliation process ตรวจ orders ระหว่าง local state กับ exchange

Market data gap — order book ไม่ตรง

Local order book ไม่ตรงกับ exchange จริง

สาเหตุ: miss incremental updates (X) ระหว่าง network issue, ไม่ handle MDUpdateAction Delete ทำให้ stale entries ค้าง, sequence gap ใน market data stream

วิธีแก้:

  • detect gaps จาก sequence numbers — ถ้าพบ gap ให้ request full snapshot (W) ใหม่
  • periodic snapshot reconciliation — ขอ full snapshot ทุก X นาทีเทียบกับ local state
  • implement circuit breaker — หยุด trade ถ้า order book data ไม่ reliable
  • log ทุก market data update เพื่อ replay และ debug

Related Skills

  • Go — ภาษาที่ใช้ implement FIX connectivity
  • Gin — web framework สำหรับ trading platform API
  • Kafka — event streaming สำหรับ order/trade events
  • Redis — caching สำหรับ market data และ session state
  • REST API Design — API design สำหรับ trading platform endpoints