รูปแบบ SQL ที่ใช้ตรวจจับการฉ้อโกงธุรกรรม

 (analytics.fixelsmith.com)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง 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
  • จำนวนเงินดอลลาร์แบบเลขกลมขนาดเล็กมักเป็นสัญญาณของ การทดสอบบัตร
    • เป็นขั้นตอนตรวจสอบว่าหมายเลขที่ได้จากการ dump หมายเลขบัตรยังใช้งานได้จริง ก่อนนำไปขายต่อ
    • กรณีที่เจ้าของบัตรจริงจะซื้อสินค้าราคา $1.00 พอดีนั้นพบได้ไม่บ่อย
    • กาแฟมักเป็น $4.73 ค่าน้ำมันอาจเป็น $52.81 มากกว่าจะเป็นเลขกลมเป๊ะ
  • จำนวนเงินที่อยู่ต่ำกว่าเกณฑ์เล็กน้อยมีความหมายอีกแบบ
    • $99.99 อาจเป็นการหลบเส้นที่หลายแห่งเริ่มขอตรวจบัตรประชาชนตั้งแต่ $100
    • $499.99 อาจเป็นการหลบวงเงินถอน ATM รายวัน $500
    • เป็นสัญญาณว่าผู้ทำธุรกรรมรู้กฎและตั้งใจอยู่ต่ำกว่าเกณฑ์
  • ในธุรกรรมสวัสดิการ รูปแบบจำนวนเงินกลม ๆ แทบไม่ช่วยมากนัก
    • สวัสดิการไม่ได้ถูกทดสอบบัตรในลักษณะเดียวกัน
    • โดยทั่วไปสัญญาณที่สำคัญกว่าคือผู้รับซ้ำซ้อน

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

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

5. Off-hours: ธุรกรรมนอกช่วงเวลาการใช้งานปกติของบุคคล

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

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 สัญญาณมักเป็นการฉ้อโกงแทบแน่นอน
  • ธุรกรรมที่ติดเพียงสัญญาณเดียวอาจเป็นการใช้งานแปลก ๆ ของเจ้าของบัตรปกติที่กำลังเดินทาง
  • หากเพิ่งเริ่มทำระบบตรวจจับการฉ้อโกง ควรเริ่มจาก Velocity
    • มันเปิดเผยการฉ้อโกงได้ในปริมาณที่มีประโยชน์
    • จับกิจกรรมปกติผิดพลาดค่อนข้างน้อย
    • ต้นทุนการรันก็ต่ำ
  • หากมีข้อ 1 ถึง 5 แล้ว จุดที่ควรลงทุนต่อคือ คอลัมน์ดิบจาก window function
    • สร้างครั้งเดียว นักวิเคราะห์ทั้งทีมใช้ต่อได้
    • การเพิ่มแพตเทิร์นฉ้อโกงถัดไปจะไม่กลายเป็นอีกหนึ่งโปรเจกต์แยก

ข้อควรระวัง

  • การจัดการ NULL

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

  • False positive

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

  • ความเป็นส่วนตัว

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

  • ต้นทุน

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

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

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

 
GN⁺ 1 시간 전
ความคิดเห็นใน 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 และผลข้างเคียงที่คาดไม่ถึง