แพตเทิร์น SQL ที่ใช้ตรวจจับการฉ้อโกงธุรกรรม

 (analytics.fixelsmith.com)
17 คะแนน โดย GN⁺ 2026-05-17 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • การตรวจจับการฉ้อโกงมักเริ่มจากการจัดการ ตารางและการ join ให้ถูกต้องก่อนแมชชีนเลิร์นนิง และใช้ SQL ค้นหารูปแบบผิดปกติด้านความเร็ว ตำแหน่ง จำนวนเงิน ร้านค้า และช่วงเวลา
  • Velocity คือการหาระยะที่ธุรกรรมของเจ้าของบัตรเดียวกันกระจุกตัวในช่วงเวลาสั้น ๆ โดยต้องปรับหน้าต่างเวลา ค่าขีดจำกัด และมีไวต์ลิสต์สำหรับ false positive
  • Impossible travel ใช้ LAG() และการคำนวณระยะทางเพื่อตรวจจับสัญญาณบัตรถูกโคลนที่รุนแรง เช่น จ่ายเงินที่ Chicago แล้วอีก 7 นาทีต่อมาจ่ายที่ Los Angeles ซึ่งเป็นการเคลื่อนที่ที่เป็นไปไม่ได้ทางกายภาพ
  • ความผิดปกติของจำนวนเงิน จะหาช่วงยอดอย่าง $1.00, $99.99, $499.99 ที่บ่งชี้การทดสอบบัตรหรือการหลบเลี่ยงกฎ แต่ไม่ค่อยเหมาะกับธุรกรรมสวัสดิการ
  • เมื่อใช้การพุ่งขึ้นของร้านค้า ธุรกรรมนอกช่วงเวลาปกติ และคอลัมน์อนุพันธ์จาก window function ร่วมกัน ก็สามารถ ให้คะแนนธุรกรรมจากหลายสัญญาณ และลดรอบการทำซ้ำจากหลายสัปดาห์เหลือไม่กี่ชั่วโมงได้

แพตเทิร์น SQL สำหรับหาสัญญาณการฉ้อโกงในข้อมูลธุรกรรม

  • การตรวจจับการฉ้อโกงมักเริ่มจาก ตารางและการ join ที่ถูกต้อง รวมถึงการใช้ SQL เพื่อหารูปแบบธุรกรรมแปลก ๆ ก่อนจะไปถึงแมชชีนเลิร์นนิงหรือกราฟดาต้าเบส
  • ใช้ได้กับข้อมูลที่มีการเคลื่อนย้ายเงินและมีบันทึกล็อก เช่น บัตรเครดิต การเคลมค่ารักษาพยาบาล อีคอมเมิร์ซ POS และโครงการสวัสดิการภาครัฐ
  • เมื่อเจอชุดข้อมูลใหม่ มักค่อย ๆ สะสมแพตเทิร์นตามลำดับ ความเร็ว การเดินทางที่เป็นไปไม่ได้ ความผิดปกติของจำนวนเงิน การกระจุกตัวของร้านค้า ช่วงเวลาผิดปกติ และสัญญาณที่อิง window function

1. Velocity: ธุรกรรมมากเกินไปในช่วงเวลาสั้น ๆ

  • หากมีการพยายามรูดใช้บัตรหรือบัญชีที่ถูกขโมยให้หมดอย่างรวดเร็ว มักจะเห็น รูปแบบที่ธุรกรรมกระจุกตัวในช่วงเวลาสั้น ๆ กับเจ้าของบัตรคนเดิม
  • คิวรีพื้นฐานจะจัดกลุ่มธุรกรรม 30 วันล่าสุดเป็นรายชั่วโมง แล้วหาระยะที่จำนวนธุรกรรมต่อ cardholder_id เกินเกณฑ์
  • ค่าที่ต้องปรับหลัก ๆ คือ ขนาดหน้าต่างเวลา และ ค่าขีดจำกัดจำนวนธุรกรรม
    • สามารถรันเวอร์ชัน 1 นาที 5 นาที และ 1 ชั่วโมงแบบขนานเพื่อเปรียบเทียบได้
    • กลุ่มที่ทดสอบบัตรมักอัดธุรกรรมภายในไม่กี่วินาที ขณะที่กลุ่มทุจริตสวัสดิการอาจกระจายการเคลื่อนไหวตลอดครึ่งวัน จึงมีสเกลต่างกัน
  • ผู้ใช้ปกติก็อาจเกินเกณฑ์ได้
    • ผู้ดูแลตู้ขายสินค้าอัตโนมัติ
    • คนที่เติมเงินบัตรเติมเงินจำนวนมาก
    • หลังจากสำรวจรอบแรกแล้ว จึงต้องมี ไวต์ลิสต์สำหรับ false positive เหล่านี้
  • วิธี sliding window ใช้ COUNT(*) OVER (...) RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW เพื่อคำนวณจำนวนธุรกรรมใน 5 นาทีล่าสุด
  • QUALIFY ใช้งานได้ใน Snowflake, BigQuery, Databricks, Teradata
    • ใน Postgres ต้องครอบคิวรีทั้งหมดด้วย CTE แล้วค่อยกรองด้านนอก

