Stripe Radar जो काम करता है उसमें बेहतरीन है: जिस पल पैसा हिलता है, उसी पल एक लेन-देन को स्कोर करना। पर जिस पल पैसा नहीं हिलता, ठीक वहीं हमारी समस्या रहती थी।
हम एक 7-दिन का फ़्री ट्रायल चलाते हैं। इसे शुरू करने के लिए, उपयोगकर्ता एक कार्ड सेव करता है पर उससे कभी पैसा नहीं काटा जाता — अंदरूनी तौर पर, वह एक Stripe SetupIntent है, कोई भुगतान नहीं। कोई चार्ज नहीं का मतलब कोई चार्ज-टाइम इवेंट नहीं, जिसका मतलब है कि Radar के सबसे ताकतवर नियमों के पास ठीक उस पल मूल्यांकन करने के लिए कुछ नहीं होता जो सबसे ज़्यादा मायने रखता है: जब एक धोखाधड़ी वाला अकाउंट बनाया जा रहा होता है और ट्रायल क्रेडिट जलाने लगता है।
यह उस सफ़र की कहानी है कि हम कैसे एक-एक चैट में धोखाधड़ी से जूझने से एक स्वचालित, मिनट-दर-मिनट चलने वाली फ़्रॉड परत तक पहुँचे — जो हमारे अपने ही प्रोडक्ट, Zero पर बनी है।
Radar शानदार है। "शानदार" का मतलब "परफ़ेक्ट" नहीं।
Stripe Radar जो काम करता है उसमें सचमुच अच्छा है। सालाना $1 ट्रिलियन से अधिक के भुगतान वॉल्यूम पर प्रशिक्षित, इसके मॉडल किसी पहले देखे गए कार्ड को 92% बार पहचान लेते हैं, और Stripe बताता है कि इसका इस्तेमाल करने वाले व्यवसायों के लिए Radar औसतन धोखाधड़ी को 32% तक घटा देता है।
पर इस आँकड़े को फिर से पढ़िए: घटाता है, खत्म नहीं करता। 32% का औसत असर बड़ा है — पर इसका मतलब है कि धोखाधड़ी के दबाव का एक बड़ा हिस्सा अब भी आपके दरवाज़े पर आ रहा है, और Stripe इसकी वजह को लेकर ताज़गी भरी ईमानदारी दिखाता है। उनके अपने शब्दों में, "false positives की संख्या घटाने से अक्सर और ज़्यादा असली फ़्रॉड के दरारों से फिसल निकलने की संभावना बढ़ जाती है।" रिसाव मॉडल में कोई बग नहीं है; यह आपके असली ग्राहकों को न रोकने की जान-बूझकर चुकाई गई कीमत है। हर फ़्रॉड टीम जान-बूझकर चुनती है कि कितना निकल जाने देना है।
ट्रायल-आधारित प्रोडक्ट के लिए, वह रिसाव सुर्खी वाले आँकड़े से कहीं ज़्यादा चौड़ा होता है — क्योंकि Radar का सबसे ताकतवर हिस्सा कभी चलता ही नहीं।
क्यों एक गेट केवल घटा ही सकता है
एक गहरी वजह है कि एक चार्ज-टाइम इंजन धोखाधड़ी को घटा तो सकता है पर कभी खत्म नहीं कर सकता, और यह Stripe के मॉडल के बारे में नहीं है — यह समय और जानकारी के बारे में है। जिस पल एक कार्ड जोड़ा जाता है, ग्राहक ने अभी तक कुछ नहीं किया होता। कोई साइन-इन इतिहास नहीं, कोई प्रोडक्ट व्यवहार नहीं, सीखने के लिए कोई उपयोग पैटर्न नहीं — बस एक कार्ड और मुट्ठी भर नेटवर्क संकेत। Radar सबूत के सबसे पतले संभव टुकड़े पर अपना सबसे अच्छा फ़ैसला ले रहा होता है, ठीक उसी पल जब उसके पास आगे बढ़ने को सबसे कम होता है।
यही असली सीमा है। आप एक गेट को ट्यून कर सकते हैं, पर आप उसे ऐसा डेटा नहीं दे सकते जो अभी मौजूद ही नहीं है। जो जानकारी सचमुच एक दुरुपयोगकर्ता को एक ग्राहक से अलग करती है, वह ज़्यादातर गेट के फ़ैसला ले लेने के बाद ही बनती है।
चरण 1: चैट विंडो में आग बुझाना
हमारी पहली प्रतिक्रिया पूरी तरह हाथ से थी। जब दुरुपयोग की एक लहर आती, तो कोई हमारे एजेंट के साथ बातचीत खोलता और घटना को सीधे संभालता: हाल के साइनअप खींचो, कार्ड देखो, पैटर्न ढूँढो, अकाउंट हाथ से बंद कर दो।
यह काम करता था, पर यह स्केल नहीं करता था। हर घटना शून्य से शुरू होती थी। ज्ञान — यह रिंग कैसा दिखता है, कौन से संकेत भरोसेमंद हैं — एक व्यक्ति के दिमाग और एक चैट थ्रेड में रहता था, और विंडो बंद होते ही उड़ जाता था।
हमने फ़नल के अच्छे हिस्से पर भी एक महँगा सबक सीखा: जब हम चेकआउट छोड़ने वाले असली उपयोगकर्ताओं को वापस जीतना चाहते थे, तो एक धोखाधड़ी वाले पते पर भेजी गई एक लापरवाह आउटरीच ईमेल असली नुकसान करती है — यह पुष्टि कर देती है कि पता ज़िंदा है। हम जो भी ऑटोमेशन बनाते, उसे एक असली संभावित ग्राहक और एक रोपे गए नकली के बीच फ़र्क समझना ज़रूरी होता।
चरण 2: Radar के साथ सामने के दरवाज़े को मज़बूत करना
हमारा अगला कदम था जो कुछ भी हम कर सकते थे उसे Radar में ऊपर की ओर धकेलना — कार्ड-जोड़ने वाले चरण पर ब्लॉक लिस्ट और वेलोसिटी नियम, उस दबाव के हिसाब से ट्यून किए हुए जो हम देख रहे थे। यह सही पहला कदम है, और इसने सबसे कच्चे हमलों को रोक दिया।
पर दो सीमाएँ जल्दी सामने आ गईं। पहली वही है जिसका नाम Stripe खुद लेता है: एक चार्ज-टाइम इंजन एक ट्रेडऑफ़ डायल है, दीवार नहीं — इसे ऊपर करो और तुम असली ग्राहकों को रोकते हो, इसे नीचे करो और ज़्यादा फ़्रॉड फिसल निकलता है। दूसरी संरचनात्मक है और खासकर ट्रायल से जुड़ी है: वह 32% चार्ज के समय अर्जित होता है, और एक SetupIntent ट्रायल के पास स्कोर करने के लिए कोई चार्ज ही नहीं होता। जब तक आप सेव किए गए पेमेंट तरीकों पर Radar को स्पष्ट रूप से चालू न करें, इंजन बिल्कुल चलता ही नहीं — और जब चलता भी है, तब SetupIntent पर केवल Block, Allow और 3DS नियम लागू होते हैं। "Review" एक्शन, वही जो किसी इंसान को दोबारा देखने का मौका देता है, कभी चलता ही नहीं।
तो स्टैक की एकमात्र सबसे अच्छी प्रदर्शन करने वाली परत, डिफ़ॉल्ट रूप से, ठीक उसी पल बाहर बैठी रहती है जब हमें उसकी सबसे ज़्यादा ज़रूरत थी। Radar सामने के दरवाज़े पर एक गेट है। हमें उसके पीछे एक गश्त चाहिए थी।
चरण 3: एक दूसरी परत, Zero पर बनी
साइनअप के बाद, जानकारी की तस्वीर पलट जाती है। अकाउंट एक निशान छोड़ने लगता है — और उस निशान का सबसे समृद्ध हिस्सा एक ऐसे सिस्टम में रहता है जिसे पेमेंट प्रोसेसर कभी नहीं देखता: हमारा आइडेंटिटी प्रोवाइडर, Clerk।
तो हमने Zero को उस तक पहुँच दी। Clerk वे चीज़ें जानता है जो Stripe नहीं जान सकता: अकाउंट कैसे बनाया गया, साइनअप का तरीका और ईमेल, उसके पीछे का सेशन और डिवाइस, और उस दिन के हर दूसरे साइनअप के सापेक्ष सटीक समय। Stripe कार्ड जानता है। कोई भी सिस्टम, अकेले अपने दम पर, पूरी कहानी नहीं बताता — पर एजेंट दोनों को पढ़ सकता है और उनके बीच सहसंबंध जोड़ सकता है। जो दुरुपयोग गेट पर अदृश्य होता है, वह आमने-सामने रखते ही साफ़ हो जाता है: एक बिल्कुल नया अकाउंट जिसकी साइन-इन पहचान उसकी बिलिंग पहचान से मेल नहीं खाती, जो हमशक्लों के एक झुंड से बस कुछ ही पल के फ़र्क पर बना है। वह क्रॉस-सिस्टम जोड़ ठीक वही है जो एक चार्ज-टाइम गेट नहीं बना सकता — और ठीक वही जो दोनों सिस्टमों के ऊपर बैठा एक एजेंट बना सकता है।
उस समृद्ध सबूत के आधार पर, हम हर कुछ मिनट में लाइव साइनअप और बिलिंग डेटा के विरुद्ध शेड्यूल किए गए Zero टास्क का एक सेट चलाते हैं। तीन सिद्धांत इन्हें आकार देते हैं:
1. गश्त करो, सिर्फ़ गेट मत बनो। एक पल का मूल्यांकन करने के बजाय, एजेंट हर हाल के साइनअप को एक छोटे लूप में खंगालता है, अकाउंट डेटा और पेमेंट मेटाडेटा को सहसंबंधित करते हुए ऐसे अकाउंट सामने लाता है जो सामने के दरवाज़े से फिसल निकले।
2. प्रतिक्रिया को भरोसे के हिसाब से स्तरबद्ध करो। हर संकेत एक ही कार्रवाई का हकदार नहीं होता। उच्च-भरोसे वाले पैटर्न अपने आप संभाले जाते हैं — अकाउंट निलंबित कर दिया जाता है और उसका ट्रायल वहीं रद्द कर दिया जाता है, क्योंकि कार्रवाई उलटी जा सकती है और इंतज़ार की कीमत असली है। कम-भरोसे वाले संकेत कभी अपने आप कार्रवाई में नहीं डाले जाते; उन्हें किसी इंसान की समीक्षा के लिए एक रिपोर्ट में इकट्ठा किया जाता है। जहाँ सुरक्षित हो वहाँ निर्णायक, जहाँ न हो वहाँ सतर्क।
3. एक मानवीय ऑडिट निशान बनाए रखो। हर स्वचालित कार्रवाई ठीक उस संकेत को दर्ज करती है जिसने उसे ट्रिगर किया, ताकि उसकी सेकंडों में समीक्षा — और पलटाव — किया जा सके। जिस ऑटोमेशन का आप ऑडिट नहीं कर सकते, उस पर आप भरोसा नहीं कर सकते।
हमने फ़नल के दोस्ताना हिस्से पर भी वही कठोरता लागू की। एक अलग टास्क असली चेकआउट-छोड़ने वाले उपयोगकर्ताओं को ढूँढता है और किसी इंसान के अनुमोदन के लिए एक विन-बैक ईमेल तैयार करता है — एक जान-बूझकर भारी फ़्रॉड फ़िल्टर के पीछे, ताकि हम कभी किसी बुरे पते को मान्य न करें। वही इंजन, विपरीत लक्ष्य।
इसने अर्थशास्त्र पर क्या असर डाला
गश्त के लाइव होते ही, आँकड़े तुरंत हिल गए। 90वें-पर्सेंटाइल साइनअप को देखिए — वे भारी अकाउंट जिन्होंने असली नुकसान किया। उनमें से किसी एक ने अपने पहले घंटों में जो ट्रायल कंप्यूट जलाया, वह लगभग $4 से घटकर लगभग $0.25 — 94% की गिरावट रह गया। उसी अवधि में हर नए साइनअप पर औसत निकालने पर, प्रति-अकाउंट नुकसान लगभग 85% गिर गया।
बदलाव का आकार ही असली राज़ बताता है। ज़्यादातर साइनअप ने हमें कभी कुछ खर्च नहीं कराया; नुकसान हमेशा ऐसे अकाउंटों की एक लंबी, भारी पूँछ में केंद्रित था जो सिर्फ़ ट्रायल क्रेडिट खाली करने के लिए मौजूद थे। गश्त ने फ़नल को नहीं सिकोड़ा — इसने उस पूँछ को काट दिया। कम साइनअप नहीं। साफ़-सुथरे साइनअप।
क्यों एक एजेंट, और एक स्क्रिप्ट क्यों नहीं
हम एक क्रॉन जॉब लिख सकते थे। हमने नहीं लिखा, एक वजह से: खतरा एक रिलीज़ चक्र से तेज़ी से बदलता है। जब कोई हमलावर अपनी रणनीति बदलता है, तो हम एक टास्क के निर्देशों को सरल भाषा में अपडेट कर देते हैं और नया तर्क अगली बार चलने पर लाइव हो जाता है — कोई डिप्लॉय नहीं, कोई स्कीमा माइग्रेशन नहीं, कोई टिकट नहीं। "नियम" एक प्रॉम्प्ट हैं, और प्रॉम्प्ट को बदलना उतना ही तेज़ है जितना हमलावर है।
यही असली सबक है। Radar चार्ज-टाइम जोखिम के लिए सही टूल है, और हम उस पर बहुत निर्भर रहते हैं। पर एक ट्रायल-आधारित व्यवसाय में एक संरचनात्मक अंधा कोना होता है जिसे कोई चार्ज-टाइम टूल ढक नहीं सकता — और इसका इलाज एक बड़ा नियम इंजन नहीं है। यह एक तेज़, ऑडिट-योग्य, हमेशा-चालू दूसरी परत है जिसे आप खतरे की रफ़्तार से दोबारा प्रोग्राम कर सकते हैं।
ट्रायल-आधारित टीमों के लिए मुख्य बातें
- अपने नो-चार्ज पलों को मैप करो। जहाँ कहीं भी एक उपयोगकर्ता को भुगतान स्कोर होने से पहले मूल्य मिलता है, वह एक ऐसा अंतराल है जिसे कोई चार्ज-टाइम टूल नहीं देख सकता।
- परत जोड़ो, बदलो मत। Radar को सामने के दरवाज़े पर रखो। उसके पीछे एक लगातार चलने वाली साइनअप-बाद गश्त जोड़ो।
- सिस्टमों के बीच जोड़ो। आपका पेमेंट प्रोसेसर और आपका आइडेंटिटी प्रोवाइडर, हर एक के पास तस्वीर का आधा हिस्सा है। फ़्रॉड उनके ओवरलैप में दिखता है।
- अपनी कार्रवाइयों को भरोसे के हिसाब से स्तरबद्ध करो, और हर एक को लॉग करो। अपने आप कार्रवाई केवल वहाँ करो जहाँ कार्रवाई उलटी जा सके और संकेत मज़बूत हो; बाकी को किसी इंसान के पास भेजो।
- अनुकूलन की रफ़्तार के लिए अनुकूलित करो। फ़्रॉड में, वह टीम जीतती है जो अपने नियम सबसे तेज़ी से बदल सकती है।
उत्सुक हैं कि एक हमेशा-चालू एजेंट आपके अपने स्टैक में क्या स्वचालित कर सकता है? Zero को एक्सप्लोर करें।
टिप्पणियाँ: Radar के आँकड़े Stripe के अपने प्रकाशित नंबर हैं (stripe.com/radar; "A primer on machine learning for fraud detection")। नुकसान के आँकड़े पंजीकरण के बाद पहले घंटों में प्रति नए साइनअप पर कंप्यूट लागत को दर्शाते हैं, जो लॉन्च से पहले और बाद की मिलान की गई अवधियों में मापे गए हैं, आंतरिक अकाउंट को छोड़कर; लॉन्च-बाद का नमूना अभी भी शुरुआती है और समय के साथ ठोस होगा।