Spread ต่ำไม่ได้หมายความว่า Forex Broker จะมี Execution Quality ดีเสมอไป

เพราะระหว่างเวลาที่ Trader เห็นราคา กดส่ง Order และได้รับ Fill จริง ยังมีหลายเรื่องที่เกิดขึ้นได้ เช่น:

• ราคาเปลี่ยน
• เกิด Slippage
• คำสั่งถูก Reject
• เกิด Requote ใน Execution Mode ที่รองรับ
• Order ถูก Fill เพียงบางส่วน
• สภาพคล่อง ณ ราคาที่ต้องการไม่เพียงพอ
• ความผันผวนเพิ่มขึ้นระหว่างการส่งคำสั่ง

ดังนั้นถ้าต้องการรู้ว่า Broker ส่งคำสั่งดีหรือไม่ คำถามไม่ควรเป็นเพียง:

“Broker นี้ Slippage กี่ Pip?”

แต่ควรถามว่า:

“เมื่อเทียบ Order ที่มีเงื่อนไขใกล้เคียงกัน Broker ให้ Execution Outcome แบบไหนอย่างสม่ำเสมอ?”

บทความนี้จึงไม่ได้สร้างคะแนน Broker หรือกำหนดว่า Slippage เกินกี่ Pip ถือว่าแย่ แต่จะสอนวิธี:

เก็บข้อมูล → วัด → แยก Sample → เปรียบเทียบ → ตีความ → และรู้ว่าข้อมูลของเรายังสรุปอะไรไม่ได้

Execution Quality ของ Forex Broker คืออะไร?

ในบริบทของ Trader คำว่า Execution Quality หมายถึงคุณภาพของผลลัพธ์ที่เกิดขึ้นเมื่อคำสั่งซื้อขายถูกส่งไปดำเนินการ

ไม่ได้มีองค์ประกอบเดียว

หน่วยงานกำกับดูแลในกรอบ MiFID II ใช้แนวคิด Best Execution โดยพิจารณาปัจจัย เช่น:

• Price
• Costs
• Speed
• Likelihood of Execution and Settlement
• Size
• Nature of Order
• ปัจจัยอื่นที่เกี่ยวข้องกับคำสั่ง

สำหรับ Retail Client กรอบดังกล่าวให้ความสำคัญกับ Total Consideration ซึ่งรวมราคาของผลิตภัณฑ์และต้นทุนที่เกี่ยวข้องกับ Execution

แต่สิ่งนี้ไม่ได้หมายความว่า Trader สามารถนำกฎ Best Execution มาสร้างสูตรว่า:

Execution Quality = 40% Slippage + 30% Speed + 30% Spread

เพราะไม่มีสูตรสากลแบบนั้น

สิ่งที่นำมาใช้ได้คือหลักคิดว่า:

อย่าตัดสิน Execution จาก Metric เดียว เพราะผลลัพธ์ของคำสั่งขึ้นอยู่กับราคา ต้นทุน ความเร็ว ความเป็นไปได้ที่จะ Fill ขนาด Order และสภาพตลาดร่วมกัน

แหล่งข้อมูล:

https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mifid-ii/article-27-obligation-execute-orders

https://handbook.fca.org.uk/handbook/cobs11/cobs11s9

Best Execution ไม่ได้แปลว่า “ต้องได้ราคาดีที่สุดทุก Trade”

คำว่า Best Execution อาจทำให้เข้าใจผิดว่า Broker ต้องให้ราคาที่ดีที่สุดในทุกคำสั่ง

แต่ Market Conditions สามารถเปลี่ยนระหว่างการส่งและ Execute Order ได้ และแต่ละคำสั่งมี:

• Order Type ต่างกัน
• Size ต่างกัน
• Liquidity ต่างกัน
• Timing ต่างกัน

ดังนั้นการเกิด Negative Slippage หนึ่งครั้งไม่ได้พิสูจน์ว่า Broker ละเมิด Best Execution

ในทางกลับกัน การได้ Positive Slippage หนึ่งครั้งก็ไม่ได้พิสูจน์ว่า Broker มี Execution Quality ดีเสมอ

สิ่งที่มีความหมายมากกว่าคือ:

Pattern ของ Execution ใน Sample ที่เปรียบเทียบกันได้

ก่อนวัด Execution ต้องรู้ก่อนว่า Order ของเรา Execute แบบไหน

MetaTrader แยก Price Execution Mode ออกเป็นหลายแบบ เช่น:

• Request Execution
• Instant Execution
• Market Execution
• Exchange Execution

และยังมี Volume Filling Policy เช่น:

• Fill or Kill — FOK
• Immediate or Cancel — IOC
• Return ใน Mode ที่รองรับ

จุดสำคัญคือ:

Execution Mode กับ Fill Policy เป็นคนละเรื่อง และทั้งสองสามารถมีผลต่อ Outcome ที่ Trader เห็น

ตัวอย่าง MetaTrader ระบุว่า Financial Market ไม่ได้มีการรับประกันว่าจะมี Volume ทั้งหมดตามจำนวนที่ต้องการ ณ ราคาที่ต้องการเสมอ

ดังนั้น Order สามารถมีผลต่างกันตาม Execution/Filling Conditions ที่ Broker กำหนดให้ Symbol นั้น

แหล่งข้อมูล:

https://www.mql5.com/en/docs/constants/tradingconstants/orderproperties

หากต้องการเข้าใจ Execution Mode ก่อน อ่านเพิ่มเติมได้ที่ Market Execution และ Instant Execution ต่างกันอย่างไร?

Market Execution กับ Instant Execution ทำให้การวัดต่างกันอย่างไร?

ประเด็นนี้สำคัญมากต่อการวัด Slippage

Instant Execution

ใน Instant Execution Trade Request มีราคาที่ต้องการ Execute ส่งไปพร้อมคำสั่ง

หาก Broker ยอมรับราคานั้น คำสั่งจึงถูก Execute

หากราคาเปลี่ยนเกินเงื่อนไขที่ยอมรับ ระบบสามารถเกิด Requote ได้

Market Execution

