उपयोग के मामले
सफलता कैसी दिखती है, real production traffic के तीन हिस्सों में।
हमारे outcomes section में संख्याएँ — chargebacks में लगभग 47% median drop, आधे प्रतिशत से कम false-positive rate, कुछ milliseconds में verification — नीचे दिए जैसे integrations से आती हैं। यहाँ के cases anonymized composites हैं; patterns real हैं।
Marketplaces
समस्या: fake-account rings जो review-bomb करने, seller rankings manipulate करने, या welcome-bonus promotions का दुरुपयोग करने के लिए दर्जनों accounts बनाते हैं।
Signal: दो घंटों के अंदर बनाए गए बारह accounts, सब अलग-अलग connections से — लेकिन browser और tampering signs एक single automated cluster की तरफ इशारा करते हुए।
Signal कैसे Compound होता है
एक real browser पर एक home connection से एक single signup unremarkable है। बारह अलग-अलग home connections से बारह signups, जो same automated browser के एक ही tampering signature के साथ दिखते हैं, वह एक fake-account ring है।
वे categories जो यहाँ एक साथ fire होती हैं:
- Automation and bots (01) — हर account पर headless-browser signatures।
- Fingerprint tampering (02) — drawing tests जो claimed browser version से match नहीं करते।
- Infrastructure abuse (03) — एक known fraud operator द्वारा बेचे गए residential proxies।
- Behavioral anomalies (06) — identical patterns में भरे गए signup forms, same timing के साथ।
कोई single category ring को flag नहीं करेगी। Combined risk score करता है।
Policy
Marketplace top tier पर block करता है — ring को, customers को नहीं — और high risk और solid confidence होने पर phone verification के लिए step up करता है। बाकी सब untouched flow होता है। व्यवहार में पूरी policy कुछ lines का कोड है जो Noxtica का लौटाया risk level पढ़ता है।
परिणाम
Integration के 30 दिनों के अंदर fake signups लगभग 70% गिर जाते हैं। Real-customer signup conversion अपरिवर्तित रहता है।
Financial Services
समस्या: Card-not-present fraud, खासकर account-takeover attacks जहाँ attacker के पास card details हैं लेकिन cardholder के known devices नहीं।
Signal: एक session जिसका profile cardholder के known devices से match नहीं करता। Response step-up verification है, outright block नहीं। Real customers को कोई friction नहीं दिखता; fraud rings हर transaction पर extra check देखते हैं।
Signal कैसे Compound होता है
Card-not-present fraud increasingly attacker-controlled devices पर real, stolen card details use करता है। Device ही differentiator है। हम प्रति customer एक profile रखते हैं; जब उस customer के लिए पहले न देखे गए profile से transaction आता है, हम उसे flag करते हैं।
वे categories जो यहाँ एक साथ fire होती हैं:
- Hardware checks (05) — नए device का अलग graphics, audio, या memory signature हो सकता है।
- Infrastructure abuse (03) — fraud rings अक्सर datacenter routes के पीछे होते हैं, यहाँ तक कि residential proxies से front होने पर भी।
- Behavioral anomalies (06) — checkout timing जो cardholder के history से match नहीं करती।
New-device signal अकेला malicious नहीं है — customers phones खरीदते हैं, laptops replace करते हैं, operating systems reinstall करते हैं। हम “new device पर customer” को “stolen card details वाले attacker” से अलग करने के लिए इसे अन्य categories के साथ weight करते हैं।
Policy
एक known device पर returning customer, top tier से नीचे, बिना friction के straight through flow होता है। जब risk high हो — या unusually large transaction पर new device दिखे — session को outright block की जगह step-up verification मिलती है। Bias हमेशा real customers को purchase complete करने देने की तरफ है।
परिणाम
तीन महीनों के अंदर chargeback losses लगभग 45 से 50% गिर जाते हैं। Step-up verification सिर्फ transactions के एक छोटे fraction को मिलती है, और उनमें से अधिकांश सफलतापूर्वक complete होते हैं — real customers check pass करते हुए।
Identity-Sensitive Platforms
समस्या: Passwordless और single-sign-on platforms को यह confirm करना होता है कि login link click करने वाला वही entity है जिसने उसे request किया था। Phishing kits और link-relay services उस assumption को तोड़ देते हैं।
Signal: एक ऐसे profile से click किया गया link जो request करने वाले से अलग हो, extra verification step trigger करता है। Phishing kits और link-relay services इस gate पर पकड़ी जाती हैं।
Signal कैसे Compound होता है
जब login link request होती है, हम requesting profile record करते हैं। जब link click होती है, हम profile re-check करते हैं और compare करते हैं। अगर वे match करते हैं — same browser, same device — तो link automatically authenticate करती है। अगर नहीं, तो हम click को एक different session मानते हैं और extra verification step की ज़रूरत रखते हैं।
वे categories जो यहाँ एक साथ fire होती हैं:
- Fingerprint tampering (02) — phishing kits अक्सर headless browsers चलाते हैं जिनके profiles user के real device से match नहीं करते।
- Behavioral anomalies (06) — request और click के बीच का समय, traffic का source, और session कैसे बदलता है — सब मायने रखता है।
- Infrastructure abuse (03) — link-relay services आमतौर पर cloud infrastructure से चलती हैं।
Policy
अगर clicking device वही है जिसने link request की, तो login link automatically काम करती है। अगर नहीं, तो platform session through करने से पहले second factor माँगता है। Match check उस profile के खिलाफ एक simple comparison है जो link issue होने पर record हुई थी।
परिणाम
Login-link campaigns के खिलाफ phishing success नाटकीय रूप से गिर जाती है — आमतौर पर successful credential-relay attacks में 90% से अधिक की कमी। Real users जो legitimately devices switch करते हैं, एक extra verification step देखते हैं, फिर future links के लिए trusted-device list में जोड़ दिए जाते हैं।
Pattern: कब Block करें, कब Challenge करें
तीनों use cases में, policy structure एक जैसा है:
- Critical risk — logging के साथ block। ये sessions challenge की लागत के लायक नहीं।
- High risk — challenge करें: step-up verification, second factor, या manual review। Real customers pass करते हैं; bots नहीं।
- Medium risk — observe करें। Session log करें और dashboard में surface करें, लेकिन कोई friction न जोड़ें।
- Low या minimal risk — allow करें। Traffic का विशाल बहुमत।
ये चार actions five-tier risk model पर map होते हैं: सबसे निचले दो tiers लगभग सभी के लिए “allow” में collapse हो जाते हैं, लेकिन उन्हें अलग रखना dashboard में यह समझने के लिए useful है कि आपकी population कहाँ बैठती है।
संबंधित पठन
- Threat categories — इन use cases द्वारा reference की गई छह categories में से हर एक का विवरण।
- Why calibration, not verdicts — policy आपकी क्यों है, हमारी नहीं।
- Engineering principles — defaults के पीछे की operating बाधाएँ।