จำแนกฝั่งที่เริ่มการซื้อขายอย่างไร: quote rule, tick test และ Lee–Ready

ในงาน market microstructure คำว่า buy มักหมายถึงธุรกรรมที่ผู้ซื้อเป็นฝ่ายเริ่ม: ส่ง market order หรือคำสั่งที่พร้อมจับคู่ทันทีเพื่อใช้สภาพคล่องที่ผู้ขายตั้งรอไว้ ส่วน sell หมายถึงผู้ขายเป็นฝ่ายเริ่มและจับคู่กับ bid ที่รออยู่ ไม่ว่าป้ายจะเขียนว่า buy หรือ sell การซื้อขายที่เสร็จสมบูรณ์ก็ยังมีคู่สัญญาทั้งสองฝั่งเสมอ

ความแตกต่างนี้สำคัญเมื่อวิเคราะห์ tape ฝั่งผู้ซื้อที่ข้ามไปจับ ask มักถูกเรียกว่า aggressor หรือ taker ส่วนคำสั่งขายที่วางรอไว้เป็นฝ่าย passive หรือ maker แต่ป้ายที่คำนวณจากข้อมูลไม่ได้บอกว่าผู้ซื้อเปิด long ปิด short ป้องกันความเสี่ยง หรือกำลังทำคำสั่งลูกค้าขนาดใหญ่ให้สำเร็จ และไม่ได้เปิดเผยตัวตน เหตุผล หรือความเสี่ยงสุทธิของคู่สัญญา

บันทึก trade และ quote มักไม่ได้มีช่องที่ระบุ initiator โดยตรง นักวิจัยจึงคำนวณจากราคา การซื้อขายก่อนหน้า และ quote ที่เกี่ยวข้อง ควรมองป้ายจากกฎเหล่านี้เป็นค่าประมาณ โดยเฉพาะชุดข้อมูลย้อนหลังที่มีเพียงราคาซื้อขายหรือ quote ที่ถูกรวมและไม่มีช่อง aggressor side จากตลาด

Tick test เปรียบเทียบราคา trade ปัจจุบันกับราคาของ trade ก่อนหน้า ถ้าราคาสูงขึ้นเรียกว่า uptick และจัดเป็น buy; ถ้าราคาลดลงเรียกว่า downtick และจัดเป็น sell วิธีนี้ใช้ได้แม้ไม่มี order book จึงมีประโยชน์กับชุดข้อมูลประวัติศาสตร์ที่เก็บเฉพาะราคาซื้อขาย

เมื่อราคาของ trade สองรายการเท่ากัน จะเรียกว่า zero tick โดยทั่วไปให้สืบทอดทิศทางจากการเปลี่ยนแปลงล่าสุดที่ไม่ใช่ศูนย์: ถ้าราคาครั้งล่าสุดเพิ่มขึ้น zero tick จะถูกจัดเป็น buy; ถ้าลดลงจะเป็น sell การทำเช่นนี้ช่วยจัดการ trade หลายรายการที่ราคาเดิมได้ แต่ก็อาจลากทิศทางเก่าต่อเนื่องผ่านรายการที่ราคาไม่เปลี่ยนหลายครั้ง หากยังไม่เคยมีการเคลื่อนไหวที่ไม่ใช่ศูนย์ก่อนหน้า ให้ถือว่าทิศทางยังระบุไม่ได้ อย่าบังคับเดาว่าเป็น buy หรือ sell

กฎที่เรียบง่ายไม่ได้ถูกต้องเสมอไป ราคาสามารถขยับขึ้นเพราะ quote เปลี่ยน ไม่ใช่เพราะ trade ล่าสุดมีผู้ซื้อเป็นฝ่ายเริ่ม การซื้อขายที่เกิดห่าง ๆ ข้อความที่มาถึงไม่พร้อมกัน trade ที่รายงานผิดลำดับ การประมูล และเงื่อนไขพิเศษล้วนทำให้สมมติฐานอ่อนลง Lee และ Ready มองว่า tick test มีประโยชน์ โดยเฉพาะเมื่อ quote ให้คำตอบไม่ชัด แต่คุณภาพป้ายยังขึ้นกับเวลาและขอบเขตของข้อมูล (Lee และ Ready, 1991)