ใน Market Execution Trader ยอมรับล่วงหน้าว่าราคาที่ใช้ Execute จะถูกกำหนดในขั้นตอน Execution โดยไม่มีขั้นตอนให้ยืนยันราคาใหม่แบบ Requote ของ Instant Execution

และในโครงสร้าง MQL5:

Market Order ที่ใช้ Market Execution ไม่จำเป็นต้องระบุ Price ใน Trade Request

นี่นำไปสู่ข้อจำกัดสำคัญ:

Trade History อาจไม่ได้มี “Requested Price” ที่สามารถนำมาลบกับ Fill Price ย้อนหลังได้ทุก Trade

แหล่งข้อมูล:

https://www.mql5.com/en/docs/constants/structures/mqltraderequest

อย่าใช้คำว่า Requested Price ถ้าคุณไม่ได้มี Requested Price จริง

นี่เป็นหนึ่งในข้อผิดพลาดที่สำคัญที่สุดในการ Audit Execution

สมมติ Statement แสดงว่า EUR/USD ถูก Fill ที่:

1.10025

Trader จำได้คร่าว ๆ ว่าตอนกด Buy เห็น:

1.10010

แล้วสรุปว่า:

Slippage = 1.5 Pip

ปัญหาคือ:

ถ้าไม่ได้มี Log หรือ Tick Data ที่บันทึกราคาขณะส่ง Order จริง เราอาจไม่รู้ว่า 1.10010 เป็น:

• Bid?
• Ask?
• ราคาที่เห็นก่อนกดกี่ Millisecond?
• ราคาที่ส่งอยู่ใน Trade Request จริงหรือไม่?

ดังนั้นในบทนี้จะใช้คำที่กว้างกว่า:

Reference Price

Valid Reference Price คืออะไร?

Valid Reference Price คือราคาที่มีหลักฐานเพียงพอว่าใช้เป็นจุดอ้างอิงสำหรับการวัด Execution ของ Order นั้น

ตัวอย่างข้อมูลที่อาจใช้ได้ ขึ้นอยู่กับระบบและวิธีเก็บข้อมูล:

• Requested Price ที่ถูกบันทึกใน Trade Request
• Platform Journal / Expert Log
• EA หรือ Script ที่บันทึก Bid/Ask และ Timestamp ก่อนส่ง Order
• Broker Execution Report
• ข้อมูล Tick ที่เก็บจาก Feed เดียวกับ Account ณ เวลาส่งคำสั่ง

สิ่งที่ไม่ควรใช้แทน Reference Price โดยไม่ตรวจสอบคือ:

• ราคา Open/Close ของแท่งเทียนย้อนหลัง
• High/Low ของ Candle
• Screenshot ที่ไม่มี Timestamp ละเอียดพอ
• ราคาจาก Broker อื่นแล้วถือว่าเป็นราคาเดียวกัน

โดยเฉพาะ Retail Forex/CFD เป็นตลาด OTC ซึ่ง Quote สามารถแตกต่างกันระหว่างผู้ให้บริการได้

อ่านเพิ่มเติมได้ที่ OTC Market คืออะไร? ทำไมราคา Forex ของแต่ละ Broker จึงต่างกันได้

Slippage ควรวัดอย่างไรเมื่อมี Reference Price ที่ใช้ได้?

Slippage คือความแตกต่างระหว่าง Reference Price กับราคาที่ Execute จริง

แต่การบอกเพียง:

Fill − Reference

อาจทำให้เครื่องหมายสับสนระหว่าง Buy กับ Sell

วิธีที่อ่านง่ายกว่าคือกำหนดให้:

Positive Slippage = Trader ได้ราคาดีกว่า Reference

Negative Slippage = Trader ได้ราคาแย่กว่า Reference

หากต้องการเก็บเป็น Signed Slippage แบบที่ Positive หมายถึง Benefit ต่อ Trader สามารถใช้แนวคิด:

Buy: Reference Price − Fill Price

Sell: Fill Price − Reference Price

จากนั้นจึงแปลง Price Difference เป็น Pip หรือ Point ตาม Specification ของ Instrument

นี่เป็นวิธีจัดข้อมูลสำหรับการ Audit ไม่ใช่สูตรที่ Regulator กำหนดให้ Retail Trader ต้องใช้

ตัวอย่างการคำนวณ Slippage ของ Buy Order

สมมติ EUR/USD:

Valid Ask Reference = 1.10000

Order เป็น Buy

Fill จริง:

1.10015

Trader ซื้อแพงขึ้น:

0.00015 = 1.5 Pip

จึงเป็น:

Negative / Adverse Slippage = 1.5 Pip

ถ้า Fill กลายเป็น:

1.09990

Trader ซื้อถูกลง 1 Pip

จึงเป็น:

Positive / Beneficial Slippage = 1 Pip

ตัวอย่างนี้มีไว้แสดงวิธีจัดเครื่องหมายเท่านั้น ไม่ใช่เกณฑ์ว่า Slippage 1 หรือ 1.5 Pip ดีหรือแย่

Slippage กี่ Pip ถึงถือว่า Broker แย่?

ไม่มี Universal Threshold ที่ใช้ได้กับทุก Broker ทุก Instrument และทุกช่วงเวลา

ตัวเลขเดียวกันสามารถมีความหมายต่างกันได้มากระหว่าง:

• EUR/USD ช่วง London Session ปกติ
• XAU/USD ช่วงข่าวแรง
• คู่เงิน Exotic
• Market Open
• ช่วง Rollover
• Order ขนาดใหญ่
• Order ขนาดเล็ก

Order Execution Policy ของ Broker อย่าง Pepperstone เองก็ระบุว่า Slippage เป็นสิ่งที่เกิดได้ตามปกติ โดยเฉพาะเมื่อ:

• Order Size ใหญ่ขึ้น
• Liquidity บาง
• Market มีความผันผวน

แหล่งข้อมูล:

https://files.pepperstone.com/legal/SCB/SCB_Order_Execution_Policy_ROW.pdf

ดังนั้นบทนี้จะไม่สร้างกฎว่า:

“เกิน X Pip = Broker ไม่ดี”

เพราะจะสร้าง False Precision มากกว่าช่วย Trader

