पेमेंट प्लेटफ़ॉर्म
कार्ड टेस्टिंग अटैक velocity काउंटरों से सेकंडों में पकड़े जाते हैं और अगली कोशिश से पहले ब्लॉक हो जाते हैं।
कोर डेटाफ़िनटेकPerformance और Scale प्लान
रियल-टाइम फ्रॉड डिटेक्शन
हर पेमेंट को request path में ही स्कोर करें। velocity काउंटर, known-bad लिस्ट, कार्ड फ़्रीक्वेंसी और मॉडल फ़ीचर, सब एक ही server से पढ़े जाते हैं।
- हर पेमेंट पर सिग्नल
- 4
- अप्रूवल से पहले
- In-path
- ब्लॉकलिस्ट के लिए मेमोरी
- Constant
कदम 1 में से 5
हर कार्ड की कोशिशें गिनें
हर कार्ड के लिए हर मिनट एक काउंटर, जिसे पहले increment के बाद एक मिनट की expiry दी जाती है।
उदाहरण सेशनplaying
# हर कार्ड की कोशिशें गिनें
hotkv> INCR velocity:card:4f1a:m
(integer) 7
असली HotKV कमांड और उदाहरण रिस्पॉन्स के साथ एक एनिमेटेड वॉकथ्रू। किसी भी कदम पर क्लिक करके वहां पहुंचें। कमांड और रिस्पॉन्स अंग्रेज़ी में ही रहते हैं, ठीक वैसे जैसे आप HotKV में टाइप करते और देखते हैं।
समस्या
फ्रॉड जाँच पेमेंट अप्रूव होने से पहले, चेकआउट के latency बजट के भीतर होनी चाहिए। जो सिग्नल मायने रखते हैं, जैसे इस कार्ड ने पिछले एक मिनट में कितनी कोशिशें कीं या यह डिवाइस ब्लॉकलिस्ट में है या नहीं, उन्हें ट्रांज़ैक्शनल डेटाबेस से जल्दी निकालना मुश्किल होता है।
HotKV इसे कैसे संभालता है
HotKV सिग्नल तैयार रखता है। छोटी expiry वाले काउंटर velocity ट्रैक करते हैं, Bloom filter बताता है कि कार्ड या डिवाइस known-bad है या नहीं, Count-min sketch अनुमान लगाता है कि दिन भर में कार्ड कितनी बार इस्तेमाल हुआ, और फ़ीचर स्टोर रिस्क मॉडल के इनपुट देता है। पेमेंट पूरा होने से पहले एक rules engine या मॉडल इन्हें जोड़कर फ़ैसला करता है।
कदम दर कदम
क्या होता है, कमांड दर कमांड
- 01
हर कार्ड की कोशिशें गिनें
हर कार्ड के लिए हर मिनट एक काउंटर, जिसे पहले increment के बाद एक मिनट की expiry दी जाती है।
INCR velocity:card:4f1a:m - 02
ब्लॉकलिस्ट जाँचें
known-bad डिवाइसों का Bloom filter, constant मेमोरी में।
BF.EXISTS blocked:devices dev:8812 - 03
आज कितनी बार?
Count-min sketch हर कार्ड के लिए अलग काउंटर रखे बिना लाखों कार्डों के इस्तेमाल का अनुमान लगाता है।
CMS.QUERY cards:today card:4f1a - 04
मॉडल फ़ीचर
रिस्क मॉडल के लिए अकाउंट की उम्र, आम तौर पर इस्तेमाल होने वाला देश और औसत बास्केट।
FEATURE.GET risk_features account:42 - 05
चार्ज करने से पहले फ़ैसला
तीन दिन पुराने अकाउंट पर ऊँची velocity है। पेमेंट प्रोवाइडर के बजाय रिव्यू में भेज दिया जाता है।
XADD fraud:review * card 4f1a account 42 score 0.91
कहां फ़िट बैठता है
असली परिदृश्य
मार्केटप्लेस
असामान्य बास्केट वाले नए अकाउंट और ब्लॉकलिस्ट वाले डिवाइस मैन्युअल रिव्यू में भेजे जाते हैं।
प्रमोशन और रेफ़रल
हर डिवाइस और पेमेंट मेथड पर रिडेम्पशन गिनकर कूपन का दुरुपयोग पकड़ा जाता है।
अंतर्निहित
आपको क्या मिलता है
Velocity काउंटर
हर time bucket के लिए expiry के साथ INCR, nanosecond की सटीकता तक।
INCREXPIRENEXPIREब्लॉकलिस्ट
कार्ड, डिवाइस और ईमेल के लिए Bloom filters।
BF.ADDBF.EXISTSफ़्रीक्वेंसी अनुमान
बहुत बड़े key स्पेस में इस्तेमाल के लिए Count-min sketches।
CMS.INCRBYCMS.QUERYमॉडल फ़ीचर
रिस्क मॉडल के लिए typed फ़ीचर।
FEATURE.GETआम सवाल
क्या Bloom filter किसी अच्छे ग्राहक को ब्लॉक कर सकता है?
आपके तय किए गए error रेट पर यह false positive बता सकता है, इसलिए इसे सीधे decline के बजाय अतिरिक्त जाँच शुरू करने के लिए इस्तेमाल करें।
Rules कहाँ चलते हैं?
आपकी अपनी सर्विस में। HotKV सिग्नल जल्दी देता है ताकि आपके rules या मॉडल चेकआउट के latency बजट के भीतर फ़ैसला कर सकें।
यह किन प्लान में शामिल है?
काउंटर और probabilistic structures हर प्लान पर काम करते हैं। फ़ीचर स्टोर Performance और Scale प्लान का हिस्सा है।
संबंधित उपयोग के मामले
इसे अपने वर्कलोड पर आज़माएं
HotKV Redis प्रोटोकॉल बोलता है, इसलिए आप किसी मौजूदा क्लाइंट को इसकी ओर इंगित करके यही कमांड चला सकते हैं।