ถ้ามี best bid และ best ask ให้คำนวณ midpoint เป็นค่าเฉลี่ยของสองราคานั้น Trade ที่สูงกว่า midpoint จะจัดเป็น buy ส่วนราคาที่ต่ำกว่าจะจัดเป็น sell Trade ที่ตรงกับ midpoint พอดีไม่ได้กำหนดทิศทางด้วยตัวเอง ต้องใช้กฎเพิ่มเติม เช่น tick test หรือปล่อยเป็น “ยังจัดประเภทไม่ได้” Trade ที่ ask มักสอดคล้องกับผู้ซื้อ aggressor และที่ bid มักสอดคล้องกับผู้ขาย aggressor หากจับคู่ quote กับ trade ถูกเวลา

การอนุมานจะอ่อนลงเมื่อ trade เกิดภายในสเปรด ระหว่าง bid กับ ask ราคาอาจมาจาก limit order ที่ปรับปรุงราคา hidden liquidity การจับคู่ภายใน หรือความล่าช้าของข้อมูล เพียงดูว่าราคาอยู่ใกล้ midpoint ฝั่งไหนยังไม่พิสูจน์ว่าใครส่งคำสั่งก่อน หากสเปรดกว้างหรือ midpoint ต้องปัดตาม tick size ความต่างเพียงหนึ่ง tick อาจเปลี่ยนป้ายทั้งที่ความหมายทางเศรษฐกิจแทบไม่ต่าง

เงื่อนไขสำคัญคือ quote ต้องเป็น quote ที่ยังมีผล ณ เวลาจับคู่ และมาจาก instrument กับ venue เดียวกัน Quote ที่ล่าช้า เป็นข้อมูลรวม หรือมาจากอีก venue อาจเกิดหลัง trade ที่ทำให้ quote เปลี่ยนแล้ว ควรตรวจแหล่งข้อมูลและ timestamp ก่อน คู่มือเปรียบเทียบ order book กับ Time and Sales ของ futures อธิบายว่าภาพสถานะใน book กับบันทึก trade เป็นข้อมูลคนละประเภท

Lee–Ready แบบดั้งเดิมเริ่มจากเทียบ trade กับ quote ที่เลือก: ที่ ask หรือสูงกว่าจะจัดเป็น buyer-initiated ส่วนที่ bid หรือต่ำกว่าจะเป็น seller-initiated หาก trade อยู่ใน spread แต่ไม่ตรง midpoint วิธีดั้งเดิมจัดให้อยู่ฝั่ง quote ที่ใกล้กว่า; ถ้าตรง midpoint จึงใช้ tick test หาก tick test เองก็ไม่มีการเปลี่ยนแปลงราคาที่ไม่เป็นศูนย์ก่อนหน้า อาจเก็บรายการนั้นเป็น unclassified ได้

ผู้เขียนยังปรับเวลาในการจับคู่ quote ด้วย งานวิจัยพบว่า quote ที่บันทึกทันทีก่อน trade อาจสะท้อนผลจาก trade นั้นเอง สำหรับข้อมูล NYSE ปี 1988 พวกเขาใช้ quote ล่าสุดที่เกิดอย่างน้อยห้าวินาทีก่อน trade การหน่วงเวลานี้เป็นการเลือกวิธีวิจัยเพื่อแก้ปัญหาการบันทึกและการซิงก์ข้อมูลในยุคนั้น ไม่ใช่ค่ามาตรฐานสำหรับตลาดอิเล็กทรอนิกส์สมัยใหม่ ในข้อมูลความถี่สูง ห้าวินาทีอาจเป็น book state ที่ต่างไปมาก

การเขียนระบบใช้เองควรกำหนดลำดับเหตุการณ์และคุณภาพ timestamp แทนการคัดลอกเลขห้าเฉย ๆ นาฬิกาของ trade และ quote ใช้เวลาเดียวกันไหม เป็นเวลาของ exchange หรือเวลาที่ผู้ให้บริการรับข้อความ? ถ้า timestamp เท่ากัน มี quote หลายรายการระหว่าง trade ข้อความหาย หรือไม่มี quote จะเรียงและจัดการอย่างไร feed ที่มีลำดับข้อความระบุไว้หรือการใช้ delay ที่สั้นกว่าอาจเหมาะกว่า ควรเลือกและบันทึกวิธีก่อนวิเคราะห์ ไม่ใช่ปรับย้อนหลังเพื่อให้ตัวชี้วัดที่ต้องการดูดีขึ้น