Positive Slippage สำคัญพอ ๆ กับ Negative Slippage

หากระบบสามารถเกิด Slippage ได้ การ Audit ที่ดีไม่ควรบันทึกเฉพาะ Trade ที่ราคาแย่ลง

ควรเก็บ:

• Positive Slippage
• Zero / No material Slippage ตามหน่วยที่กำหนด
• Negative Slippage

เพราะเป้าหมายไม่ใช่หาแต่เหตุการณ์ที่ไม่พอใจ

แต่คือดู:

Distribution ของ Execution Outcome

OANDA UK ตัวอย่างเช่นเผยแพร่ Best Execution Slippage Report รายไตรมาส โดยรายงาน Slippage แยกตาม Instrument และแบ่งเป็นช่วงของ:

• Adverse Slippage
• No Slippage
• Beneficial Slippage

แทนการรายงานเพียง Average ตัวเดียว

แหล่งข้อมูล:

https://www.oanda.com/uk-en/legal/disclosures/

https://www.oanda.com/assets/documents/2105/OEL_Best_Execution_Slippage_Report_MT5_April_-_June_2026.pdf

แต่อย่านับ Positive vs Negative รวมทุก Order Type แล้วสรุปทันที

นี่เป็นข้อจำกัดที่สำคัญมาก

Order Type ต่างกันมี Execution Characteristics ต่างกัน

ตัวอย่างเช่น:

Limit Order

โดยโครงสร้างของ Limit Order มุ่งให้ Execute ที่ Limit Price หรือดีกว่า หากไม่มีราคาตามเงื่อนไข Order อาจไม่ถูก Fill

Stop Order

เมื่อ Stop ถูก Trigger สามารถกลายเป็น Order ที่ Execute ตามราคาตลาด ดังนั้นในตลาดที่เคลื่อนไหวเร็ว Fill สามารถเกิดที่ราคาที่แย่กว่าระดับ Stop ได้

ข้อมูล Execution Statistics ของ FXCM แสดงตัวอย่างเรื่องนี้ชัดเจน โดยรายงานปี 2025 แยก Limit Order ออกจาก Stop Order และพบ Distribution ของ Positive/Negative Slippage แตกต่างกันมากระหว่างสองประเภท

IG ก็เผยแพร่ Slippage Statistics โดยแยก Stop และ Limit Orders เช่นเดียวกัน

แหล่งข้อมูล:

https://www.fxcm-markets.com/about-fxcm/slippage-statistics/

https://www.ig.com/en/best-execution

ดังนั้น:

Negative Slippage มากกว่า Positive Slippage ในข้อมูลที่รวมทุก Order ไม่ได้พิสูจน์ว่า Broker มี Asymmetric Slippage

ต้องแยก Order Type ก่อน

Sample Execution ควรแบ่งอย่างไร?

อย่างน้อยควรพยายามแยกตาม:

Instrument × Order Type × Order Size × Market Condition

และถ้าต้องการละเอียดขึ้นสามารถเพิ่ม:

• Account Type
• Session
• News / Non-news
• Day of Week
• Normal / Rollover
• Execution Mode

ตัวอย่าง:

EUR/USD Market Buy 0.10 Lot ช่วง London ปกติ

ควรเปรียบเทียบกับ:

EUR/USD Market Buy ขนาดใกล้เคียงกันในสภาพตลาดใกล้เคียงกัน

ไม่ควรนำไปเทียบตรง ๆ กับ:

XAU/USD Buy Stop ช่วง NFP

ทำไมต้องแยก Normal Condition กับ Stress Condition?

หากต้องการรู้ Execution Quality ในการใช้งานปกติ ต้องมีข้อมูลช่วงตลาดปกติ

หากต้องการรู้ว่า Broker จัดการกับตลาดรุนแรงอย่างไร ต้องมี Stress Sample แยกต่างหาก

ตัวอย่าง Stress Condition ได้แก่:

• NFP
• CPI
• FOMC
• Major Central Bank Decision
• Market Open/Reopen
• Rollover
• ช่วง Liquidity ต่ำผิดปกติ

การทดสอบเฉพาะ NFP แล้วเรียกผลนั้นว่า:

“Execution Quality ของ Broker โดยรวม”

จึงไม่เหมาะ

แต่ NFP Sample มีประโยชน์ถ้าคำถามคือ:

“Execution ภายใต้ Stress Condition เป็นอย่างไร?”

Execution Outcome ต้องเก็บอะไรนอกจาก Slippage?

อย่างน้อยควรบันทึกว่า Order:

• Full Fill
• Partial Fill หากระบบรองรับและเกิดขึ้น
• Rejected
• Requoted ใน Execution Mode ที่เกี่ยวข้อง
• Cancelled ตาม Fill Policy

เพราะ Broker ที่ให้ราคาดีมากเมื่อ Fill สำเร็จ แต่ Reject Order บ่อย อาจมี Experience ต่างจาก Broker ที่ Fill ได้สม่ำเสมอกว่า

ในทางกลับกัน Broker ที่ Fill ทุก Order ไม่ได้หมายความว่าราคาที่ได้จะดีที่สุด

นี่คือเหตุผลที่:

Fill Quality กับ Price Quality ต้องดูร่วมกัน

Fill Rate คืออะไร?

ในระดับ Audit ส่วนตัว สามารถนิยามง่าย ๆ ว่า:

Fill Rate = จำนวน Order ที่ได้ Execution Outcome ตามนิยามที่กำหนด ÷ จำนวน Order ที่ส่ง

แต่ต้องระบุให้ชัดว่า “Fill” หมายถึง:

• Full Fill เท่านั้น?
• รวม Partial Fill?
• นับ Pending Order ที่ยังไม่ Trigger หรือไม่?

ไม่มีประโยชน์ที่จะเปรียบ Fill Rate ระหว่างสอง Dataset หากนิยามไม่เหมือนกัน

Reject Rate และ Requote Rate ใช้ได้ไหม?

ใช้เป็น Descriptive Metric ได้ แต่ต้องตีความตาม Execution Mode

Reject Rate

ควรดูร่วมกับ:

