ภาษาไทย
ขอสาธิต

การเฝ้าระวังตลาดการคาดการณ์และการตรวจจับการซื้อขายที่ผิดปกติ: ระบบป้องกันหลายชั้นต่อการซื้อขายโดยใช้ข้อมูลภายใน การซื้อขายเพื่อสร้างปริมาณการซื้อขาย การโจมตีแบบ Sybil และการโจมตีในช่วงหน้าต่างการชำระบัญชี

โครงสร้างพื้นฐานตลาดการคาดการณ์4 สิงหาคม 2569

ตลาดการคาดการณ์ (Prediction Market) ได้พัฒนาจากโครงการทดลองในวงการคริปโตไปสู่ผลิตภัณฑ์ทางการเงินหลักระหว่างปี 2024 ถึง 2026 แพลตฟอร์มต่าง ๆ เช่น Polymarket, Kalshi, Manifold และ Limitless ได้สะสมปริมาณการซื้อขายถึงหลายพันล้านดอลลาร์สหรัฐฯ ในเหตุการณ์สำคัญต่าง ๆ ที่ครอบคลุมการเลือกตั้งทางการเมือง กีฬา เศรษฐกิจมหภาค และราคาคริปโต ด้วยขนาดนี้ ตลาดการคาดการณ์จึงกลายเป็นเป้าหมายที่มีมูลค่าสูงสำหรับการบิดเบือนตลาด — แต่กลับถูกบิดเบือนได้ง่ายกว่าตลาดสปอตหรือตลาดฟิวเจอร์สแบบต่อเนื่อง

ทำไมตลาดการคาดการณ์จึงถูกควบคุมได้ง่ายกว่า? มีสามสาเหตุหลัก: 1) การชำระบัญชีเป็นแบบทวิภาค (binary) ทำให้ผลประโยชน์จากการควบคุมเพิ่มขึ้นแบบไม่เชิงเส้น; 2) ความสภาพคล่องต่ำ (โดยเฉพาะในเหตุการณ์ที่มีโอกาสเกิดขึ้นน้อย) ซึ่งคำสั่งซื้อขายเพียง 50,000 ดอลลาร์ก็สามารถผลักดันราคาจาก 0.30 เป็น 0.70 ได้; 3) ความไม่สมดุลของข้อมูลเป็นธรรมชาติ — นักการเมือง สมาชิกครอบครัวของนักกีฬา หรือผู้บริหารบริษัทมหาชนสามารถสร้างตำแหน่งได้ภายในไม่กี่นาทีก่อนที่ข้อมูลจะถูกเปิดเผยต่อสาธารณะ และได้รับผลตอบแทนจากข้อมูลภายในเกือบ 100% คุณสมบัติทั้งสามประการนี้เมื่อรวมกัน ทำให้ตลาดการคาดการณ์กลายเป็นจุดร้อนสำหรับการซื้อขายโดยใช้ข้อมูลภายใน การซื้อขายหลอก (wash trading) การโจมตีแบบ Sybil และการโจมตีในช่วงหน้าต่างการชำระบัญชี (settlement-window sniping)

สำหรับทีมที่ดำเนินการตลาดคาดการณ์ การเฝ้าระวังไม่ใช่เพียง “สิ่งที่ดีที่มี” อีกต่อไป — แต่เป็นพื้นฐานสำหรับการอยู่รอด แพลตฟอร์มที่หน่วยงานกำกับดูแลพบว่า “ยอมให้มีการบิดเบือน” จะต้องเผชิญกับค่าปรับ การเพิกถอนใบอนุญาต และการสูญเสียผู้ใช้; ส่วนแพลตฟอร์มที่ตลาดมองว่า “มีข้อมูลบิดเบือน” จะสูญเสียผู้ค้าข้อมูลและล้มหายตายจากไปเอง

บทความนี้เริ่มต้นจากเหตุผลทางโครงสร้างทางการเงินที่ทำให้ตลาดคาดการณ์สามารถถูกบิดเบือนได้ จากนั้นอธิบายภาพรวมของการบิดเบือน (การซื้อขายโดยใช้ข้อมูลภายใน, การซื้อขายล้างบัญชี, การโจมตีแบบ Sybil, การสปูฟฟิง, การกำหนดราคาปิด, การโจมตีออราเคิล) และนำเสนอสถาปัตยกรรมการตรวจจับแบบหลายชั้น (ระบบกฎ + การตรวจจับความผิดปกติทางสถิติ + อัลกอริทึมกราฟ + การเรียนรู้ของเครื่อง) พร้อมการนำไปใช้ทางวิศวกรรมอย่างครบถ้วน บทความนี้ครอบคลุมการจัดระดับการแจ้งเตือน (alert tiering), กระบวนการตรวจสอบโดยมนุษย์ (human review workflows), มาตรการบังคับใช้ (จำกัดตำแหน่ง, ยกเลิกคำสั่งซื้อขาย, ยกเลิกตลาด, การล่าช้าในการชำระบัญชี), การแก้ไขข้อพิพาทด้วย oracle แบบมองโลกในแง่ดี (optimistic oracles) ตามสไตล์ UMA, ความสามารถในการอธิบาย (explainability) และห่วงโซ่หลักฐาน (evidence chains), การรายงานตามกฎระเบียบในภูมิภาคเอเชียตะวันออกเฉียงใต้ (SC Malaysia, BAPPEBTI/OJK Indonesia, SEC Thailand, MAS สิงคโปร์) รวมถึงสถาปัตยกรรมทางวิศวกรรมที่ใช้ Flink/Kafka และฐานข้อมูลกราฟ โดยสรุปด้วยโซลูชันที่พัฒนาเป็นผลิตภัณฑ์ของ SoonTech ไม่ว่าคุณจะเป็นผู้นำผลิตภัณฑ์ ผู้อำนวยการด้านความเสี่ยง หัวหน้าฝ่ายการปฏิบัติตามกฎระเบียบ หรือสถาปนิก CTO ของตลาดการคาดการณ์ หลังจากอ่านบทความนี้ คุณจะได้รับกรอบงานที่ครบถ้วนซึ่งสามารถนำไปใช้งานได้ทันที

1. ทำไมตลาดการคาดการณ์จึงมีแนวโน้มที่จะถูกบิดเบือนได้ง่ายโดยธรรมชาติ

1.1 สามสาเหตุหลัก

สาเหตุที่ 1: การชำระบัญชีเป็นแบบทวิภาคี และกำไรถูกขยายตัวแบบไม่เชิงเส้น ในตลาดสปอตหรือตลาดฟิวเจอร์สแบบถาวร การผลักดันราคาขึ้น 1% จะให้ผลต่างเพียง 1% เท่านั้น ในสัญญาแบบไบนารี "Yes" การดันราคาจาก 0.30 เป็น 0.90 หมายความว่า "ต้นทุนตำแหน่ง 0.30, การชำระบัญชีที่อาจเกิดขึ้น 1.00, ผลตอบแทน 200% บนเลเวอเรจ 3 เท่า" ผู้ควบคุมราคาที่ใช้ทุนเท่ากันสามารถได้รับผลตอบแทนจากธุรกรรมสูงกว่าหลายเท่าเมื่อเทียบกับผู้ควบคุมราคาในตลาดสปอต

สาเหตุที่ 2: ความสภาพคล่องต่ำ และคำสั่งซื้อขายเพียงหนึ่งคำสั่งก็สามารถกำหนดราคาได้ ตลาดเหตุการณ์แบบ long-tail หลัก (เช่น "พรรคเดโมแครตจะพลิกผลการเลือกตั้งเขตที่ 7 ในการเลือกตั้งสภาผู้แทนราษฎรสหรัฐฯ ปี 2026 ได้หรือไม่?") อาจมีความลึกของตลาดที่รออยู่เพียง $20,000–$30,000 เท่านั้น คำสั่งตลาดมูลค่า $10,000 สามารถผลักดันราคาให้เปลี่ยนแปลงได้ 30–50 basis points แพลตฟอร์มหลักอย่าง Polymarket และ Kalshi อาจมีปริมาณการซื้อขายรายวันถึง $50 million สำหรับเหตุการณ์ที่ได้รับความนิยม แต่สำหรับ 95% ของเหตุการณ์ ปริมาณการซื้อขายรายวันอยู่ต่ำกว่า $50,000

สาเหตุที่ 3: ความไม่สมดุลของข้อมูลเป็นธรรมชาติและยากที่จะขจัดให้หมดไป ผลลัพธ์ของเหตุการณ์ในตลาดคาดการณ์มักเป็นที่รู้กันโดยกลุ่มคนจำนวนน้อยมาก — เช่น ความตั้งใจในการลงคะแนนของสมาชิกสภาผู้แทนราษฎร รายชื่อผู้เล่นตัวจริงของทีมกีฬา หรือข้อมูลเศรษฐกิจที่รั่วไหล กลุ่มคนเหล่านี้สามารถเปิดตำแหน่งได้ 5–10 นาทีก่อนที่ข้อมูลจะถูกเปิดเผยต่อสาธารณะ และได้รับผลตอบแทนจากข้อมูลวงในเกือบ 100% ในระบบการเงินแบบดั้งเดิม การ "ซื้อขายโดยใช้ข้อมูลภายใน" แบบนี้จะถูกตรวจจับและสอบสวนโดยระบบ SMARTS ของ SEC และระบบเฝ้าระวังของ FINRA; ส่วนในตลาดคาดการณ์ ชั้นโปรโตคอลแทบไม่สามารถแยกแยะการวิจัยที่ถูกต้องตามกฎหมายจากการซื้อขายโดยใช้ข้อมูลภายในได้ เมื่อข้อได้เปรียบด้านข้อมูลใน "ช่วงสุดท้าย" เป็นประเด็นสำคัญ

1.2 การเปรียบเทียบกับตลาดสปอต

มิติตลาดสปอต / สัญญาถาวรตลาดคาดการณ์เส้นโค้งผลตอบแทน

เชิงเส้น, สเปรด 1% = ผลตอบแทน 1%

แบบไม่เชิงเส้น, 0.30→0.90 = ผลตอบแทน 200%

สภาพคล่อง

คู่สกุลเงินหลักมักมีความลึกของตลาดมากกว่า $50M ใน 24 ชั่วโมง

95% ของเหตุการณ์มีปริมาณการซื้อขายรายวันต่ำกว่า $50K

การชำระบัญชี

การกำหนดราคาแบบต่อเนื่อง, ปิดการซื้อขายได้ทุกเวลา

ผลลัพธ์แบบไบนารี / แบบไม่ต่อเนื่อง, ปิดการชำระเมื่อถึงวันหมดอายุ

แหล่งข้อมูล

ข้อมูลสาธารณะขนาดใหญ่ + ตัวชี้วัดบนเชน

ผู้รู้ข้อมูลภายในน้อยมาก + ข่าวสาธารณะ

แรงจูงใจในการสร้างตลาด

HFT และ MM แข่งขันกันอย่างดุเดือด

ไม่มีผู้เชี่ยวชาญในตลาดแบบ long-tail

การติดตามหลังการแทรกแซง

หน่วยงานกำกับดูแลที่พัฒนาแล้ว และหน่วยกำกับดูแลตลาด

กรอบกฎหมายยังอยู่ในขั้นตอนการจัดตั้ง

1.3 ต้นทุนจริงและผลประโยชน์ที่อาจเกิดขึ้นจากการแทรกแซง

ชุดข้อมูลเพื่ออธิบายว่าทำไมตลาดการคาดการณ์จึงเป็นเป้าหมายการโจมตีที่ "ต้นทุนต่ำ ผลตอบแทนสูง" สมมติว่าผู้ปั่นตลาดมีข้อมูลที่ไม่เปิดเผยต่อสาธารณะ เหตุการณ์จะสิ้นสุดใน 30 นาที ราคา "Yes" ปัจจุบันคือ 0.40 (ตลาดยังไม่ได้สะท้อนผลลัพธ์ที่แท้จริง 0.95) และผู้ปั่นตลาดใช้เงิน $50,000 เพื่อซื้อ "Yes" เมื่อถึงเวลาชำระบัญชี พวกเขาจะได้รับ $50,000 / 0.40 = 125,000 หุ้น "Yes" ซึ่งสามารถขายคืนที่ราคา 1.00 = $125,000 กำไรสุทธิ $75,000 อัตราผลตอบแทนใน 30 นาที 150% แม้จะหักลด 5% สำหรับการลื่นราคา (slippage), 2% สำหรับค่าธรรมเนียม และ 10% สำหรับความน่าจะเป็นที่จะถูกบล็อกโดยระบบเฝ้าระวัง ผลตอบแทนที่คาดการณ์ได้ก็ยังคงเกิน 50%

นี่คือเหตุผลที่ในตลาดการคาดการณ์มูลค่า $600M ผู้โจมตีจะลงทุนหลายแสนดอลลาร์ในการวิจัย การซื้อขายหลอก และการปั่นราคา: ตราบใดที่พวกเขาประสบความสำเร็จเพียงครั้งเดียว ผลตอบแทนก็เพียงพอที่จะครอบคลุมค่าใช้จ่ายทั้งปี เมื่อ SoonTech พัฒนาโซลูชันการเฝ้าระวังสำหรับลูกค้าในเอเชียตะวันออกเฉียงใต้ เราเน้นย้ำซ้ำแล้วซ้ำอีกว่า "ผลตอบแทนจากการลงทุน (ROI) ของการเฝ้าระวังไม่ใช่ศูนย์ต้นทุน แต่เป็นพื้นฐานการอยู่รอดของแพลตฟอร์ม"

2. ภาพรวมการบิดเบือน: จากการซื้อขายโดยใช้ข้อมูลภายใน ไปจนถึงการโจมตีในช่วงหน้าต่างการชำระบัญชี

2.1 การจัดประเภทเทคนิคการบิดเบือนตลาด

เทคนิค พฤติกรรมทั่วไป ระดับความรุนแรง ท่าทีของหน่วยงานกำกับดูแล การซื้อขายโดยใช้ข้อมูลภายใน

สร้างตำแหน่งก่อนที่ข้อมูลจะเปิดเผยต่อสาธารณะ

รุนแรง

ผิดกฎหมายอย่างชัดเจนในเขตอำนาจส่วนใหญ่

การซื้อขายล้างบัญชี

บัญชีที่เกี่ยวข้องทำการซื้อขายไปมา

สูง