2. Impossible travel: การเคลื่อนที่ที่เป็นไปไม่ได้ทางกายภาพ

  • หากบัตรใบเดียวกันจ่ายเงินที่ Chicago แล้วอีก 7 นาทีต่อมาจ่ายที่ Los Angeles มีโอกาสสูงว่าหนึ่งในสองรายการเป็นของปลอม
  • แพตเทิร์นนี้เป็นสัญญาณแรงในการจับ บัตรที่ถูกโคลน เพราะแทบไม่มีเหตุผลปกติที่บัตรใบเดียวจะไปอยู่สองสถานที่ไกลกันภายในไม่กี่นาที
  • คิวรีจะใช้ LAG() ดึงเวลาและตำแหน่งของธุรกรรมก่อนหน้า จากนั้นคำนวณระยะทางและเวลาระหว่างตำแหน่งก่อนหน้ากับตำแหน่งปัจจุบัน
  • haversine เป็นฟังก์ชันสำหรับคำนวณ ระยะทางตามแนววงกลมใหญ่ (great-circle distance)
    • ดาต้าแวร์เฮาส์ส่วนใหญ่มีให้
    • ถ้าไม่มี ก็เป็นฟังก์ชันที่เขียนเองได้ไม่ยาก
  • ตัวอย่างค่าขีดจำกัดคือ 600mph
    • เพราะความเร็วเดินทางของเครื่องบินพาณิชย์อยู่ราว 575mph จึงหมายถึงเร็วเกินกว่าจะเป็นไปได้แม้เดินทางด้วยเครื่องบิน
    • ถ้าลดลงเหลือ 100mph ก็จะจับการเคลื่อนที่เร็วบนพื้นดินได้ด้วย แต่จะเริ่มกินธุรกรรมปกติของผู้โดยสารเครื่องบินจริง หรือพ่อแม่ที่ขับรถพาลูกไปส่ง
  • ยังมีสัญญาณอื่นในตระกูลเดียวกันที่ดูเพิ่มได้
    • ถ้ามีธุรกรรมในสองเมืองที่ห่างกันมากภายในรัฐเดียวกันในเวลา 5 นาที อาจบ่งชี้ ขบวนการโคลนบัตรในพื้นที่
    • ถ้ามีธุรกรรมในหลาย ZIP code ภายใน 1 ชั่วโมง อาจบ่งชี้ ขบวนการ skimmer ที่เคลื่อนไหวอยู่ในพื้นที่เดียวกัน
    • ธุรกรรมที่ข้ามพรมแดนภายใน 10 นาที อาจเป็นสัญญาณของ ขบวนการระหว่างประเทศ

3. Amount anomalies: ธุรกรรมผิดปกติที่จำนวนเงินบางช่วง

  • ในการฉ้อโกงมี รูปแบบจำนวนเงิน ที่พบได้บ่อย แต่ไม่ค่อยเกิดในการใช้งานปกติ
  • ตัวอย่างเงื่อนไขจะหาช่วงจำนวนเงินต่อไปนี้
    • $1.00, $5.00, $10.00
    • ตั้งแต่ $99.50 ขึ้นไปแต่ต่ำกว่า $100.00
    • ตั้งแต่ $499.50 ขึ้นไปแต่ต่ำกว่า $500.00
  • จำนวนเงินดอลลาร์เต็ม ๆ ที่เล็กมักเป็นสัญญาณของ การทดสอบบัตร
    • คือการตรวจว่าหมายเลขบัตรที่ได้มาจาก card dump ใช้งานได้จริงหรือไม่ก่อนนำไปขายต่อ
    • โดยทั่วไปเจ้าของบัตรจริงไม่ค่อยซื้อของราคาเป๊ะ ๆ ที่ $1.00
    • กาแฟมักเป็น $4.73 ค่าน้ำมันมักเป็น $52.81 มากกว่าจะเป็นยอดปัดกลมพอดี
  • จำนวนเงินที่อยู่ต่ำกว่าค่าขีดจำกัดเล็กน้อยมีความหมายอีกแบบ
    • $99.99 อาจเป็นรูปแบบที่พยายามหลบเส้นที่หลายแห่งกำหนดให้ต้องตรวจบัตรประชาชนตั้งแต่ $100 ขึ้นไป
    • $499.99 อาจเป็นรูปแบบที่พยายามหลบวงเงินถอน ATM รายวัน $500
    • เป็นสัญญาณว่าผู้ทำธุรกรรมรู้กฎและตั้งใจอยู่ต่ำกว่าเกณฑ์
  • สำหรับธุรกรรมสวัสดิการ แพตเทิร์นจำนวนเงินแบบปัดกลม ไม่ค่อยช่วยมาก
    • สวัสดิการไม่ได้ถูกทดสอบบัตรในลักษณะเดียวกัน
    • ปกติแล้วผู้รับสิทธิ์ซ้ำซ้อนมักเป็นสัญญาณที่สำคัญกว่า

