การแก้ไข futures order ทำให้เสีย queue priority หรือไม่?
เรียนรู้ว่าเหตุใดการเปลี่ยน futures order จึงอาจมีผลต่อ queue priority เหตุใดการแก้ราคาและจำนวนจึงไม่ได้ถูกปฏิบัติเหมือนกันเสมอ และวิธีตรวจสอบ priority หลัง cancel-replace
คำตอบโดยตรง
การแก้ไข futures order อาจเปลี่ยน queue priority แต่ผลลัพธ์ขึ้นอยู่กับสิ่งที่แก้และกฎของ venue อย่าสมมติว่าการเปลี่ยนราคาหรือจำนวนจะรักษา timestamp เดิม หรือส่งคำสั่งทั้งรายการไปอยู่ท้ายคิว
Queue priority เป็นของสถานะคำสั่งปัจจุบัน
Limit order ที่ resting อยู่จะแข่งขันกับคำสั่งอื่นที่มีสิทธิ์ในราคาเดียวกัน
ในตลาดแบบ price-time คำสั่งที่มีสิทธิ์และมาก่อนอาจมี priority เหนือคำสั่งที่มาทีหลัง
ผลิตภัณฑ์อื่นอาจใช้วิธี allocation ที่นอกเหนือจาก FIFO ล้วน ๆ
เมื่อคุณแก้คำสั่ง venue จะเป็นผู้กำหนดว่าคำสั่งที่เปลี่ยนแล้วได้รับ priority อย่างไร
เอกสารการรับรองของ CME ทดสอบ cancel-replace messages ที่มีและไม่มีการเปลี่ยน priority โดยเฉพาะ
ดังนั้นผลกระทบที่แน่นอนต้องอ้างอิงกฎปัจจุบันของผลิตภัณฑ์และ order entry
การเปลี่ยนราคาเป็นมากกว่าความสะดวกในการแก้ไข
สมมติว่าคุณมี buy limit resting อยู่ที่ 5,000.00
คุณเปลี่ยนเป็น 5,000.25
ขณะนี้คำสั่งกำลังแข่งขันที่ระดับราคาอื่น
คุณไม่ควรคิดว่าตำแหน่งในคิวเดิมที่ 5,000.00 จะเลื่อนตามคำสั่งไปเฉย ๆ
ระดับราคาใหม่อาจมีคำสั่งเดิมและลำดับ allocation ของตัวเอง
บันทึก acknowledgement ของการแก้ไขและสถานะคำสั่งใหม่
การเปลี่ยนจำนวนอาจได้รับการปฏิบัติต่างจากการเปลี่ยนราคา
การเปลี่ยนจำนวนไม่ได้มีผลต่อ priority เหมือนการเปลี่ยนราคาเสมอไป
Workflow ของบาง venue แยกการลดจำนวน การเพิ่มจำนวน และการแก้ราคาออกจากกัน
การทดสอบรับรองของ CME ตรวจสอบ quantity-only changes และ price changes ว่าอาจมีผลต่อ priority หรือไม่โดยเฉพาะ
ด้วยเหตุนี้ กฎสากลอย่าง “การเปลี่ยน size ไม่เคยทำให้เสีย priority” จึงไม่ปลอดภัย
ใช้เอกสารด้านเทคนิคและเอกสารผลิตภัณฑ์ปัจจุบันของ venue
ตัวอย่างคำนวณคิวก่อนและหลังการเปลี่ยน
สมมติเป็นตัวอย่างแบบ FIFO ที่ 5,000.00
คำสั่งของคุณจำนวน 3 contracts มี 12 contracts อยู่ข้างหน้า
ก่อนแก้ไข อย่างน้อย 12 contracts เหล่านั้นต้องได้รับการจัดสรรก่อนจึงจะถึงตำแหน่งของคุณในคิว
ทีนี้สมมติว่าคุณแก้คำสั่งในลักษณะที่ทำให้เสีย priority
หากหลังการส่งกลับเข้าไปใหม่มี 25 contracts resting อยู่ข้างหน้าคำสั่งที่แก้แล้ว ตำแหน่งคิวในทางปฏิบัติของคุณก็เปลี่ยนไปอย่างมีนัยสำคัญ
ตัวเลขเป็นเพียงสมมติฐาน
ประเด็นคือการแก้ไขอาจเปลี่ยนปริมาณสภาพคล่องที่ต้องเทรดก่อนคำสั่งของคุณจะได้รับ allocation
ข้อมูล order book ช่วยได้ แต่ไม่ใช่บันทึกคำสั่งสุดท้าย
CME Market by Order อาจเปิดเผยคำสั่งรายรายการแบบไม่ระบุตัวตนและข้อมูลคิว
หน้าจอของโบรกเกอร์อาจแสดงรายละเอียดน้อยกว่า
แม้มี market data โดยละเอียด คุณก็ยังต้องใช้ acknowledgement ของการแก้ไขและ order ID หรือ identifiers ปัจจุบัน
การประเมินจากหน้าจอไม่สามารถพิสูจน์ได้ว่า cancel-replace รายการหนึ่งรักษา priority ไว้หรือไม่
เหตุใด futures limit order จึงแตะราคาแต่ไม่ fill อธิบายว่าเหตุใดตำแหน่งในคิวจึงสำคัญ
Partial fills ทำให้ต้องติดตามการแก้ไขอย่างละเอียดขึ้น
สมมติว่า 2 จาก 5 contracts fill ไปแล้ว
จึงเหลือเพียง 3 contracts ที่ยังทำงานอยู่
หากคุณแก้คำสั่งต่อจากนั้น ให้แยก position 2 contracts ที่เสร็จแล้วออกจาก leaves quantity จำนวน 3
อย่าปฏิบัติต่อ 5 contracts เดิมเสมือนว่ายังรออยู่ทั้งหมด
การแก้ไขใช้กับส่วนที่ยัง live ตาม workflow ของคำสั่งจริง
เหตุใด futures orders จึง fill หลายราคา อธิบายการแยก filled quantity ออกจาก leaves quantity [!TRYMARK] สร้าง cancel-replace ขึ้นใหม่ เริ่มจาก buy limit จำนวน 3 contracts ที่มี 12 contracts อยู่ข้างหน้า เปลี่ยนจำนวน แล้วเปลี่ยนราคา สำหรับการเปลี่ยนแต่ละครั้ง ให้บันทึก acknowledgement, ราคาปัจจุบัน, leaves quantity และระบุว่า priority ถูกเก็บไว้หรือไม่
ใช้ checklist สำหรับการแก้ไข
บันทึกผลิตภัณฑ์ที่แน่นอนและเดือนของสัญญา
บันทึก order ID, ราคา, จำนวน และ timestamp เดิม
บันทึก field ที่กำลังเปลี่ยน
เก็บ acknowledgement ของ cancel-replace
ตรวจสอบว่า venue ระบุว่า priority ถูกเก็บไว้หรือเปลี่ยนไป
แยก filled quantity ออกจาก leaves quantity
ตรวจสอบ order book อีกครั้งหลังยืนยันสถานะคำสั่งใหม่แล้วเท่านั้น
อย่าเปรียบเทียบ fills โดยใช้การประเมินตำแหน่งคิวก่อนแก้ไข
คู่มือนี้อธิบายกลไกของคำสั่ง ไม่ใช่คำแนะนำให้แก้ไขหรือยกเลิกคำสั่ง
คำถามที่พบบ่อย
การเปลี่ยนราคาของ futures limit ทำให้เสีย queue priority หรือไม่?
อาจทำให้เสีย การเปลี่ยนราคาทำให้คำสั่งไปอยู่คนละระดับราคา และกฎของ venue จะกำหนด priority ใหม่ อย่าสมมติว่าตำแหน่งในคิวเดิมจะติดตามไป
การลดจำนวนของ futures order ยังรักษา priority หรือไม่?
ขึ้นอยู่กับ venue และประเภทคำสั่ง การลดจำนวนและการเพิ่มจำนวนอาจได้รับการปฏิบัติต่างกัน ดังนั้นให้ตรวจสอบกฎปัจจุบันแทนการใช้สมมติฐานสากล
Cancel-replace สร้าง futures order ใหม่หรือไม่?
Workflow ทางเทคนิคอาจรักษาหรือเปลี่ยน identifiers และ priority ขึ้นอยู่กับ venue ใช้ execution acknowledgement เพื่อระบุสถานะคำสั่งที่เกิดขึ้นจริง
จะรู้ได้อย่างไรว่าคำสั่งที่แก้ไขเสีย priority?
ตรวจสอบกฎของ venue, acknowledgement ของ cancel-replace และข้อมูลคิวระดับคำสั่งที่มี อย่าสรุปจาก fill ที่พลาดในภายหลังเพียงอย่างเดียว