Stripe Radar ทำหน้าที่ได้ยอดเยี่ยม: ประเมินความเสี่ยงของธุรกรรมทันทีที่มีการเคลื่อนไหวของเงิน แต่ปัญหาของเรากลับอยู่ตรงช่วงเวลาที่ ไม่มี การเคลื่อนไหวของเงิน
เรามีช่วงทดลองใช้ฟรี 7 วัน ผู้ใช้เพียงแค่บันทึกบัตรเครดิตเพื่อเริ่มใช้งาน แต่จะไม่ถูกเรียกเก็บเงิน — เบื้องหลังคือ Stripe SetupIntent ไม่ใช่การชำระเงินจริง ไม่มีการเรียกเก็บเงินจึงไม่มีเหตุการณ์ให้ Radar ประเมิน ซึ่งหมายความว่ากฎที่ทรงพลังที่สุดของ Radar ไม่ได้ทำงานในช่วงเวลาสำคัญที่สุด: ตอนที่บัญชีฉ้อโกงถูกสร้างขึ้นและเริ่มใช้เครดิตทดลองใช้ฟรี
นี่คือเรื่องราวของเราจากการดับไฟฉ้อโกงแบบเฉพาะกิจในแชท สู่การมีระบบป้องกันฉ้อโกงอัตโนมัติแบบนาทีต่อนาที — สร้างบนผลิตภัณฑ์ของเราเอง Zero
Radar ดีมาก แต่ "ดีมาก" ไม่ใช่ "สมบูรณ์แบบ"
Stripe Radar ทำหน้าที่ได้ดีจริง ๆ ด้วยข้อมูลการชำระเงินต่อปีมากกว่า $1 ล้านล้าน โมเดลของมันสามารถจดจำบัตรที่เคยเห็นได้ 92% ของเวลา และ Stripe รายงานว่า Radar ลดการฉ้อโกงได้เฉลี่ย 32% สำหรับธุรกิจที่ใช้งาน
แต่ลองอ่านตัวเลขนั้นอีกครั้ง: ลดลง ไม่ใช่ หมดไป การลดเฉลี่ย 32% ถือว่าเยอะ — แต่ก็ยังมีแรงกดดันจากการฉ้อโกงจำนวนมากที่ยังหลุดรอดมา และ Stripe ก็ซื่อสัตย์กับเรื่องนี้ ในคำพูดของพวกเขาเอง "การลดจำนวน false positive มักเพิ่มโอกาสที่การฉ้อโกงจริงจะหลุดรอดมากขึ้น" การหลุดรอดไม่ใช่ข้อผิดพลาดของโมเดล แต่เป็นต้นทุนที่ตั้งใจจ่ายเพื่อไม่ปิดกั้นลูกค้าจริง ทุกทีมป้องกันฉ้อโกงต้องเลือกเองว่าจะปล่อยผ่านมากน้อยแค่ไหน
สำหรับผลิตภัณฑ์ที่เน้นทดลองใช้ฟรี ช่องโหว่นี้กว้างกว่าตัวเลขที่เห็น — เพราะส่วนที่ทรงพลังที่สุดของ Radar ไม่ได้ทำงานเลย
ทำไม gate ถึงลดได้แต่ไม่หมด
มีเหตุผลลึกกว่านั้นว่าทำไมระบบที่ประเมินตอนชำระเงินถึง ลด การฉ้อโกงได้แต่ไม่หมด และมันไม่ใช่เพราะโมเดลของ Stripe — แต่เป็นเรื่อง เวลาและข้อมูล ทันทีที่มีการเพิ่มบัตร ลูกค้ายังไม่ได้ทำอะไรเลย ไม่มีประวัติการเข้าสู่ระบบ ไม่มีพฤติกรรมการใช้ ไม่มีรูปแบบการใช้งานให้เรียนรู้ — มีแค่บัตรกับสัญญาณเครือข่ายไม่กี่อย่าง Radar ต้องตัดสินใจจากข้อมูลที่น้อยที่สุด ในช่วงเวลาที่มีข้อมูลน้อยที่สุด
นี่คือขีดจำกัดที่แท้จริง คุณปรับแต่ง gate ได้ แต่คุณไม่สามารถให้ข้อมูลที่ยังไม่มีอยู่จริงได้ ข้อมูลที่แยกผู้ฉ้อโกงออกจากลูกค้าจริงส่วนใหญ่จะเกิดขึ้น หลัง gate ตัดสินใจไปแล้ว
ระยะที่ 1: ดับไฟในแชท
การตอบสนองแรกของเราคือทำเองทั้งหมด เมื่อเกิดการฉ้อโกง มีคนเปิดแชทกับ agent ของเราและจัดการเหตุการณ์แบบสด: ดึงรายชื่อสมัครล่าสุด ดูบัตร ค้นหารูปแบบ ปิดบัญชีด้วยมือ
มันได้ผล แต่ขยายไม่ได้ ทุกเหตุการณ์ต้องเริ่มจากศูนย์ ความรู้ — วงนี้หน้าตาเป็นอย่างไร สัญญาณไหนเชื่อถือได้ — อยู่ในหัวคนเดียวและในแชทเดียว พอปิดหน้าต่างก็หายไปหมด
เรายังได้บทเรียนราคาแพงในฝั่ง ดี ของ funnel: เวลาต้องการดึงผู้ใช้จริงที่ละทิ้งการชำระเงินกลับมา อีเมล outreach ที่ส่งไปหาผู้ฉ้อโกงโดยไม่ระวังจะยิ่งแย่ — มันยืนยันว่าอีเมลนั้นใช้งานได้จริง ทุกระบบอัตโนมัติที่สร้างต้องแยกแยะผู้ใช้จริงกับผู้ปลอมให้ได้
ระยะที่ 2: เสริมความแข็งแกร่งที่หน้าประตูด้วย Radar
ขั้นต่อไปคือดันทุกอย่างที่ทำได้ไปที่ Radar — รายการบล็อกและกฎความถี่ที่ขั้นตอนเพิ่มบัตร ปรับตามแรงกดดันที่เจอ เป็นก้าวแรกที่ถูกต้อง และหยุดการโจมตีแบบหยาบ ๆ ได้
แต่ก็เจอขีดจำกัดสองอย่างอย่างรวดเร็ว อย่างแรกคือที่ Stripe เองก็พูดไว้: ระบบประเมินตอนชำระเงินคือ ปุ่มปรับสมดุล ไม่ใช่กำแพง — ปรับเข้มก็ปิดลูกค้าจริง ปรับอ่อนก็ปล่อยให้ฉ้อโกงหลุดรอดมากขึ้น อย่างที่สองเป็นข้อจำกัดเฉพาะของทดลองใช้ฟรี: 32% จะเกิดขึ้นตอนชำระเงิน และ SetupIntent สำหรับทดลองใช้ฟรีไม่มีการชำระเงินให้ประเมิน เว้นแต่คุณจะเปิดใช้ Radar กับวิธีชำระเงินที่บันทึกไว้โดยเฉพาะ ระบบจะไม่ทำงานเลย — และถึงจะทำงาน ก็ใช้ได้แค่กฎ Block, Allow และ 3DS กับ SetupIntent เท่านั้น การกระทำ "Review" ที่ให้มนุษย์ตรวจสอบซ้ำจะไม่ถูกเรียกใช้เลย
ดังนั้นชั้นที่มีประสิทธิภาพที่สุดในระบบจึงไม่ได้ทำงานในช่วงเวลาที่เราต้องการมากที่สุดโดยปริยาย Radar เป็น gate ที่หน้าประตู แต่เราต้องการหน่วยลาดตระเวนหลังประตู
ระยะที่ 3: ชั้นที่สอง สร้างบน Zero
หลังสมัคร ข้อมูลเปลี่ยนไป บัญชีเริ่มทิ้งร่องรอย — และร่องรอยที่สำคัญที่สุดอยู่ในระบบที่ผู้ประมวลผลการชำระเงินไม่เห็น: ผู้ให้บริการยืนยันตัวตนของเรา Clerk
เราจึงให้ Zero เข้าถึงข้อมูลนี้ Clerk รู้สิ่งที่ Stripe ไม่รู้: บัญชีถูกสร้างอย่างไร วิธีสมัครและอีเมล เซสชันและอุปกรณ์ที่ใช้ และเวลาที่แน่นอนเมื่อเทียบกับการสมัครอื่น ๆ ในวันเดียวกัน Stripe รู้แค่บัตร แต่ไม่มีระบบไหนรู้เรื่องทั้งหมด — แต่ agent สามารถอ่านทั้งสองและ เชื่อมโยงข้อมูลข้ามระบบ การฉ้อโกงที่มองไม่เห็นที่ gate จะเห็นได้ชัดเมื่อดูควบคู่กัน: บัญชีใหม่ที่ข้อมูลยืนยันตัวตนไม่ตรงกับข้อมูลบิลลิ่ง สร้างห่างกันไม่กี่นาทีกับกลุ่มบัญชีหน้าตาคล้าย ๆ กัน การเชื่อมโยงข้ามระบบแบบนี้ gate ตอนชำระเงินทำไม่ได้ — แต่ agent ที่นั่งอยู่บนทั้งสองระบบทำได้
ด้วยฐานข้อมูลที่สมบูรณ์กว่า เราตั้ง Zero ให้รันงานตามกำหนดทุกไม่กี่นาที กับข้อมูลสมัครและบิลลิ่งสด โดยมีหลักการสามข้อ:
1. ลาดตระเวน ไม่ใช่แค่ gate แทนที่จะประเมินแค่ช่วงเดียว agent จะตรวจสอบการสมัครล่าสุดทั้งหมดในรอบสั้น ๆ เชื่อมโยงข้อมูลบัญชีและข้อมูลการชำระเงินเพื่อหาบัญชีที่หลุดรอดจาก gate
2. แบ่งระดับการตอบสนองตามความมั่นใจ ไม่ใช่ทุกสัญญาณจะต้องดำเนินการเหมือนกัน รูปแบบที่มั่นใจสูงจะถูกจัดการอัตโนมัติ — บัญชีจะถูกระงับและยกเลิกทดลองใช้ฟรีทันที เพราะสามารถย้อนกลับได้และต้นทุนของการรอสูง สัญญาณที่มั่นใจต่ำจะไม่ถูกดำเนินการอัตโนมัติ จะถูกรวบรวมเป็นรายงานให้มนุษย์ตรวจสอบ ตัดสินใจเด็ดขาดเมื่อปลอดภัย ระมัดระวังเมื่อไม่แน่ใจ
3. เก็บประวัติการตรวจสอบโดยมนุษย์ ทุกการดำเนินการอัตโนมัติจะบันทึกสัญญาณที่กระตุ้นให้เกิดการกระทำนั้น เพื่อให้ตรวจสอบ — และย้อนกลับ — ได้ในไม่กี่วินาที ระบบอัตโนมัติที่ตรวจสอบไม่ได้คือระบบที่ไว้ใจไม่ได้
เรานำหลักการเดียวกันมาใช้กับฝั่งดีของ funnel งานแยกจะค้นหาผู้ใช้ที่ละทิ้งขั้นตอนชำระเงินสำหรับการซื้อจริงและ ร่าง อีเมลดึงกลับมาให้มนุษย์อนุมัติ — ภายใต้ตัวกรองฉ้อโกงที่เข้มข้นโดยตั้งใจ เพื่อไม่ยืนยันอีเมลปลอม เครื่องยนต์เดียวกัน เป้าหมายตรงข้าม
ผลกระทบต่อเศรษฐศาสตร์
เมื่อระบบลาดตระเวนทำงาน ตัวเลขเปลี่ยนทันที ดูที่การสมัครกลุ่ม 90 เปอร์เซ็นไทล์ — บัญชีหนักที่สร้างความเสียหายจริง เครดิตคอมพิวต์ทดลองใช้ฟรีที่บัญชีเหล่านี้ใช้ในชั่วโมงแรก ลดจาก ประมาณ $4 เหลือประมาณ $0.25 — ลดลง 94% เฉลี่ยต่อการสมัครใหม่ในช่วงเวลาเดียวกัน การขาดทุนต่อบัญชีลดลง ประมาณ 85%
ลักษณะของการเปลี่ยนแปลงคือสิ่งที่บอกได้ ส่วนใหญ่ของการสมัครไม่เคยสร้างต้นทุนอะไร การขาดทุนกระจุกอยู่ที่กลุ่มบัญชีหนักที่มีไว้ดูดเครดิตทดลองใช้ฟรี ระบบลาดตระเวนไม่ได้ลดจำนวนการสมัคร — แต่มันตัดหางยาวนั้นออก ไม่ใช่สมัครน้อยลง แต่สมัครสะอาดขึ้น
ทำไมต้องใช้ agent ไม่ใช่ script
เราจะเขียน cron job ก็ได้ แต่เราไม่ทำด้วยเหตุผลเดียว: ภัยคุกคามเปลี่ยนเร็วกว่ารอบ release เมื่อผู้โจมตีเปลี่ยนวิธี เราอัปเดตคำสั่งงานเป็นภาษาธรรมดาและตรรกะใหม่ก็ทำงานทันทีในรอบถัดไป — ไม่ต้อง deploy ไม่ต้อง migrate schema ไม่ต้องเปิด ticket "กฎ" คือ prompt และ prompt เปลี่ยนได้เร็วเท่าผู้โจมตี
นี่คือบทเรียนที่แท้จริง Radar เหมาะกับความเสี่ยงตอนชำระเงิน และเราก็ใช้มันเต็มที่ แต่ธุรกิจที่เน้นทดลองใช้ฟรีมีจุดบอดเชิงโครงสร้างที่เครื่องมือประเมินตอนชำระเงินไม่มีทางปิดได้ — และทางแก้ไม่ใช่เพิ่มกฎ แต่คือชั้นที่สองที่รวดเร็ว ตรวจสอบได้ ทำงานตลอดเวลา และปรับเปลี่ยนได้เร็วเท่าภัยคุกคาม
ข้อคิดสำหรับทีมที่เน้นทดลองใช้ฟรี
- แผนที่ช่วงที่ไม่มีการชำระเงิน ทุกที่ที่ผู้ใช้ได้รับคุณค่าก่อนมีการประเมินการชำระเงิน คือช่องโหว่ที่เครื่องมือประเมินตอนชำระเงินมองไม่เห็น
- เพิ่มชั้น ไม่ใช่แทนที่ ให้ Radar อยู่หน้าประตู เพิ่มระบบลาดตระเวนหลังสมัครต่อเนื่องไว้ข้างหลัง
- เชื่อมโยงข้ามระบบ ผู้ประมวลผลการชำระเงินและผู้ให้บริการยืนยันตัวตนแต่ละรายมีข้อมูลคนละส่วน การฉ้อโกงจะเห็นได้ในจุดที่ข้อมูลทับซ้อนกัน
- แบ่งระดับการดำเนินการตามความมั่นใจ และบันทึกทุกครั้ง ดำเนินการอัตโนมัติเฉพาะเมื่อย้อนกลับได้และสัญญาณชัดเจน ที่เหลือส่งให้มนุษย์
- ปรับให้เปลี่ยนแปลงได้เร็วที่สุด ในโลกฉ้อโกง ทีมที่เปลี่ยนกฎได้เร็วที่สุดคือผู้ชนะ
สงสัยว่า agent ที่ทำงานตลอดเวลาจะช่วยอัตโนมัติอะไรในระบบของคุณได้บ้าง? สำรวจ Zero
หมายเหตุ: ตัวเลข Radar อ้างอิงจาก Stripe (stripe.com/radar; "A primer on machine learning for fraud detection") ตัวเลขขาดทุนคำนวณจากต้นทุน compute ต่อการสมัครใหม่ในชั่วโมงแรกหลังสมัคร วัดในช่วงเวลาเดียวกันก่อนและหลังเปิดใช้งาน โดยไม่รวมบัญชีภายใน; ตัวอย่างหลังเปิดใช้งานยังอยู่ในช่วงต้นและจะมีความแม่นยำมากขึ้นเมื่อเวลาผ่านไป