ผิดกฎหมายอย่างชัดเจนในเขตอำนาจส่วนใหญ่

การซื้อขายกับบัญชีตัวเอง

บัญชีเดียวกันทำการซื้อขายกับตัวเอง

สูง

ถูกห้ามอย่างชัดเจนตามกฎของแพลตฟอร์ม

การเชื่อมโยงหลายบัญชี / Sybil

บุคคลธรรมดาหนึ่งคนควบคุมบัญชีหลายบัญชี

สูง

ละเมิดเงื่อนไขการใช้บริการ (ToS) ของแพลตฟอร์ม

การปลอมแปลง

การสั่งซื้อในปริมาณมากแล้วถูกยกเลิกเพื่อสร้างภาพความลึกที่ปลอม

ระดับกลาง

ถูกกำหนดอย่างชัดเจนโดย CFTC ของสหรัฐอเมริกา

สภาพคล่องเทียม / การจัดชั้น

คำสั่งหลายระดับเพื่อสร้างภาพความลึกตลาดปลอม

ระดับกลาง

อยู่ภายใต้การกำกับดูแลของ CFTC / FCA

การกำหนดราคาปิด

การซื้อที่กระจุกตัวในไม่กี่นาทีก่อนการตั้งราคาปิด

ระดับสุดขั้ว

การปั่นตลาดแบบคลาสสิก

การอาร์บิทราจเพื่อรับรางวัล / การฟาร์มแอร์ดรอป

การหาประโยชน์จากรางวัลของแพลตฟอร์ม

ระดับกลาง

ละเมิดเงื่อนไขการใช้บริการ

Oracle / การจัดการแหล่งที่มาของค่าความละเอียด

การโจมตีหรือการให้สินบนแหล่งข้อมูล

ระดับสูง

ความผิดทางอาญา

การบิดเบือนข่าวลือ

ข่าวปลอมที่สอดคล้องกับจุดยืน

สูง

ผิดกฎหมายในเขตอำนาจส่วนใหญ่

2.2 “5 นาทีทอง” ของช่วงเวลาการตั้งราคา

ความแตกต่างที่ใหญ่ที่สุดระหว่างตลาดการคาดการณ์กับสัญญาซื้อขายทันที / สัญญาต่อเนื่อง คือ "ช่วงเวลาการตัดสิน" — ช่วงไม่กี่นาทีถึงไม่กี่สิบนาทีก่อนที่เหตุการณ์จะสิ้นสุดลง เป็นช่วงเวลาที่มีโอกาสเกิดการโจมตีสูงที่สุด มีสามเหตุผล:

  1. สภาพคล่องลดลงอย่างรวดเร็ว (ผู้ค้าอื่น ๆ ได้ปิดตำแหน่งหรือกำลังรอชม);
  2. ข้อมูลสาธารณะยังไม่ถูกวิเคราะห์อย่างครบถ้วน (การประกาศอย่างเป็นทางการ / การเผยแพร่ข้อมูลมีความล่าช้า);
  3. ผู้ควบคุมตลาดมีข้อมูลอยู่ในมือแล้วและรอ "วินาทีสุดท้าย" เพื่อเพิ่มผลตอบแทนให้สูงสุด

ในสภาพแวดล้อมการผลิต SoonTech สังเกตว่าประมาณ 68% ของการซื้อขายที่ผิดปกติอย่างชัดเจนเกิดขึ้นในช่วง 60 นาทีสุดท้ายก่อนที่เหตุการณ์จะสิ้นสุด และ 42% เกิดขึ้นในช่วง 5 นาทีสุดท้าย ระบบเฝ้าระวังต้องเข้าสู่ "โหมดความกดดันสูง" ในช่วงหน้าต่างการแก้ไข — ใช้เกณฑ์ความไวที่สูงขึ้น, การแจ้งเตือนที่ถี่ขึ้น, และการแทรกแซงของมนุษย์ที่มีลำดับความสำคัญสูงขึ้น

2.3 การอุตสาหกรรมของผู้ควบคุมตลาด

หลังปี 2025 การแทรกแซงตลาดการคาดการณ์จะไม่ใช่การโจมตีแบบ "บุคคลเดียวดำเนินการด้วยมือ" ในสไตล์เวิร์กช็อปอีกต่อไป เราสังเกตเห็นแนวโน้มการอุตสาหกรรมสามประการ:

  • ฝูงบอท: ผู้โจมตีใช้สคริปต์เพื่อควบคุมบัญชีหลายสิบถึงหลายร้อยบัญชีพร้อมกัน โดยประสานตำแหน่งและเวลา;
  • การจัดเตรียมข้อมูลล่วงหน้า: การรับสมัคร "ผู้ค้าข้อมูล" บน Twitter, กลุ่ม Telegram และช่อง Discord โดยแบ่งปันผลกำไรตามผลลัพธ์;
  • การซิงโครไนซ์ข้ามแพลตฟอร์ม: ใช้ข้อมูลเดียวกันเพื่อสร้างตำแหน่งอย่างพร้อมกันบน Polymarket, Kalshi, Limitless, Opinion และแพลตฟอร์มอื่น ๆ เพื่อกระจายความเสี่ยง

สิ่งนี้ทำให้ระบบเฝ้าระวังต้องดำเนินการวิเคราะห์ความสัมพันธ์ทั้งในมิติ "กลุ่มบัญชี" และ "ข้ามแพลตฟอร์ม" — การแจ้งเตือนตามเกณฑ์ของบัญชีเดียวนั้นยังไม่เพียงพอเลย

3. แบบจำลองการตรวจจับการซื้อขายโดยใช้ข้อมูลภายใน

3.1 สามลักษณะของการซื้อขายข้อมูลภายใน

ความแตกต่างหลักระหว่างการซื้อขายภายในตลาดคาดการณ์ (prediction market) และการซื้อขายภายในตลาดสปอต (spot market) อยู่ที่ "ความเร็วในการรวมตัวของราคา" หลังจากข้อมูลสาธารณะถูกเปิดเผย ราคาในตลาดคาดการณ์ควรปรับตัวเข้าใกล้ 0 หรือ 1 อย่างรวดเร็ว หากก่อนการเปิดเผยข้อมูลสาธารณะ ราคาได้แสดง "การเคลื่อนที่ตามทิศทาง" ที่สอดคล้องกับผลลัพธ์สุดท้าย และบัญชีที่สร้างตำแหน่งดังกล่าวมี "หลักฐานการเชื่อมโยงล่วงหน้า" การซื้อขายโดยใช้ข้อมูลภายในจะถูกสงสัยอย่างสูง

ลักษณะที่ 1: การเคลื่อนที่ก่อนเหตุการณ์ ราคาแสดงการเคลื่อนที่ตามทิศทางที่เกินค่าเกณฑ์ (เช่น 10bp) ภายใน 60 นาทีก่อนการเปิดเผยข้อมูลสาธารณะ และทิศทางดังกล่าวสอดคล้องกับผลลัพธ์สุดท้าย

ลักษณะที่ 2: ความสัมพันธ์ทางเวลา การเคลื่อนไหวของราคาในช่วงเวลาดังกล่าวมีความสัมพันธ์อย่างสูงกับ “เวลาที่แหล่งข้อมูลเริ่มมีอยู่” ตัวอย่างเช่น รายชื่อผู้เล่นตัวจริงของทีมบาสเกตบอลถูกประกาศ 30 นาทีก่อนเริ่มการแข่งขัน แต่บัญชีบางบัญชีได้สร้างตำแหน่งไว้แล้ว 60 นาทีก่อนเริ่มการแข่งขัน

ลักษณะที่ 3: การรวมกลุ่มบัญชี (Account clustering). บัญชีหลายบัญชีสร้างตำแหน่งในทิศทางเดียวกันในช่วงเวลาที่ใกล้เคียงกัน และมีหลักฐานความเกี่ยวข้อง (ความคล้ายคลึงของอุปกรณ์ / IP / เงินทุน / พฤติกรรม) ระหว่างบัญชีเหล่านั้น

3.2 การวิศวกรรมคุณลักษณะ: ตารางสัญญาณการซื้อขายภายใน

คุณสมบัติความหมายค่าเกณฑ์ที่แนะนำน้ำหนักpre_event_price_drift

การเคลื่อนไหวของราคาในทิศทางเดียวสูงสุดในช่วง 60 นาทีที่ผ่านมา

> 10bp

0.20

volume_spike_ratio

ปริมาณการซื้อขายใน 30 นาทีที่ผ่านมา / ค่าเฉลี่ยของช่วงเวลาเดียวกันในอดีต

> 5x

0.15

account_count_cluster

จำนวนบัญชีที่เพิ่มตำแหน่งในทิศทางเดียวกัน

> 5

0.15

info_source_timing

ช่องว่างระหว่างเวลาที่แหล่งข้อมูลเปิดเผยข้อมูลกับเวลาที่เริ่มสร้างตำแหน่ง

< 30 นาที

0.20

pnl_to_volume_ratio

กำไร/ขาดทุน (PnL) / ปริมาณการซื้อขาย

> 0.30

0.10

account_age

จำนวนวันนับตั้งแต่การลงทะเบียนบัญชี

< 7 วัน

0.05

device_reuse_count

จำนวนบัญชีอื่นที่ใช้ลายนิ้วมืออุปกรณ์เดียวกัน

> 1

0.10

cross_platform_match

อุปกรณ์/IP เดียวกันเคยแสดงพฤติกรรมคล้ายกันบนแพลตฟอร์มอื่น

ใช่

0.05

ผลรวมของน้ำหนักคือ 1.0 คะแนนต่อบัญชี = Σ(ค่าคุณสมบัติที่ปรับมาตรฐาน × น้ำหนัก) คะแนน > 0.65 จะทริกเกอร์การแจ้งเตือนระดับสูง

3.3 การตรวจจับความผิดปกติในข้อมูลอนุกรมเวลา

ในการระบุการเบี่ยงเบนก่อนเกิดเหตุการณ์ การแจ้งเตือนด้วยค่าเกณฑ์จุดเดียวมักพลาดการปรับแต่งแบบ "การสะสมอย่างช้าๆ" เราแนะนำให้ใช้การตรวจจับความผิดปกติของข้อมูลอนุกรมเวลา:

  • CUSUM / Page-Hinkley: ตรวจจับการเปลี่ยนแปลงสะสมในค่าเฉลี่ย / ความแปรปรวนของราคา ซึ่งไวต่อการเบี่ยงเบนแบบช้า;
  • Prophet / STL: สร้างแบบจำลองความผันผวนตามช่วงเวลา "ปกติ" ของราคา (ก่อนเกม vs ระหว่างเกม, ก่อน/หลังการประกาศข้อมูลเศรษฐกิจมหภาค), ตรวจจับความผิดปกติที่เหลืออยู่;
  • Bayesian change-point: การตรวจจับจุดเปลี่ยนใน distribution ของราคาแบบออนไลน์ ซึ่งเหมาะสำหรับสถานการณ์ที่ต้องการความหน่วงต่ำ

3.4 การจัดเรียงเวลาให้สอดคล้องกับแหล่งข้อมูลเหตุการณ์

ระบบการเฝ้าระวังต้องรักษา "เส้นเวลาของแหล่งข้อมูลเหตุการณ์" ไว้:

  • เกมบาสเกตบอล: เวลาเริ่มเกม, การประกาศรายชื่อผู้เล่น, เวลาทำคะแนน;
  • การเลือกตั้งทางการเมือง: การอภิปราย, เวลาปิดการลงคะแนน, การประกาศผล;
  • จุดข้อมูลระดับมหภาค: เวลาประกาศ (ตามเขตเวลาอย่างเป็นทางการ)

ทุกเหตุการณ์ที่เกี่ยวข้องกับการสร้างตำแหน่งจะถูกจัดให้สอดคล้องกับเส้นเวลาดังกล่าว และจะคำนวณ "ความแตกต่างของเวลาจากแหล่งข้อมูลเหตุการณ์ที่ใกล้ที่สุด" หากมีบัญชีหลายบัญชีสร้างตำแหน่งก่อน 30 นาทีขึ้นไป ก่อนที่แหล่งข้อมูลเหตุการณ์ที่มีมูลค่าข้อมูลภายในสูง (รายชื่อผู้เล่นตัวจริง, การลงคะแนนภายใน, ข้อมูลเศรษฐกิจ) จะถูกเปิดเผยต่อสาธารณะ ความน่าจะเป็นของการซื้อขายโดยใช้ข้อมูลภายในจะเพิ่มขึ้นอย่างมีนัยสำคัญ

4. การตรวจจับการซื้อขายล้าง (Wash Trading) และการจับคู่ซื้อขายด้วยตนเอง (Self-Match)

4.1 คำนิยามและผลกระทบของการซื้อขายล้าง

การซื้อขายแบบวอช (Wash Trading) คือการที่บัญชีต่าง ๆ ซื้อขายกันเองเพื่อสร้างปริมาณการซื้อขายและราคาปลอม ในตลาดคาดการณ์ การซื้อขายแบบวอชมักมีวัตถุประสงค์สองประการ:

  1. การเก็บเกี่ยวรางวัลจาก Airdrop / การหาประโยชน์จากส่วนต่างของรางวัล: แพลตฟอร์มให้รางวัลตามปริมาณการซื้อขาย และการซื้อขายปลอมสามารถสร้าง "พฤติกรรมผู้ใช้จริง" ได้ด้วยต้นทุนเป็นศูนย์ (หรือติดลบเล็กน้อยหลังหักค่าธรรมเนียม);
  2. การควบคุมราคา / การรับรู้สภาพสภาพคล่อง: การสร้างภาพ "ตลาดที่คึกคัก" เพื่อล่อผู้ค้าอื่น ๆ หรือผลักดันราคาเสนอของผู้สร้างตลาดให้เข้าใกล้เป้าหมายของผู้ควบคุมราคา

การซื้อขายแบบจับคู่ตัวเอง (Self-match) เป็นรูปแบบพิเศษของการซื้อขายล้าง — บัญชีที่อยู่ภายใต้ผู้ควบคุมเดียวกันทำการซื้อขายกันเอง หรือบัญชีเดียวกันทำการซื้อขายกับตัวเอง (ในระบบจับคู่ที่สนับสนุนตำแหน่งสองด้าน)

4.2 คุณลักษณะการตรวจจับ

คุณสมบัติความหมายค่าเกณฑ์ที่แนะนำself_match_rate