• Order Size
• Symbol
• Liquidity
• Market Condition
• Trading Rules

Requote Rate

มีความหมายเฉพาะใน Execution Workflow ที่รองรับ Requote เช่น Instant Execution

ไม่ควรเอา:

“Broker A มี Requote 0%”

ไปใช้เป็นข้อได้เปรียบเหนือ Broker B โดยไม่ดูว่า Broker A ใช้ Market Execution ซึ่งไม่มี Requote แบบเดียวกันอยู่แล้ว

อ่านเพิ่มเติมเรื่อง Requote ได้ที่ Requote คืออะไร?

Partial Fill บอกอะไรเกี่ยวกับ Execution?

Partial Fill เกิดขึ้นได้เมื่อ Volume ที่ต้องการไม่สามารถถูก Execute ทั้งหมดในครั้งเดียวตามเงื่อนไขที่มี

Order Execution Policy ของ Pepperstone อธิบายว่า Partial Fill สามารถเกิดเมื่อ Liquidity ไม่เพียงพอสำหรับ Fill Order ทั้งหมด ณ ราคาเดียว และแต่ละส่วนอาจถูก Execute คนละราคา

ดังนั้นสำหรับ Order Size ที่ใหญ่ขึ้น ควรบันทึก:

• จำนวน Fill
• Volume ของแต่ละ Fill
• ราคาของแต่ละ Fill
• Volume-weighted average fill price หากจำเป็น

ไม่ควรดูเฉพาะ Fill สุดท้ายแล้วถือว่าเป็นราคาของ Order ทั้งหมด

Execution Speed วัดอย่างไร?

นี่เป็นอีก Metric ที่เข้าใจผิดง่ายมาก

Trader อาจจับเวลาจาก:

กด Buy → เห็น Position เปิด

แล้วได้:

250 ms

แต่ 250 ms นี้อาจประกอบด้วย:

Device → Platform → Internet → Network Route → Broker Infrastructure → Execution → Response → Platform Display

ดังนั้นไม่ควรเรียกตัวเลขนี้ว่า:

“Broker Execution Time = 250 ms”

โดยอัตโนมัติ

คำที่ระมัดระวังกว่าคือ:

Client-observed Order Round-trip Time

Broker-side Execution Time ต่างจาก Latency ที่ Trader เห็นอย่างไร?

Broker สามารถวัดเวลาภายใน Infrastructure ของตนเองได้ต่างจาก Trader

ตัวอย่าง FXCM ระบุ Execution Speed ของตนว่าเป็นเวลาตั้งแต่ระบบได้รับ Order จนถึง Execution และระบุชัดว่าไม่รวม Internet Latency ของลูกค้าและ Post-trade Booking

แหล่งข้อมูล:

https://www.fxcm-markets.com/about-fxcm/execution-transparency/

ดังนั้นถ้า:

Trader เห็น 200 ms

แต่ Broker รายงาน:

Broker-side Execution 20 ms

สองตัวเลขนี้ไม่จำเป็นต้องขัดกัน

เพราะกำลังวัดคนละช่วงของระบบ

Execution เร็วกว่า แปลว่าดีกว่าเสมอไหม?

ไม่

Speed มีความสำคัญกับ Strategy บางประเภทมาก เช่น:

• Scalping
• Short-term trading
• Trading ช่วงตลาดเปลี่ยนเร็ว

แต่ Broker ที่เร็วกว่าหลาย Millisecond ไม่ได้แปลว่ามี:

• ราคาดีกว่า
• Slippage ดีกว่า
• Fill Rate ดีกว่า
• ต้นทุนรวมต่ำกว่า

Execution Quality จึงควรถูกประเมินหลายด้านร่วมกัน

Spread ต้องรวมอยู่ในการ Audit หรือไม่?

ควรเก็บ หากมีข้อมูลที่เหมาะสม

เพราะ Trader จ่าย Spread ตอนเข้าหรือออก Position และ Spread สามารถเปลี่ยนตาม Market Condition

แต่ต้องแยกระหว่าง:

Spread

กับ:

Slippage

Spread คือความต่างระหว่าง Bid และ Ask ณ ช่วงหนึ่ง

Slippage คือความต่างระหว่าง Reference Price ที่เหมาะสมกับราคาที่ Execute จริง

Trader สามารถเจอ:

• Spread แคบ + Negative Slippage
• Spread กว้าง + No Slippage
• Spread กว้าง + Negative Slippage
• Spread แคบ + Positive Slippage

ได้

อ่านพื้นฐานเพิ่มเติมได้ที่ Spread Forex คืออะไร?

อย่าเอา Spread ตอนนี้ไปอธิบาย Trade เมื่อวาน

หากจะวิเคราะห์ Order ย้อนหลัง Spread ต้องมาจากช่วงเวลาใกล้เคียงกับการส่ง/Execute Order จริง

การเปิด MT5 วันนี้แล้วเห็น EUR/USD Spread 0.8 Pip ไม่ได้พิสูจน์ว่า Trade เมื่อวานตอน 20:30 มี Spread 0.8 Pip เช่นกัน

หากต้องการ Execution Audit ที่ละเอียดจึงควรเก็บ Tick หรือ Bid/Ask ณ เวลาส่ง Order ตั้งแต่แรก

วิธีสร้าง Execution Log ของตัวเอง

Template ขั้นพื้นฐานสามารถมีคอลัมน์ดังนี้:

หากไม่มีข้อมูลในช่องใด:

ให้ใส่ว่า “ไม่มีข้อมูล”

ดีกว่าประมาณค่าขึ้นมาเอง

เวลาควรเก็บเป็น Server Time หรือ UTC?

ถ้าเป็นไปได้ควรเก็บทั้ง:

• Broker Server Time
• UTC

เพราะช่วยให้:

• เปรียบเทียบกับข่าว
• เปรียบเทียบ Broker หลายราย
• ตรวจ Tick Data
• ทำ Timeline กรณี Dispute

ได้ง่ายกว่า

แต่ต้องระบุ Conversion และ Daylight Saving Time ให้ถูกต้องหากเกี่ยวข้อง

จำนวน Trade เท่าไรถึงพอ?