4. Suspicious merchants: การกระจุกตัวผิดปกติในระดับร้านค้า

  • หากเครื่องอ่านบัตรเฉพาะจุด เช่น เครื่องอ่านที่ปั๊มน้ำมัน ติด skimmer ขึ้นมา มันอาจไม่จบแค่รายการเดียว แต่ลามเป็น ธุรกรรมฉ้อโกงหลายสิบรายการ
  • บัตรทุกใบที่ใช้กับเครื่องอ่านนั้นตลอดหลายสัปดาห์อาจถูกเก็บเข้าไปในฐานข้อมูลของใครบางคน
  • ในมุมร้านค้า มักเห็นเป็นรูปแบบที่ภายในช่วงเวลาสั้น ๆ จำนวนบัตรที่ไม่เกี่ยวข้องกันเพิ่มขึ้นมากกว่าปกติ และยอดธุรกรรมก็สูงขึ้นด้วย
  • ตัวอย่างเกณฑ์แบบง่ายคือจัดกลุ่มตามร้านค้าและรายชั่วโมงในช่วง 7 วันล่าสุด แล้วคำนวณ
    • จำนวนบัตรไม่ซ้ำ
    • จำนวนธุรกรรมรวม
    • มูลค่าธุรกรรมรวม
    • ค้นหาช่วงเวลาที่มีบัตรไม่ซ้ำเกิน 20 ใบ และยอดรวมเกิน $5000
  • ค่าขีดจำกัดแบบคงที่มีปัญหาเรื่องการชดเชยขนาด
    • Costco อาจเกินเกณฑ์นี้ได้ภายใน 90 วินาที
    • แต่ร้านหนังสือมือสองอาจแทบไม่เคยเกินเลย
  • วิธีที่ดีกว่าคือเทียบแต่ละร้านค้าเข้ากับ ค่า baseline ในอดีตของตัวเอง
    • จัดกลุ่มธุรกรรม 60 วันล่าสุดเป็นรายชั่วโมง
    • คำนวณค่าเฉลี่ยจำนวนบัตรไม่ซ้ำของแต่ละร้านค้าโดยอิงจาก 168 hourly bucket ย้อนหลัง
    • หาช่วงที่จำนวนบัตรไม่ซ้ำปัจจุบันมากกว่าค่าเฉลี่ยในอดีต 3 เท่า
  • 168 hourly bucket คือ ช่วงรายชั่วโมงของ 7 วันที่ผ่านมา
    • เพราะ seasonality รายวันและรายสัปดาห์มีความสำคัญ
    • แม้เป็นร้านกาแฟเดียวกัน baseline ตอนบ่าย 2 วันอังคารกับ 9 โมงเช้าวันเสาร์ก็ไม่เหมือนกัน
  • จุดตั้งต้นอาจใช้ 3 เท่าของค่าปกติ
    • หลวมพอที่จะไม่ทำให้มี alert ถล่มเข้ามามากเกินไป
    • แต่ก็ยังเข้มพอจะจับช่วงเวลาที่ผิดปกติจริงได้

5. Off-hours: ธุรกรรมนอกช่วงเวลาที่บุคคลนั้นมักใช้งาน

  • คนส่วนใหญ่มีรูปแบบการใช้จ่ายของตัวเอง
  • ถ้าคนที่ทำงาน 9 โมงถึง 5 โมงเย็นจู่ ๆ ไปเติมน้ำมันตอนตี 3 ก็อาจหมายถึงบัตรถูกคนอื่นใช้ หรือกำลังเดินทางอยู่
  • เรื่องกำลังเดินทางหรือไม่สามารถตรวจเพิ่มด้วยสัญญาณอื่นได้
  • คิวรีจะนับจำนวนธุรกรรมตามเจ้าของบัตรและชั่วโมงในช่วง 90 วันล่าสุด แล้วถือว่าเฉพาะชั่วโมงที่มีธุรกรรมอย่างน้อย 2 ครั้งเท่านั้นเป็น ช่วงเวลาปกติ
  • จากนั้นถ้าเวลาของธุรกรรมใหม่อยู่นอกช่วง earliest_hour ถึง latest_hour ของเจ้าของบัตรนั้น ก็จะถูกตรวจจับ
  • เงื่อนไข “อย่างน้อย 2 รายการในชั่วโมงนั้น” ในคิวรีด้านในมีความสำคัญ
    • เพื่อกันไม่ให้การเติมน้ำมันดึก ๆ เพียงครั้งเดียวเมื่อ 3 เดือนก่อนถูกนับเป็นช่วงเวลาปกติ
    • ทำให้เกณฑ์อิงกับ พฤติกรรมจริง ไม่ใช่ “เคยเกิดขึ้นครั้งหนึ่ง”
  • ข้อเสียคือ ต้องมีข้อมูลประวัติ
    • บัญชีใหม่ยังไม่มี baseline
    • สำหรับบัญชีใหม่อาจใช้แพตเทิร์นช่วงเวลาของผู้ใช้ทั้งหมด หรือข้ามแพตเทิร์นนี้ไปจนกว่าจะมีข้อมูลสะสมหลายเดือน