ปริมาณการซื้อขายจากบัญชีที่เกี่ยวข้อง / ปริมาณการซื้อขายรวมของบัญชี

> 30%

round_trip_pnl

ผลรวม PnL ของคู่การซื้อขายแบบวงจรปิด

ใกล้ 0 (±0.5%)

time_to_close

เวลาตั้งแต่เปิดตำแหน่งจนถึงปิดตำแหน่ง

< 5 นาที

price_unchanged

การเปลี่ยนแปลงราคาช่วงกลางก่อนและหลังการซื้อขาย

< 0.5%

volume_to_unique_accounts

ปริมาณรวม / จำนวนบัญชีคู่ค้าที่ไม่ซ้ำกัน

> 10x

round_trip_count

จำนวนการซื้อขายแบบวงจรปิดของกลุ่มบัญชีเดียวกันภายใน 24 ชั่วโมง

> 5

cross_market_correlation

การซื้อขายล้างบัญชีแบบซิงโครไนซ์ข้ามตลาด

มีความสัมพันธ์สูง

อัตราจับคู่เอง = ปริมาณจากคู่สัญญาในบัญชีที่เกี่ยวข้อง / ปริมาณรวมของบัญชี เมื่อเกิน 30% จะมีการแจ้งเตือนระดับกลาง

4.3 อัลกอริทึมตรวจจับวงจรปิด

การตรวจจับแบบวงจรปิด (Round-Trip Detection) ติดตามลำดับ "ซื้อ-ถือ-ขาย" ของแต่ละบัญชี เพื่อระบุวงจร "A ขายให้ B, B ขายกลับให้ A" หรือ "A→B→C→A" เราใช้อัลกอริทึมกราฟ:

  1. สร้างกราฟมีทิศทางของบัญชี × เวลา โดยแต่ละขอบเป็นกิจกรรม "ขาย";
  2. ตรวจหาทุกวงจรที่มีความยาว ≤ 5 (วงจรสั้นมีจำนวนมากกว่าวงจรยาวอย่างมีนัยสำคัญ = น่าสงสัย);
  3. สำหรับแต่ละวงจร คำนวณ PnL รวม การเปลี่ยนแปลงราคา และระยะเวลา แล้วออกคะแนนความน่าสงสัย

บัญชีพันธมิตรที่รู้จัก (มี KYC ID เดียวกัน, ลายนิ้วมืออุปกรณ์เดียวกัน, กลุ่มที่อยู่บนเชนเดียวกัน) จะได้รับการให้น้ำหนักสูงกว่า สำหรับบัญชีที่ยังไม่ได้รับการระบุตัวตนแต่มีลักษณะคล้ายกัน จะใช้เทคนิคการฝังกราฟ (graph embedding) เพื่อจัดกลุ่มบัญชีที่เป็นไปได้ ก่อนที่จะส่งให้เจ้าหน้าที่ตรวจสอบด้วยมือ

4.4 รูปแบบการซื้อขายล้างที่มีต้นทุนต่ำ

การซื้อขายล้างแบบอุตสาหกรรมไม่ทิ้งรูปแบบ "A→B→A" ที่ชัดเจน แต่ใช้โครงสร้างที่ซับซ้อนกว่า:

  • Wash trading แบบรีเลย์: A→B→C→D→E, A ได้รับกำไรจากส่วนต่างราคา 5%, B–E แต่ละฝ่ายได้รับ 1%, แต่ทุนจะกลับสู่ที่อยู่บนเชนที่ A ควบคุมในที่สุด;
  • Time offset: A ขายให้ B ที่ T0, B ขายให้ C ที่ T0+10, C ขายให้ A ที่ T0+20, ทั้งสามการซื้อขายมีราคาที่เกือบเท่ากัน;
  • การล้างข้ามตลาด: A ขาย outcome_1 ให้ B ในตลาด X, B ขาย outcome_1 ให้ C ในตลาด Y, C ขาย outcome_1 ให้ A ในตลาด X.

การตรวจจับรูปแบบเหล่านี้ต้องการอัลกอริทึมกราฟที่ซับซ้อนยิ่งขึ้น (กราฟที่ไม่เป็นเนื้อเดียวกันระหว่างบัญชี-ตลาด-เวลา) และโมเดลลำดับพฤติกรรม (Transformer)

5. การตรวจจับการเชื่อมโยงบัญชีหลายบัญชีและการโจมตีแบบ Sybil

5.1 มิติการเชื่อมโยง

ในระบบผลิตจริง SoonTech ใช้ห้ามิติสำหรับการเชื่อมโยงบัญชี โดยน้ำหนักถูกปรับแต่งตามป้ายกำกับจากผู้เชี่ยวชาญด้านการป้องกันการฉ้อโกง:

มิติ สัญญาณ น้ำหนัก ตัวอย่าง ลายนิ้วมืออุปกรณ์

ID อุปกรณ์, UA, ความละเอียดหน้าจอ, แบบอักษร, ลายนิ้วมือแคนวาส

0.25

โทรศัพท์เครื่องเดียวกันควบคุมบัญชี 10 บัญชี

IP และเครือข่าย

IP, ช่วง IP, ASN, MAC Wi-Fi, จุดออก VPN/Tor

0.20

5 บัญชีที่เชื่อมต่อกับเครือข่าย Wi-Fi ที่บ้านเดียวกัน

การไหลของเงิน

ที่อยู่การฝากบนเชน, ที่อยู่การถอนบนเชน, กราฟพฤติกรรมบนเชน

0.25

หลายบัญชีที่รับเงินทุนจากที่อยู่เดียวกัน

ความคล้ายคลึงของพฤติกรรม

รูปแบบเวลาการซื้อขาย รูปแบบคำสั่งซื้อขาย ระดับความทนต่อสลิปเปจ จังหวะการใช้งาน UI

0.15

บัญชีที่ควบคุมโดยสคริปต์เดียวกัน

KYC และข้อมูลเมตา

หมายเลข ID, เบอร์โทรศัพท์, อีเมล, บัตรธนาคาร, ผู้แนะนำ

0.15

ใช้ ID เดียวกันเปิดบัญชีหลายบัญชี

คะแนนความเกี่ยวข้อง = Σ(ค่ามิติที่ปรับมาตรฐาน × น้ำหนัก). คะแนน > 0.70 ถือว่ามีความเกี่ยวข้องสูง (หนึ่งคนมีหลายบัญชี), 0.50–0.70 ถือว่ามีความเกี่ยวข้องที่น่าสงสัย

5.2 รายละเอียดการนำลายนิ้วมืออุปกรณ์ไปใช้

การระบุลายนิ้วมืออุปกรณ์ไม่สามารถพึ่งพาเพียง IP หรือคุกกี้ได้เท่านั้น แต่ต้องรวมสัญญาณหลายมิติเข้าด้วยกัน:

  • ชั้นฮาร์ดแวร์: ความละเอียดหน้าจอ, อัตราส่วนพิกเซล, รุ่น GPU, จำนวนแกน CPU, หน่วยความจำ, แบตเตอรี่;
  • ชั้นซอฟต์แวร์: UA, ภาษา, เขตเวลา, ฟอนต์ที่ติดตั้ง, ลายนิ้วมือการเรนเดอร์ Canvas/WebGL, ลายนิ้วมือ AudioContext;
  • ชั้นพฤติกรรม: เส้นทางการเคลื่อนที่ของเมาส์, จังหวะการกดคีย์บอร์ด, แรงกดคลิก (มือถือ), ไจโรสโคป (มือถือ);
  • ชั้นเครือข่าย: IP, ASN, Wi-Fi BSSID (มือถือ), ช่วง IP, ลายนิ้วมือ TCP.

SDK ลายนิ้วมืออุปกรณ์ของ SoonTech บรรลุความเสถียรในการระบุอุปกรณ์เดียวกันที่ 99.5% บนอุปกรณ์มือถือ (โทรศัพท์เดียวกัน การเปิดแอปหลายครั้งยังคงเสถียร) และการระบุข้ามอุปกรณ์ (บุคคลเดียว อุปกรณ์หลายเครื่อง) ได้รับการเสริมด้วยลักษณะพฤติกรรมที่คล้ายคลึงกัน

5.3 การจัดกลุ่มที่อยู่บนเชน

เวอร์ชันบนเชนของตลาดคาดการณ์ (โดยเฉพาะที่สร้างบน Polygon, Base, Arbitrum) มีที่อยู่ฝาก/ถอนจำนวนมาก และการจัดกลุ่มที่อยู่ถือเป็น "เหมืองทอง" สำหรับการเชื่อมโยงบัญชี:

  • การใช้จ่ายร่วมกัน: หลายที่อยู่ถูกใช้เป็นอินพุตของธุรกรรมเดียวกัน ซึ่งน่าจะอยู่ภายใต้การควบคุมเดียวกัน;
  • ที่อยู่รับเงินทอน: การระบุรูปแบบเงินทอน (ผลลัพธ์หนึ่งของการทำธุรกรรมมีมูลค่าต่ำกว่าผลลัพธ์อื่น ๆ อย่างมาก และยังไม่ถูกใช้จ่าย);
  • ที่อยู่ร้อนของแพลตฟอร์มแลกเปลี่ยน: การถอนเงินจากแพลตฟอร์มแลกเปลี่ยนเดียวกันไปยังที่อยู่ของแพลตฟอร์มต่าง ๆ;
  • ป้ายกำกับของ Mixer: ที่อยู่ที่มีโปรโตคอลความเป็นส่วนตัว (Tornado Cash, Railgun) มีป้ายกำกับพิเศษ;
  • NFT / เครือข่ายสังคม: การถือครอง NFT ในกระเป๋าเงิน และความสัมพันธ์ทางสังคมบนเชนเป็นสัญญาณเสริม

SoonTech ร่วมมือกับ Chainalysis, Elliptic, TRM Labs และผู้ให้บริการวิเคราะห์บนเชนอื่น ๆ และได้พัฒนาโมเดลการจัดกลุ่มที่อยู่ภายในบริษัทเอง ซึ่งครอบคลุมเชนหลักและ L2 กว่า 30 ตัว

5.4 ความคล้ายคลึงด้านพฤติกรรม

ความคล้ายคลึงด้านพฤติกรรมถูกใช้เพื่อระบุบัญชีที่ควบคุมโดย "สคริปต์เดียวกัน / กลุ่มเดียวกัน" ลักษณะทั่วไป:

  • รูปแบบเวลา: การกระจายตัวของชั่วโมงซื้อขาย, สถิติระยะเวลาที่ใช้งาน (สคริปต์เดียวกันมักใช้งานในช่วงเวลาที่กำหนด);
  • รูปแบบคำสั่ง: การกระจายของความเบี่ยงเบนราคาคำสั่งจากราคาเฉลี่ย, อัตราการยกเลิก, เวลาตั้งแต่ยกเลิกจนถึงการจับคู่คำสั่ง;
  • จังหวะการซื้อขาย: การกระจายของช่วงเวลาที่ห่างกันระหว่างการซื้อขายที่ติดกัน, การกระจายของขนาดคำสั่ง;
  • การกู้คืนข้อผิดพลาด: รูปแบบการลองใหม่หลังการล้มเหลวของเครือข่าย, ลายเซ็นการเรียก API

เราใช้ออโต้เอ็นโคเดอร์ (autoencoder) สำหรับการฝังข้อมูลพฤติกรรม; บัญชีที่มีพฤติกรรมคล้ายกันจะมีระยะห่างในพื้นที่ฝังข้อมูลที่น้อยกว่าอย่างมีนัยสำคัญเมื่อเทียบกับบัญชีที่ไม่เกี่ยวข้องกัน

5.5 ห่วงโซ่อุตสาหกรรมของการโจมตีแบบ Sybil

ตั้งแต่ปี 2025 การโจมตีแบบ Sybil ในตลาดการคาดการณ์ได้ก่อตัวเป็นห่วงโซ่อุตสาหกรรม:

  • ฟาร์มบัญชี: ลงทะเบียนบัญชีแบบกลุ่ม, เชื่อมต่อหมายเลขโทรศัพท์, ผ่านการตรวจสอบใบหน้า (บนบางแพลตฟอร์ม), และดูแลบัญชี;
  • ฟาร์มอุปกรณ์: โทรศัพท์/แท็บเล็ตที่ควบคุมโดยกลุ่ม, เครื่องจำลอง, เครื่องมือปรับเปลี่ยนอุปกรณ์;
  • ช่องทางจัดหาเงินทุน: เติมเงินเข้าบัญชีหลายบัญชีผ่าน OTC desks, OTC, PayPal/บัญชีธนาคาร;
  • การหลีกเลี่ยง KYC: ใช้ "white hats" ในเอเชียตะวันออกเฉียงใต้ แอฟริกา และอเมริกาใต้ เพื่อผ่านการตรวจสอบใบหน้าแทน;
  • การประสานงานการตัดสินใจ: ประสานเวลาการสั่งซื้อ, ตำแหน่ง, และจังหวะการยกเลิกคำสั่งผ่านกลุ่ม Telegram และการสนทนาที่เข้ารหัส

โมเดลการตรวจจับ Sybil ของ SoonTech หลังจากถูกนำไปใช้กับลูกค้าในเอเชียตะวันออกเฉียงใต้ในปี 2025 ได้ตรวจพบและแบนกลุ่มบัญชี Sybil จำนวน 4,200 กลุ่มภายใน 3 เดือน ช่วยกู้คืนความสูญเสียที่อาจเกิดขึ้นได้ประมาณ 1.2 ล้านดอลลาร์

6. การปลอมแปลง (Spoofing), ความคล่องตัวปลอม (Fake Liquidity), และการบิดเบือนสมุดคำสั่ง (Order Book Manipulation)

6.1 คำนิยามของ Spoofing

Spoofing คือการบิดเบือนตลาดที่ได้รับการกำหนดไว้อย่างชัดเจนในกฎหมาย Dodd-Frank ของสหรัฐอเมริกาปี 2010: ผู้ค้าวางคำสั่งซื้อขายในปริมาณใหญ่โดยไม่มีเจตนาที่จะดำเนินการ เพื่อสร้างภาพลวงของอุปสงค์/อุปทาน จากนั้นยกเลิกคำสั่งหลังจากผู้ค้าอื่น ๆ ติดตามมา และทำการซื้อขายในทิศทางตรงกันข้ามเพื่อทำกำไร