สมมติว่า best bid คือ 100.00 และ best ask คือ 100.04 ทำให้ midpoint เท่ากับ 100.02 Trade ก่อนหน้าเกิดที่ 100.00 ตัวเลขทั้งหมดเป็นตัวอย่างสมมติไว้สาธิตวิธีจำแนก ไม่ใช่ข้อมูลตลาดจริงหรือผลการซื้อขาย

Trade ถัดมาเกิดที่ 100.01 เพราะ 100.01 สูงกว่า trade ก่อนหน้าที่ 100.00 tick test จึงจัดเป็น buy แต่ราคา 100.01 ต่ำกว่า midpoint 100.02 quote rule จึงจัดเป็น sell นี่ไม่ใช่ความผิดพลาดทางเลขคณิต แต่เป็นเพราะกฎใช้หลักฐานคนละแบบ ในกรณี trade ภายในสเปรด ราคาอย่างเดียวไม่เพียงพอที่จะตัดสินว่าฝั่งใดถูก

ต่อมา trade เกิดที่ 100.02 ซึ่งตรง midpoint พอดี Quote rule อย่างเดียวไม่สามารถระบุทิศทางได้ ส่วน Lee–Ready จะใช้ tick test แทน ราคา 100.02 สูงกว่า trade ก่อนหน้าที่ 100.01 จึงให้ผลเป็น buy หาก trade ต่อไปเกิดที่ ask ราคา 100.04 โดยทั่วไปการเทียบกับ quote จะจัดเป็น buy อย่างไรก็ตาม ระบบจริงต้องรับมือกับการปัดเศษ zero tick quote ที่ล้าสมัย และ timestamp ที่ไม่ตรงกันด้วย

ตัวอย่างนี้ไม่ได้หมายความว่า trade ที่ midpoint ทุกครั้งเป็น buy หรือป้าย sell สำหรับราคา 100.01 ต้องผิดเสมอ จุดประสงค์คือแสดงหลักฐานทางอ้อมที่ขัดกันและเหตุผลที่ต้องบันทึกกฎการตัดสินใจ หาก feed มีข้อมูล aggressor จากตลาดโดยตรง อาจใช้ข้อมูลนั้นแทนการเดาจากราคาเดียวได้ แต่ต้องอ่านตามข้อกำหนดของ feed นั้น

ถ้ากำหนดปริมาณของ trade ทั้งสามเป็น 4, 3 และ 2 ตามลำดับ สัญญาณของ Lee–Ready คือขาย ซื้อ ซื้อ จึงได้ signed volume −4 + 3 + 2 = +1 ส่วน tick test เพียงอย่างเดียวให้สัญญาณบวกทั้งสามรายการ รวมเป็น +9 วิธีจำแนกทำให้ยอดต่างกัน 8 หน่วยทั้งที่ราคาและปริมาณไม่เปลี่ยน หากมีรายการที่ยังไม่มีทิศทาง ให้รายงานสัดส่วนและวิธีจัดการด้วย ตัวเลขนี้เป็นเพียงการคำนวณสมมติ

Ellis, Michaely และ O’Hara เปรียบเทียบวิธีจำแนกหลายแบบด้วยข้อมูล Nasdaq ที่เป็นกรรมสิทธิ์ ในตัวอย่างของงานนั้น quote rule มีความแม่นยำ 76.4%, tick rule 77.66% และ Lee–Ready 81.05% ตัวเลขนี้อธิบายผลการเปรียบเทียบในชุดข้อมูลดังกล่าว ไม่ได้ทำนายความแม่นยำในทุกตลาด ผลขึ้นกับช่วงเวลา เครื่องมือ คุณภาพ timestamp วิธีสร้างป้ายอ้างอิง และสัดส่วน trade ภายในสเปรด ซึ่งเป็นกลุ่มที่จำแนกยากเป็นพิเศษ (งานของ Ellis, Michaely และ O’Hara)