6. การรวมสัญญาณด้วย window function

  • แพตเทิร์น window function ไม่ใช่ประเภทการฉ้อโกงแยกต่างหาก แต่เป็นงานเตรียมให้แพตเทิร์นทั้งห้าก่อนหน้านี้กลายเป็น สัญญาณที่นำมาประกอบกันได้
  • สามารถสร้างคอลัมน์อนุพันธ์ต่อธุรกรรมไว้ล่วงหน้าได้ เช่น
    • เวลาที่ผ่านไปนับจากธุรกรรมก่อนหน้า: timestamp - LAG(timestamp)
    • มีการเปลี่ยนร้านค้าหรือไม่: เปรียบเทียบ merchant_id ก่อนหน้ากับ merchant_id ปัจจุบัน
    • ยอดสะสมใน 24 ชั่วโมงล่าสุด: SUM(amount) OVER (...)
    • เป็นธุรกรรมลำดับที่เท่าไรของวันนั้น: ROW_NUMBER()
  • เมื่อ materialize คอลัมน์เหล่านี้ไว้ กฎตรวจจับการฉ้อโกงก็จะยุบเหลือแค่ filter expression ง่าย ๆ
  • กลุ่มทดสอบบัตรอาจหาได้ด้วยเงื่อนไขต่อไปนี้
    • เป็นธุรกรรมลำดับที่ 5 ของวันหรือมากกว่า
    • ห่างจากธุรกรรมก่อนหน้าไม่ถึง 60 วินาที
    • ร้านค้าแตกต่างจากธุรกรรมก่อนหน้า
  • ถ้าสามารถเขียนสมมติฐานการฉ้อโกงใหม่เป็น SQL filter แทนการเปิด engineering ticket ได้ รอบการทำซ้ำก็จะลดจาก หลายสัปดาห์เหลือไม่กี่ชั่วโมง
  • ผลลัพธ์คือจับการฉ้อโกงได้มากขึ้นและเร็วขึ้น

วิธีใช้แพตเทิร์นร่วมกัน

  • ไม่มีแพตเทิร์นใดแพตเทิร์นหนึ่งเพียงลำพังที่เพียงพอ
  • แต่ละแพตเทิร์นมีข้อจำกัดชัดเจน
    • Velocity มี false positive อย่างผู้ดูแลตู้ขายสินค้าอัตโนมัติ
    • การเคลื่อนที่ที่เป็นไปไม่ได้ทางภูมิศาสตร์จะพลาดการฉ้อโกงที่เกิดภายในเขตเมืองใหญ่เดียวกัน
    • ความผิดปกติของจำนวนเงินไม่ค่อยแม่นนอกบริบทการทดสอบบัตร
    • กฎช่วงเวลาผิดปกติต้องอาศัยประวัติ
  • ในงานจริง วิธีที่ใช้ได้ผลคือรันทุกแพตเทิร์น แล้ว ให้คะแนนแต่ละธุรกรรมจากหลายสัญญาณ
  • ธุรกรรมที่โดน 3 หรือ 4 สัญญาณพร้อมกันแทบจะเป็นการฉ้อโกงเสมอ
  • ธุรกรรมที่โดนแค่ 1 สัญญาณอาจเป็นเพียงการใช้งานแปลก ๆ ของเจ้าของบัตรปกติที่กำลังเดินทาง
  • ถ้าเพิ่งเริ่มทำการตรวจจับการฉ้อโกง ควรเริ่มจาก Velocity
    • เปิดให้เห็นการฉ้อโกงได้ในปริมาณที่มีประโยชน์
    • จับกิจกรรมปกติค่อนข้างน้อย
    • และมีต้นทุนในการรันต่ำ
  • ถ้ามีข้อ 1 ถึง 5 อยู่แล้ว จุดที่ควรลงทุนต่อคือ raw column ที่อิง window function
    • สร้างครั้งเดียวแล้วนักวิเคราะห์ทุกคนในทีมใช้ต่อได้
    • การเพิ่มแพตเทิร์นฉ้อโกงถัดไปก็ไม่ต้องกลายเป็นอีกโปรเจกต์หนึ่ง

ข้อควรระวัง

  • การจัดการ NULL

    • ตารางธุรกรรมจริงมักไม่ได้ใช้ NULL แบบในตำรา SQL เบื้องต้น
    • ระบบ legacy จำนวนมากใช้ sentinel value อย่าง 9999-12-31 สำหรับ “ไม่มีวันสิ้นสุด” และ 0001-01-01 สำหรับ “ไม่มีวันเริ่มต้น”
    • ถ้ากรองด้วย IS NULL อาจพลาดแถวเหล่านี้ไปแบบเงียบ ๆ
    • ควรตรวจธรรมเนียมของตารางนั้นก่อน แล้วค่อยเขียน WHERE clause

  • False positive

    • ทุกกฎสามารถจับเจ้าของบัตรจริงที่มีพฤติกรรมผิดปกติแต่ถูกต้องตามกฎหมายได้
    • เคสที่ถูกปักธงต้องมี การตรวจสอบโดยมนุษย์
    • ต้องมี feedback loop เพื่อปรับค่าขีดจำกัดโดยอิงจากสิ่งที่เป็นการฉ้อโกงจริงและไม่ใช่จริง
    • ถ้าบล็อกอัตโนมัติด้วยกฎเดี่ยวเพียงข้อเดียว อาจเสียลูกค้าได้

  • ข้อมูลส่วนบุคคล

    • หากข้อมูลมี PII ต้องปฏิบัติตาม นโยบายการใช้ข้อมูล ที่เกี่ยวข้อง
    • ควรเริ่มจากข้อมูลที่ไม่ระบุตัวตนหรือข้อมูลตัวอย่างก่อน และใช้ข้อมูลโปรดักชันหลังได้รับอนุมัติแล้วเท่านั้น

  • ต้นทุน

    • window function บนพาร์ทิชันขนาดใหญ่ไม่ได้ราคาถูก
    • ควรกรองช่วงวันที่ก่อน แล้วค่อยใช้ window function
    • ถ้ารัน LAG() กับธุรกรรม 2 ปีของทั้งชุดข้อมูลก่อน แล้วค่อยใส่ WHERE ทีหลัง อาจกินงบ warehouse credit อย่างมาก