ในสมุดคำสั่งของตลาดคาดการณ์ สถานการณ์ทั่วไปคือ:

  1. ผู้โจมตีวางคำสั่งซื้อ $500,000 สำหรับ Yes ที่ราคา 0.40 เพื่อสร้างภาพ "ความต้องการซื้อที่แข็งแกร่ง";
  2. นักลงทุนรายย่อยเห็นการซื้อและเข้าร่วมตาม ทำให้ราคา Yes เพิ่มขึ้นเป็น 0.45;
  3. ผู้โจมตียกเลิกคำสั่งและขายตำแหน่ง Yes ที่เตรียมไว้ล่วงหน้า ณ ราคา 0.45;
  4. ราคาคืนกลับสู่ 0.41 ผู้โจมตีได้กำไร 5% × ขนาดตำแหน่ง

6.2 Layering

การวางชั้น (Layering) เป็นเวอร์ชันที่พัฒนาขึ้นจากเทคนิคการหลอกลวง (Spoofing): ผู้โจมตีวางคำสั่งซื้อขายที่ระดับราคาหลายระดับเพื่อสร้างภาพลวงตาว่า "ความลึกของตลาด" แต่ไม่มีเจตนาให้คำสั่งใดถูกจับคู่ ตัวอย่างเช่น:

  • วางคำสั่งซื้อสามคำสั่ง มูลค่า $100,000 ที่ระดับราคา 0.40/0.41/0.42;
  • วางคำสั่งขายสามคำสั่ง มูลค่า $100,000 ที่ระดับราคา 0.44/0.45/0.46;
  • สร้างภาพลวงตาว่า "สเปรด 4bp, ความลึก $300,000" ในระดับราคาตรงกลาง;
  • หลังจากผู้ค้าปลีกทำการซื้อขายที่ระดับกลาง ผู้โจมตีจะยกเลิกคำสั่งด้านหนึ่งและกลับทิศทาง

6.3 คุณลักษณะการตรวจจับ

คุณสมบัติ ความหมาย ค่าเกณฑ์order_to_trade_ratio

ขนาดคำสั่ง / ขนาดการดำเนินการ

> 20x

cancel_rate

จำนวนคำสั่งที่ถูกยกเลิก / จำนวนคำสั่งทั้งหมด

> 80%

cancel_latency

เวลาตั้งแต่ส่งคำสั่งซื้อจนถึงการยกเลิก

< 10 วินาที

price_distance_to_touch

ระยะห่างระหว่างราคาที่สั่งซื้อกับราคาที่ดีที่สุด

> 2bp

cancel_after_other_trade

การยกเลิกจะเกิดขึ้นหลังจากคำสั่งซื้อของผู้อื่นถูกเติมเต็มในฝั่งเดียวกันหรือไม่

ใช่

inventory_imbalance

ทิศทางตำแหน่งบัญชีหลังการยกเลิก

ตรงกันข้ามกับทิศทางการยกเลิก

layer_count

จำนวนระดับราคาในฝั่งเดียวกัน

> 3

อัตราส่วนคำสั่งต่อปริมาณการซื้อขาย = ขนาดคำสั่ง / ขนาดที่ดำเนินการ เมื่อเกิน 20 เท่า จะเกิดการแจ้งเตือนระดับกลาง; อัตราการยกเลิกเกิน 80% และเวลาหน่วงการยกเลิก < 10 วินาที เป็นหลักฐานที่ชัดเจนของการสร้างราคาหลอก

6.4 ความสภาพคล่องจริง vs. ความสภาพคล่องปลอม

การแยกแยะระหว่างสภาพคล่องจริงกับสภาพคล่องปลอมเป็นความท้าทายทั่วไปสำหรับผู้สร้างตลาดในตลาดคาดการณ์และหน่วยงานกำกับดูแล วิธีการของ SoonTech นำเสนอ "คะแนนความมั่นใจในสภาพคล่อง":

  • สภาพคล่องของแต่ละระดับถูกให้น้ำหนักตาม "ปริมาณการซื้อขายใน 1 ชั่วโมงที่ผ่านมา / ขนาดคำสั่ง";
  • คำสั่งที่มีอายุยาวนานแต่แทบไม่ถูกจับคู่ (คำสั่งผี) จะถูกให้น้ำหนักน้อยลง;
  • ในช่วงที่ราคาเคลื่อนไหวอย่างรวดเร็ว ด้านคำสั่งที่ไม่ตามราคา = ความมั่นใจสูง (MM), ด้านที่ตามราคาหรือยกเลิก = ความมั่นใจต่ำ (อาจเป็นการหลอกลวง);

คะแนนนี้จะแสดงบนส่วนหน้า (ด้วยสเกลสีหรือไอคอน) เพื่อให้ผู้ใช้สามารถเห็นได้อย่างชัดเจนว่า "สภาพคล่องใดเป็นของจริง"

6.5 การกำหนดราคาปิด

"ราคาปิด" ของตลาดคาดการณ์สอดคล้องกับราคาที่คาดการณ์ได้หรือราคาที่ปิดการซื้อขายครั้งสุดท้าย ณ เวลาการชำระบัญชี ผู้โจมตีอาจรวมการซื้อไว้ในช่วง 5–10 นาทีสุดท้ายก่อนการชำระบัญชี ทำให้ราคาปิดเข้าใกล้ 1.00 ซึ่งอาจก่อให้เกิดผลกระทบแบบลูกโซ่ในระบบอื่น ๆ: การชำระบัญชีอัตโนมัติ การกำหนดราคา NAV ของกองทุนดัชนี และการปรับสมดุลของผู้สร้างตลาด

จุดตรวจจับ:

  • การเพิ่มขึ้นของปริมาณการซื้อขายอย่างผิดปกติในช่วง N นาทีที่ผ่านมา (N โดยทั่วไปคือ 5–15 นาที);
  • การถือตำแหน่งในทิศทางเดียวอย่างเข้มข้นในบัญชีต่างๆ ก่อนการตั้งบัญชี โดยเฉพาะบัญชีที่เพิ่งลงทะเบียนหรือบัญชีที่ไม่ได้ใช้งานมานาน;
  • การดำเนินการแบบพร้อมกันของบัญชีหลายบัญชีภายใต้ผู้ควบคุมเดียวกัน

SoonTech แนะนำให้เข้าสู่ "โหมดความกดดันสูง" 30 นาทีก่อนการตั้งบัญชี: คำสั่งซื้อใหม่ทั้งหมดถูกจำกัดไว้ที่ 0.5x ของขีดจำกัด, บัญชีที่ผิดปกติจะถูกระงับการเปิดตำแหน่งใหม่, และเหตุการณ์สำคัญต้องได้รับการยืนยันด้วยมือ

7. การป้องกันการแทรกแซงข้อมูล Oracle และแหล่งข้อมูลการชำระบัญชี

7.1 ระดับความรุนแรงของการโจมตี Oracle

Oracle เป็น "จุดยึดความเชื่อถือ" ของตลาดการคาดการณ์; หากถูกเจาะระบบ ตำแหน่งทั้งหมดในห่วงโซ่เหตุการณ์ทั้งหมดอาจถูกชำระผิดพลาด ในปี 2023 แพลตฟอร์มการคาดการณ์หลักแห่งหนึ่งเคยทำการชำระผลการแข่งขันที่ถูกยกเลิกเป็น "ทีมเจ้าบ้านชนะ" เนื่องจากข้อผิดพลาดในแหล่งข้อมูล ทำให้เกิดการจ่ายเงินผิดพลาดมูลค่า $2.8M; ในปี 2024 แพลตฟอร์มอีกแห่งหนึ่งทำการชำระผลเหตุการณ์ข้อมูลมาโครผิดพลาด เนื่องจากผู้รวบรวมข้อมูลส่งคืนการตอบสนอง API ที่ถูกปนเปื้อน

7.2 พื้นที่การโจมตี

พื้นที่โจมตี คำอธิบาย การป้องกัน ข้อผิดพลาดของ API แหล่งข้อมูล

API ของผู้ให้บริการล้มเหลว ส่งข้อมูลผิด

การรวมข้อมูลจากหลายแหล่ง, การตรวจสอบค่ามัธยฐาน

การรั่วไหลของกุญแจ API

กุญแจลงนาม Oracle ถูกขโมย

การลงนามหลายฝ่าย (Multi-sig), HSM, การหมุนเวียนกุญแจ

การรับสินบนของผู้เสนอ

ผู้เสนอรับสินบนเพื่อส่งผลลัพธ์ที่ผิด

เงินประกันสูง + ระยะเวลาท้าทาย

การเซ็นเซอร์ผู้ท้าทาย

ผู้ท้าทายที่มีเจตนาร้ายบล็อกผลลัพธ์ที่ถูกต้อง

เพิ่มค่าใช้จ่ายในการท้าทาย, ช่วงเวลาพัก

การปรับเปลี่ยนเขตเวลาและเวลาประทับ

การโจมตีเวลาประทับของแหล่งข้อมูล

แหล่งข้อมูลเวลาอิสระอย่างน้อย 3 แหล่ง

ความคลุมเครือของเหตุการณ์ตามมุมมองส่วนตัว

คำอธิบายที่ไม่ชัดเจน ผู้โจมตีเลือกการตีความที่เอื้อประโยชน์

การตรวจสอบการสร้างตลาดอย่างเคร่งครัด

การปลอมแปลงหลักฐาน ZK

ผู้โจมตีปลอมแปลงหลักฐาน ZK

ผู้ตรวจสอบหลายคน, วงจรที่ลดความไว้วางใจให้ต่ำที่สุด

7.3 การรวมข้อมูลจากหลายแหล่งและค่ามัธยฐาน

สำหรับเหตุการณ์ที่วัดได้ (ผลการแข่งขันกีฬา, ราคาคริปโต, ข้อมูลมาโคร), SoonTech กำหนดให้ต้องมีแหล่งข้อมูลอิสระอย่างน้อย 3 แหล่ง:

  • อย่างน้อยสองแหล่งจาก Chainlink, API3, UMA พร้อมกับการเก็บข้อมูลภายในองค์กร;
  • ต้องมีแหล่งข้อมูลอย่างน้อย 2 แหล่งที่ให้ผลลัพธ์สอดคล้องกัน เพื่อก้าวสู่ขั้นตอนการเสนอ;
  • หากมีความไม่สอดคล้องกัน ให้ทริกเกอร์กระบวนการ "การชำระล่าช้า" หรือ "การตรวจสอบด้วยมือ"

สำหรับเหตุการณ์เชิงอัตวิสัย (การเมือง, บันเทิง) ต้องมีคำอธิบายเหตุการณ์ที่ชัดเจน พร้อมด้วยแหล่งข้อมูลอิสระที่สามารถตรวจสอบได้อย่างน้อย 3 แหล่ง; ผู้เสนอต้องแนบลิงก์และข้อความต้นฉบับเมื่อเสนอ

7.4 ออราเคิลแบบ Optimistic และช่วง Challenge

อ้างอิงจากออกแบบ Optimistic Oracle ของ UMA:

  • ขั้นตอนการเสนอ: ผู้เสนอส่งผลลัพธ์ + ลิงก์หลักฐาน และวางเงินประกัน;
  • ระยะท้าทาย (2–24 ชั่วโมง): ใครก็ได้สามารถท้าทายได้ ผู้ท้าทายต้องวางเงินประกันในจำนวนที่สูงกว่า;
  • ผ่านอัตโนมัติหากไม่มีการท้าทาย: หากไม่มีการท้าทายภายในระยะเวลาที่กำหนด ผลลัพธ์จะมีผลโดยอัตโนมัติ;
  • การส่งต่อข้อพิพาท: ข้อพิพาทจะถูกส่งต่อไปยังระดับการแก้ไขที่สูงขึ้น (สภา, การลงคะแนน DAO, ศาลนอกเชน)

ระยะเวลาการท้าทายควรปรับเปลี่ยนอย่างไดนามิกตามมูลค่าของเหตุการณ์ — 2 ชั่วโมงสำหรับมูลค่าต่ำ, 24 ชั่วโมงสำหรับมูลค่าสูง, 72 ชั่วโมงสำหรับการเลือกตั้งทางการเมือง การนำไปใช้ของ SoonTech อนุญาตให้กำหนดระยะเวลาการท้าทายตามความต้องการเมื่อสร้างตลาด

7.5 ลายเซ็นข้อมูลและหลักฐานที่ตรวจสอบได้

ออราเคิลรุ่นต่อไปต้องการให้แหล่งข้อมูลให้หลักฐานที่สามารถตรวจสอบได้:

  • ลายเซ็น API: แหล่งข้อมูลลงลายเซ็นบนคำตอบด้วยกุญแจส่วนตัว Ed25519 และ Oracle ตรวจสอบลายเซ็น;
  • TLS Notary / DECO: พิสูจน์ว่าข้อมูลนั้นมาจากจุดปลายทาง HTTPS ที่เฉพาะเจาะจงจริง ๆ;
  • ภาพถ่ายหน้าเว็บอย่างเป็นทางการ: บันทึกหน้าเว็บอย่างเป็นทางการ ณ เวลาที่กำหนดด้วย OpenTimestamps หรือ IPA (Inheritance Proof of Authority);
  • ลายเซ็นดิจิทัลของสำนักข่าว: Reuters และ AP ลงลายเซ็นในประกาศอย่างเป็นทางการ

Oracle Hub ของ SoonTech ผสานรวม Chainlink Functions, API3 QRNG, UMA Optimistic Oracle และระบบจัดเก็บหลักฐานที่ตรวจสอบได้ภายในองค์กร

8. สถาปัตยกรรมการตรวจจับแบบชั้น: กฎเกณฑ์, สถิติ, อัลกอริทึมกราฟ, และการเรียนรู้ของเครื่อง

8.1 ทำไมจึงจำเป็นต้องมีชั้น

วิธีการตรวจจับแบบใดก็ตามมีข้อจำกัด:

  • กฎเกณฑ์ล้วนๆ: ความแม่นยำสูง แต่การเรียกคืนต่ำ ยากที่จะตรวจจับรูปแบบ "ที่ยังไม่เคยเห็น";
  • ML แบบบริสุทธิ์: อัตราการเรียกคืนสูง แต่เป็นแบบกล่องดำ ยากที่จะอธิบาย และถูกหลีกเลี่ยงได้ง่ายด้วยตัวอย่างที่ออกแบบมาเพื่อโจมตี;
  • กราฟล้วน: แข็งแกร่งในการวิเคราะห์ความสัมพันธ์ที่มีโครงสร้าง แต่อ่อนแอต่อสัญญาณแบบอนุกรมเวลาและข้อความ;
  • สถิติล้วน: ไวต่อความผิดปกติ แต่ค่าเกณฑ์ปรับได้ยาก มีอัตราผลบวกเท็จสูง

