01 · धोखाधड़ी रोकथाम के लिए डिवाइस इंटेलिजेंस वे जर्नी जिन्हें आप टैग करते हैं
आपकी चुनी हुई हर स्क्रीन के लिए एक टैग
आपकी साइट पर एक स्क्रिप्ट डेस्कटॉप पर लगभग एक सेकंड के दसवें हिस्से में ब्राउज़र और डिवाइस को पढ़ लेती है। आपके बैकएंड से एक साइन की हुई कॉल, आपके दिए नाम वाले टैग के साथ, तुरंत जवाब पाती है: एक ट्रस्ट स्कोर, एविडेंस कवरेज और 13 इंडिकेटर, बॉट और ऑटोमेशन, ब्राउज़र स्पूफिंग और एमुलेटर से लेकर VPN, प्रॉक्सी और Tor तक, और हर सिफ़ारिश के पीछे की वजह। अकाउंट टेकओवर, फ़र्ज़ी साइनअप और पेआउट फ्रॉड को अंदाज़े से नहीं, सबूत से पकड़ें। हम सिफ़ारिश करते हैं। फ़ैसला और कार्रवाई आपकी।
आपकी टैग की हुई किसी भी स्क्रीन पर सिंक्रोनस रिस्पॉन्स · किसी भी फ़ैसले पर असर डालने से पहले शैडो मोड · आपके नियम, आपकी लिस्ट, आपका फ़ैसला
इस रिस्पॉन्स को कैसे पढ़ें · v1.1/login_completed उदाहरण
यह सिफ़ारिश क्यों
ALLOW
पॉलिसी जिन इंडिकेटर को वेट देती है, उनमें से कोई भी detected नहीं आया। कॉन्ट्रैक्ट का उदाहरण: FingerTrackID की मैनेज्ड पॉलिसी हर स्कोर पर MONITOR की सिफ़ारिश करती है; ALLOW उस स्कोर बैंड से आता है जो आपकी कंपनी ने अपने रिस्क नियमों में तय किया है। policy-login-v1 के तहत तय हुआ।
स्कोर क्या है, और क्या नहीं
trust_score 100
इस पॉलिसी वर्ज़न के तहत इस एक्सेस पर भरोसा, फ्रॉड की संभावना नहीं। COMPLETED के बाहर यह null होता है, कभी डिफ़ॉल्ट नहीं।
कितना देखा जा सका
evidence_coverage 100
अपेक्षित जाँचों में से कितनी चलीं, उसका हिस्सा। गायब सबूत का नाम यहाँ लिखा जाता: वह कवरेज घटाता है और कभी रिस्क की वजह नहीं बनता।
फिर फ़ैसला आपका
customer_action
आपका बैकएंड फ़ैसला लेता है और कार्रवाई करता है, फिर बताता है कि उसने क्या किया और असली नतीजा क्या रहा। हम कभी ब्लॉक नहीं करते और पैसा नहीं रोकते।
POST /v1/assessments → 201
event-assessment.v1.1 · कॉन्ट्रैक्ट का उदाहरण
{ "schema_version": "event-assessment.v1.1", "tag": "login", "assessment_status": "COMPLETED", "trust_score": 100, "device_match_confidence": 0.98, "evidence_coverage": 100, "signals": [ … 13 objects ], "limitation_codes": [], "reason_codes": ["NO_ADVERSE_INDICATOR_MATCH"], "recommended_action": "ALLOW", "recommendation_basis": "EVALUATION", "policy_version": "policy-login-v1" // … 21 more fields in the full response: ids, snapshot, versions, timestamps}
1{2 "schema_version": "event-assessment.v1.1",3 "assessment_id": "01996f2a-0000-7000-8000-000000000101",4 "assessment_version": 1,5 "supersedes_assessment_id": null,6 "business_event_id": "01996f2a-0000-7000-8000-000000000102",7 "external_event_id": "login_20260904_000001",8 "tag": "login",9 "assessment_status": "COMPLETED",10 "retryable": false,11 "trust_score": 100,12 "device_intelligence_snapshot_id": "01996f2a-0000-7000-8000-000000000103",13 "device_intelligence_snapshot_version": 1,14 "device_id": "dev_0123456789abcdefghij",15 "device_match_confidence": 0.98,16 "evidence_coverage": 100,17 "data_freshness": {18 "evidence_cutoff_at": "2026-09-04T12:00:00Z",19 "oldest_required_observed_at": "2026-09-04T11:59:59Z",20 "maximum_required_age_ms": 300000,21 "all_required_fresh": true22 },23 "signals": [24 { "signal_code": "ANTI_FINGERPRINTING", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },25 { "signal_code": "BOT_AUTOMATION", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },26 { "signal_code": "BROWSER_SPOOFING", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },27 { "signal_code": "EMULATED_ENVIRONMENT", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },28 { "signal_code": "PRIVATE_BROWSING", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },29 { "signal_code": "BROWSER_PRIVACY_BRAVE", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },30 { "signal_code": "BROWSER_PRIVACY_SAFARI", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },31 { "signal_code": "BROWSER_PRIVACY_SAMSUNG_INTERNET", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },32 { "signal_code": "NETWORK_PROXY", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },33 { "signal_code": "NETWORK_VPN", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },34 { "signal_code": "NETWORK_HOSTING", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },35 { "signal_code": "NETWORK_TOR", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … },36 { "signal_code": "DEVICE_MULTI_USER", "signal_state": "NOT_DETECTED", "source": "DERIVED", "detector_version": "detector-web-v1", … }37 ],38 "limitation_codes": [],39 "reason_codes": ["NO_ADVERSE_INDICATOR_MATCH"],40 "recommended_action": "ALLOW",41 "recommendation_basis": "EVALUATION",42 "policy_version": "policy-login-v1",43 "fallback_policy_version": "production-observation-fallback-v2",44 "ruleset_version": "ruleset-web-v1",45 "signal_catalog_version": "signals-web-v1",46 "feature_schema_version": "features-v1",47 "resolver_version": "resolver-v1",48 "sdk_version": "web-sdk-1.0.0",49 "provider_versions": ["network-provider-2026-09-04"],50 "evidence_cutoff_at": "2026-09-04T12:00:00Z",51 "evaluated_at": "2026-09-04T12:00:01Z",52 "expires_at": "2026-09-04T12:05:00Z",53 "correlation_id": "corr-assessment-login-0001"54}
जिन वर्ज़न से यह बना · policy-login-v1 · production-observation-fallback-v2 · ruleset-web-v1 · signals-web-v1 · features-v1 · resolver-v1 · web-sdk-1.0.0 · network-provider-2026-09-04
पूरे रिस्पॉन्स में 13 सिग्नल · इंडिकेटर मैट्रिक्स ↓
आँकड़ों में प्रोडक्ट
रिस्पॉन्स
13
हर रिस्पॉन्स में वेब इंडिकेटर
3
हर इंडिकेटर की स्थितियाँ: detected, not detected, not evaluated
14
"not evaluated" की नामित वजहें, कभी चुपचाप false नहीं
5
संभावित सिफ़ारिशें
3
अलग-अलग माप: ट्रस्ट, डिवाइस मैच, एविडेंस कवरेज
1
हर आकलित इवेंट पर साइन की हुई कॉल
कलेक्शन
17
हर कलेक्शन में ब्राउज़र और डिवाइस के सबूत के सेक्शन
48
ब्राउज़र API जिन्हें ब्राउज़र के बताए वर्ज़न से मिलाकर जाँचा जाता है
125
मिलीसेकंड या उससे कम: Chrome, Firefox और Safari में डेस्कटॉप कलेक्शन का मीडियन
0
आपके यूज़र को दिखाए गए परमिशन प्रॉम्प्ट
आपके नियम और आपकी जाँच
54
हर असेसमेंट के अंदर कैलकुलेट होने वाली कॉन्टेक्स्ट इनसाइट
67
नियम जिन्हें आपकी कंपनी अपने स्कोर में वेट दे सकती है: 13 इंडिकेटर और 54 इनसाइट
6
नेटवर्क इंडिकेटर के पीछे प्रकाशित रेफ़रेंस लिस्ट
6
कंसोल की भाषाएँ: अंग्रेज़ी, पुर्तगाली (ब्राज़ील और पुर्तगाल), स्पेनिश, फ़्रेंच, जर्मन
कभी नहीं — और यह किसी प्लान से नहीं बदलता
— हर वैल्यू किसी वर्ज़न वाले कॉन्ट्रैक्ट, कैटलॉग या लिस्ट की गिनती है, सिवाय कलेक्शन टाइम के, जो हमारी टेस्ट मशीनों पर कोल्ड कैश के साथ मापा गया। इनमें से कोई भी प्लान या वॉल्यूम से नहीं बदलता।
03 · उपयोग के मामले
आपका बैकएंड कार्रवाई को आगे बढ़ने दे, उससे पहले डिवाइस इंटेलिजेंस एक सवाल का जवाब देता है: इस स्क्रीन के दूसरी तरफ़ असल में क्या है? एक ही कॉल हर जर्नी के लिए काम करती है; आपका भेजा टैग बस उसे फ़ाइल करता है।
login · password_recovery · profile_change
एक जाना-पहचाना अकाउंट ऐसे डिवाइस पर जो उसने कभी इस्तेमाल नहीं किया, अपने बारे में झूठ बोलता ब्राउज़र, anti-detect ब्राउज़र, ऐसा सफ़र जो उतने समय में मुमकिन नहीं। हर एक सबूत के रूप में लौटता है, ताकि आप दूसरा फ़ैक्टर सिर्फ़ तभी माँगें जब ज़रूरी हो।
signup · login · checkout
Headless ब्राउज़र, ऑटोमेशन फ़्रेमवर्क, सिग्नेचर से पहचाने गए AI एजेंट और डेटासेंटर से आने वाला ट्रैफ़िक। BOT_AUTOMATION और NETWORK_HOSTING बताते हैं कि क्या दिखा; कवरेज बताता है कि कितना देखा जा सका।
signup · deposit · promotions
हर डिवाइस और हर IP पर अकाउंट और लोग, आपके बेस में डिवाइस प्रोफ़ाइल कितनी दुर्लभ है, एक ही कलेक्शन का दूसरे डिवाइस पर दोहराया जाना। ऐसा कॉन्टेक्स्ट जिसे आपके नियम वेट दे सकते हैं, कभी अपने-आप फ़ैसला नहीं: एक व्यक्ति के कई वैध अकाउंट हो सकते हैं।
withdrawal · pix_transfer · trade
नए डिवाइस के बाद पहले घंटे में निकासी, कई अकाउंट में साझा बेनिफ़िशियरी, ऐसे पड़ोसी जिन्हें आपने confirmed फ्रॉड मार्क किया है। पैसा आपका बैकएंड रोकता या रिव्यू करता है; हम कभी नहीं।
कोई भी जर्नी
Android एमुलेटर और वर्चुअलाइज़ेशन, घोषित सिस्टम के लिए नामुमकिन GPU, ऐसा ब्राउज़र वर्ज़न जिसे उसके अपने API ही झुठलाते हैं। डिवाइस फिंगरप्रिंटिंग सिग्नल हैश और फ़ैमिली के रूप में पढ़े जाते हैं, कभी रॉ पिक्सल के रूप में नहीं।
कोई भी जर्नी
जाने-माने VPN प्रोवाइडर, पब्लिक प्रॉक्सी, Tor एग्ज़िट, होस्टिंग रेंज और Apple iCloud Private Relay, हमारी ओर से रिफ़्रेश की जाने वाली प्रकाशित लिस्ट से। गुमनामी कॉन्टेक्स्ट है, दोष नहीं: उसे कितना वेट मिले, यह आपकी पॉलिसी तय करती है।
04 · माप
कॉन्फ़िडेंस, कवरेज और डिवाइस मैच को एक ही नंबर में मिलाने से ठीक वही छिप जाता है जो एनालिस्ट को देखना है: समस्या एक्सेस में है या सबूत में।
trust_score
72
बताता है कि इस पॉलिसी वर्ज़न के तहत यह एक्सेस कितना भरोसेमंद है; आपका भेजा टैग इसे नहीं बदलता। 0 से 100 तक पूर्णांक। सिर्फ़ तब मौजूद जब assessment_status = COMPLETED; बाकी हर स्थिति में यह null है, कभी डिफ़ॉल्ट वैल्यू नहीं।
फ्रॉड की संभावना, व्यक्ति की साख या गायब डेटा का डिफ़ॉल्ट नहीं। हम 72/100 दिखाते हैं, कभी "72% भरोसेमंद" नहीं।
device_match_confidence
0.94
इस सबूत की मज़बूती कि यह एक्सेस पहले से देखे गए उसी डिवाइस से आ रहा है, 0 से 1 तक। साथ में device_id आता है, प्रोबेबिलिस्टिक क्लस्टर का एक अपारदर्शी पब्लिक आइडेंटिफ़ायर।
व्यक्ति की पहचान नहीं, और हार्डवेयर का सबूत भी नहीं। Party और Account अलग चीज़ें हैं।
evidence_coverage
100
अपेक्षित जाँचों के सेट में से कितनी चलाई जा सकीं, 0 से 100 तक। NOT_EVALUATED छोड़ा गया हर लागू इंडिकेटर कवरेज घटाता है और limitation_codes में दिखता है।
स्कोर का हिस्सा नहीं। कम कवरेज न स्कोर नीचे खींचता है न ऊपर धकेलता है: यह असेसमेंट को अनिर्णायक छोड़ देता है।
हम इन्हें जोड़ते क्यों नहीं
एक अकेला "शक" वाला स्कोर तीन अलग सवालों को मिला देता है: क्या यह एक्सेस भरोसे लायक है? क्या सबूत काफ़ी था? क्या यह वही डिवाइस है? जब जवाब अलग-अलग आता है, तो आपका एनालिस्ट जानता है कि दूसरा फ़ैक्टर माँगना है, कलेक्शन का इंतज़ार करना है या हिस्ट्री देखनी है। जब सब मिलाकर आता है, तो उन्हें बस इतना पता होता है कि "स्कोर 42 आया"।
05 · 13 इंडिकेटर
हर वेब असेसमेंट हमेशा 13 कोड लौटाता है। बदलती है हर एक की स्थिति, लिस्ट कभी नहीं। हर इंडिकेटर का अपना वर्ज़न वाला डिटेक्टर है, और रिस्पॉन्स उस वर्ज़न का नाम बताता है जिसने उसे आँका। जो डिटेक्टर गायब, एक्सपायर्ड या फ़ेल हो रहा हो, वह कभी false नहीं बनता।
signal_catalog web · 13 कोड · withdrawal_completed उदाहरण
एनवायरनमेंट की इंटेग्रिटी
ब्राउज़र प्राइवेसी · न्यूट्रल कॉन्टेक्स्ट
नेटवर्क · न्यूट्रल कॉन्टेक्स्ट
डिवाइस
हमारी मैनेज्ड पॉलिसी में अकेला Tor कभी BLOCK_RECOMMENDED को सही नहीं ठहराता; आपकी कंपनी के बनाए नियम उसके चुने हुए वेट और कटऑफ़ पर चलते हैं। इस v1 कॉन्ट्रैक्ट उदाहरण में, policy-withdrawal-v1 ने निकासी का रिव्यू माँगा, ब्लॉक नहीं, और अकेला reason code ठीक यही कहता है। प्रोडक्शन में आज की मैनेज्ड पॉलिसी हर स्कोर पर MONITOR की सिफ़ारिश करती है।
एक ही इंडिकेटर, तीन स्थितियाँ
जो डिटेक्टर गायब, एक्सपायर्ड या फ़ेल हो रहा हो, वह कभी false नहीं बनता। NOT_APPLICABLE सिर्फ़ चैनल, इंजन और प्लेटफ़ॉर्म के हिसाब से कैटलॉग की अपरिवर्तनीय मैट्रिक्स से आता है; आपका टैग इसे कभी नहीं बदलता, और बंद की गई पॉलिसी, टाइमआउट या आउटेज कभी यह शॉर्टकट नहीं लेते।
डिफ़ॉल्ट रूप से न्यूट्रल कॉन्टेक्स्ट
ये हमारे ऑब्ज़र्वेशन को सीमित कर सकते हैं। कवरेज सिर्फ़ वहीं घटता है जहाँ सबूत evaluated नहीं होता। ये फ्रॉड नहीं हैं। ये एनवायरनमेंट का वर्णन करते हैं; व्यक्ति पर आरोप नहीं लगाते। हमारी मैनेज्ड पॉलिसी में अकेले ये कभी BLOCK_RECOMMENDED को सही नहीं ठहराते; आपकी कंपनी के बनाए नियम उसके चुने हुए वेट और कटऑफ़ पर चलते हैं। जब नेटवर्क का प्रकार अलग से पहचाना न जा सके, जैसे Apple के iCloud Private Relay के पीछे, तो होस्टिंग, VPN और प्रॉक्सी तीनों NETWORK_TYPE_AMBIGUOUS के साथ NOT_EVALUATED रहते हैं: हम एक ही boolean से तीन डिटेक्शन कभी मार्क नहीं करते।
नेटवर्क का सबूत प्रकाशित रेफ़रेंस लिस्ट से आता है, जिन्हें हम अपने इंफ़्रास्ट्रक्चर पर रिफ़्रेश करते हैं: Tor एग्ज़िट एड्रेस, क्लाउड प्रोवाइडर रेंज, होस्टिंग-नेटवर्क लिस्ट, VPN प्रोवाइडर रेंज और एक पब्लिक-प्रॉक्सी डेटाबेस। आपके यूज़र्स के एड्रेस लिस्ट पब्लिशर को कभी नहीं भेजे जाते। अपनी अधिकतम उम्र पार कर चुकी लिस्ट अपने इंडिकेटर को NOT_EVALUATED छोड़ती है, कभी NOT_DETECTED नहीं।
06 · कॉन्टेक्स्ट इनसाइट
हर असेसमेंट के अंदर, रिस्पॉन्स से पहले, हम जो कलेक्ट हुआ उससे और आपकी कंपनी की अपनी हिस्ट्री से 54 कॉन्टेक्स्ट इनसाइट कैलकुलेट करते हैं: डिवाइस और कौन इस्तेमाल करता है, अकाउंट कितनी तेज़ी से चल रहा है, किस नेटवर्क से, किन अकाउंट के पास। FingerTrackID की मैनेज्ड पॉलिसी इन्हें स्कोर से बाहर रखती है। आपके अपने रिस्क नियमों में, इनमें से कोई भी off, ghost या active हो सकता है, असामान्य और बहुत असामान्य के लिए पॉइंट के साथ: जो active इनसाइट ट्रिगर होता है वह ट्रस्ट स्कोर से पॉइंट घटाता है और reason_codes में अपना नाम दर्ज करता है।
context-insight.v1 · छह थीम में 54 इनसाइट · जैसे कंसोल और आपके नियमों में ग्रुप किए गए हैं
अकाउंट और डिवाइस · 10
अकाउंट के लिए नया डिवाइस और नया ऑपरेटिंग सिस्टम · 30 दिनों में डिवाइस पर अलग-अलग अकाउंट और लोग · उस पर एक ही व्यक्ति के अकाउंट · 24 घंटों में हर अकाउंट और हर व्यक्ति पर डिवाइस · हाई-एक्टिविटी डिवाइस · आपकी कंपनी में डिवाइस प्रोफ़ाइल कितनी आम, कम आम या दुर्लभ है · डिवाइस कुकी खो गई
निकासी और ऑर्डर · 7
नए डिवाइस के बाद पहले घंटे में निकासी · 30 दिनों में हर डिवाइस पर बेनिफ़िशियरी और हर बेनिफ़िशियरी पर अकाउंट · हर अकाउंट पर निकासी की संख्या और राशि · हर अकाउंट पर ऑर्डर की संख्या और ऑर्डर के बीच का मीडियन अंतराल
नेटवर्क और लोकेशन · 12
अकाउंट के लिए नया देश और नया इंटरनेट प्रोवाइडर (ASN) · हर अकाउंट पर अलग-अलग देश, प्रोवाइडर और IP · हर IP पर अकाउंट और लोग · असंभव यात्रा · ब्राउज़र का टाइम ज़ोन जो IP के देश से मेल नहीं खाता · VPN egress देश · पब्लिक एब्यूज़ लिस्ट पर मौजूद प्रोवाइडर · Apple iCloud Private Relay
ब्राउज़र और SDK इंटेग्रिटी · 16
डेवलपर टूल खुले · ऑटोमेशन के निशान · anti-detect ब्राउज़र मार्कर · TLS सिग्नेचर जो घोषित ब्राउज़र से मेल नहीं खाता, और 30 दिनों में उसकी स्थिरता · सॉफ़्टवेयर रेंडरर और GPU फ़ैमिली · canvas या ऑडियो जो दो रीड के बीच बदल जाए · in-app ब्राउज़र · संभावित गेस्ट मोड · सिग्नेचर से पहचाना गया AI एजेंट · बॉट कैटेगरी · अप्रूव्ड पैकेज से अलग SDK · कई डिवाइस पर एक ही SDK सेशन · दूसरे डिवाइस पर दोहराया गया एक जैसा कलेक्शन · बहुत दूर-दूर की जगहों पर इस्तेमाल हुई डिवाइस कुकी
वेलोसिटी · 5
5 मिनट, 1 घंटे और 24 घंटों में हर डिवाइस और हर अकाउंट पर एक्सेस; 5 मिनट और 1 घंटे में हर IP पर · 1 मिनट, 5 मिनट और 1 घंटे में हर अकाउंट और हर डिवाइस पर एक ही टैग वाले असेसमेंट
अकाउंट के बीच लिंक, एक हॉप · 4
दूसरे अकाउंट जिन्होंने वही डिवाइस इस्तेमाल किए · पड़ोसी अकाउंट जहाँ ऑटोमेशन या ब्राउज़र स्पूफ़िंग detected हुई · पड़ोसी अकाउंट जिन्हें आपने confirmed फ्रॉड मार्क किया · दूसरे अकाउंट के साथ साझा निकासी बेनिफ़िशियरी
तीन स्थितियाँ · एक वजह, कभी शून्य नहीं
कुछ इनसाइट इस पर निर्भर हैं कि आप क्या भेजते हैं। अकाउंट या व्यक्ति के ref के बिना, टैग के बिना, या आउटकम के बिना, आइटम यही बताता है: अकाउंट नहीं भेजा गया, टैग के बिना असेसमेंट, कोई आउटकम नहीं भेजा गया। टैग वाली रिक्वेस्ट में राशि या बेनिफ़िशियरी नहीं होता, इसलिए निकासी की राशि और बेनिफ़िशियरी वाले आइटम भी यही बताते हैं। पहला एक्सेस, गुमनाम नेटवर्क या किसी जाँच की एक घंटे की विंडो से बाहर का IP भी वजहें हैं।
ये क्या नहीं हैं
reason_codes तक सिर्फ़ उस नियम से पहुँचते हैं जिसे आपकी कंपनी ने active किया हो।एनालिस्ट इन्हें कहाँ पढ़ता है
एक्सेस डिटेल। एक "एक्सेस कॉन्टेक्स्ट" कार्ड इनसाइट को थीम के हिसाब से ग्रुप करता है, उनकी टाइम विंडो, उन्होंने हिस्ट्री का कौन-सा कटऑफ़ माना, आपके पैमाने पर हर एक कितना असामान्य है और बिना वैल्यू वाले हर आइटम की वजह के साथ। जो इनसाइट असेसमेंट के टाइम बजट में फ़िट नहीं होता, वह बैकग्राउंड में पूरा होता है और यह बताता है; वह रिस्पॉन्स को कभी देर से नहीं करता या फ़ेल नहीं करता।
इंडिकेटर कैटलॉग। एक पेज बताता है कि 13 इंडिकेटर में से हर एक क्या ढूँढता है, किस वजह से वह evaluated नहीं रहता और क्या वह स्कोर बदल सकता है, और कॉन्टेक्स्ट इनसाइट को उन वजहों के साथ लिस्ट करता है जिनसे वे बिना वैल्यू रह सकते हैं।
Canvas, WebGL, ऑडियो और फ़ॉन्ट हर कंपनी की मैनेज्ड कलेक्शन पॉलिसी के तहत, सिर्फ़ डिराइव्ड वैल्यू के रूप में पढ़े जाते हैं, और इनमें से कुछ इनसाइट को फ़ीड करते हैं, जैसे GPU फ़ैमिली, सॉफ़्टवेयर रेंडरर या दो रीड के बीच बदलने वाला रेंडर। जहाँ ब्राउज़र किसी जाँच की अनुमति नहीं देता, वह आइटम अपनी वजह के साथ not evaluated रहता है।
07 · अनिर्णायक भी एक नतीजा है
गायब सबूत से 100 कॉन्फ़िडेंस नहीं बनता, और न ही वह फ्रॉड सिग्नल बनता है। स्कोर न होने पर, सिफ़ारिश पॉलिसी वर्ज़न के अंदर फ़्रीज़ किए गए और उसके हैश से कवर किए गए fallback से आती है, और हर स्कोर-रहित स्थिति के लिए एक ही जवाब होता है, टैग चाहे जो हो: MONITOR। कभी ALLOW नहीं।
कॉन्ट्रैक्ट उदाहरणों से स्कोर-रहित मामले
टैग कभी fallback नहीं चुनता। मैनेज्ड पॉलिसी में बिना स्कोर की हर स्थिति, किसी भी टैग पर, MONITOR की सिफ़ारिश करती है: आगे बढ़ें और इसे रिकॉर्ड करें। नीचे के तीनों कॉन्ट्रैक्ट उदाहरण भी यही करते हैं।
INCONCLUSIVEटैग login · SDK लोड नहीं हुआ
कोई कलेक्शन नहीं: trust_score: null, evidence_coverage: 0, COLLECTOR_NOT_LOADED, basis INSUFFICIENT_EVIDENCE। कुछ भी कभी ALLOW के रूप में रिलीज़ नहीं होता।
INCONCLUSIVEनेटवर्क सबूत उपलब्ध नहीं
चार नेटवर्क इंडिकेटर NOT_EVALUATED, evidence_coverage: 69, PROVIDER_UNAVAILABLE। ऑपरेशन जो भी हो, वह आपके सिस्टम में, आपके फ़ैसले के तहत रहता है; हम कभी पैसा नहीं रोकते।
FAILEDटैग pix_transfer · पॉलिसी उपलब्ध नहीं
तकनीकी विफलता: POLICY_UNAVAILABLE, policy_version: null, basis TECHNICAL_FAILURE। कभी "कोई रिस्क नहीं" के रूप में नहीं पढ़ा जाता।
स्कोर न होने पर हम कभी ALLOW की सिफ़ारिश नहीं करते · उदाहरणों में fallback_policy_version production-observation-fallback-v2 · हर बार पॉलिसी पढ़े जाने पर fallback को पॉलिसी के साथ वैलिडेट किया जाता है
असेसमेंट की चार स्थितियाँ
कैटलॉग के 14 limitation code · क्या कमी थी, कभी यह नहीं कि रिस्क क्यों है
limitation code कलेक्शन और क्वालिटी को समझाता है; reason code पॉलिसी को। हर इंडिकेटर NOT_EVALUATED अपने कोड की ओर इशारा करता है; असेसमेंट उन सबको limitation_codes में इकट्ठा करता है। कलेक्शन की सीमा कभी रिस्क की वजह नहीं होती।
08 · फ़ैसला आपका
recommended_action बताता है कि पॉलिसी क्या सुझाती है। customer_action बताता है कि आपने क्या किया। दो फ़ील्ड, क्योंकि ये दो तथ्य हैं।
कौन सिफ़ारिश करता है, कौन फ़ैसला लेता है, कौन कार्रवाई करता है
FingerTrackID सिफ़ारिश करता है
सिर्फ़ प्राइवेसी के आधार पर कभी नहीं · Tor, VPN, प्रॉक्सी, incognito, साझा डिवाइस
आपका फ़्लो फ़ैसला लेता है
आपका बैकएंड फ़ैसला लेता है और कार्रवाई करता है। हम एक सिफ़ारिश लौटाते हैं; आज मैनेज्ड पॉलिसी MONITOR का जवाब देती है, सिर्फ़ ऑब्ज़र्वेशन। एक्सेस का क्या होगा, यह आपकी तरफ़ तय और लागू होता है। आप अकाउंट, लिमिट, हिस्ट्री और फ़्रिक्शन की लागत जानते हैं। हम नहीं।
आप कार्रवाई करते हैं और वापस बताते हैं
customer_action · वह फ़ील्ड जो आप वापस भेजते हैं
हर सिफ़ारिश का क्या मतलब नहीं है
पॉलिसी को इस एक्सेस पर फ़्रिक्शन की कोई वजह नहीं मिली। इसका मतलब यह नहीं कि व्यक्ति वैध है या एक्सेस प्रमाणित है। यह सिर्फ़ स्कोर और ज़रूरी सबूत evaluated होने पर ही जारी होता है।
आगे बढ़ें, लेकिन इसे रिकॉर्ड करें। यह हर टैग पर स्कोर-रहित fallback है, और आज हर स्कोर पर मैनेज्ड पॉलिसी का जवाब भी। इसका मतलब यह नहीं कि शक की पुष्टि हुई है, और इसके लिए यूज़र से कोई कार्रवाई ज़रूरी नहीं।
दूसरा फ़ैक्टर या पुष्टि माँगें। इसका मतलब यह नहीं कि हम किसी को चैलेंज करते हैं: चैलेंज आप दिखाते हैं।
इसे ह्यूमन रिव्यू के लिए भेजें। इसका मतलब यह नहीं कि हम पैसा रोकते हैं: ऑपरेशन आपके सिस्टम में, आपके फ़ैसले के तहत रहता है।
पॉलिसी मना करने का सुझाव देती है। इसका मतलब यह नहीं कि ब्लॉक लागू हुआ, फ्रॉड की पुष्टि हुई या बैन हुआ। जब आप ब्लॉक करते हैं, तो वह customer_action: BLOCKED बनता है, आपका एक इवेंट, और यह एक्यूरेसी मापने में काम आता है।
09 · इंटीग्रेशन
आपकी साइट पर एक स्क्रिप्ट, आपके बैकएंड में एक सर्वर-टू-सर्वर एंडपॉइंट और कार्रवाई व नतीजा वापस भेजने के लिए दो कॉल। क्लाइंट पर कोई फ़ैसला नहीं।
आपकी साइट पर SDK
आपके ही एक सबडोमेन से सर्व होता है। जिस रिक्वेस्ट का आकलन आप चाहते हैं उसे भेजने से पहले, स्क्रीन चाहे जो हो, यह ब्राउज़र और एनवायरनमेंट के सिग्नल कलेक्ट करता है और 202 PROCESSING पाता है: यह रिसीप्ट की पुष्टि करता है, नतीजे की नहीं। नेटवर्क सिग्नल आपके कलेक्शन डोमेन पर edge जोड़ता है, स्क्रिप्ट कभी नहीं। कोई स्कोर, सिग्नल या फ़ैसला ब्राउज़र में वापस नहीं जाता।
import { initializeSdk } from '@ftid/sdk-web'
// publicKey is a public locator, not a secret.
// collectionOrigin is YOUR collection domain (https).
const sdk = initializeSdk({
publicKey: 'pub_app_0123456789abcdef',
collectionOrigin: 'https://collect.yourcompany.com',
})
// ACCEPTED (202 PROCESSING on the wire): confirms receipt, not a result.
const collection = await sdk.collect()
if (collection.status !== 'ACCEPTED') {
// Without collection the journey continues; the backend will get
// INCONCLUSIVE / COLLECTOR_NOT_LOADED: no fake score.
return continueWithoutToken()
}
// Create the event before sending the request to be assessed.
const event = sdk.createEvent(collection.observation)
// Only a COMPLETED collection yields a token. The token goes in the POST
// that YOUR backend makes; the decision never comes back here.
const ctx = await sdk.getEventContext(event)
const token =
ctx.status === 'COMPLETED'
? ctx.eventContextToken
: nullआपका बैकएंड कॉल करता है
दस कैनोनिकल लाइनों पर HMAC-SHA-256 — मार्कर, key_id, मेथड, पाथ, टाइमस्टैम्प, इवेंट और रिक्वेस्ट id, कंटेंट मेटाडेटा, और आख़िरी लाइन पर बॉडी के सटीक बाइट्स का SHA-256। हैश करने से पहले JSON को कभी दोबारा serialize न करें; कॉन्ट्रैक्ट में नॉर्मेटिव वेक्टर है। key_id ही एकमात्र पब्लिक लोकेटर है। सीक्रेट कभी ट्रैवल नहीं करता। v1.1 कॉन्ट्रैक्ट का कैनोनिकल वेक्टर requests.both_refs_deadline_750: v1 जैसा ही रूट और वही सिग्नेचर, journey, action और journey_context की जगह tag के साथ।
POST /v1/assessments HTTP/1.1
Host: api.fingertrackid.com
Content-Type: application/json
X-FTID-Signature: v1=<key_id>:<mac-hex>
X-FTID-Timestamp: 1791720000
X-FTID-Request-Id: <uuidv7 of the attempt>
X-FTID-External-Event-Id: evt:tag-0003
{
"schema_version": "event-assessment-request.v1.1",
"external_event_id": "evt:tag-0003",
"idempotency_key": "idem-tag-0003",
"occurred_at": "2026-10-11T12:00:00.000Z",
"subject_ref": "subject:synthetic",
"account_ref": "account:synthetic",
"event_context_token": "ctx.synthetic-token_0003",
"tag": "pix_transfer_a1b2c3d4e5f6g7h8i9j0abcdeabcdeabcdeabcdeabcdeabcdez",
"deadline_ms": 750
}tag 64 कैरेक्टर तक का lowercase slug है (अक्षर, अंक और underscore, अधिकतम दस अंक), कभी पर्सनल डेटा नहीं; यह वेक्टर ठीक उसी सीमा पर है · subject_ref और account_ref null हो सकते हैं, और account_ref के लिए subject_ref ज़रूरी है · refs आपके अपारदर्शी कोड हैं, कभी नेशनल ID, ईमेल या सीक्वेंशियल ID नहीं · deadline_ms 250 से 5000 तक का पूर्णांक है, या 5000 के लिए null; इसके पार होने पर retry किया जा सकने वाला 503 Problem लौटता है, आंशिक स्कोर नहीं
सिंक्रोनस रिस्पॉन्स
फिर दो फ़ीडबैक कॉल: customer_action जिसमें आपने क्या किया और, पता चलने पर, truth_status असली नतीजे के साथ (आउटकम: वैध, फ्रॉड की पुष्टि या अपर्याप्त सबूत)। कॉन्ट्रैक्ट दोनों पर असेसमेंट कॉल जैसा ही अनुशासन लागू करता है: टिकाऊ commit से पहले कुछ भी स्वीकार नहीं माना जाता, और एक जैसा retry कोई दूसरा असर नहीं जोड़ता। आउटकम बाद में सुधारा जा सकता है — सुधार उत्तराधिकारी के रूप में जोड़ा जाता है, और पिछला रिकॉर्ड पढ़ने लायक रहता है।
POST /v1/assessments/POST /v1/assessments/
वेब, किसी भी मॉडर्न ब्राउज़र में · कोई ऐप इंस्टॉल नहीं करना · SDK, असेसमेंट और फ़ीडबैक एक ही वर्ज़न वाले कॉन्ट्रैक्ट में
npm install @fingertrackid/server आपके लिए कॉल साइन करता है, और @fingertrackid/mcp से Claude Code, Cursor या कोई भी MCP-सक्षम कोडिंग एजेंट प्रकाशित कॉन्ट्रैक्ट से इंटीग्रेशन जोड़ सकता है। स्टेप-बाय-स्टेप quickstart, Web SDK गाइड और API रेफ़रेंस में।
10 · ब्राउज़र पर ज़ीरो ट्रस्ट
ब्राउज़र से आने वाली किसी भी चीज़ को अथॉरिटी नहीं माना जाता। असेसमेंट सर्वर-टू-सर्वर और साइन किया हुआ है, और हर प्रयास एक बार गिना जाता है: उसे दोहराने से कोई नया असर नहीं होता।
कौन किससे बात करता है
ब्राउज़र को सिर्फ़ अपारदर्शी सेशन और इवेंट ID मिलते हैं। स्कोर, सिग्नल और सिफ़ारिश सर्वर पर बनते हैं और वहीं रहते हैं। फ़र्स्ट-पार्टी कुकी साइन की हुई, HttpOnly, Secure और आपके टेनेंट और एप्लिकेशन तक सीमित है।
कॉल की बनावट
ftidHmacV1key_id UUIDv7 ही एकमात्र लोकेटर है; टेनेंट, एप्लिकेशन, एनवायरनमेंट और capabilities कॉन्स्टेंट-टाइम तुलना में वैध MAC के बाद ही अथॉरिटी बनते हैं। X-Client-Id, लेगेसी nonce और कई सिग्नेचर अस्वीकार किए जाते हैं।request_id साइन करता है; अवैध MAC कोई रिज़र्वेशन नहीं बनाता।assessment-unavailable (503, retryable: true), आंशिक स्कोर नहीं।key_id जो मौजूद नहीं, रद्द हो चुका, या गलत सिग्नेचर, सब एक ही authentication-failed देते हैं।key_id मौजूद है या नहीं। नया request_id साइन करें।11 · वर्ज़न वाली पॉलिसी
किसी एक इंडिकेटर की संवेदनशीलता बदलने से नया वर्ज़न बनता है, लेखक, लागू अवधि, सिमुलेशन और रोलबैक के साथ। हिस्ट्री नहीं बदलती। असली वर्ज़न न हो तो उपयोग रुक जाता है।
जिस वर्ज़न ने फ़ैसला किया · withdrawal_completed उदाहरण
policy-withdrawal-v1
correlation_id पर्सनल आइडेंटिफ़ायर उजागर किए बिना सपोर्ट के लिए है। दिखाए गए वर्ज़न अपारदर्शी पब्लिक टैग हैं; इंटरनल डेटाबेस ID कभी API, वेबहुक या कंसोल में नहीं दिखते।
पॉलिसी वर्ज़न क्या फ़्रीज़ करता है
दोहराया जा सकने वाला, कभी दोबारा लिखा नहीं गया
login_completed उदाहरण
assessment_version1
supersedes_assessment_idnull
login_completed_revision_2 उदाहरण
assessment_version2
supersedes_assessment_id…0000000101
ऑपरेशनल रिविज़न इवेंट के received_at पर लागू पॉलिसी और बाकी हर वर्ज़न को बरकरार रखता है। पुराने इवेंट पर नई पॉलिसी एक अलग सिमुलेशन है; वह कभी दोबारा नहीं लिखती कि किस सिफ़ारिश ने ऐतिहासिक फ़ैसले को दिशा दी।
12 · शैडो मोड
शैडो मोड का मतलब है FingerTrackID को उसके साथ-साथ चलाना जो आप आज इस्तेमाल करते हैं, बिना रिस्पॉन्स के किसी फ़ैसले को छुए। आप तुलना करते हैं, असली नतीजे वापस भेजते हैं, और उसके बाद ही सिफ़ारिश का इस्तेमाल शुरू करते हैं। हम इसी तरह शुरू करने की सलाह देते हैं।
पूरा साइकल
SDK कलेक्ट करता है
202 PROCESSING · event_context_token
आपका बैकएंड असेसमेंट माँगता है
POST /v1/assessments · सिंक्रोनस
आप अपने फ़्लो से फ़ैसला लेते हैं
शैडो में, रिस्पॉन्स का इस्तेमाल किए बिना
आप कार्रवाई की रिपोर्ट करते हैं
customer_action · POST …/customer-actions
आप नतीजे की रिपोर्ट करते हैं
truth_status · POST …/outcomes
recommendation_alignment · सर्वर पर सिफ़ारिश × कार्रवाई की जोड़ी से निकाला जाता है; क्लाइंट कभी घोषित नहीं करता। संयोग न कारण साबित करता है, न सटीकता, न फ्रॉड।
तुलना, फ़ील्ड-दर-फ़ील्ड
| recommended_action | customer_action | recommendation_alignment |
|---|---|---|
REVIEW | REVIEWED या HELD | ALIGNED |
STEP_UP | ALLOWED | NOT_ALIGNED |
ALLOW या MONITOR | ALLOWED | ALIGNED |
BLOCK_RECOMMENDED | BLOCKED | ALIGNED |
| कोई भी | CANCELLED | NOT_COMPARABLE |
ब्लॉक करना फ्रॉड साबित नहीं करता। फ्रॉड की पुष्टि के लिए स्वतंत्र सबूत चाहिए: truth_status PENDING से LEGITIMATE, FRAUD_CONFIRMED या INSUFFICIENT_EVIDENCE पर जाता है, maturity PROVISIONAL या MATURE के साथ। सिर्फ़ mature लेबल ही क्वालिटी मेट्रिक बनता है।
साइकल किसे फ़ीड करता है
customer_action और truth_status अलग तथ्य हैं, और हर सुधार एक उत्तराधिकारी बनाता है।13 · कॉन्ट्रैक्ट से प्राइवेसी
क्लियरटेक्स्ट PII प्रोडक्ट की ज़रूरत नहीं है। आप व्यक्ति और अकाउंट के अपारदर्शी ref भेजते हैं; एक्सेस का आकलन करने के लिए हम नेशनल ID, ईमेल या फ़ोन नंबर नहीं माँगते।
packages/contracts/src/sdk-handshake-v1.ts · कलेक्शन पॉलिसी
canvas: z.boolean(),
audio: z.boolean(),
fonts: z.boolean(),
behavioral: z.literal(false),packages/contracts/src/sdk-signals/rendering-v1.ts · अंश
const Hash128 = z.string().regex(/^[0-9a-f]{32}$/)
canvas_hash: Hash128.optional(),
webgl_gpu_family: z.enum(SDK_RENDERING_GPU_FAMILY_V1).optional(),
audio_hash: Hash128.optional(),
fonts_count: z.number().int().min(0).max(SDK_RENDERING_FONT_COUNT_V1).optional(),बिहेवियरल कलेक्शन, यानी पॉइंटर मूवमेंट और कीस्ट्रोक, सिर्फ़ off वैल्यू स्वीकार करता है: इसे चालू करने के लिए कॉन्ट्रैक्ट बदलना पड़ता है, सेटिंग नहीं। Canvas, WebGL, ऑफ़लाइन ऑडियो और फ़ॉन्ट प्रेज़ेंस मैनेज्ड कलेक्शन पॉलिसी के तहत पढ़े जाते हैं, जो इन्हें हर कंपनी के लिए चालू करती है, और ये ब्राउज़र से सिर्फ़ डिराइव्ड वैल्यू के रूप में बाहर जाते हैं: तय लंबाई वाले हैश, एक बंद GPU फ़ैमिली, एक गिनती और तय फ़ॉन्ट लिस्ट पर एक प्रेज़ेंस मास्क। कॉन्ट्रैक्ट में पिक्सल, ऑडियो सैंपल, GPU वेंडर या रेंडरर के नाम, या फ़ॉन्ट के नाम के लिए कोई फ़ील्ड नहीं है। साथ मिलकर ये डिराइव्ड वैल्यू उसी ब्राउज़र को दोबारा पहचान सकती हैं, इसलिए इन्हें डिवाइस डेटा माना जाता है, गुमनाम डेटा नहीं। पूर्ण नियम के रूप में कभी कलेक्ट नहीं किया जाता: पासवर्ड, टाइप किया गया टेक्स्ट, चैट या डॉक्यूमेंट का कंटेंट, क्लिपबोर्ड, स्क्रीनशॉट, माइक्रोफ़ोन, कैमरा। हर सबूत की एक प्राइवेसी क्लास है, और क्लास रिस्क वेट नहीं है।
गारंटियाँ जो नीयत पर निर्भर नहीं
tenant_id होता है, डेटाबेस में फ़ोर्स किए गए आइसोलेशन के साथ। ग्राहकों के बीच कोई साझा रेप्युटेशन या लेबल नहीं है।HttpOnly, Secure, आपके टेनेंट और एप्लिकेशन तक सीमित। वैल्यू कभी डेटाबेस, क्यू या लॉग तक नहीं जाती; अगर वह गायब या अस्वीकृत हो, तो निरंतरता एक limitation के रूप में घटती है और असेसमेंट नहीं रुकता।Party, Account नहीं है
लिंक आपके बैकएंड से आता है · फ़िंगरप्रिंट से कभी अनुमान नहीं लगाया जाता
एक व्यक्ति, कई वैध अकाउंट। कोई अकाउंट कभी चुपचाप व्यक्ति नहीं बदलता; सेशन सिर्फ़ गुमनाम से व्यक्ति और फिर उसी व्यक्ति के अकाउंट तक आगे बढ़ता है। विरोधाभास एक कॉन्फ़्लिक्ट है, नया एसोसिएशन नहीं और न ही गढ़ा हुआ नेगेटिव सबूत।
डेटा कहाँ रहता है
14 · कंसोल
कंसोल पहले इस सवाल का जवाब देता है कि "क्या हम क्वालिटी के साथ रिसीव, असेस और एक्सप्लेन कर रहे हैं?", और उसके बाद ही किसी को वैधता पर बात करने देता है। हर प्रतिशत अपना denominator बताता है।
स्कीमैटिक, स्क्रीनशॉट नहीं · फ़्रेम के अंदर कंसोल के रंग
एक्सेस डिटेल। तीन माप, तीन अलग कंपोनेंट के रूप में; सिफ़ारिश अपने recommendation_basis के साथ, लागू पॉलिसी और आपकी टीम ने जो किया उसकी रिपोर्ट; सबूत की ताज़गी; 13 इंडिकेटर स्थिति, लागू होने, सोर्स, डिटेक्टर कॉन्फ़िडेंस, ताज़गी और किसी भी not evaluated की वजह के साथ; limitation और reason code; सेशन, डिवाइस और उनके एसोसिएशन; डिवाइस पर मल्टीप्लिसिटी; नेटवर्क से अनुमानित लोकेशन; एक्सेस कॉन्टेक्स्ट; और एक टेक्निकल डेटा टैब जिसमें SDK और edge ने जो कुछ कलेक्ट किया वह सब है, जिसमें ब्राउज़र के एक्सपोज़ किए API से पढ़ा गया असली ब्राउज़र वर्ज़न भी है, उसके घोषित वर्ज़न के बगल में।
जाँच के फ़िल्टर। एक्सेस लिस्ट को इंटरनेट प्रोवाइडर (ASN), नेटवर्क के देश, डिवाइस इंस्टॉलेशन, इंडिकेटर के not evaluated रहने की वजह, और एक साथ चुनी हुई स्थितियों में अधिकतम दो इंडिकेटर से छाँटा जा सकता है, और यह आपके अपने अकाउंट या व्यक्ति ref से कोई एक्सेस ढूँढ लेती है। IP एड्रेस से कोई फ़िल्टर नहीं है: वह पर्सनल डेटा है। हर एक्सेस डिटेल में उसकी कॉन्टेक्स्ट इनसाइट ↑ भी होती हैं।
गहराई से जाँच करें। किसी भी एक्सेस से, एक लिंक ग्राफ़ उसके आसपास के डिवाइस और अकाउंट खोलता है, एक बार में एक हॉप, आपकी अपनी हिस्ट्री के 92 दिनों तक। हर विस्तार एक रिकॉर्ड किया गया रीड है; IP एड्रेस कभी नोड नहीं बनते।
ब्लॉक और अलाउ लिस्ट। एक्सेस डिटेल से, आपकी टीम किसी डिवाइस, अकाउंट ref या एक IP को आपकी कंपनी की ब्लॉक लिस्ट (block या review) या अलाउ लिस्ट में डालती है, एक नोट और जोड़ने वाले के नाम के साथ। स्कोर वाले प्रोडक्शन एक्सेस पर, एंट्री सिफ़ारिश को ओवरराइड करती है और reason_codes में अपना नाम दर्ज करती है। कुछ भी डिलीट नहीं होता: एंट्री हटाने पर रिकॉर्ड होता है कि किसने और कब हटाई।
AI असिस्टेंट। एक साइड पैनल हर स्क्रीन समझाता है और आपके अपने इंटीग्रेशन और एक्सेस के बारे में सवालों के जवाब देता है, आपकी कंपनी और आपके रोल के दायरे में।
रिस्क कॉन्फ़िगरेशन। हर एप्लिकेशन के लिए आपकी कंपनी के अपने रिस्क नियम: 13 इंडिकेटर में से हर एक off, ghost या active है, 1 से 100 पॉइंट के वेट के साथ, और आप स्कोर बैंड और हर बैंड की कार्रवाई तय करते हैं। ghost नियम कैलकुलेट और रिकॉर्ड होता है लेकिन रिस्पॉन्स कभी नहीं बदलता। पब्लिश करने से पहले, इम्पैक्ट कार्ड आपके ड्राफ़्ट को पिछले 1, 7 या 30 दिनों के असेसमेंट पर दोबारा चलाता है। 54 कॉन्टेक्स्ट इनसाइट ↑ में से हर एक अपने पॉइंट के साथ इनमें जुड़ सकती है। आपका एडमिनिस्ट्रेटर या रिस्क सुपरवाइज़र सीधे पब्लिश करता है; हर पब्लिकेशन एक नया ऑडिट किया हुआ वर्ज़न है, और सब कुछ ghost में आपके सभी नियम एक साथ रोक देता है। FingerTrackID कभी आपके लिए कोई नियम active नहीं करता: उसका सपोर्ट सिर्फ़ किसी एप्लिकेशन के हर नियम को ghost में डाल सकता है, एक वजह के साथ जो आपका कंसोल दिखाता है। जब तक कोई नियम active नहीं होता, मैनेज्ड पॉलिसी जवाब देती है, जिसे FingerTrackID टीम रिकॉर्ड की गई मंज़ूरी के साथ पब्लिश करती है।
चार ग्रुप में सोलह स्क्रीन · मुख्य, डिटेक्शन, ऑपरेशन, एडमिनिस्ट्रेशन
रिव्यू क्यू निकासी रिव्यू मॉड्यूल है: उसी कोर पर बनी एक ऑपरेशनल क्यू, जो REVIEW के लिए सुझाई गई हर v1 निकासी को सबूत के साथ एक व्यक्ति तक पहुँचाती है। टैग वाले असेसमेंट इसमें कभी नहीं आते, और जब तक पॉलिसी MONITOR की सिफ़ारिश करती है, यह खाली रहती है, जैसा आज मैनेज्ड पॉलिसी करती है।
अंग्रेज़ी, पुर्तगाली (ब्राज़ील और पुर्तगाल), स्पेनिश, फ़्रेंच और जर्मन में। passkey या दूसरे फ़ैक्टर से साइन-इन; रोल के हिसाब से परमिशन; इसका ऑडिट ट्रेल कि संवेदनशील डेटा किसने देखा और किसने क्या बदला। रॉ डेटा खुलेआम नहीं दिखता: उस तक हर एक्सेस रिकॉर्ड होता है।
15 · हम कैसे चार्ज करते हैं
पूरे हुए कलेक्शन के वॉल्यूम के हिसाब से कीमत, प्रपोज़ल में तय। शैडो मोड भी वही यूनिट इस्तेमाल करता है और कंसोल में अनुमानित उपयोग के रूप में दिखता है; उस अवधि के इनवॉइस में क्या जाएगा, यह प्रपोज़ल में तय होता है।
यूनिट
यह माप की यूनिट और संभावित बिलिंग यूनिट है। हर device_intelligence_snapshot_id अधिकतम एक यूनिट बनाता है, चाहे उस कलेक्शन को कितने भी असेसमेंट, टैग, प्रोवाइडर या रीप्रोसेसिंग इस्तेमाल करें।
इवेंट · क्या यूनिट बनती है?
idempotency_key के साथ retryनहींcustomer_action और आउटकमनहीं4xxनहीं5xx, हमारी तरफ़ टाइमआउट, कलेक्शन INCONCLUSIVE या FAILEDनहींवॉल्यूम के हिसाब से प्रपोज़ल, शैडो मोड के उपयोग के साथ।
प्रपोज़ल माँगें16 · FAQ
customer_action और आउटकम वापस भेजते हैं, और कंसोल में एक्सेस-दर-एक्सेस सिफ़ारिश की तुलना उससे करते हैं जो आपकी टीम ने किया, और एविडेंस कवरेज पर नज़र रखते हैं। जब आँकड़े सही बैठते हैं, आपकी टीम तय करती है कि सिफ़ारिश किसी फ़ैसले पर असर डालना शुरू करे या नहीं और कहाँ, जिसे हमेशा आपका बैकएंड लागू करता है।tag भेजता है, एक lowercase slug जैसे login, withdrawal या pix_transfer: कोई रजिस्ट्रेशन नहीं, कोई बंद लिस्ट नहीं और कोई लिमिट नहीं। कंसोल टैग के हिसाब से फ़िल्टर, ग्रुप और एक्सपोर्ट करता है, और टेम्पलेट (साइनअप, लॉगिन, पासवर्ड रिकवरी, दूसरा फ़ैक्टर, प्रोफ़ाइल बदलाव, डिपॉज़िट, निकासी, Pix ट्रांसफ़र, ट्रेड, चेकआउट) एक इंटीग्रेशन गाइड हैं। टैग कभी पॉलिसी, डिटेक्टर, fallback या डेडलाइन नहीं चुनता: हर टैग वाला असेसमेंट उसी पॉलिसी और उन्हीं 13 इंडिकेटर के तहत चलता है। इसमें कभी पर्सनल डेटा नहीं होना चाहिए। रिक्वेस्ट में कोई राशि, करेंसी या बेनिफ़िशियरी नहीं होता।BLOCK_RECOMMENDED सबसे मज़बूत सिफ़ारिश है, और फिर भी यह एक सिफ़ारिश ही है। जब आप ब्लॉक करते हैं, तो आप customer_action: BLOCKED रिकॉर्ड करते हैं, और वह यह मापने का डेटा बनता है कि सिफ़ारिश सही थी या नहीं।BLOCK_RECOMMENDED नहीं बनाता; आपकी कंपनी के बनाए नियम उसके चुने हुए वेट और कटऑफ़ पर चलते हैं। प्राइवेट मोड और ब्राउज़र सुरक्षाएँ न्यूट्रल कॉन्टेक्स्ट हैं: ये कवरेज घटा सकती हैं और डिटेल में दिखती हैं, बिना किसी प्रतिकूल reason code के। Tor, प्रॉक्सी, VPN और होस्टिंग गुमनामी का कॉन्टेक्स्ट हैं: पॉलिसी इन्हें बाकी देखी गई चीज़ों के साथ वेट दे सकती है, टैग के हिसाब से कभी नहीं। आज मैनेज्ड पॉलिसी में सिर्फ़ ऑटोमेशन और ब्राउज़र स्पूफ़िंग स्कोर बदलते हैं, और सिफ़ारिश MONITOR है। इस पेज के v1 निकासी कॉन्ट्रैक्ट उदाहरण में, detected Tor से REVIEW हुआ, और reason code यही बताता है। यह अपने-आप में कभी फ्रॉड नहीं है।event_context_token के बिना API कॉल करता है और INCONCLUSIVE, trust_score: null, evidence_coverage: 0, limitation_codes: ["COLLECTOR_NOT_LOADED"] और fallback सिफ़ारिश MONITOR पाता है। कभी गढ़ा हुआ स्कोर नहीं। सबूत की कमी पर कभी ALLOW नहीं।deadline_ms इसे 250 से 5000 के बीच कहीं भी सेट करता है (डिफ़ॉल्ट के लिए अपना HTTP टाइमआउट लगभग 6 s से ऊपर रखें); इसके पार होने पर आपको Problem assessment-unavailable (503, retryable: true, Retry-After के साथ) मिलता है, आंशिक रिस्पॉन्स नहीं। उसी लॉजिकल ऑपरेशन को नए request_id के साथ दोहराएँ। लेटेंसी और SLA प्रपोज़ल में जाते हैं, आपके शैडो मोड में मापे गए, इससे पहले कि कोई फ़ैसला रिस्पॉन्स पर निर्भर हो।key_id UUIDv7 ही एकमात्र पब्लिक लोकेटर है; request_id replay के ख़िलाफ़ रिज़र्व होता है; ऑथेंटिकेशन फ़ेल होने पर एक समान 401 लौटता है, यह बताए बिना कि key मौजूद है या नहीं। सीक्रेट कभी ट्रैवल नहीं करता। प्रोटोकॉल का नॉर्मेटिव टेस्ट वेक्टर कॉन्ट्रैक्ट का हिस्सा है; इससे आप सिग्नेचर को बाइट-दर-बाइट दोहरा सकते हैं।@fingertrackid/server कॉल साइन करता है, MCP सर्वर @fingertrackid/mcp Claude Code, Cursor या किसी भी MCP-सक्षम एजेंट को कॉन्ट्रैक्ट, सिग्नेचर वेक्टर, हर टैग के लिए तैयार सर्वर मॉड्यूल और आपके कलेक्शन डोमेन की जाँच देता है, सब read-only, और डॉक्यूमेंटेशन llms.txt और आपके AGENTS.md के लिए नियमों का तैयार ब्लॉक प्रकाशित करता है। सीक्रेट आपके एनवायरनमेंट में रहता है; एजेंट को इसे कभी देखने की ज़रूरत नहीं।17 · संपर्क
शैडो मोड में शुरू करें: रिस्पॉन्स आपके असली फ़्लो के साथ-साथ चलता है, किसी फ़ैसले को छुए बिना, आप तुलना करते हैं, नतीजे वापस भेजते हैं, और उसके बाद ही सिफ़ारिश का इस्तेमाल शुरू करते हैं। अगर आपके पास ऐसी स्क्रीन हैं जहाँ फ़ैसला मायने रखता है और आप भरोसा करने से पहले समझाया हुआ रिस्पॉन्स देखना चाहते हैं, तो हमसे बात करें।
डेमो बुक करें
शुरुआत कैसे होती है
साथ में क्या मिलता है
event-assessment.v1 कॉन्ट्रैक्ट, HMAC टेस्ट वेक्टर के साथ