ไม่มี Universal Minimum ที่ทำให้ Sample กลายเป็น “น่าเชื่อถือ” ทันที

หลักสำคัญกว่าคือ:

• Sample ต้องมากพอที่จะเห็น Pattern
• Trade ต้องมี Context ที่เปรียบเทียบกันได้
• ไม่ควรถูกครอบงำด้วยเหตุการณ์พิเศษเพียงไม่กี่ครั้ง

Trade 100 ครั้งที่ผสม:

• 10 Instrument
• หลาย Order Type
• หลาย Size
• ข่าวและช่วงปกติ

อาจมีประโยชน์ในการเปรียบเทียบน้อยกว่า Dataset ที่เล็กกว่าแต่ควบคุม Context ได้ดีกว่า

ดังนั้น:

Sample Size สำคัญ แต่ Sample Comparability สำคัญด้วย

Average Slippage เพียงพอหรือไม่?

ไม่ควรใช้ Average เพียงตัวเดียว

สมมติ Slippage 5 Trade คือ:

0, 0, 0, 0, -10 Pip

Average = -2 Pip

แต่ Trader ส่วนใหญ่ใน Sample ได้ 0 และมี Tail Event หนึ่งครั้งที่รุนแรงมาก

ถ้าดูแต่ Average เราจะไม่เห็นโครงสร้างนี้

ดังนั้นควรดูอย่างน้อย:

• จำนวน Observation
• Positive Slippage %
• No/Near-zero Slippage % ตามเกณฑ์หน่วยวัดที่กำหนด
• Negative Slippage %
• Mean
• Median
• Worst / Tail Observations

Mean กับ Median ต่างกันอย่างไร?

Mean คือค่าเฉลี่ยของทุก Observation

Median คือค่ากึ่งกลางเมื่อเรียงข้อมูล

Median มีประโยชน์ใน Dataset ที่มี Outlier เพราะไม่ถูกลากด้วย Extreme Observation มากเท่า Mean

แต่ Median ก็ไม่ได้แทนข้อมูลทั้งหมดเช่นกัน

ดังนั้น:

Mean + Median + Distribution

ให้ภาพดีกว่าค่าใดค่าหนึ่ง

การใช้ Mean/Median ในบทนี้เป็น Methodology เชิงสถิติสำหรับการวิเคราะห์ข้อมูล ไม่ใช่ Regulatory Metric ที่ Broker ทุกแห่งต้องรายงาน

Tail Slippage คืออะไร?

Trader บาง Strategy อาจไม่ได้รับผลกระทบมากจาก Median Slippage แต่ได้รับผลกระทบอย่างมากจากเหตุการณ์ Extreme

ตัวอย่างเช่น:

• ส่วนใหญ่ Slippage ใกล้ศูนย์
• แต่มีบาง Trade ที่เกิด Adverse Slippage รุนแรงมาก

ดังนั้นควรดู:

• Worst Observations
• เหตุการณ์ที่อยู่ปลาย Distribution
• สภาพตลาดที่เกิดเหตุ

ถ้า Dataset ใหญ่เพียงพอ สามารถใช้ Percentile เช่น 90th หรือ 95th Percentile ของ Adverse Slippage เพื่ออธิบาย Tail ได้

แต่ Percentile เหล่านี้เป็น Analytical Choice ไม่ใช่เกณฑ์ที่บอกว่า:

“P95 เกิน X = Broker แย่”

ตัวอย่าง Execution Summary ที่มีประโยชน์กว่า Average เดียว

วิธีเปรียบ Broker A กับ Broker B อย่าง Fair

ถ้าต้องการทดสอบสอง Broker ควรพยายามควบคุมเงื่อนไขให้ใกล้เคียงกันมากที่สุด

ตัวแปรที่ควรใกล้เคียงกัน ได้แก่:

• Instrument เดียวกัน
• Order Type เดียวกัน
• Order Size ใกล้เคียงกัน
• Session เดียวกัน
• Volatility Regime ใกล้เคียงกัน
• Account Type ที่เปรียบเทียบได้
• Location / VPS / Network Environment ใกล้เคียงกันหากทดสอบ Latency
• Normal หรือ Stress Condition ประเภทเดียวกัน

ไม่ควรทำแบบ:

Broker A: EUR/USD Market Order ช่วง London

เทียบกับ:

Broker B: XAU/USD Stop Order ตอน CPI

แล้วสรุปว่าใคร Execution ดีกว่า

ควรส่ง Order สอง Broker พร้อมกันหรือไม่?

การส่ง Order ใกล้เคียงกันช่วยลด Timing Difference ได้ แต่ไม่ได้ทำให้การทดสอบ Perfect

เพราะแต่ละ Broker อาจมี:

• Price Feed ต่างกัน
• Liquidity ต่างกัน
• Execution Infrastructure ต่างกัน
• Account Specification ต่างกัน
• Spread/Markup ต่างกัน

ดังนั้นผลควรถูกตีความเป็น:

ประสบการณ์ Execution ของ Account สองชุดภายใต้การทดสอบนี้

ไม่ใช่:

ค่าความจริงสากลของ Broker ทั้ง Brand

ทำไม Brand เดียวกันก็อาจได้ Execution ไม่เหมือนกัน?

Execution สามารถแตกต่างตาม:

• Legal Entity
• Account Type
• Trading Platform
• Symbol
• Server
• Liquidity Arrangement
• Client Region

ดังนั้นผลจาก Account หนึ่งไม่ควรถูกขยายเป็นข้อสรุปว่า:

“ลูกค้าทุกคนของ Broker นี้ได้ Execution แบบเดียวกัน”

สิ่งที่ Execution Log ของคุณพิสูจน์ได้

หากเก็บข้อมูลดีพอ คุณสามารถพูดได้ เช่น:

• ใน Sample นี้ Slippage Distribution เป็นอย่างไร
• Market Orders กลุ่มนี้มี Median Slippage เท่าไร
• Stress Condition ต่างจาก Normal Condition อย่างไร
• มี Reject/Requote เกิดขึ้นบ่อยเพียงใดใน Sample
• Order Size ที่ใหญ่ขึ้นในข้อมูลของคุณสัมพันธ์กับ Outcome ที่ต่างออกไปหรือไม่