ในระบบผลิตจริง SoonTech ใช้สถาปัตยกรรมสี่ชั้น โดยแต่ละชั้นมีหน้าที่ชัดเจนและสามารถอัปเกรดได้อย่างอิสระ:

ชั้นเทคโนโลยีความรับผิดชอบความล่าช้าอัตราการตรวจพบผิด L1 เครื่องยนต์กฎ

Drools / DSL ภายในองค์กร

การละเมิดที่ทราบแล้ว, กฎการปฏิบัติตามข้อกำหนดที่เข้มงวด

< 10 ms

ต่ำมาก

L2 ความผิดปกติทางสถิติ

CUSUM / EWMA / Isolation Forest

ความผิดปกติทางสถิติของรูปแบบที่ทราบแล้ว

100 มิลลิวินาที–1 วินาที

ต่ำ

อัลกอริทึมกราฟ L3

Neo4j / TigerGraph / GraphX

การเชื่อมโยงบัญชี, วงจรปิด, กลุ่ม

1–10 วินาที

ระดับกลาง

L4 การเรียนรู้ของเครื่อง

XGBoost / GNN / Transformer

รูปแบบที่ซับซ้อน, ภัยคุกคามที่ยังไม่เคยพบ

10 วินาที–หลายนาที

ระดับกลาง-สูง

แต่ละชั้นจะส่งข้อมูลออกเป็น "คะแนนความสงสัย + หลักฐาน" และ "ตัวรวมการแจ้งเตือน" จะให้คะแนนและส่งไปยังคิวการแจ้งเตือน

8.2 เครื่องมือสร้างกฎ L1

เครื่องยนต์กฎเป็นพื้นฐานการปฏิบัติตามกฎระเบียบ โดยมีหน้าที่สามประการ:

  1. กฎการปฏิบัติตามข้อกำหนดที่เข้มงวด: ข้อจำกัดทางภูมิศาสตร์, ข้อจำกัดอายุ, สถานะ KYC, ข้อจำกัดการซื้อขายครั้งเดียว, ข้อจำกัดสะสม;
  2. รูปแบบการละเมิดที่รู้จัก: การตรวจจับการจับคู่ตนเอง, รูปแบบการปลอมแปลงที่ชัดเจน, ที่อยู่ Sybil ที่รู้จัก;
  3. ตัวกระตุ้นการรายงานตามกฎระเบียบ: สร้างร่างรายงาน SAR/STR โดยตรงเมื่อถึงเกณฑ์ที่กำหนด (ปริมาณสะสม, ขนาดการซื้อขายครั้งเดียว)

กฎถูกเขียนด้วย DSL (DSL ของ SoonTech คล้ายกับ WHEN account.age < 7d AND trade.size > 10000 THEN alert("new_account_large_trade")), ซึ่งสนับสนุนการรีโหลดแบบร้อน (hot-reload), การควบคุมเวอร์ชัน และการทดสอบ A/B.

8.3 ความผิดปกติทางสถิติ L2

เก็บข้อมูลอนุกรมเวลาสำหรับแต่ละบัญชีและแต่ละตลาด:

  • ปริมาณการซื้อขาย ขนาดคำสั่งซื้อ อัตราการยกเลิก ค่าเฉลี่ยเคลื่อนที่ และค่าความแปรปรวน;
  • z-score และ IQR ของการเปลี่ยนแปลงราคา;
  • CUSUM / Page-Hinkley การเบี่ยงเบนสะสม.

เมื่อตัวชี้วัดเบี่ยงเบนจากการแจกแจงทางประวัติศาสตร์เกินค่าเกณฑ์ (เช่น 3σ หรือเปอร์เซ็นไทล์ที่ 99.5) ให้ส่งสัญญาณเตือน ชั้นนี้ใช้เพื่อตรวจจับ "ความผิดปกติทางสถิติของรูปแบบที่รู้จัก" เป็นหลัก เช่น "ปริมาณการซื้อขายของบัญชีหนึ่งภายใน 1 ชั่วโมงสูงกว่า 10 เท่าของค่าเฉลี่ยในช่วง 30 วันที่ผ่านมา"

8.4 L3 Graph Algorithms

ตลาดการคาดการณ์มีโครงสร้างกราฟที่ซับซ้อน:

  • กราฟบัญชี-บัญชี: ขอบเชื่อมผ่านอุปกรณ์ IP หรือความเกี่ยวข้องกับกองทุนที่เหมือนกัน;
  • กราฟบัญชี-ตลาด: กราฟสองส่วนผ่านพฤติกรรมการซื้อขาย;
  • กราฟที่อยู่บนเชนของกองทุน: กราฟมีทิศทางของการฝาก/ถอน;
  • กราฟเหตุการณ์-แหล่งข้อมูล: ความสัมพันธ์ทางเวลาระหว่างเหตุการณ์และแหล่งข้อมูลที่เข้าถึงได้

เราใช้สามประเภทของอัลกอริทึมบน Neo4j / TigerGraph:

  • การตรวจหาชุมชน (Louvain / Leiden): ระบุกลุ่มบัญชีที่มีความเกี่ยวข้องสูง;
  • โหนดผิดปกติ (Oddball / Ego-splitting): โหนดที่มีระดับความเชื่อมโยงสูงแต่มีลักษณะผิดปกติ;
  • การจับคู่ซับกราฟ: ค้นหารูปแบบเฉพาะ (เช่น "5 บัญชีทำการซื้อขายล้างกันแบบซิงโครนัสใน 3 ตลาด")

ข้อได้เปรียบของอัลกอริทึมกราฟคือ "ความสามารถในการอธิบาย" — กลุ่มที่น่าสงสัยแต่ละกลุ่มสามารถแสดงผลเป็นภาพให้ผู้รับผิดชอบด้านการปฏิบัติตามกฎระเบียบได้

8.5 L4 Machine Learning

ML ตรวจจับรูปแบบที่ซับซ้อนและไม่เคยเห็นมาก่อน:

  • XGBoost / LightGBM: ฐานอ้างอิงที่แข็งแกร่งสำหรับคุณลักษณะที่มีโครงสร้าง, การจำแนกแบบทวิภาคีว่า "บัญชีนี้มีความน่าสงสัยหรือไม่";
  • GNN (Graph Neural Network): การฝังข้อมูลของกราฟบัญชี-ตลาด-ที่อยู่, ใช้เพื่อตรวจสอบว่า "บัญชีเหล่านี้กำลังร่วมมือกันหรือไม่";
  • Transformer / LSTM: การสร้างแบบจำลองลำดับการซื้อขาย, "รูปแบบพฤติกรรมนี้ผิดปกติหรือไม่";
  • Autoencoder / Isolation Forest: การตรวจจับความผิดปกติแบบไม่มีการกำกับสำหรับ "รูปแบบใหม่ที่ยังไม่เคยพบ"

โมเดลจะให้ผลลัพธ์เป็นความน่าจะเป็น + ส่วนร่วมของลักษณะสำคัญ (ค่า SHAP) เพื่อการตรวจสอบโดยมนุษย์

8.6 การรวมและกำจัดข้อมูลซ้ำของคำเตือน

พฤติกรรมผิดปกติเดียวกันอาจถูกทริกเกอร์โดยหลายชั้นพร้อมกัน (เช่น กฎ สถิติ และ ML ทั้งหมดตรงกัน) ดังนั้นจึงจำเป็นต้องมีการรวมและกำจัดข้อมูลซ้ำ:

  • ใช้ ID เหตุการณ์ (บัญชี + ตลาด + ช่วงเวลากำหนด) เป็นกุญแจในการกำจัดข้อมูลซ้ำ;
  • รวมการแจ้งเตือนที่มีสาเหตุหลักเดียวกันภายในช่วงเวลา 5 นาที;
  • แสดงผล "ความสงสัยรวม" และ "ชั้นหลักที่มีส่วนร่วม" เพื่อทำให้การตรวจสอบโดยมนุษย์เป็นไปอย่างเข้าใจง่าย

9. การจัดระดับการแจ้งเตือน การตรวจสอบโดยมนุษย์ และมาตรการบังคับใช้

9.1 ระดับการแจ้งเตือน

SoonTech ใช้ระดับการแจ้งเตือนสี่ระดับ ซึ่งสอดคล้องกับ SLA และเส้นทางการดำเนินการบังคับใช้ที่แตกต่างกัน:

ระดับความสำคัญความหมายตัวอย่างการทริกเกอร์การตอบสนอง SLAอำนาจการบังคับใช้P0 ระดับวิกฤต

ภัยคุกคามต่อความอยู่รอดของแพลตฟอร์ม, เส้นแดงตามกฎระเบียบ

การโจมตีแบบ Sybil ในวงกว้าง หรือการละเมิดระบบ Oracle

5 นาที

ประธานกรรมการบริหาร + ผู้อำนวยการฝ่ายการปฏิบัติตามกฎระเบียบ

P1 High

มีหลักฐานการปั่นหุ้นที่ชัดเจน ให้ระงับบัญชีทันที

5+ บัญชีทำการซื้อขายภายในพร้อมกัน

30 นาที

ผู้อำนวยการฝ่ายการปฏิบัติตามกฎระเบียบ + ผู้จัดการฝ่ายความเสี่ยง

P2 ระดับกลาง

น่าสงสัยอย่างยิ่ง ต้องตรวจสอบด้วยมือ

บัญชีที่มีอัตราจับคู่เอง > 50%

4 ชั่วโมง

ผู้จัดการความเสี่ยง + ผู้รับผิดชอบการปฏิบัติตามกฎระเบียบแบบพร้อมรับงาน

P3 ต่ำ

สัญญาณอ่อน, การประมวลผลแบบกลุ่ม

ความเบี่ยงเบนของปริมาณที่ 2σ

24 ชั่วโมง

การปฏิบัติตามข้อกำหนดในการเรียกตัว

9.2 กระบวนการตรวจสอบโดยมนุษย์

การตรวจสอบโดยมนุษย์ไม่ใช่การ "ดูผ่านๆ แล้วผ่าน" — แต่ต้องใช้กระบวนการมาตรฐาน:

  1. รับการแจ้งเตือน: ระบบส่งข้อมูลไปยังระบบตั๋วของเจ้าหน้าที่ตรวจสอบความสอดคล้อง พร้อมชุดหลักฐาน (การซื้อขายที่น่าสงสัย, กราฟความสัมพันธ์, โมเดล SHAP, โปรไฟล์บัญชี);
  2. จัดประเภทอย่างรวดเร็ว: ภายใน 5 นาที ตัดสินใจว่า "ผลบวกปลอม", "ติดตามต่อไป", "ส่งต่อระดับสูง";
  3. การแช่แข็งหลักฐาน: เก็บสถานะบัญชี, บันทึกการซื้อขาย, ลายนิ้วมืออุปกรณ์, และที่อยู่บนเชน ไปยังที่เก็บหลักฐาน (บันทึกในล็อกแบบอ่านอย่างเดียว + จุดยึดบนเชน);
  4. การตัดสินใจและดำเนินการ: เลือกมาตรการบังคับใช้ (ดูส่วนถัดไป), ส่งคำขออนุมัติด้วยลายเซ็นคู่;
  5. ติดตามและเก็บเข้าคลัง: หลังการบังคับใช้ ให้ติดตามเป็นระยะเวลา 7/30/90 วัน ยืนยันว่าไม่เกิดซ้ำ และบันทึกเข้าคลังกรณีเพื่อฝึกโมเดล

เจ้าหน้าที่กำกับดูแลการปฏิบัติตามกฎระเบียบทำงาน 24 ชั่วโมงทุกวัน 7 วันต่อสัปดาห์ โดยแบ่งเป็นหลายกะ และมีเจ้าหน้าที่อย่างน้อย 2 คนต่อกะ เพื่อหลีกเลี่ยงการละเลยจากจุดเดียว ระบบตั๋วของ SoonTech มีกลไก "การตรวจสอบสองชั้น" ที่ฝังตัวอยู่ — การบังคับใช้ระดับ P0/P1 ใดๆ ก็ตาม ต้องได้รับการอนุมัติจากสองฝ่ายที่อิสระกันก่อนจึงจะดำเนินการได้

9.3 มาตรการบังคับใช้

การดำเนินการสถานการณ์ที่นำไปใช้ได้ผลข้างเคียงความเสี่ยงทางกฎหมายคำเตือน

การละเมิดครั้งแรก, ระดับเล็กน้อย

แทบไม่มี

ต่ำ

การจำกัดการใช้งาน

การละเมิดบ่อยครั้ง, ต้องติดตาม

ประสบการณ์ของผู้ใช้ลดลง

ระดับกลาง

ระงับบัญชี

การละเมิดที่ชัดเจน ต้องมีการสอบสวน

คำร้องเรียนจากผู้ใช้

ระดับกลาง

ยกเลิกคำสั่ง / การซื้อขาย

การซื้อขายกับตัวเอง, ความผิดพลาดที่ชัดเจน

ผลกระทบต่อตลาด

ระดับกลาง (ต้องเปิดเผยเงื่อนไขการใช้บริการ)

คำสั่งตลาดถูกยกเลิก

การตลาดถูกควบคุม, เหตุการณ์ไม่ถูกต้อง

ชื่อเสียงของแพลตฟอร์ม

ระดับกลาง (จำเป็นต้องมีกฎเกณฑ์ที่ชัดเจน)

ความล่าช้าในการชำระหนี้

มีข้อพิพาท ต้องตรวจสอบ

ประสบการณ์ผู้ใช้ลดลง

ระดับกลาง

ตัดงบประมาณ

การละเมิดอย่างรุนแรง มีกฎระเบียบที่กำหนดไว้

การฟ้องร้องจากผู้ใช้

ระดับกลาง (จำเป็นต้องมีความชัดเจนในข้อกำหนดการใช้บริการ)

ส่งให้ศาลพิจารณา

เกี่ยวข้องกับความผิดทางอาญา, ข้ามพรมแดน

