Stripe Radar מצטיינת במה שהיא עושה: ניקוד עסקה ברגע שכסף עובר. אבל הרגע שבו כסף לא עובר הוא בדיוק המקום שבו הבעיה שלנו חיה.
אנחנו מציעים תקופת ניסיון חינם של 7 ימים. כדי להתחיל אותה, המשתמש שומר כרטיס אך לא מחויב – מאחורי הקלעים, זהו SetupIntent של Stripe, לא תשלום. אין חיוב – אין אירוע בזמן חיוב, כלומר הכללים החזקים ביותר של Radar לא מקבלים מה להעריך בדיוק ברגע הקריטי: כאשר חשבון הונאה נוצר ומתחיל לשרוף קרדיטים של ניסיון.
זו הסיפור על איך עברנו מכיבוי שריפות הונאה בצ'אטים נקודתיים להפעלת שכבת הונאה אוטומטית, דקה-לדקה – שנבנתה על גבי המוצר שלנו, Zero.
Radar מצוינת. "מצוינת" זה לא "מושלמת".
Stripe Radar באמת טובה במה שהיא עושה. היא מאומנת על יותר מ-$1 טריליון דולר בנפח תשלומים שנתי, והמודלים שלה מזהים כרטיס שראו בעבר 92% מהפעמים, ו-Stripe מדווחת ש-Radar מפחיתה הונאה ב-32% בממוצע לעסקים שמשתמשים בה.
אבל קראו שוב את המספר: מפחיתה, לא מעלימה. ירידה ממוצעת של 32% היא משמעותית – אבל זה אומר שחלק גדול מהלחץ ההונאתי עדיין מגיע אליכם, ו-Stripe כנה לגבי הסיבה. במילותיהם: "הפחתת מספר החיוביים השגויים מגדילה לעיתים את הסיכוי להונאה אמיתית שתעבור מתחת לרדאר." הדליפה אינה באג במודל; זהו המחיר המכוון של אי חסימת לקוחות אמיתיים. כל צוות הונאה בוחר, במודע, כמה לתת לעבור.
למוצר שמבוסס על תקופת ניסיון, הדליפה הזו רחבה יותר ממה שהכותרת מרמזת – כי החלק החזק ביותר של Radar כלל לא פועל.
למה שער יכול רק להפחית
יש סיבה עמוקה יותר לכך שמנוע בזמן חיוב יכול להפחית הונאה אך לעולם לא להפסיק אותה, והיא לא קשורה למודלים של Stripe – אלא לתזמון ומידע. ברגע שכרטיס מתווסף, הלקוח עדיין לא עשה כלום. אין היסטוריית כניסות, אין התנהגות מוצר, אין דפוסי שימוש ללמוד מהם – רק כרטיס וכמה אותות רשת. Radar עושה את ההערכה הטובה ביותר שלה על בסיס המידע הדל ביותר, בדיוק ברגע שבו יש לה הכי פחות נתונים.
זהו התקרה האמיתית. אפשר לכוון שער, אבל אי אפשר לתת לו מידע שעדיין לא קיים. המידע שמבדיל באמת בין מנצל ללקוח נוצר ברובו אחרי שהשער כבר היה חייב להחליט.
שלב 1: כיבוי שריפות בחלון הצ'אט
התגובה הראשונה שלנו הייתה ידנית לחלוטין. כשגל הונאה הגיע, מישהו פתח שיחה עם הסוכן שלנו וטיפל באירוע בזמן אמת: שלף את ההרשמות האחרונות, בדק את הכרטיסים, מצא את הדפוס, סגר את החשבונות ידנית.
זה עבד, אבל לא היה ניתן להרחבה. כל אירוע התחיל מאפס. הידע – איך נראה המעגל הזה, אילו אותות אמינים – היה בראש של אדם אחד ובשרשור צ'אט אחד, ונעלם ברגע שהחלון נסגר.
למדנו גם לקח יקר בצד החיובי של המשפך: כשניסינו להחזיר משתמשים אמיתיים שנטשו את התשלום, שליחת מייל לא זהיר לכתובת הונאה גרמה לנזק אמיתי – היא אישרה שהכתובת פעילה. כל אוטומציה שנבנה תצטרך להבדיל בין לקוח אמיתי למושתל.
שלב 2: חיזוק הדלת הקדמית עם Radar
הצעד הבא היה לדחוף כל מה שאפשר ל-Radar – רשימות חסימה וכללי מהירות בשלב הוספת הכרטיס, מותאמים ללחץ שראינו. זהו הצעד הראשון הנכון, והוא עצר את ההתקפות הגסות ביותר.
אבל שתי תקרות הופיעו מהר. הראשונה היא זו ש-Stripe מציינת בעצמה: מנוע בזמן חיוב הוא כפתור איזון, לא חומה – מגבירים וחוסמים לקוחות אמיתיים, מחלישים ויותר הונאה עוברת. השנייה היא מבנית וספציפית לניסיונות: אותו 32% מתקבל בזמן חיוב, ולניסיון SetupIntent אין חיוב לנקד. אלא אם תפעילו במפורש את Radar על אמצעי תשלום שמורים, המנוע כלל לא פועל – וגם כשכן, רק כללי Block, Allow ו-3DS חלים על SetupIntent. פעולת "Review", שמאפשרת לאדם לבדוק שוב, לעולם לא מתבצעת.
כך ששכבת ההגנה הטובה ביותר במערכת, כברירת מחדל, לא פועלת בדיוק ברגע שהכי היינו צריכים אותה. Radar היא שער בכניסה. היינו צריכים סיור מאחוריו.
שלב 3: שכבה שנייה, מבוססת על Zero
לאחר ההרשמה, תמונת המידע מתהפכת. החשבון מתחיל להשאיר עקבות – והחלק העשיר ביותר של העקבות האלה נמצא במערכת שמעבד התשלומים לעולם לא רואה: ספק הזהות שלנו, Clerk.
אז נתנו ל-Zero גישה אליו. Clerk יודע דברים ש-Stripe לא: איך נוצר החשבון, שיטת ההרשמה והאימייל, הסשן והמכשיר שמאחוריו, והתזמון המדויק יחסית לכל הרשמה אחרת באותו יום. Stripe מכירה את הכרטיס. אף מערכת לבדה לא מספרת את כל הסיפור – אבל הסוכן יכול לקרוא את שתיהן ולהצליב ביניהן. ההונאה שבלתי נראית בשער הופכת לברורה זו לצד זו: חשבון חדש שזהות הכניסה שלו לא תואמת את זהות החיוב, שנוצר רגעים אחרי אשכול של דומים. החיבור הזה בין מערכות הוא בדיוק מה ששער בזמן חיוב לא יכול לעשות – ובדיוק מה שסוכן שיושב על שתיהן כן יכול.
על בסיס הראיות העשיר הזה, אנו מריצים סדרת משימות Zero מתוזמנות כל כמה דקות על נתוני הרשמה וחיוב חיים. שלושה עקרונות מנחים אותם:
1. לסייר, לא רק לשער. במקום להעריך רגע אחד, הסוכן סורק כל הרשמה חדשה בלולאה קצרה, מצליב נתוני חשבון ומטא-דאטה של תשלום כדי להבליט חשבונות שחלפו דרך הדלת הקדמית.
2. לדרג תגובה לפי ביטחון. לא כל אות דורש אותה פעולה. דפוסים בעלי ביטחון גבוה מטופלים אוטומטית – החשבון מושעה והניסיון מבוטל מיד, כי הפעולה הפיכה והמחיר של המתנה אמיתי. אותות בעלי ביטחון נמוך לעולם לא מטופלים אוטומטית; הם נאספים לדוח לסקירה אנושית. החלטי כשבטוח, שמרני כשלא.
3. לשמור תיעוד אנושי. כל פעולה אוטומטית מתעדת את האות שגרם לה, כך שניתן לבדוק – ולהפוך – אותה בשניות. אוטומציה שלא ניתן לבקר אינה אמינה.
החמרנו באותה מידה גם בצד הידידותי של המשפך. משימה נפרדת מאתרת משתמשים אמיתיים שנטשו את התשלום ומנסחת מייל החזרה לאישור אנושי – מאחורי מסנן הונאה כבד במיוחד, כדי שלעולם לא נאשר כתובת מזויפת. אותו מנוע, מטרה הפוכה.
מה זה עשה לכלכלה
ברגע שהסיור פעל, המספרים השתנו מיד. הסתכלו על ההרשמה באחוזון ה-90 – החשבונות הכבדים שגרמו לנזק האמיתי. החישוב של משאבי הניסיון שחשבון כזה שרף בשעות הראשונות ירד מ-בערך $4 לכ-$0.25 – ירידה של 94%. בממוצע לכל הרשמה חדשה באותו חלון זמן, ההפסד לחשבון ירד ב-כ-85%.
הצורה של השינוי היא הסימן. רוב ההרשמות מעולם לא עלו לנו כלום; ההפסד תמיד רוכז בזנב כבד וארוך של חשבונות שנוצרו רק כדי לרוקן קרדיטים של ניסיון. הסיור לא צמצם את המשפך – הוא חתך את הזנב הזה. לא פחות הרשמות. הרשמות נקיות יותר.
למה סוכן ולא סקריפט
יכולנו לכתוב משימת cron. לא עשינו זאת מסיבה אחת: האיום משתנה מהר יותר ממחזור שחרור. כשמתקיף משנה טקטיקה, אנו מעדכנים את הוראות המשימה בשפה טבעית והלוגיקה החדשה פועלת בהרצה הבאה – בלי פריסה, בלי שינוי סכימה, בלי טיקט. ה"כללים" הם prompt, וה-prompt משתנה מהר כמו המתקיף.
זו הלקח האמיתי. Radar היא הכלי הנכון לסיכון בזמן חיוב, ואנו נשענים עליה חזק. אבל למוצר שמבוסס על ניסיון יש נקודת עיוורון מבנית ששום כלי בזמן חיוב לא יכול לכסות – והפתרון אינו מנוע כללים גדול יותר. זהו שכבה שנייה מהירה, ניתנת לביקורת, פועלת תמיד, שניתן לתכנת מחדש במהירות האיום.
מסקנות לצוותים מבוססי ניסיון
- מפו את הרגעים ללא חיוב. כל מקום שבו משתמש מקבל ערך לפני שתשלום נבדק הוא פער שכלי בזמן חיוב לא רואה.
- הוסיפו שכבות, אל תחליפו. השאירו את Radar בכניסה. הוסיפו סיור מתמשך אחרי ההרשמה.
- הצליבו בין מערכות. מעבד התשלומים וספק הזהות שלכם מחזיקים כל אחד חצי מהתמונה. ההונאה נראית בחפיפה.
- דרגו פעולות לפי ביטחון, ותעדו כל אחת. בצעו אוטומציה רק כשאפשר להפוך את הפעולה והאות חזק; את השאר הפנו לאדם.
- אופטימיזציה למהירות הסתגלות. בהונאה, הצוות שמעדכן כללים הכי מהר מנצח.
סקרנים מה סוכן פעיל תמיד יכול לאוטומט אצלכם? גלו את Zero.
הערות: נתוני Radar הם ממספרים ש-Stripe פרסמה (stripe.com/radar; "A primer on machine learning for fraud detection"). נתוני ההפסד משקפים עלות חישוב לכל הרשמה חדשה בשעות הראשונות לאחר הרישום, נמדד בחלונות תואמים לפני ואחרי ההשקה, ללא חשבונות פנימיים; המדגם לאחר ההשקה עדיין מוקדם ויתייצב עם הזמן.