สิ่งที่ Execution Log ของคุณยังพิสูจน์ไม่ได้

แม้เก็บข้อมูลละเอียด ก็ต้องระวังการสรุปเกินหลักฐาน

ข้อมูลของคุณอาจยังพิสูจน์ไม่ได้ว่า:

• Broker จงใจให้ Negative Slippage
• Broker Manipulate Price
• Broker ละเมิด Best Execution
• Liquidity Provider ต้นทางทำอะไร
• ลูกค้าทุก Account ได้ Outcome แบบเดียวกัน
• Delay ทั้งหมดเกิดจาก Broker

ข้อสรุปเหล่านี้ต้องการหลักฐานมากกว่าการดู Account History

Trade เดียวที่ Slippage รุนแรงควรทำอย่างไร?

Trade เดียวไม่เพียงพอสำหรับตัดสิน Execution Quality โดยรวม

แต่ไม่ได้หมายความว่าควรเพิกเฉย

หากพบเหตุผิดปกติ ให้เก็บ:

• Ticket ID
• Symbol
• Side
• Order Type
• Volume
• Timestamp
• Requested/Reference Price ถ้ามีหลักฐาน
• Fill Price
• Platform Log
• Tick Data
• Screenshot
• ข่าวหรือ Market Event ที่เกิดขึ้น

จากนั้นจึงถาม Broker โดยระบุข้อมูล Trade เฉพาะเจาะจง

เมื่อไรควรถาม Broker เพิ่ม?

ไม่มี Threshold สากล แต่เหตุที่สมเหตุสมผลในการขอข้อมูลเพิ่มอาจรวมถึง:

• Execution Outcome แตกต่างจาก Trading Conditions ที่ประกาศอย่างชัดเจน
• เกิด Pattern ซ้ำใน Comparable Orders
• พบ Price/Fill ที่อธิบายจากข้อมูลที่มีไม่ได้
• เกิด Reject/Requote ผิดปกติเมื่อเทียบกับเงื่อนไขปกติของ Account เดียวกัน
• Execution Policy กับพฤติกรรมที่สังเกตได้ดูไม่สอดคล้องกัน

คำถามที่ควรส่งคือ:

“ช่วยอธิบาย Execution ของ Ticket X พร้อมราคา เวลา และเงื่อนไขการ Fill ได้หรือไม่?”

ดีกว่า:

“Broker โกงผมใช่ไหม?”

เพราะคำถามแรกเปิดทางให้ตรวจสอบ Evidence ได้

Order Execution Policy ต้องอ่านอะไร?

ก่อนทดสอบ Broker ควรอ่านเอกสาร Order Execution Policy หรือเอกสารชื่อใกล้เคียง

หัวข้อที่ควรหา ได้แก่:

• Execution Venue / Counterparty
• Price Sources
• Price Construction
• Slippage
• Order Size
• Partial Fill
• Order Type
• Execution Factors
• Liquidity
• Abnormal Market Conditions
• Best Execution Monitoring

จากนั้นเปรียบ:

สิ่งที่ Policy บอกว่าจะเกิด

กับ:

สิ่งที่ Account ของคุณแสดง

Broker เป็น Market Maker, STP หรือ ECN บอก Execution Quality ได้ไหม?

ไม่เพียงพอ

Label ของ Execution Model ไม่สามารถแทนผลการ Execute จริงได้

Broker ที่ใช้ Model หนึ่งยังสามารถมี:

• Pricing ต่างกัน
• Liquidity ต่างกัน
• Technology ต่างกัน
• Execution Policy ต่างกัน

ดังนั้นแทนที่จะถามเพียง:

“Broker นี้ ECN ไหม?”

ควรถามเพิ่มว่า:

“Account ของฉันได้รับราคา Fill และ Execution Outcome อย่างไร?”

อ่านเพิ่มเติมได้ที่ Market Maker, STP, ECN และ DMA ต่างกันอย่างไร?

Execution Audit Framework ของ ThaiFX

เพื่อให้ใช้งานง่าย สามารถวิเคราะห์ตามลำดับนี้:

STEP 1 — Order Context

Order นี้คืออะไร?

• Symbol
• Buy/Sell
• Order Type
• Volume
• Execution Mode

STEP 2 — Valid Reference Price

เรามีราคาที่ใช้อ้างอิงจากหลักฐานจริงหรือไม่?

ถ้าไม่มี:

อย่าคำนวณ Slippage แบบสร้าง Reference ขึ้นย้อนหลัง

STEP 3 — Execution Outcome

เกิดอะไรขึ้น?

• Full Fill
• Partial Fill
• Reject
• Requote
• อื่น ๆ ตาม Platform

STEP 4 — Price / Slippage / Cost

หากมีข้อมูลพอ:

• Slippage เท่าไร?
• Positive หรือ Negative?
• Spread ณ ช่วงนั้นเท่าไร?
• Commission เกี่ยวข้องหรือไม่?

STEP 5 — Market Condition

Trade เกิดใน:

• Normal Session
• News
• Rollover
• Thin Liquidity
• Market Open

STEP 6 — Comparable Sample

อย่าเปรียบ Order ที่มีธรรมชาติต่างกัน

แยก:

Instrument × Order Type × Size × Condition

STEP 7 — Distribution

ดู:

• Positive / Negative
• Mean
• Median
• Reject/Requote
• Tail

STEP 8 — Interpretation

ถามว่า:

ข้อมูลนี้สนับสนุนข้อสรุปอะไรได้ และข้อสรุปอะไรยังเกินหลักฐาน?

ตัวอย่างข้อสรุปที่ดีและไม่ดี

Execution Quality Checklist

คำถามที่พบบ่อย

Execution Quality คือ Broker ที่ส่งคำสั่งเร็วที่สุดใช่ไหม?

ไม่ Speed เป็นเพียงหนึ่งในปัจจัย Execution Quality ยังเกี่ยวข้องกับ Price, Costs, Likelihood of Execution, Size, Order Nature และผลลัพธ์ด้าน Fill ด้วย