การฟ้องร้องที่ยาวนาน

สูง

แพลตฟอร์มต้องระบุอย่างชัดเจนในเงื่อนไขการใช้บริการ (ToS) และกฎตลาดเกี่ยวกับเงื่อนไขการทริกเกอร์ กระบวนการอนุมัติ และขั้นตอนการอุทธรณ์สำหรับแต่ละการดำเนินการ นี่ไม่ใช่เพียงข้อกำหนดด้านการปฏิบัติตามกฎหมายเท่านั้น แต่ยังเป็นการ "แจ้งให้ทราบล่วงหน้า" แก่ผู้ใช้ด้วย

9.4 การยกเลิกการซื้อขายในตลาด

การยกเลิกตลาดเป็นหนึ่งในมาตรการบังคับใช้ที่รุนแรงที่สุด ซึ่งมักใช้ในกรณีต่อไปนี้:

  • คำอธิบายเหตุการณ์มีความคลุมเครือที่ไม่สามารถแก้ไขได้;
  • มีหลักฐานที่ชัดเจนว่าผลลัพธ์ถูกปรับแต่ง;
  • Oracle ถูกละเมิดและไม่สามารถแก้ไขได้ภายในระยะเวลาท้าทาย;
  • หน่วยงานกำกับดูแลกำหนดไว้อย่างชัดเจน

การจัดการทุนหลังการยกเลิก:

  • การไถ่ถอนตามสัดส่วนที่เท่ากัน: ทุกหุ้นจะถูกไถ่ถอนในอัตรา 1/N โดยผู้บิดเบือนราคาและผู้ใช้รายอื่นได้รับการปฏิบัติอย่างเท่าเทียมกัน;
  • กองทุนชดเชย: ใช้ "กองทุนประกันตลาดผิดปกติ" เพื่อซื้อคืนตำแหน่งของผู้ใช้ที่ไม่ละเมิดกฎตามราคาปกติล่าสุด;
  • การยกเลิกส่วนหนึ่ง: ยกเลิกเฉพาะผลลัพธ์ย่อยที่ถูกบิดเบือน ส่วนอื่น ๆ ปิดสถานะตามปกติ;

SoonTech แนะนำให้ตัดสินใจการยกเลิกผลร่วมกันโดยฝ่ายการปฏิบัติตามกฎระเบียบ + ฝ่ายกฎหมาย + ฝ่ายธุรกิจ พร้อมบันทึกเหตุผลการตัดสินใจและห่วงโซ่หลักฐาน

10. การแก้ไขข้อพิพาท, ห่วงโซ่หลักฐาน, และความสามารถในการอธิบาย

10.1 สถาปัตยกรรมการแก้ไขข้อพิพาทสามชั้น

โดยอ้างอิงจาก Optimistic Oracle ของ UMA และกลไกการฟอร์กของ Augur, SoonTech ได้นำระบบการแก้ไขข้อพิพาทสามชั้นมาใช้:

  1. ชั้น 1: เสนอ–ท้าทาย (2–24 ชั่วโมง)
  • ผู้เสนอผลส่งผลลัพธ์ + หลักฐาน และวางเงินประกัน;
  • ใครก็ได้สามารถท้าทายได้ ผู้ท้าทายต้องวางเงินประกันในจำนวนที่สูงกว่า;
  • ผ่านอัตโนมัติหากไม่มีการท้าทาย
  1. ชั้น 2: การลงคะแนนของสภา (3–7 วัน)
  • หากมีการท้าทาย สภาที่มีสมาชิก 9–15 คนจะลงคะแนน (ลูกค้า SoonTech สามารถปรับแต่งสมาชิกได้);
  • ผ่านด้วยเสียงข้างมากแบบธรรมดา ผู้เสนอ/ผู้คัดค้านแบ่งเงินประกันตามผล;
  • รายละเอียดการลงคะแนนอยู่บนเชน และเหตุผลของสมาชิกแต่ละคนสามารถเปิดเผยต่อสาธารณะได้
  1. ชั้น 3: DAO หรือเขตอำนาจศาล (7–30 วัน)
  • ข้อพิพาทที่รุนแรง (ที่เกี่ยวข้องกับเงินหลายล้านดอลลาร์หรือประเด็นทางรัฐธรรมนูญ) จะถูกส่งต่อไปยังการลงคะแนนของ DAO หรือการอนุญาโตตุลาการของเขตอำนาจศาลเฉพาะ;
  • นี่คือ "ปุ่มนิวเคลียร์" ที่ถูกใช้งานเพียงในบางกรณีเท่านั้น

10.2 การเก็บรักษาห่วงโซ่หลักฐาน

การดำเนินการบังคับใช้ใด ๆ (คำสั่งยกเลิก, ระงับ, หรือยกเลิกผล) ต้องมีห่วงโซ่หลักฐานที่สามารถตรวจสอบได้:

  • ภาพถ่ายสถานะบัญชี: สถานะ KYC, ตำแหน่ง, เงินทุน, คะแนนความเสี่ยง ณ เวลาที่ดำเนินการ;
  • รายละเอียดการซื้อขาย: ประวัติการซื้อขายครบถ้วนของบัญชีที่เกี่ยวข้อง คู่สัญญา ที่อยู่ IP ลายนิ้วมืออุปกรณ์ และเวลาประทับ;
  • ผลลัพธ์จากโมเดล: คะแนนความสงสัย, การมีส่วนร่วมของคุณลักษณะหลัก (SHAP), การแจ้งเตือนที่เกี่ยวข้อง;
  • บันทึกการตัดสินใจ: ผู้ตัดสินใจ, เวลาตัดสินใจ, เหตุผลในการตัดสินใจ, ผู้ตรวจสอบ;
  • การติดตามผล: การเปลี่ยนแปลงพฤติกรรมบัญชีหลังจาก 7/30/90 วัน

ระบบการปฏิบัติตามกฎระเบียบของ SoonTech จะบันทึกชุดหลักฐานลงในล็อกแบบอ่านอย่างเดียว (PostgreSQL + S3) พร้อมกับการยึดตรึงบนเชน (แฮชล็อกทุกชั่วโมงที่บันทึกไปยัง Ethereum/Polygon) เพื่อรับประกันความไม่เปลี่ยนแปลงและความสามารถในการค้นหาข้อมูลในระยะยาว

10.3 ความสามารถในการอธิบาย

หน่วยงานกำกับดูแลและศาลกำลังเรียกร้องให้คำตัดสินของ AI สามารถอธิบายได้มากขึ้นเรื่อยๆ แนวปฏิบัติของ SoonTech:

  • การแจ้งเตือนตามกฎ: แต่ละกฎมีคำอธิบายด้วยภาษาธรรมชาติ ("บัญชีที่เชื่อมโยงกับ 3 IP ภายใน 24 ชั่วโมง");
  • การแจ้งเตือนทางสถิติ: แสดงกราฟอนุกรมเวลา, เส้นค่าขีดจำกัด, และค่าสถิติ;
  • การแจ้งเตือน ML: แนบแผนภูมิการมีส่วนร่วมของฟีเจอร์ SHAP พร้อมระบุ "เหตุผลที่บัญชีนี้ถูกทำเครื่องหมาย";
  • การแจ้งเตือนแบบกราฟ: แสดงกราฟความสัมพันธ์ พร้อมระบุว่า "ทำไมบัญชีเหล่านี้จึงถูกเชื่อมโยงกัน"

เจ้าหน้าที่ด้านการปฏิบัติตามกฎระเบียบสามารถใช้ภาษาธรรมชาติเพื่ออธิบายให้หน่วยงานกำกับดูแลหรือผู้ใช้ฟังได้: "บัญชีนี้ถูกทำเครื่องหมายเพราะใช้ BSSID Wi-Fi เดียวกันกับบัญชี Sybil 4 บัญชีที่รู้จักภายใน 30 นาทีก่อนเหตุการณ์ และได้รับเงินจากที่อยู่บนเชน 0xab12..."

11. การรายงานตามกฎระเบียบและการบูรณาการด้านการปฏิบัติตามกฎระเบียบ

11.1 เขตอำนาจหลักในเอเชียตะวันออกเฉียงใต้

เขตอำนาจศาล หน่วยงานกำกับดูแล จุดเน้นการกำกับดูแล ข้อกำหนดการรายงาน มาเลเซีย

SC คณะกรรมการกำกับหลักทรัพย์มาเลเซีย

การปั่นตลาดทุน การซื้อขายข้อมูลภายใน KYC/AML

รายงานการค้าประจำไตรมาส, STR แบบทันที

อินโดนีเซีย

BAPPEBTI (สัญญาซื้อขายล่วงหน้า) / OJK (หลักทรัพย์)

การกำกับดูแลการซื้อขายสัญญาซื้อขายล่วงหน้า, AML

การกำกับดูแลแบบเรียลไทม์, รายงานการปฏิบัติตามกฎระเบียบรายเดือน

ไทย

SEC ไทย

สินทรัพย์ดิจิทัล, AML

รายงานความผิดปกติแบบเรียลไทม์, การตรวจสอบความสอดคล้องตามกฎระเบียบประจำปี

สิงคโปร์

MAS (หน่วยงานกำกับดูแลการเงินของสิงคโปร์)

DPT (Digital Payment Token), AML/CFT

รายงาน STR/CTR แบบเรียลไทม์, รายงานการปฏิบัติตามกฎระเบียบประจำปี

เวียดนาม

ธนาคารกลาง + กระทรวงข้อมูลและการสื่อสาร

สินทรัพย์ดิจิทัล, AML

จำเป็นต้องมีช่วงทดลองใช้และดำเนินการบูรณาการอย่างค่อยเป็นค่อยไป

ฟิลิปปินส์

BSP (ธนาคารกลาง) + SEC

สินทรัพย์ดิจิทัล, AML

รายงานรายไตรมาส + STR แบบเรียลไทม์

11.2 เนื้อหาของรายงาน

ประเภทรายงานเงื่อนไขการแจ้งเตือนเนื้อหาความถี่รายงานธุรกรรมที่น่าสงสัย (STR/SAR)

ละเมิดกฎ AML

บัญชี, การซื้อขาย, คู่สัญญา, หลักฐาน

ทันที

รายงานธุรกรรมสกุลเงิน (CTR)

แบบรายรายการหรือแบบสะสมเมื่อเกินเกณฑ์

รายละเอียดการซื้อขาย, คู่สัญญา, KYC

รายวัน/รายสัปดาห์

รายงานการบิดเบือนตลาด

การละเมิดกฎการควบคุมตลาด

เทคนิคการปั่นราคา, บัญชีที่เกี่ยวข้อง, การประมาณการสูญเสีย

ทันที + รายเดือน

เหตุการณ์ความปลอดภัยของระบบ

การแฮ็ก, ความล้มเหลวของระบบออราเคิล

เส้นเวลาของเหตุการณ์, ขอบเขตผลกระทบ, ความคืบหน้าในการแก้ไข

ทันที

รายงานการปฏิบัติตามข้อกำหนดประจำปี

รายปี

สถานะความเสี่ยงโดยรวม, เหตุการณ์สำคัญ, แผนการปรับปรุง

รายปี

การตอบคำถามจากหน่วยงานกำกับดูแล

หน่วยงานกำกับดูแลขอข้อมูลอย่างกระตือรือร้น

ข้อมูลรายละเอียดเกี่ยวกับบัญชี/ตลาดเฉพาะ

ตามคำขอ

11.3 การประสานงานด้านกฎระเบียบข้ามพรมแดน

ตลาดการคาดการณ์มีลักษณะข้ามพรมแดนโดยธรรมชาติ — ผู้ใช้อาจฝากเงินในฟิลิปปินส์ ซื้อขายในมาเลเซีย และถอนเงินในอินโดนีเซีย ระบบการปฏิบัติตามกฎระเบียบของ SoonTech รองรับ:

  • คลังกฎการปฏิบัติตามกฎระเบียบข้ามเขตอำนาจ (แต่ละกฎสามารถกำหนดภูมิภาคที่บังคับใช้ได้);
  • การรายงานอัตโนมัติสำหรับธุรกรรมที่น่าสงสัยข้ามพรมแดน (บัญชีในฟิลิปปินส์ + ตลาดในมาเลเซีย + การถอนเงินในอินโดนีเซีย → รายงานพร้อมกันไปยังหน่วยงานกำกับดูแลทั้งสามแห่ง);
  • การบูรณาการ API กับหน่วยงานกำกับดูแล (MAS, SC, SEC ไทย ล้วนมีข้อกำหนด API เฉพาะ);
  • โหมดแซนด์บ็อกซ์ด้านกฎระเบียบ (ทำให้ข้อมูลเป็นนิรนามหรือจำกัดคุณสมบัติเฉพาะตามความต้องการ);

12. สถาปัตยกรรมทางวิศวกรรมและการออกแบบประสิทธิภาพ

12.1 สถาปัตยกรรมโดยรวม