บทความที่เกี่ยวข้อง

4 ความคิดเห็น

 
kaydash 2026-05-17

ดูเป็นวิธีที่เคยถูกนำมายืมใช้ในระบบบัญชีธนาคารและระบบช่องทางมาก่อนนะครับ
 
GN⁺ 2026-05-17
ความคิดเห็นใน Hacker News

  • เกณฑ์ที่ว่าผู้ถือบัตรตัวจริงแทบไม่ค่อยซื้อของราคา $1.00 เป๊ะ ๆ ดูจะขึ้นอยู่กับว่าผู้ขายตั้งราคาอย่างไรไม่ใช่หรือ
    เวลาจะทดสอบบัตรเครดิตที่ขโมยมาโดยซื้ออะไรสักอย่างบนเว็บไซต์ ผู้ซื้อก็ไม่ได้กำหนดราคาเองได้ตามใจ
    อีกอย่างมันยังดูคิดอยู่บนสมมติฐานแบบสหรัฐฯ มากเกินไป ซึ่งราคาไม่รวมภาษี แต่ในภูมิภาคอื่น ๆ ราคากลม ๆ เป็นเรื่องปกติมาก
    เกณฑ์อื่น ๆ ในบทความก็น่าสงสัยว่าจะใช้ได้ดีแค่ไหน เช่น ถ้าตั้งธงคนที่ทำธุรกรรมนอกช่วงเวลาที่ปกติทำเกิน 2 ครั้งในช่วง 90 วันที่ผ่านมา แบบนั้นคงจับคนได้สักครึ่งหนึ่งหรือเปล่า
    ไม่ชัดว่านี่เป็นบทความที่เอาความรู้เฉพาะทางซับซ้อนมาทำให้ง่ายเกินไปด้วย SQL query ธรรมดา ๆ หรือเป็นแค่การเดาและแต่งขึ้นทั้งหมด ประโยค “หกแพตเทิร์น SQL ที่ใช้จับธุรกรรมฉ้อโกง” กับ “ไม่มีอะไรในนี้ที่ฉันเคยทำจริงหรือเคยเห็นจริง” มันขัดกันเอง

    • “ธุรกรรมนอกช่วงเวลาปกติ” ดูเป็นเกณฑ์พื้นฐานมาก
      ปกติคงไม่ไปซื้อน้ำมัน กาแฟ หรือขนมตอนตี 2 แต่ถ้าเกิดทำแบบนั้นนาน ๆ ที ก็น่าจะเป็นเหตุฉุกเฉินส่วนตัว และคงไม่อยากโทรหาธนาคารในจังหวะนั้น
      เข้าใจว่าโจรแบบฉวยโอกาสก็อาจออกปฏิบัติการเวลานั้นได้ แต่ ต้นทุนของ false positive ก็มีจริงเหมือนกัน
    • แย่กว่านั้นอีก จากประสบการณ์ของฉัน กาแฟมักเป็น ยอดกลม ๆ เป๊ะ และบางคนก็ตั้งใจเติมน้ำมันให้ได้ยอดพอดี
      อีกทั้งยังมีปั๊มน้ำมันที่ให้เลือกยอดตายตัวอย่าง 10, 20 หรือ 50 ยูโรด้วย
    • คืนหนึ่งที่บาร์ฉันหิวเลยจะซื้อขนมมันฝรั่งถุงหนึ่ง แต่ร้านกำหนดยอดชำระขั้นต่ำด้วยบัตรที่ £5 ก็เลยบอกให้คิดเป็น £5 ไปเลย
      ปรากฏว่าบัตรถูกบล็อกเพราะสงสัยว่าเป็นการฉ้อโกง ซึ่งน่าหงุดหงิดมาก ไม่ใช่เรื่องที่อยากจัดการตอนตี 2 ขณะเมา
      บางทีอาจพูดได้ว่ามันปกป้องฉันจากตัวเอง แต่ก็ยังน่ารำคาญอยู่ดี
    • ไม่แน่ใจว่ายังใช้กันอยู่ไหม แต่เมื่อก่อนสถานที่อย่างโรงแรมหรือบริษัทเช่ารถมักตรวจสอบว่าบัตรเครดิตใช้ได้หรือไม่ด้วย ธุรกรรม $1.00 ก่อนยืนยันการจองห้องหรือปล่อยรถเช่า
    • วิธีนี้หลบได้ง่ายถ้าใส่ ค่าการส่ายเล็กน้อย ลงไปในธุรกรรมทดสอบ และก็ปรับปรุงได้ง่ายด้วยการวิเคราะห์ทางสถิติที่เหมาะสม
      และการรู้จำแพตเทิร์นแบบ heuristic ที่ไม่ได้หวังความแม่นยำเกือบ 100% แบบนี้ ไม่ใช่งานที่ AI ควรจะถนัดพอดีหรือ

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

    • เมื่อไม่กี่สัปดาห์ก่อน ตอนข้ามจากสหรัฐฯ ไปแคนาดา ก็น่าจะใช้เวลาแค่ 10 นาที เอง

  • อ่านจนจบแล้วจะเห็นว่ามันเป็นคำแนะนำที่กลวงและขัดแย้งกันเอง ดูแทบจะแน่ใจได้ว่าเป็น บทความที่ LLM สร้าง
    บอกว่า “ทีมของคุณ” ไม่ควรพึ่งพาแพตเทิร์นใดแพตเทิร์นหนึ่ง แต่ก็กลับบอกว่าแพตเทิร์นแรกเพียงอย่างเดียวก็เผย “ปริมาณการฉ้อโกงที่มีประโยชน์” ได้
    ยังมีประโยคประหลาดอย่าง “นักวิเคราะห์ทุกคนในทีมจะใช้สิ่งเหล่านั้น นั่นคือ window function เมื่อมีมัน และการเพิ่มแพตเทิร์นฉ้อโกงถัดไปจะไม่ใช่โปรเจกต์”
    อีกทั้งตัวอย่างแทบทั้งหมดไม่ได้ใช้ IS NULL เลย แต่กลับมีการอภิปรายที่ไม่เกี่ยวกันว่าการกรอง IS NULL อาจไม่ถูกนำไปใช้ และตัวอย่างเดียวที่ใช้ก็อยู่คนละบริบท
    โดยรวมคือ คุณภาพต่ำและยาวเกินไป

  • Hacker News เรื่องนี้ต้องพูดกันตรง ๆ
    “Fixel Smith” คือ ตัวตนที่ AI สร้างขึ้น และบทความนี้แทบไม่เกี่ยวกับการวิเคราะห์การฉ้อโกงเลย ชื่อนี้ถูกใช้เป็นแทบทุกตัวตนที่นึกออกได้ ทั้งนักดนตรี (1) นักเขียนนิยาย (2) นักวิเคราะห์การฉ้อโกง (3) อินฟลูเอนเซอร์ (4)
    ได้คะแนนเกิน 220 และมีคอมเมนต์เกิน 70 แต่แทบไม่มีใครสังเกตว่าบทความนี้ปลอมพอตัว และไม่มีใครเห็นว่าผู้เขียนเป็นตัวละครที่ AI สร้าง

    1. https://www.amazon.it/Forged-Soundtrack-Explicit-Fixel-Smith...

    2. https://fixelsmith.com

    3. https://analytics.fixelsmith.com/

    4. https://www.instagram.com/fixeltales/

    • ช่วงหลัง ๆ Hacker News ดูเหมือนจะมีนิสัยน่าหงุดหงิดในการดัน โพสต์ AI คุณภาพต่ำ แบบนี้ขึ้นมา
      เลยชวนสงสัยว่าน้ำท่วมจาก AI นี้กำลังเปิดเผยความจริงที่น่าอึดอัดเกี่ยวกับวิจารณญาณของชุมชน หรือเป็นแค่ความล้มเหลวของกลไกป้องกันเดิมที่แก้ไขได้ถ้าปรับให้ถูกจุด
    • ฉันเช็กบทความบนมือถือแล้วกวาดตาดูคอมเมนต์นิดหน่อย ไม่ใช่ว่าจะตัดสินได้ง่ายเสมอไปว่าบทความไหนสร้างโดย AI หรือผ่านการเรียบเรียงมา แต่กรณีนี้แค่มองคำพูดที่ยกมาก็ชัดตั้งแต่แรกเห็นแล้ว
      ถ้าสมมติว่าคอมเมนต์ทั้งหมดเขียนด้วยความสุจริตใจ แม้แต่ที่นี่ยังมี ความรู้เท่าทัน AI ต่ำ ก็ถือว่าน่ากังวลพอสมควร
    • มองผ่าน ๆ ก็เหมือนเป็นคนที่ผลิตงานจำนวนมากผิดปกติหรือไม่ก็เป็นบอต
      งานนิยายแทบไม่เกี่ยวอะไรกับบทความวิเคราะห์ และบทความวิเคราะห์ก็ดูมี สำนวนแบบ LLM เลยยิ่งน่าสงสัยไปหมด พอนึกว่าหัวข้อของต้นฉบับคือการฉ้อโกงก็ยิ่งประชดดี
    • ถ้าบอกว่าคนส่วนใหญ่มีนิสัยไปตรวจสอบผู้เขียนของทุกบทความที่อ่าน ฉันคงแปลกใจกว่านั้นอีก
      พูดตรง ๆ คือปกติฉันแทบไม่ดูแม้แต่ชื่อผู้เขียน และยิ่งไม่ค่อยไปดูส่วนอื่นของเว็บไซต์
    • นี่เป็นบทความที่มีอยู่จริงแน่นอน แน่นอนว่ามัน ดูเหมือน LLM เขียน แต่ถ้าคำวิจารณ์ที่แย่ที่สุดที่มีต่อบทความคือมันดูเหมือน LLM ก็อาจแปลว่ายังไม่มีคำวิจารณ์ที่เป็นรูปธรรมก็ได้
      จะเป็นข้อมูลแต่งหรือไม่ก็ยังไม่ชัด แต่เราก็วิจารณ์เนื้อหาของบทความได้โดยไม่ต้องเดาว่า LLM เขียนหรือเป็นนิยาย เพราะมีข้อบกพร่องที่เจาะจงกว่านั้นอีกมาก

  • พวกเรากำลังพัฒนาเฟรมเวิร์กความปลอดภัยโอเพนซอร์ส tirreno
    ฉันสงสัยแนวทางที่อธิบายไว้ที่นี่ เช่น impossible travel เป็นเทคนิคที่ใช้จริงและแพร่หลาย แต่เกี่ยวกับพฤติกรรมผู้ใช้ออนไลน์ที่อิงจากที่อยู่ IP
    ใน tirreno มี rule แยกสำหรับกรณีที่ชัดเจนว่า IP มาจาก Apple Relay หรือ VPN/Tor และพวกนั้นก็เป็นแฟล็กอีกชุดหนึ่งต่างหาก
    ฉันคิดว่าตัวอย่างบางส่วนหรือทั้งหมดน่าจะถูกสร้างโดย LLM เพราะบริบทปนกันมั่ว และในโลกจริงไม่มีใครเก็บตำแหน่ง GPS ของการจ่ายเงินผ่านบัตรในปริมาณมากแบบนั้น

    1. https://github.com/tirrenotechnologies/tirreno

  • นี่ใกล้เคียงกับ ตรรกะแบบอิงกฎ ที่เข้ารหัสเป็น SQL query โดยไม่มีข้อมูลหลักฐานมารองรับมากกว่า
    มี threshold เต็มไปหมด แต่ไม่มีข้อมูลว่าค่า threshold เหล่านั้นมีความหมายจริง

  • คำยืนยันทำนองว่า “การตรวจจับการฉ้อโกงในข้อมูลธุรกรรมส่วนใหญ่คือ SQL ไม่ใช่ machine learning ไม่ใช่ graph database และไม่ใช่อะไรก็ตามที่ Gartner กำลังปั่นในปีนี้” จะพอฟังขึ้นก็ต่อเมื่อกำลังพูดถึงงานด้าน program integrity ทั้งหมด
    ถ้าวิธีที่ง่ายกว่าและหยาบกว่าช่วยแก้ปัญหาในโดเมนได้ มันก็อาจดีกว่า
    ลูกค้า fintech มักอยากรู้ว่าธุรกรรมที่กำลังเกิดขึ้นตอนนี้เป็นการฉ้อโกงหรือไม่ และต้องการคำตอบภายในไม่กี่มิลลิวินาทีบนข้อมูลมิติสูง งานนี้มีขนาดและข้อจำกัดแบบเรียลไทม์ที่ relational database มักรองรับได้ยาก จึงมักถูกใช้กับอย่างอื่นแทน เช่น การโหลดข้อมูลย้อนหลัง
    นั่นจึงเป็นเหตุผลที่มีทั้งฐานข้อมูล in-memory, stream processing engine และ machine learning เข้ามาเกี่ยวข้อง
    ถึงอย่างนั้นบางประเด็นของผู้เขียนก็สมเหตุสมผล โดยเฉพาะปัญหาการรับมือกับการแจ้งเตือนที่มีสัญญาณรบกวนเยอะ ซึ่งเป็นปัญหาทั่วไปที่ไกลเกินกว่าแค่งาน performance engineering เลยทำให้อยากอ่านบทความถัดไป

    • จากประสบการณ์ของฉัน สิ่งที่อธิบายมานี้ถ้าจะให้เฉพาะเจาะจงกว่าน่าจะเรียกว่า การป้องกันการฉ้อโกง มากกว่าการตรวจจับการฉ้อโกง ในระบบที่โตเต็มที่ทั้งสองอย่างจะอยู่ร่วมกันและเสริมกัน
      ฝั่งการป้องกันจะถูกจำกัดด้วยข้อกำหนดด้าน latency ข้อมูลที่มีให้ใช้ และภาพพฤติกรรมของผู้ใช้ที่ไม่สมบูรณ์เสมอ เราใช้ machine learning และกฎเพื่อให้ตัดสินใจได้เร็วและจัดการเคสส่วนใหญ่ แต่ด้วยข้อจำกัดเหล่านั้นจึงไม่อาจหยุดการฉ้อโกงทั้งหมดได้อย่างแม่นยำ
      ส่วนการตรวจจับจะจัดการกับผลลัพธ์หลังจากนั้น โดยทั่วไปจะมีทีมนักวิเคราะห์คอยวิเคราะห์ธุรกรรมที่ได้รับอนุมัติแล้วเพื่อหาสัญญาณการฉ้อโกง เรื่องนี้สำคัญมากโดยเฉพาะกับประเภทการฉ้อโกงที่ไม่มีสัญญาณภายนอกอย่าง chargeback หรือคำร้องเรียนจากลูกค้า เช่น platform integrity ก็เป็นตัวอย่างหนึ่ง และระบบต่อต้านการฟอกเงินของ fintech ก็ต้องออกตามหาการฉ้อโกงเช่นกัน
      ที่ว่าทั้งสองเสริมกันก็เพราะธุรกรรมที่ตรวจพบภายหลังจะกลายเป็น label สำหรับฝึกและประเมินโมเดลการป้องกันรุ่นถัดไป

  • เขาบอกว่าถ้ารูดบัตรในชิคาโกแล้วอีก 7 นาทีต่อมารูดอีกครั้งที่ลอสแอนเจลิส อย่างใดอย่างหนึ่งต้องปลอม ฉันเลยสงสัยว่าแล้วในกรณี การช็อปปิงออนไลน์ มันทำงานยังไง
    ถ้านั่งบนโซฟาแล้วซื้อของจาก Amazon ระบบจะลงที่อยู่ว่าอยู่ที่ไหน
    และยังมีกรณีขอบอย่างคู่สมรสใช้บัญชีออนไลน์ร่วมกัน แล้วอีกคนกำลังเดินทางและซื้อของด้วยข้อมูลบัตรที่บันทึกไว้ด้วย

    • การรูด เสียบ หรือแตะบัตรคือ ธุรกรรมแบบใช้บัตรจริง ส่วนการกรอกเลขบัตรแบบช็อปปิงออนไลน์คือธุรกรรมแบบไม่ใช้บัตรจริง
      ร้านค้าและธนาคารแยกความต่างนี้ได้
    • แยกได้จาก metadata ของธุรกรรม ฉันเคยทำงานที่บริษัทบัตรเครดิต
    • เท่าที่ฉันรู้ ระบบแยก card present กับ card not present ได้

  • ประเด็นที่ว่า “วิธีนี้ใช้ไม่ได้จนกว่าจะมีประวัติสะสมพอ และบัญชีใหม่ไม่มี baseline” เป็นองค์ประกอบด้าน ประสบการณ์ลูกค้า ที่คนมองข้ามกันมาก
    ถ้าฉันเป็นลูกค้าใหม่หรือมีพฤติกรรมใหม่ แล้วบัตรถูกปฏิเสธ มันจะรู้สึกเหมือนซอฟต์แวร์ทำงานดี
    แต่ถ้าฉันมีประวัติที่ผ่านมาแล้วว่าเป็นคนยืนยันธุรกรรมจริง และยังถูกปฏิเสธอีก แบบนั้นจะรู้สึกรำคาญกับอัลกอริทึมที่ทั้งใสซื่อและหวาดระแวง

    • แรงจูงใจของธนาคารคือ ลดการฉ้อโกง
      ธุรกรรมฉ้อโกงสุดท้ายแล้วมักถูกยกเลิกหรือคืนเงิน ทำให้ธนาคารต้องรับภาระขาดทุนเอง ส่วนธุรกรรมที่ถูกปฏิเสธก็แค่ทำให้มีลูกค้าโกรธเพิ่มอีกคนหนึ่ง และลูกค้าก็มักบ่นแล้วก็ลืมไปในไม่ช้า ดังนั้นภาระของต้นทุนที่ถูกผลักออกไปจึงตกอยู่กับลูกค้า
      เพราะฉะนั้นธนาคารจึงมีแรงจูงใจให้พลาดไปในทางระวังเกินไว้ก่อน และพร้อมจะปฏิเสธธุรกรรมแม้จะมี false positive ก็ตาม

  • แก่นของ machine learning ไม่ใช่การเรียนรู้กฎแบบนี้จากข้อมูลหรือ
    ฉันคิดว่าแนวทางที่ถูกคือใช้โมเดล machine learning หาแพตเทิร์นที่สัมพันธ์กับการฉ้อโกง แล้วประเมินว่ามีอันไหนที่ฟังขึ้นบ้าง แบบนั้นอาจค้นพบ สมมติฐานใหม่ ได้ด้วย

    • อะไรก็ตามที่อธิบายไม่ได้และปรับปรุงซ้ำแบบกำหนดผลแน่นอนไม่ได้ ถือว่าเสี่ยงเกินไปสำหรับงานปฏิเสธธุรกรรมทางการเงิน
      นักวิเคราะห์ที่เป็นมนุษย์ควรจะอธิบายให้ทีม compliance ฟังได้ด้วย อีเมล 5 นาที ว่าทำไมธุรกรรมหนึ่งจึงถูกปฏิเสธ และถ้าอยากเลี่ยงการตัดสินใจเชิงลบต้องทำอะไรให้ต่างออกไป
      เวลาซ่อมปัญหาหนึ่งด้วย machine learning มักจะได้ปัญหาใหม่อีกสองอย่างที่ยังมองไม่ชัดตามมา พอเวลาผ่านไปและสิ่งต่าง ๆ เปลี่ยนไป SQL ก็มักมีเรื่องให้ประหลาดใจน้อยกว่า ทั้งในแง่ regression และผลข้างเคียงที่คาดไม่ถึง
 
aliveornot 29 일 전

พอเห็นว่าเป็นจำนวนเงินลงท้ายเลขกลม ๆ ก็สงสัยว่าคืออะไร.. ที่แท้ก็หมายถึง rounded นี่เอง
 
xguru 29 일 전

ทำไมถึงแปลแบบนั้นนะ T_T ฉันแก้ไว้แล้วครับ