Jurkatis เสนอวิธี full-information ที่จับคู่ trade กับ quote โดยใช้ข้อมูลละเอียดกว่า ในการศึกษาของเขา วิธีนี้ให้ผลดีกว่ากฎมาตรฐานที่เปรียบเทียบ โดยเฉพาะเมื่อ timestamp มีความละเอียดต่ำ นี่เป็นหลักฐานเชิงประจักษ์จากการศึกษาหนึ่ง ไม่ใช่ข้อรับประกันว่าวิธีนี้ชนะใน exchange สัญญา หรือ protocol อื่น การจับคู่แบบ full-information ต้องสร้าง book จากข้อความให้ถูกต้อง และอาจทำไม่ได้หากมีเพียง consolidated feed แบบสรุป (Jurkatis, 2022)

เมื่อตรวจวิธีเหล่านี้ ให้ใช้ป้ายฝั่งอิสระจาก exchange หากมี และรายงานสัดส่วนที่จัดประเภทได้ จัดไม่ได้ และถูกตัดออกแยกกัน ค่า accuracy รวมอาจซ่อนข้อผิดพลาดสำหรับ trade ภายในสเปรดหรือสัญญาที่มีสภาพคล่องน้อย หากป้ายอ้างอิงสร้างด้วยกฎเดียวกันอีกเวอร์ชัน การเปรียบเทียบก็ไม่ได้ยืนยันทิศทางจริง

บาง feed ระบุฝั่ง aggressor โดยตรง เอกสาร CME MDP 3.0 Trade Summary อธิบายฟิลด์ AggressorSide ว่าระบุฝั่ง aggressor หรือไม่มี aggressor: ค่า 1 หมายถึง bid aggressor และค่า 2 หมายถึง ask aggressor ต้องอ่านค่าตามรูปแบบข้อความที่ใช้อยู่ หากไม่มีการระบุ aggressor อย่าแปลงเป็น buy หรือ sell โดยพลการ (เอกสาร CME MDP 3.0)

Nasdaq TotalView-ITCH ให้ side ของ displayed resting order ในข้อความเพิ่มคำสั่ง และผูกข้อความ execution เข้ากับตัวระบุคำสั่งนั้นได้ ถ้า resting order เป็นฝั่งขาย ฝั่งที่มาจับคู่มักเป็นผู้ซื้อ aggressor; ถ้า resting order เป็นฝั่งซื้อก็กลับกัน แต่นี่เป็นการอนุมานโดยเชื่อมหลายข้อความ ไม่ใช่ช่อง aggressor ที่ใช้ได้ทั่วไป ITCH มีข้อกำหนดแยกตามชนิดข้อความ เช่น Buy/Sell Indicator ใน Non-Cross Trade อาจเป็น “B” เสมอไม่ว่าฝั่ง resting order จะเป็นอะไรตามสเปก อย่าตีความไบต์ที่ชื่อคล้ายกันว่าเป็นฝั่งเริ่ม trade; ให้ถอดข้อความชนิดที่ถูกต้องตามเอกสาร Nasdaq (TotalView-ITCH 5.0)

ฟิลด์จาก exchange ช่วยลดการเดาได้เฉพาะในขอบเขตความหมาย เวอร์ชันข้อความ และเงื่อนไขเผยแพร่ที่ระบุไว้ ตลาดอื่นอาจไม่มี aggressor field เลย Order flow imbalance และการเปลี่ยนแปลงของ limit order book ก็ไม่ใช่การติดป้ายฝั่งของ trade: OFI รวมการเปลี่ยนแปลง quote และคิวในช่วงเวลา ส่วน signed volume คำนวณหลังจากใส่ป้ายให้ trade แต่ละรายการแล้ว

เริ่มจากกำหนดแหล่ง trade และ quote, instrument แบบเต็ม, venue, timezone, ความละเอียด timestamp และกฎเรียงข้อความให้ชัด จากนั้นระบุว่าใช้ best quote ของ venue หรือ NBBO แบบรวม ลำดับ trade ใดเป็นฐานของ tick test และจะจัดการราคาซ้ำ midpoint ตลาดที่ถูกล็อก trade จาก auction รายงานล่าช้า หรือราคานอก quote อย่างไร การตัดสินใจเหล่านี้เปลี่ยน label และควรทำซ้ำได้