กระบวนการเฝ้าระวังทั้งหมดเริ่มจากจุดเข้าซื้อขายไปจนถึงขั้นตอนการบังคับใช้โดยเจ้าหน้าที่ และแบ่งออกเป็นเจ็ดชั้นตามทิศทางการไหลของข้อมูล:

  1. ชั้นเข้า: คำขอจากลูกค้าและอุปกรณ์มือถือผ่าน API Gateway เข้าสู่ระบบจับคู่ (matching engine) หรือ AMM โดยเกตเวย์จะบันทึกสัญญาณดิบด้านตัวตน เช่น ลายนิ้วมืออุปกรณ์ (device fingerprint), IP และ user agent พร้อมกัน
  2. Event bus: เครื่องมือจับคู่จะบันทึกทุกการเติมคำสั่ง (fill), การวาง/ยกเลิกคำสั่งซื้อขาย และการเปลี่ยนแปลงตำแหน่งลงในหัวข้อ Kafka เช่น trade-event-stream และ order-event-stream, ซึ่งทำหน้าที่เป็นแหล่งข้อมูลที่เชื่อถือได้เพียงแหล่งเดียวสำหรับโมดูลตรวจจับทั้งหมดในขั้นตอนถัดไป
  3. ชั้นการคำนวณแบบเรียลไทม์: งาน Flink รับข้อมูลจากสตรีมเหตุการณ์และรวมคุณสมบัติแบบเรียลไทม์ตามบัญชี ตลาด และช่วงเวลา — เช่น อัตราการจับคู่ด้วยตนเอง อัตราการวางคำสั่งต่อคำสั่งยกเลิก ส่วนแบ่งปริมาณในช่วงเวลาการชำระบัญชี และอื่น ๆ
  4. ชั้นเก็บข้อมูลคุณลักษณะ: คุณลักษณะแบบเรียลไทม์ถูกบันทึกลงใน Redis หรือระบบเก็บข้อมูลคุณลักษณะ เพื่อการอนุมานออนไลน์ที่มีความหน่วงต่ำ พร้อมทั้งมีสำเนาแบบขนานที่ถูกบันทึกลงใน data lake สำหรับการฝึกอบรมแบบออฟไลน์และการทดสอบย้อนหลัง
  5. ชั้นการอนุมานและการรวมข้อมูล: เครื่องมือประมวลผลกฎ (Rule engine), แบบจำลองทางสถิติ และแบบจำลองการเรียนรู้ของเครื่อง (machine learning) ทำการให้คะแนนแบบขนาน; บริการรวมการแจ้งเตือนจะกำจัดข้อมูลซ้ำ, รวมสัญญาณที่มีต้นกำเนิดเดียวกัน และคำนวณคะแนนความเสี่ยงสุดท้าย
  6. ชั้นวิเคราะห์กราฟ: ฐานข้อมูลกราฟ เช่น Neo4j จัดเก็บเครือข่ายความเชื่อมโยงระหว่างบัญชี–อุปกรณ์–แหล่งเงินทุน–ที่อยู่บนเชน งานออฟไลน์จะคำนวณการตรวจจับชุมชนและความแข็งแกร่งของความเชื่อมโยงใหม่เป็นระยะๆ และส่งผลลัพธ์กลับเป็นคุณสมบัติระดับบัญชี
  7. ชั้นการบังคับใช้: การแจ้งเตือนที่เกินเกณฑ์จะเข้าสู่คิวการแจ้งเตือนและระบบออกตั๋ว โดยถูกส่งต่อไปยังเจ้าหน้าที่จัดการความเสี่ยงที่รับเวร ตามระดับความรุนแรง ไปยังการตรวจสอบการปฏิบัติตามกฎระเบียบ หรือการดำเนินการบังคับใช้อัตโนมัติ

12.2 แกนหลักการประมวลผลสตรีม: Flink + Kafka

  • Kafka รับส่งข้อมูลทุกเหตุการณ์ทางการค้า พฤติกรรมของผู้ใช้ เหตุการณ์บนเชน และเหตุการณ์จากออราเคิล;
  • Flink รับผิดชอบการคำนวณคุณสมบัติแบบเรียลไทม์ (หน้าต่างเลื่อน, CEP – การประมวลผลเหตุการณ์ซับซ้อน), การอนุมานแบบจำลองแบบเรียลไทม์, และการสร้างการแจ้งเตือนแบบเรียลไทม์;
  • Flink CEP เหมาะอย่างยิ่งสำหรับการตรวจจับ "รูปแบบข้อมูลอนุกรมเวลา" (เช่น "A ส่งคำสั่งซื้อ 3 ครั้งภายใน 5 นาที โดยแต่ละคำสั่งห่างกัน 30 วินาที");
  • หลักการ "Exactly-Once" รับประกันว่าคำเตือนจะไม่ถูกซ้ำหรือพลาด (ข้อกำหนดสำคัญด้านความสอดคล้อง)

12.3 Feature Store

SoonTech แนะนำให้ใช้ Feature Store แบบหลายชั้น:

  • คุณสมบัติแบบเรียลไทม์ (Redis / Aerospike): ความล่าช้า < 1 มิลลิวินาที สำหรับการคำนวณแบบเรียลไทม์ของ Flink;
  • คุณสมบัติแบบออฟไลน์ (Parquet บน S3 / Hudi): T+1, สำหรับการฝึกโมเดลแบบออฟไลน์;
  • แพลตฟอร์มฟีเจอร์ (Feast / Tecton): การกำหนดฟีเจอร์แบบรวมศูนย์ การจัดการเวอร์ชัน และการแบ่งปันระหว่างทีม;
  • การอนุมานออนไลน์ (< 100 ms) และการฝึกอบรมออฟไลน์ใช้การกำหนดคุณลักษณะเดียวกัน เพื่อหลีกเลี่ยงความคลาดเคลื่อนระหว่างการฝึกอบรมและการให้บริการ

12.4 ฐานข้อมูลกราฟ

  • Neo4j สำหรับการวิเคราะห์ความสัมพันธ์ในระดับเล็กถึงกลาง (< 100M โหนด);
  • TigerGraph สำหรับอัลกอริทึมกราฟระดับใหญ่ (ระดับพันล้านโหนด);
  • GraphX / NetworkX สำหรับการวิเคราะห์ออฟไลน์แบบครั้งเดียว (การตรวจหาชุมชน, การจับคู่ซับกราฟ);
  • Amazon Neptune / Alibaba GraphScope สำหรับการปรับใช้แบบคลาวด์เนทีฟ

คำสั่งค้นหาข้อมูลกราฟทั่วไป:

  • "บัญชีที่ใช้ IP ช่วง C ร่วมกับบัญชี Sybil ที่รู้จักในช่วง 24 ชั่วโมงที่ผ่านมา";
  • "ที่อยู่การฝากเงินบนเชนของบัญชี X ใน 7 วันที่ผ่านมา, กราฟหลังการจัดกลุ่ม Common Spending";
  • "ช่วงเวลาสั้นที่สุดที่บัญชี 5 บัญชีทำการซื้อขายล้างกันแบบซิงโครนัสบน 3 ตลาด";

12.5 ประสิทธิภาพและความพร้อมใช้งาน

ตัวชี้วัดเป้าหมายการออกแบบการแจ้งเตือนความล่าช้า (P95)

< 1 วินาที

Flink streaming + real-time features

ความล่าช้าในการอนุมานแบบจำลอง (P99)

< 100 ms

การอนุมานออนไลน์ + แคชโมเดล

ความล่าช้าในการค้นหาข้อมูลบนกราฟ

< 5 วินาที

การคำนวณล่วงหน้า + ดัชนี + แคชซับกราฟ

ความพร้อมใช้งานของระบบ

99.95%

การปรับใช้แบบหลายแอคทีฟ, วงจรเบรกเกอร์, การลดระดับประสิทธิภาพ

Throughput

100K TPS เหตุการณ์การซื้อขาย

พาร์ติชัน Kafka + ความขนานของ Flink

พื้นที่จัดเก็บข้อมูล

การเก็บรักษาข้อมูลตามข้อกำหนดเป็นระยะเวลา 5 ปี

การจัดเก็บแบบแบ่งชั้นร้อน/เย็น + การจัดเก็บแบบอ็อบเจ็กต์

13. โซลูชันการเฝ้าระวังตลาดของ SoonTech

13.1 ภาพรวมของโซลูชัน

ชุดโซลูชันการเฝ้าระวังตลาดของ SoonTech เป็นส่วนสำคัญของโครงสร้างพื้นฐานสำหรับแพลตฟอร์มตลาดการคาดการณ์ ซึ่งทำงานร่วมกับ AMM, หนังสือคำสั่ง และ oracle องค์ประกอบของโมดูล:

  1. ชั้นการรับข้อมูล: เหตุการณ์การซื้อขาย, พฤติกรรมผู้ใช้, เหตุการณ์บนเชน, เหตุการณ์จากออราเคิล, ลายนิ้วมืออุปกรณ์;
  2. ชั้นการประมวลผลแบบเรียลไทม์: Kafka + Flink (คุณสมบัติแบบเรียลไทม์และ CEP);
  3. ชั้นการตรวจจับ: เครื่องมือกำหนดกฎ (L1) + ความผิดปกติทางสถิติ (L2) + อัลกอริทึมกราฟ (L3) + การเรียนรู้ของเครื่อง (L4);
  4. การแจ้งเตือนและตั๋ว: การแจ้งเตือนตามระดับ, การตรวจสอบสองขั้นตอน, ห่วงโซ่หลักฐาน;
  5. การบังคับใช้และดำเนินการ: การจำกัดตำแหน่ง, การยกเลิกคำสั่ง, การระงับ, การยกเลิกคำสั่ง, การล่าช้าในการชำระบัญชี;
  6. รายงานการปฏิบัติตามกฎระเบียบ: STR/CTR, การบูรณาการ API ของหน่วยงานกำกับดูแล, การประสานงานข้ามพรมแดน;
  7. ความสามารถในการอธิบายและตรวจสอบ: SHAP, ห่วงโซ่หลักฐาน, การยึดตรึงบนเชน;
  8. คอนโซลผู้ดูแลระบบ: พื้นที่ทำงานของเจ้าหน้าที่กำกับดูแลการปฏิบัติตามกฎระเบียบ, ห้องสมุดกรณีศึกษา, การติดตามตรวจสอบโมเดล, การจัดการกฎเกณฑ์.

13.2 สามสถานการณ์การนำไปใช้ทั่วไป

สถานการณ์ 1: ตลาดการคาดการณ์ที่ฝังอยู่ใน CEX ชั้นนำของเอเชียตะวันออกเฉียงใต้

ลูกค้าเป็น CEX ที่ได้รับใบอนุญาตในสิงคโปร์/มาเลเซีย ซึ่งต้องการเพิ่มธุรกิจตลาดการคาดการณ์ (prediction market) เข้าสู่แอปพลิเคชันที่มีอยู่ พร้อมทั้งปฏิบัติตามข้อกำหนดด้านการปฏิบัติตามกฎระเบียบของ MAS และ SC เราได้ติดตั้งชุดระบบเฝ้าระวังอย่างครบถ้วน ปรับแต่งไลบรารีกฎให้สอดคล้องกับแนวทางของ MAS DPT และ SC พร้อมทั้งปรับระดับการแจ้งเตือนและกระบวนการบังคับใช้ให้สอดคล้องกับแผนกการปฏิบัติตามกฎระเบียบที่มีอยู่ของลูกค้า ภายใน 6 เดือนหลังการเปิดตัว เราได้ตรวจพบและจัดการธุรกรรมที่น่าสงสัย 380 รายการ กู้คืนเงินที่อาจสูญเสียได้จำนวน 2.2 ล้านดอลลาร์ และไม่พบข้อบกพร่องสำคัญใดๆ ในการตรวจสอบจากหน่วยงานกำกับดูแล

กรณีศึกษา 2: ตลาดการคาดการณ์ UGC แบบสแตนด์อโลนในอินโดนีเซีย

ลูกค้าเป็นตลาดการคาดการณ์แบบ UGC ที่มุ่งเป้าไปยังผู้ใช้ในอินโดนีเซีย ครอบคลุมด้านกีฬา อีสปอร์ต และการเมือง เราได้เสริมความแข็งแกร่งในการตรวจจับ Sybil (มีกลุ่มบัญชีฟาร์มจากอินโดนีเซียที่ยังคงทำงานอยู่), การวิเคราะห์กราฟสังคม (ผู้มีอิทธิพลด้านการคาดการณ์บน Twitter/Instagram), และการตรวจจับการเก็งกำไรจากแรงจูงใจ (การฟาร์มเพื่อรับ airdrop/ขึ้นอันดับใน leaderboard) ภายใน 4 เดือนหลังการเปิดตัว กลุ่มบัญชี Sybil กว่า 1,800 กลุ่มถูกแบน และจำนวนคำร้องเรียนที่เกี่ยวข้องกับการฟาร์มบัญชีลดลง 92%

สถานการณ์ 3: ตลาดการคาดการณ์แบบกระจายศูนย์ระดับโลก

ลูกค้าเป็นตลาดการคาดการณ์แบบกระจายศูนย์ที่ปรับใช้บน Polygon/Base โดยเน้นย้ำว่า "ไม่จำเป็นต้อง KYC และดำเนินการทั้งหมดบนเชน" ภายใต้หลักการรักษาความเป็นส่วนตัว (ใช้ ZK proofs + พฤติกรรมบนเชน) เราดำเนินการระบุ Sybil การตรวจจับการโจมตี Oracle และการติดตามเงินทุนข้ามโปรโตคอล หลังการเปิดตัว เราได้ร่วมมือกับบริการป้องกัน MEV และผู้ให้บริการวิเคราะห์บนเชนหลายแห่ง เพื่อสร้างระบบการเฝ้าระวังแบบไฮบริดที่เน้น "KYC แบบเบา แต่การวิเคราะห์บนเชนที่แข็งแกร่ง"

13.3 กำหนดการส่งมอบ

  • สัปดาห์ที่ 1–2: การวิจัยธุรกิจ, ข้อกำหนดด้านกฎระเบียบ, ไลบรารีกฎเบื้องต้น;
  • สัปดาห์ที่ 3–6: การรับข้อมูลและบูรณาการ Kafka, คุณสมบัติแบบเรียลไทม์ของ Flink, เครื่องมือจัดการกฎ;
  • สัปดาห์ที่ 7–8: ฐานข้อมูลกราฟและคุณสมบัติแบบออฟไลน์, การฝึกอบรมโมเดล ML;
  • สัปดาห์ที่ 9–10: ระบบตั๋ว, การบูรณาการกับฝ่ายปฏิบัติตามกฎระเบียบ, การฝึกซ้อม;
  • สัปดาห์ที่ 11: ทดลองใช้งานจริง, กฎแบบเกรย์สเกล;
  • ตั้งแต่สัปดาห์ที่ 12: ปรับค่าเกณฑ์ตามคุณภาพการแจ้งเตือน, ขยายกฎและโมเดล;

14. คำแนะนำสำหรับการนำไปใช้ในองค์กร

14.1 สามขั้นตอนการสร้างระบบเฝ้าระวัง

ขั้นตอนที่ 1 (การอยู่รอด): กฎ + สถิติ (0–3 เดือน)

  • การบูรณาการ Kafka/Flink, เครื่องมือสร้างกฎ, กฎการจับคู่อัตโนมัติ/การปลอมแปลง/การจำกัด;
  • เน้นที่ข้อกำหนดทางกฎหมายขั้นต่ำ (KYC/AML/STR);
  • ทีม 2–3 คนสามารถดำเนินการได้