Slippage เยอะแค่ไหนถึงถือว่า Broker ไม่ดี?

ไม่มี Universal Threshold ต้องดู Instrument, Order Type, Size, Liquidity, Volatility และช่วงเวลาประกอบกัน

Slippage ติดลบครั้งเดียวแปลว่า Broker มีปัญหาไหม?

ไม่สามารถสรุปได้จาก Trade เดียว ควรตรวจ Market Context และ Comparable Sample เพิ่ม

Positive Slippage กับ Negative Slippage ควรมีจำนวนเท่ากันไหม?

ไม่มีเหตุผลให้คาดว่าต้องเท่ากัน โดยเฉพาะเมื่อ Order Type มีธรรมชาติต่างกัน จึงต้องแยก Market, Limit และ Stop ก่อนวิเคราะห์ Distribution

Account History ใช้คำนวณ Slippage ได้ไหม?

ใช้ได้เมื่อมี Valid Reference Price ที่เหมาะสม แต่ History ที่มีเพียง Fill Price ไม่ได้ทำให้เรารู้ Requested/Reference Price ของทุก Market Execution Order โดยอัตโนมัติ

Requested Price กับราคาที่เห็นบนหน้าจอเหมือนกันไหม?

ไม่ควรถือว่าเหมือนกันเสมอ ต้องดู Execution Mode และหลักฐานจาก Trade Request/Log โดยเฉพาะ Market Execution ซึ่ง Trade Request ไม่จำเป็นต้องระบุ Price

Broker ที่ไม่มี Requote ดีกว่า Broker ที่มี Requote ไหม?

ยังสรุปไม่ได้ เพราะ Market Execution ไม่มี Requote แบบ Instant Execution โดยโครงสร้างอยู่แล้ว ต้องดูราคา Fill, Slippage, Reject และปัจจัยอื่นร่วมกัน

Execution Speed 20 ms ดีกว่า 100 ms ไหม?

ถ้าเป็น Metric ที่วัดนิยามเดียวกันและเงื่อนไขเทียบกันได้ ความเร็วต่ำกว่าอาจมีประโยชน์ต่อบาง Strategy แต่ Execution Speed เพียงตัวเดียวไม่ได้พิสูจน์ว่าราคาและต้นทุนดีกว่า

ใช้ Ping วัด Execution Speed ได้ไหม?

Ping วัด Network Latency ในระดับหนึ่ง ไม่ได้วัดกระบวนการ Execute Order ทั้งหมด จึงไม่ควรใช้แทน Broker-side Execution Time

Broker A Slippage น้อยกว่า Broker B แปลว่า A ดีกว่าไหม?

ต้องตรวจว่ากำลังเปรียบ Instrument, Order Type, Size, Account และ Market Condition ที่ใกล้เคียงกันหรือไม่ รวมถึงดู Reject, Fill และ Costs อื่นด้วย

ทดสอบตอนข่าวแรงดีที่สุดไหม?

เหมาะสำหรับ Stress Test แต่ไม่ควรใช้แทน Normal-condition Sample ทั้งหมด

Spread ต่ำแปลว่า Execution ดีไหม?

ไม่เสมอ Spread เป็นส่วนหนึ่งของต้นทุน แต่ไม่ได้บอก Slippage, Reject, Fill หรือ Execution Outcome ทั้งหมด

Market Maker Execution แย่กว่า ECN หรือไม่?

ไม่สามารถสรุปจาก Label ของ Business/Execution Model เพียงอย่างเดียว ควรดูผลการ Execute จริงและ Order Execution Policy ของ Account ที่ใช้งาน

สรุป: วัด Execution Quality จาก Pattern ไม่ใช่ Trade เดียว

ถ้าต้องการรู้ว่า Forex Broker ส่งคำสั่งดีหรือไม่ อย่าเริ่มจากการสร้างเกณฑ์ว่า:

“Slippage ไม่เกิน X Pip = ดี”

หรือ:

“Execute ไม่เกิน X ms = เร็ว”

เพราะไม่มีตัวเลขสากลที่ใช้ตัดสินได้ทุก Instrument และทุก Market Condition

วิธีที่แข็งแรงกว่าคือ:

Order Context → Valid Reference Price → Execution Outcome → Price/Slippage → Market Condition → Comparable Sample → Distribution → Interpretation

และต้องรู้ว่าข้อมูลแต่ละระดับตอบคำถามอะไรได้

Trade History อาจบอกราคา Fill

แต่ไม่ได้รับประกันว่าจะมี Requested Price ที่ถูกต้อง

Client Timer อาจบอก Round-trip Time

แต่ไม่ได้บอก Broker-side Execution Time โดยตรง

Negative Slippage สามารถเกิดขึ้นได้

แต่ไม่ได้พิสูจน์ Misconduct จาก Observation เดียว

Positive/Negative Distribution มีประโยชน์

แต่ต้องแยก Order Type ก่อน

ดังนั้นหลักสำคัญที่สุดคือ:

อย่าถามเพียงว่า “Broker นี้ Execute ดีไหม?” ให้ถามว่า “ข้อมูลอะไรสนับสนุนคำตอบนั้น และข้อมูลอะไรที่เรายังไม่มี?”

เมื่อเก็บ Execution Log อย่างเป็นระบบ Trader จะเปลี่ยนจากการตัดสินด้วยความรู้สึก เช่น:

“เมื่อกี้เหมือน Fill ช้ามาก”

เป็นคำถามที่ตรวจสอบได้ เช่น:

“Market Orders EUR/USD ขนาดเดียวกันใน London Session ช่วงปกติ มี Slippage Distribution และ Reject Rate เปลี่ยนไปจาก Sample ก่อนหน้าหรือไม่?”

นี่ไม่ได้ทำให้ Trader สามารถพิสูจน์ทุกอย่างเกี่ยวกับ Infrastructure ของ Broker ได้

แต่ช่วยให้แยก:

Observation

ออกจาก:

ข้อกล่าวหาหรือข้อสรุปที่เกินหลักฐาน

และเป็นพื้นฐานที่ดีกว่ามากหากวันหนึ่งต้องขอให้ Broker ตรวจสอบ Trade ที่ผิดปกติ