อย่าบังคับอัลกอริทึมให้ติดป้ายทุก trade ทิศทางอาจยังระบุไม่ได้เมื่อไม่มี quote quote ถูกล็อก เวลาไม่สอดคล้อง ข้อความผิดลำดับ หรือยังไม่มีการเปลี่ยนราคาที่ไม่ใช่ศูนย์ให้ tick test ใช้ สัดส่วนกรณีเหล่านี้บอกคุณภาพและขอบเขตของข้อมูล การเติม label ที่หายด้วย trade ใกล้ที่สุดหรือการเคลื่อนไหวในอนาคตอาจรั่วข้อมูลจากอนาคตเข้ามาโดยไม่รู้ตัว

สำหรับการตรวจด้วยคน ให้เลือกตัวอย่างเล็ก ๆ ที่เก็บข้อความก่อนและหลัง execution ไว้ เปรียบเทียบ best bid/ask, midpoint, trade price, การเปลี่ยนราคาครั้งล่าสุดที่ไม่เป็นศูนย์, ชนิดข้อความ และฟิลด์ exchange ถ้ามี ตรวจ trade ที่ ask, bid, ภายใน spread และตรง midpoint แยกกัน ดูว่า quote เปลี่ยนเพราะ trade ที่กำลังตรวจหรือไม่ และคำนวณซ้ำด้วย timing adjustment ที่มีเหตุผลหลายแบบ การวิเคราะห์ sensitivity แสดงความคงทนของผล แต่ไม่ได้อนุญาตให้เลือกเวอร์ชันที่ให้ผลดีที่สุดโดยไม่มีเกณฑ์ที่กำหนดไว้ก่อน

รูปแบบหนึ่งของการรวมคือ signed volume หรือ S = Σ sᵢvᵢ โดยให้ sᵢ = +1 สำหรับฝั่งซื้อที่อนุมานได้, sᵢ = −1 สำหรับฝั่งขาย และ vᵢ คือปริมาณที่ซื้อขาย ผลลัพธ์ขึ้นกับหน้าต่างเวลา venue หน่วยปริมาณ และการตัดออกหรือจัดการ trade ที่ยังระบุทิศทางไม่ได้ ดังนั้นควรรายงาน coverage และกฎที่ใช้กับค่าที่ยังไม่ทราบควบคู่กับยอดรวม

ผู้ซื้อ aggressor อาจกำลังปิด short ผู้ขายอาจลด long และฝ่ายใดฝ่ายหนึ่งอาจ hedge หรือทำเพียงส่วนหนึ่งของคำสั่งขนาดใหญ่ การจำแนกไม่บอกว่าใครแบกรับความเสี่ยงหลังจบ trade มีกรอบเวลาเท่าใด หรือมีธุรกรรมอะไรเกิดใน venue อื่น การรวม signed buy volume ตลอดหนึ่งนาทีก็เป็นสถิติอีกชนิดหนึ่ง ขึ้นกับหน้าต่างและวิธีรวม ไม่ใช่รายการตำแหน่ง long ใหม่

แม้จำแนกฝั่งได้ถูกต้องก็ไม่ได้พิสูจน์ว่าจะทำกำไรในอนาคต ราคาอาจเคลื่อนไหวไปแล้วก่อนข้อมูลมาถึง คำสั่งอาจ fill แค่บางส่วน และ spread ค่าคอมมิชชัน latency market impact กับราคาออกอาจกินการเคลื่อนไหวระยะสั้นหมด หากต้องการวิเคราะห์ต้นทุนจริงเป็นคำถามอีกแบบ: คู่มือ implementation shortfall เปรียบเทียบราคาเมื่อมีการตัดสินใจกับ execution และจำนวนที่ยังไม่ fill

รายงานวิจัยควรระบุกฎที่ใช้จำแนก โปรโตคอลด้านเวลา สัดส่วน label ที่ยังไม่ชัดเจน ลักษณะตัวอย่าง และวิธีตรวจสอบ อย่าเรียกการคาดเดาจากข้อมูลว่าเป็นหลักฐานตรงของเจตนาผู้ซื้อขาย ป้ายด้าน microstructure ใช้บรรยาย flow ได้ แต่ไม่ใช่สัญญาณรับประกัน การพยากรณ์ หรือคำรับรองผลลัพธ์