ขั้นตอนที่ 2 (การป้องกัน): กราฟ + ML (3–9 เดือน)

  • สร้างฐานข้อมูลกราฟ, จัดการการแบ่งกลุ่ม (clustering), ความคล้ายคลึงของพฤติกรรม;
  • ปรับใช้โมเดล XGBoost/GNN;
  • ทีมขยายตัวเป็น 5–8 คน รวมถึงนักวิทยาศาสตร์ข้อมูล

เฟส 3 (การนำ): การคาดการณ์ + การดำเนินการเชิงรุก (9–18 เดือน)

  • ใช้ Agentic AI for Compliance เพื่อค้นหาปัญหาอย่างเชิงรุก;
  • สร้างกลไกการแบ่งปันข้อมูลกับหน่วยงานกำกับดูแล;
  • สร้างแบรนด์ด้านการปฏิบัติตามกฎระเบียบที่นำหน้าในอุตสาหกรรม

14.2 โครงสร้างทีม

ทีมเฝ้าระวังขั้นต่ำ:

  • 1 หัวหน้าฝ่ายการปฏิบัติตามกฎระเบียบ (ติดต่อกับหน่วยงานกำกับดูแล, นโยบาย);
  • 2 เจ้าหน้าที่การปฏิบัติตามกฎระเบียบ (ทำงานเป็นกะ 7×24 ชั่วโมง, ตรวจสอบการแจ้งเตือนและดำเนินการบังคับใช้);
  • 2 วิศวกรข้อมูล (Kafka/Flink/ฐานข้อมูลกราฟ);
  • 1 นักวิทยาศาสตร์ข้อมูล (การฝึกและปรับแต่งโมเดล ML);
  • 1 ผู้จัดการผลิตภัณฑ์ด้านความเสี่ยง (ปรับปรุงคลังกฎ, การจัดการกรณี);
  • 1 นักกฎหมาย (การปฏิบัติตามกฎระเบียบข้ามพรมแดน, การแก้ไขข้อพิพาท);

ด้วยบริการเอาท์ซอร์สและที่ปรึกษาของ SoonTech สามารถสร้างระบบการเฝ้าระวังที่ครบวงจรได้ภายใน 3 เดือน

14.3 ตัวชี้วัดหลัก

  • คุณภาพการแจ้งเตือน: อัตราผลบวกเท็จ P0/P1 < 5%, P2/P3 < 20%;
  • ความล่าช้าของการแจ้งเตือน: P0 < 5 นาที, P1 < 30 นาที, P2 < 4 ชั่วโมง;
  • การปิดการดำเนินการบังคับใช้: 100% ของการแจ้งเตือนได้รับการจัดการภายใน SLA, 100% ของการดำเนินการบังคับใช้มีห่วงโซ่หลักฐานครบถ้วน;
  • ตัวชี้วัดของโมเดล: อัตราการเรียกคืน (recall) ในการตรวจจับ Sybil > 85%, อัตราการเรียกคืน (recall) ในการตรวจจับการซื้อขายภายใน > 70%;
  • การปฏิบัติตามกฎระเบียบ: ไม่มี STR/CTR ที่ถูกพลาด, การตอบคำถามจากหน่วยงานกำกับดูแลภายใน < 24 ชั่วโมง;
  • ผลกระทบต่อธุรกิจ: อัตราการระงับบัญชีผิดพลาด < 0.1%, อัตราการร้องเรียนของผู้ใช้ < 0.05%.

14.4 ข้อผิดพลาดที่พบบ่อย

  • การพึ่งพา ML มากเกินไป: ทีมงานหลายทีมเริ่มต้นด้วยการพยายาม "ใช้ AI เพื่อแก้ปัญหาทุกอย่าง" แต่กลับได้อัตราการตรวจพบเพียง 5% และผลบวกเท็จถึง 80% เราแนะนำให้เริ่มต้นด้วยกฎเกณฑ์ + สถิติ; ใช้ ML เฉพาะในกรณีที่กฎเกณฑ์ไม่สามารถครอบคลุมได้;
  • ความเหนื่อยล้าจากคำเตือน: คำเตือนที่มากเกินไปทำให้เจ้าหน้าที่กำกับดูแลสูญเสียความไวต่อคำเตือน จนพลาด P0 ที่แท้จริง ต้องจัดระดับ จัดสรร และรวมคำเตือนอย่างเคร่งครัด;
  • ขาดห่วงโซ่หลักฐาน: คุณจะตระหนักว่าหลักฐานไม่ได้ถูกเก็บรักษาไว้ก็ต่อเมื่อต้องการติดตามความรับผิดชอบหลังจากเหตุการณ์เกิดขึ้นแล้ว ห่วงโซ่หลักฐานต้องได้รับการพิจารณาตั้งแต่วันแรกของการออกแบบระบบ;
  • การขาดการสื่อสารกับหน่วยงานกำกับดูแล: อธิบายเพียงเมื่อหน่วยงานกำกับดูแลมาตรวจสอบเท่านั้น ควรจัดตั้งช่องทางการสื่อสารกับหน่วยงานกำกับดูแลอย่างเชิงรุกและรายงานอย่างสม่ำเสมอ;
  • ช่องว่างด้านการปฏิบัติตามกฎระเบียบข้ามพรมแดน: การคิดว่า "กฎจะตามผู้ใช้ไปทุกที่" แต่ในความเป็นจริง สถานที่จดทะเบียนของแพลตฟอร์ม ตำแหน่งเซิร์ฟเวอร์ และตำแหน่งทางกายภาพของผู้ใช้ ล้วนมีข้อกำหนดด้านการปฏิบัติตามกฎระเบียบที่แตกต่างกัน

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

Q1: ทำไมตลาดการคาดการณ์จึงถูกควบคุมได้ง่ายกว่าตลาดซื้อขายทันที?

A: มีสามสาเหตุหลัก: 1) การชำระบัญชีเป็นแบบทวิภาค ดังนั้นผลประโยชน์จากการบิดเบือนจะเพิ่มขึ้นแบบไม่เชิงเส้น (0.30→0.90 = ผลตอบแทน 200%); 2) 95% ของเหตุการณ์มีปริมาณการซื้อขายรายวันต่ำกว่า $50K คำสั่งซื้อขายเพียงคำสั่งเดียวสามารถกำหนดราคาได้; 3) ความไม่สมดุลของข้อมูลเป็นธรรมชาติ (ครอบครัวของผู้เล่น หรือผู้ช่วยของนักการเมืองสามารถสร้างตำแหน่งได้ภายในไม่กี่นาทีก่อนที่ข้อมูลสาธารณะจะเผยแพร่) ลักษณะทั้งสามนี้รวมกันทำให้ตลาดการคาดการณ์กลายเป็นจุดร้อนสำหรับการซื้อขายโดยใช้ข้อมูลภายใน การซื้อขายหลอก (wash trading) การโจมตีแบบ Sybil และการโจมตีในช่วงหน้าต่างการชำระบัญชี (settlement-window sniping)

Q2: คุณจะแยกการซื้อขายโดยใช้ข้อมูลภายใน (insider trading) ออกจาก "การทำการบ้าน" (doing homework) อย่างไร?

A: การแยกแยะให้ชัดเจน 100% นั้นยาก แต่คุณสามารถประเมินได้จากสัญญาณหลายประการ: 1) ช่องว่างระหว่างเวลาที่สร้างตำแหน่งกับเวลาที่แหล่งข้อมูลถูกเปิดเผยต่อสาธารณะ (< 30 นาที ถือเป็นข้อสงสัยสูง); 2) การรวมกลุ่มของกลุ่มบัญชี (บัญชีหลายบัญชีสร้างตำแหน่งในทิศทางเดียวกันในเวลาเดียวกัน); 3) ลักษณะของบัญชี (บัญชีที่เพิ่งลงทะเบียนใหม่, บัญชีที่ปรากฏตัวครั้งแรกบนหลายแพลตฟอร์ม, IP/อุปกรณ์ที่เชื่อมโยงกับผู้ละเมิดที่รู้จัก); 4) ว่าแหล่งข้อมูลนั้นเป็น "ข้อมูลที่ไม่เปิดเผยต่อสาธารณะ" หรือไม่ (รายชื่อผู้เล่นตัวจริง, การลงคะแนนภายใน, ข้อมูลเศรษฐกิจที่ยังไม่เผยแพร่ ล้วนเป็น "ข้อมูลที่ไม่เปิดเผยต่อสาธารณะ") โมเดลตรวจจับข้อมูลภายในของ SoonTech ให้คะแนนจาก 8 คุณลักษณะ; คะแนน > 0.65 จะทริกเกอร์การแจ้งเตือนระดับสูง

Q3: อัตราการจับคู่ตัวเองต้องสูงถึงระดับใดจึงจะถือว่ารุนแรง?

A: SoonTech แนะนำให้ใช้เกณฑ์สามระดับ: อัตราการจับคู่ตนเอง = ปริมาณการซื้อขายจากบัญชีที่เกี่ยวข้อง / ปริมาณการซื้อขายรวมของบัญชี > 30% จะทริกเกอร์การแจ้งเตือนระดับกลาง > 50% จะทริกเกอร์การแจ้งเตือนระดับสูง > 70% จะทริกเกอร์การระงับบัญชีทันทีและตรวจสอบด้วยมือ "การซื้อขายกับตัวเอง" แบบบริสุทธิ์ไม่จำเป็นต้องเป็นการซื้อขายล้าง (การป้องกันความเสี่ยงของผู้สร้างตลาดมืออาชีพก็อาจก่อให้เกิดการซื้อขายระหว่างบัญชีที่เกี่ยวข้องได้) แต่ต้องพิจารณาควบคู่กับ PnL แบบวงจรปิด อัตราการยกเลิก และระดับความเชื่อมโยงของบัญชี

Q4: การตรวจจับ Sybil จะไม่ส่งผลกระทบต่อ "สมาชิกในครอบครัวที่ใช้เครื่องเดียวกัน" หรือไม่?

A: ใช่ครับ นี่คือความท้าทายที่ใหญ่ที่สุดในการตรวจจับ Sybil วิธีการของ SoonTech: 1) ใส่ "สถานการณ์ในครอบครัว" เข้าในรายชื่ออนุญาต (Wi-Fi BSSID เดียวกัน + ที่อยู่จัดส่งเดียวกัน + ID KYC ที่เชื่อมโยงกัน); 2) แต่หากมีหลายบัญชีทำการซื้อขายจำนวนมากจากอุปกรณ์เดียวกันและในทิศทางที่สอดคล้องกันอย่างสูง ก็ยังคงถือว่าผิดปกติ ("ผู้ใช้ในครอบครัว" มักไม่ค่อยทำการซื้อขายที่ซิงโครไนซ์กันอย่างแม่นยำ); 3) เสริมความเข้มงวดของ KYC (การจดจำใบหน้า, ID สี่องค์ประกอบ) เพื่อลดการสร้างบัญชีฟาร์มตั้งแต่ต้นทาง; 4) ตรวจสอบกลุ่มที่ถูกทำเครื่องหมายอย่างเป็นระยะด้วยมือ เพื่อแยกแยะ "ผู้ใช้ในครอบครัว" จาก "บัญชีฟาร์ม";

Q5: หลังจากตลาดถูกบิดเบือนแล้ว การยกเลิกคำสั่ง (Void) เป็นมาตรการบังคับใช้ที่ดีที่สุดหรือไม่?

A: ไม่จำเป็นเสมอไป การยกเลิกผล (Void) เป็นมาตรการบังคับใช้ที่รุนแรงที่สุด ซึ่งส่งผลเสียต่อชื่อเสียงของแพลตฟอร์มและความเชื่อมั่นของผู้ใช้ทั้งหมด จึงควรเป็นทางเลือกสุดท้าย ลำดับความสำคัญที่ SoonTech แนะนำ: 1) ระงับบัญชีที่เกี่ยวข้อง + ยกเลิกคำสั่งซื้อขาย (ผลกระทบน้อยที่สุด); 2) เลื่อนการชำระบัญชี (เพื่อให้มีเวลาสอบสวน); 3) ยกเลิกส่วนหนึ่ง (ยกเลิกเฉพาะผลลัพธ์ย่อยที่ถูกบิดเบือน); 4) ยกเลิกตลาดทั้งหมด + ชดเชยจากกองทุนประกัน (ขั้นสุดโต่ง). การยกเลิกควรได้รับการพิจารณาอย่างร่วมกันโดยฝ่ายปฏิบัติตามกฎระเบียบ + ฝ่ายกฎหมาย + ฝ่ายธุรกิจ และอธิบายให้ชัดเจนต่อสาธารณะ

Q6: ทำอย่างไรให้การรายงานตามกฎระเบียบทั้งสอดคล้องกับกฎระเบียบและมีประสิทธิภาพ?

A: ระบบการปฏิบัติตามกฎระเบียบของ SoonTech ทำให้การรายงานต่อหน่วยงานกำกับดูแลเป็น "ระบบที่ขับเคลื่อนด้วยการกำหนดค่า": กฎการรายงานแต่ละข้อจะกำหนดเงื่อนไขการทริกเกอร์, แม่แบบเนื้อหา, วิธีการส่ง, หน่วยงานกำกับดูแล และความถี่ ระบบจะดึงข้อมูลจากคำเตือนการเฝ้าระวังและข้อมูลการซื้อขายโดยอัตโนมัติ สร้างร่างรายงาน และหลังจากเจ้าหน้าที่ปฏิบัติตามกฎระเบียบตรวจสอบแล้ว จะส่งผ่าน API หรือด้วยตนเอง นอกจากนี้ เรายังรักษา "คลังข้อมูลการตอบคำถามจากหน่วยงานกำกับดูแล" ที่แปลงคำถามทั่วไปจากหน่วยงานกำกับดูแลให้เป็นแม่แบบ ซึ่งช่วยลดเวลาตอบกลับเฉลี่ยจาก 5 วันลงเหลือ 1 วัน

🌐 สร้างแพลตฟอร์ม Web3 ที่ปลอดภัยและสามารถขยายได้กับ SoonTech.

ค้นพบโซลูชันของเราสำหรับตลาดคริปโตแบบ White Label, ตลาดการคาดการณ์, กระเป๋าเงิน MPC, เครื่องมือจับคู่, การบูรณาการสภาพคล่อง และการปฏิบัติตามกฎระเบียบ

เริ่มต้นการเดินทางบล็อกเชนทันที

ทีมงานมืออาชีพให้คำปรึกษาโซลูชันฟรี

ติดต่อทันที