---

แหล่งอ้างอิง

European Securities and Markets Authority — MiFID II Article 27: Obligation to execute orders on terms most favourable to the client
ใช้ตรวจสอบกรอบ Best Execution และปัจจัย Price, Costs, Speed, Likelihood of Execution and Settlement, Size และ Nature รวมถึงแนวคิด Total Consideration สำหรับ Retail Client

https://www.esma.europa.eu/publications-and-data/interactive-single-rulebook/mifid-ii/article-27-obligation-execute-orders

Financial Conduct Authority — COBS 11.2A Best Execution
ใช้ตรวจสอบ Best Execution Criteria, Total Consideration และข้อกำหนดเกี่ยวกับการตรวจ Fairness ของราคาสำหรับ OTC Product ด้วย Market Data และ Comparable Products เมื่อเป็นไปได้

https://handbook.fca.org.uk/handbook/cobs11/cobs11s9

MetaQuotes — MQL5 Order Properties
ใช้ตรวจสอบ Price Execution Modes, Volume Filling Policies และข้อจำกัดว่าตลาดไม่ได้รับประกันว่าจะมี Volume ทั้งหมด ณ ราคาที่ต้องการเสมอ

https://www.mql5.com/en/docs/constants/tradingconstants/orderproperties

MetaQuotes — MqlTradeRequest Structure
ใช้ตรวจสอบ Fields ที่ใช้ใน Trade Request และข้อเท็จจริงว่า Market Order ภายใต้ Market Execution ไม่จำเป็นต้องระบุ Price ใน Request ขณะที่ Instant Execution ต้องระบุ Price

https://www.mql5.com/en/docs/constants/structures/mqltraderequest

MetaTrader 5 — Market Watch
ใช้ตรวจสอบว่า Trade Command ไม่ได้รับประกันว่าจะกลายเป็น Deal ทุกครั้ง รวมถึง Requote, Refusal, Fill Policy และ Allowable Price Deviation สำหรับ Instant Execution

https://www.metatrader5.com/en/terminal/help/trading/market_watch

MetaTrader 5 — One Click Trading
ใช้ตรวจสอบ Allowable Price Deviation และ Fill Policy ที่เกี่ยวข้องกับ Execution Mode

https://www.metatrader5.com/en/terminal/help/trading/one_click_trading

OANDA UK — Best Execution Reports
ใช้เป็นตัวอย่างของ Broker ที่เผยแพร่ Slippage Distribution รายไตรมาส แยกตาม Instrument และแบ่ง Adverse, No Slippage และ Beneficial Slippage เป็นช่วง

https://www.oanda.com/uk-en/legal/disclosures/

OANDA Europe Limited — MT5 Best Execution Slippage Report, April–June 2026
ใช้เป็น Case Study ของการนำเสนอ Slippage แบบ Distribution แทนการรายงาน Average เพียงตัวเดียว

https://www.oanda.com/assets/documents/2105/OEL_Best_Execution_Slippage_Report_MT5_April_-_June_2026.pdf

Pepperstone — Order Execution Policy
ใช้ตรวจสอบตัวอย่าง Broker Disclosure เรื่อง Slippage, Order Size, Thin Liquidity, Volatile Markets และ Partial Fill

https://files.pepperstone.com/legal/SCB/SCB_Order_Execution_Policy_ROW.pdf

IG — Best Execution
ใช้เป็นตัวอย่างการแยก Slippage ของ Stop Orders ออกจาก Limit Orders และการเปิดเผย Price Improvement/Execution Information

https://www.ig.com/en/best-execution

FXCM — Execution Transparency
ใช้ตรวจสอบตัวอย่างการนิยาม Broker-side Execution Speed ซึ่งเริ่มตั้งแต่ Broker ได้รับ Order จน Execution และไม่รวม Client Internet Latency

https://www.fxcm-markets.com/about-fxcm/execution-transparency/

FXCM — Slippage Statistics
ใช้เป็นกรณีศึกษาว่า Limit และ Stop Orders สามารถมี Positive/Negative Slippage Distribution แตกต่างกัน จึงไม่ควรรวม Order Type ทั้งหมดแล้วตีความจากสัดส่วนเดียว

https://www.fxcm-markets.com/about-fxcm/slippage-statistics/

---

ข้อจำกัดของการวิเคราะห์

Execution Audit จากบัญชีของ Trader เป็นการวิเคราะห์ข้อมูลที่ผู้ใช้สามารถสังเกตหรือบันทึกได้ ไม่ใช่การตรวจ Infrastructure, Liquidity Provider หรือระบบภายในทั้งหมดของ Broker

ผลจาก Account, Legal Entity, Platform หรือช่วงเวลาใดช่วงเวลาหนึ่งไม่ควรถูกนำไปสรุปว่าเป็น Execution Quality ของลูกค้าทุกคนภายใต้ Brand เดียวกัน

Metric เช่น Mean, Median, Percentile และ Execution Log Framework ในบทความเป็นวิธีวิเคราะห์ข้อมูล ไม่ใช่เกณฑ์ Regulatory Threshold และไม่ควรถูกใช้สร้างข้อกล่าวหาเรื่อง Manipulation หรือ Best Execution Breach โดยไม่มีหลักฐานเพิ่มเติม

คำเตือนเกี่ยวกับความเสี่ยง

Forex และ CFD ที่ใช้ Leverage มีความเสี่ยงสูงและสามารถทำให้สูญเสียเงินทุนได้ Slippage, Spread Expansion, Partial Fill และความล่าช้าในการ Execute สามารถเกิดขึ้นได้ โดยเฉพาะในช่วงที่ตลาดมีความผันผวนหรือสภาพคล่องเปลี่ยนแปลง

การทดสอบ Execution ด้วยเงินจริงมี Market Risk และไม่ควรเปิด Order เพิ่มเพียงเพื่อสร้าง Sample หากไม่สอดคล้องกับ Trading Plan

บทความนี้จัดทำขึ้นเพื่อการศึกษาและการวิเคราะห์ Execution Data ไม่ใช่การรับรอง Broker, การจัดอันดับ Broker หรือคำแนะนำทางการเงิน