> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# चेहरा खोज 1:N API: डुप्लिकेट का पता लगाना

> Didit पहचान सत्यापन के साथ डुप्लिकेट व ब्लॉकलिस्टेड जालसाजों का पता लगाने के लिए चेहरा खोजें। सब-2-सेकंड रिस्पॉन्स, निःशुल्क।

चेहरा खोज एक शक्तिशाली सुविधा है जो आपको अपने सभी स्वीकृत पहचान सत्यापन सत्रों में किसी विशिष्ट चेहरे को खोजने की अनुमति देती है। यह क्षमता डुप्लिकेट खातों की पहचान करने, धोखाधड़ी को रोकने और आपके सुरक्षा उपायों को बेहतर बनाने में मदद करती है।

चेहरा खोज इंटीग्रेशन प्रॉम्प्ट
        प्रॉम्प्ट को क्लिपबोर्ड पर कॉपी करें



      
      

\<pre>

\````# Goal
Integrate Didit Face Search (1:N — search a face across your enrolled users + blocklist) into your app.

\# Delivery mode
Face Search is a **standalone API**. It runs against the face index your application has enrolled through prior verifications (sessions with save_api_request=true or Passive Liveness with save_api_request=true), faces uploaded to User profiles, your face lists, and any image-free biometric templates the application retained after deleting sessions (opt-in, see /management-api/biometric-templates/overview). There is no separate Face Search workflow feature.

POST https://verification.didit.me/v3/face-search/
multipart/form-data — x-api-key: YOUR_API_KEY

Required: `user_image` (jpg/jpeg/png/tiff/webp, max 5 MB; PDFs not accepted). The image must contain at least one detectable face (largest bbox wins when multiple).

Optional: `search_type` = "most_similar" (default — dedupe / returning-user) | "blocklisted_or_approved" (blocklist screening).

curl example:
\```bash
curl -X POST 'https://verification.didit.me/v3/face-search/' \
-H 'x-api-key: YOUR_API_KEY' \
-F 'user_image=@./selfie.jpg' \
-F 'search_type=most_similar' \
-F 'save_api_request=true' \
-F 'vendor_data=user-123'
\```

\# Response shape (singular)
Unlike most features, Face Search returns a **singular** `face_search` object — not a plural array:
\{ request_id, face_search: { status, total_matches, matches: [{ session_id, session_number, similarity_percentage, source, vendor_data, vendor_user_id, biometric_template_id, verification_date, user_details, match_image_url, status, is_blocklisted, is_allowlisted, api_service }], user_image: {entities}, warnings: [...] } }

match.source is "session", "imported", "list_entry", or "retained_template". A retained_template hit comes from an image-free biometric template kept after the source session was deleted: session_id, session_number, status, api_service, match_image_url, and user_details are null; vendor_data and vendor_user_id identify the User; biometric_template_id is the template you can inspect or purge via /v3/biometric-templates/{id}/.

\`status` is "Declined" only when at least one blocklist match is found. Pure duplicate matches return "Approved" (informational) — apply your own dedupe policy in app logic.

\# Warnings
Face Search emits risk codes from the LogWarningChoices.FACEMATCH bucket plus blocklist/duplicate semantics:
FACE_IN_BLOCKLIST, POSSIBLE_FACE_IN_BLOCKLIST, DUPLICATED_FACE, POSSIBLE_DUPLICATED_FACE, MULTIPLE_FACES_DETECTED.
Full catalogue: /core-technology/face-search/warnings-face-search.

\# Failure modes to handle
\- HTTP 400 — no face detected in user_image. Ask the user to retake.
\- HTTP 403 — out of credits.
\- status="Declined" with FACE_IN_BLOCKLIST — definitive blocklist hit; reject.
\- POSSIBLE_FACE_IN_BLOCKLIST — borderline match below the hard threshold; route to manual review.
\- DUPLICATED_FACE — user already verified under a different vendor_data; merge or block according to policy.

\# See also
\- Canonical schema: /reference/data-models#face-search
\- Per-feature report: /core-technology/face-search/report-face-search
\- Risk catalogue: /core-technology/face-search/warnings-face-search
\- Full integration playbook: /integration/integration-prompt````

\</pre>



      
      

यहाँ पेस्ट करें

सत्यापन परिणाम पढ़ने वाले Academy के पाठ में 6:53 पर चेहरा खोज और ब्लॉकलिस्ट का भाग आता है।[चेहरा खोज और ब्लॉकलिस्ट — Didit Academy](https://www.youtube.com/embed/7htTWCWsl60?start=413\&rel=0\&playsinline=1)![डुप्लिकेट और ब्लॉकलिस्ट का पता लगाने के लिए लाइवनेस के साथ एकीकृत Didit चेहरा खोज 1:N फ़्लो](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/face-search-liveness.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=0cb5738f8ceaae7891cf13631485c400)## स्वचालित चेहरा खोज इंटीग्रेशन> सत्यापन सत्रों में डुप्लिकेट उपयोगकर्ताओं का पता लगाने और ब्लॉकलिस्ट किए गए चेहरों के विरुद्ध जाँच करने के लिए लाइवनेस जाँच के दौरान चेहरा खोज स्वचालित रूप से की जाती है।### स्वचालित डुप्लिकेट डिटेक्शनजब कोई उपयोगकर्ता पहचान सत्यापन के दौरान लाइवनेस जाँच पूरी करता है:- उनके फेशियल बायोमेट्रिक्स की तुलना पहले से सत्यापित सभी उपयोगकर्ताओं से स्वचालित रूप से की जाती है
- सिस्टम चेहरे की समानता के आधार पर संभावित डुप्लिकेट खातों की पहचान करता है
- आपके कॉन्फ़िगर किए गए समानता थ्रेशोल्ड के अनुसार मिलानों को फ़्लैग किया जाता है
- आप संभावित डुप्लिकेट उपयोगकर्ताओं की समीक्षा कर सकते हैं और उन पर कार्रवाई कर सकते हैं### ब्लॉकलिस्ट इंटीग्रेशनचेहरा खोज [ब्लॉकलिस्ट सुविधा](https://docs.didit.me/hi/management-api/lists/overview.md) के साथ निर्बाध रूप से एकीकृत होती है:- सत्यापन के दौरान, आपकी ब्लॉकलिस्ट के विरुद्ध चेहरों की स्वचालित रूप से जाँच की जाती है
- यदि ब्लॉकलिस्ट किए गए चेहरे से कोई मिलान मिलता है, तो सत्यापन स्वचालित रूप से अस्वीकृत हो जाता है
- यह पहले से पहचाने गए समस्याग्रस्त उपयोगकर्ताओं को नए खाते बनाने से रोकता है
- आपकी सत्यापन प्रक्रिया की अखंडता बनाए रखने में मदद करता है### दस्तावेज़ कैप्चर के दौरान ली गई सेल्फ़ीजब उपयोगकर्ता अपने दस्तावेज़ की फ़ोटो लेता है, तो फ्रंट कैमरा उनकी एक सेल्फ़ी लेता है (साइलेंट कैप्चर)। हर बार जब दस्तावेज़ का मूल्यांकन किया जाता है, तो वह सेल्फ़ी लाइवनेस सेल्फ़ी की तरह ही 1:N खोज से गुजरती है:- इसकी तुलना आपकी फ़ेस ब्लॉकलिस्ट और आपके एप्लिकेशन में पहले से स्वीकृत उपयोगकर्ताओं से की जाती है, जिसमें लाइवनेस खोज के समान ही समानता थ्रेशोल्ड और समान प्राथमिकता होती है।
- ब्लॉकलिस्ट मिलान होने पर `FRONT_CAMERA_FACE_IN_BLOCKLIST` (हमेशा Declined) या `POSSIBLE_FRONT_CAMERA_FACE_IN_BLOCKLIST` (हमेशा Review) उत्पन्न होता है। किसी स्वीकृत उपयोगकर्ता के साथ मिलान होने पर `FRONT_CAMERA_DUPLICATED_FACE` या `POSSIBLE_FRONT_CAMERA_DUPLICATED_FACE` उत्पन्न होता है, साथ ही जब उस स्वीकृत उपयोगकर्ता को किसी भिन्न नाम के तहत सत्यापित किया गया था तो `FRONT_CAMERA_DUPLICATED_FACE_NAME_MISMATCH`, और जब उस उपयोगकर्ता का पहचान दस्तावेज़ एक अलग जन्म तिथि दिखाता है तो `FRONT_CAMERA_DUPLICATED_FACE_DOCUMENT_MISMATCH` उत्पन्न होता है। [पहचान सत्यापन चेतावनियाँ](https://docs.didit.me/hi/core-technology/id-verification/warnings-id-verification.md) देखें।
- मिलानों को सत्र विवरण में, पहचान सत्यापन कार्ड में सूचीबद्ध किया जाता है, और [सत्र निर्णय](https://docs.didit.me/hi/sessions-api/retrieve-session.md) के `id_verifications[].document_selfie_face_matches` में लौटाया जाता है। यह `liveness_checks[].matches` के समान प्रविष्टि प्रारूप का उपयोग करता है। पुराने सत्रों के लिए या जब खोज नहीं चली थी, तो यह फ़ील्ड `null` होती है, और जब यह चली और कुछ नहीं मिला, तो यह एक खाली ऐरे होती है। `match_image_url` एक प्रीसाइन्ड URL है जिसकी समय-सीमा समाप्त हो जाती है।
- सेल्फ़ी में केवल सबसे बड़े चेहरे का उपयोग किया जाता है, और केवल तभी जब डिटेक्टर आश्वस्त हो कि यह एक चेहरा है। प्रति दस्तावेज़ एक सेल्फ़ी खोजी जाती है: सामने की तरफ़ वाली सेल्फ़ी, या पीछे की तरफ़ वाली सेल्फ़ी जब सामने की सेल्फ़ी में कोई स्पष्ट चेहरा नहीं होता है।
- सेल्फ़ी की केवल तुलना की जाती है। इसका बायोमेट्रिक टेम्पलेट कभी संग्रहीत नहीं किया जाता है, इसलिए बाद के सत्रों का इससे कभी मिलान नहीं किया जाता है। किसी सत्र की सेल्फ़ी से किसी व्यक्ति को प्रतिबंधित करने के लिए, उसे सत्र पेज से अपनी फ़ेस ब्लॉकलिस्ट में जोड़ें।इस खोज का अपना स्विच और अपनी कार्रवाइयाँ **पहचान सत्यापन** चरण पर, चरण के **नियम** टैब (**साइलेंट कैप्चर चेहरा खोज**) में, या [वर्कफ़्लो सुविधा कॉन्फ़िग](https://docs.didit.me/hi/management-api/workflows/feature-configs.md#ocr-/-पहचान-सत्यापन) में `document_selfie_face_search_enabled` और `document_selfie_duplicated_face_*` कार्रवाइयों के साथ उपलब्ध हैं। यह डिफ़ॉल्ट रूप से चालू होती है; डुप्लिकेट-चेहरा कार्रवाई डिफ़ॉल्ट रूप से Approve (चेतावनी अभी भी रिपोर्ट की जाती है) पर सेट होती है और नाम व दस्तावेज़ क्रॉस-चेक डिफ़ॉल्ट रूप से Review पर सेट होते हैं, ठीक उनके लाइवनेस समकक्षों की तरह। इस खोज को सेल्फ़ी की आवश्यकता होती है, इसलिए यह केवल तभी चलती है जब साइलेंट कैप्चर चालू हो। लाइवनेस चरण पर चेहरा खोज को बंद करने से यह खोज भी बंद हो जाती है: वह ऑप्ट-आउट व्यक्ति के चेहरे के बारे में एक विकल्प है, इसलिए यह सत्र की प्रत्येक सेल्फ़ी को कवर करता है।### दस्तावेज़ बेमेल नियम**दस्तावेज़ बेमेल** नियम (लाइवनेस सेल्फ़ी के लिए `DUPLICATED_FACE_DOCUMENT_MISMATCH`, साइलेंट कैप्चर के लिए `FRONT_CAMERA_DUPLICATED_FACE_DOCUMENT_MISMATCH`) किसी डुप्लिकेट चेहरे को केवल तभी फ़्लैग करता है जब मिलान किए गए उपयोगकर्ता का पहचान दस्तावेज़ एक अलग जन्म तिथि दिखाता है।
एक ही व्यक्ति द्वारा भिन्न दस्तावेज़ प्रस्तुत करना, उदाहरण के लिए ID कार्ड के बाद पासपोर्ट, फ़्लैग नहीं किया जाता है।
नवीनीकृत दस्तावेज़ को भी फ़्लैग नहीं किया जाता है।
एक ही देश के एक ही दस्तावेज़ नंबर को साझा करने वाले दो सत्र कभी भी फ़्लैग नहीं किए जाते हैं।### स्वचालित चेहरा खोज को बंद करनाप्रत्येक लाइवनेस चरण के लिए स्वचालित चेहरा खोज डिफ़ॉल्ट रूप से चालू होती है। यदि आपकी गोपनीयता नीति इसकी मांग करती है, तो आप इसे Business Console (सरल और उन्नत मोड) में **लाइवनेस जाँच** चरण के **नियम** टैब से प्रति वर्कफ़्लो बंद कर सकते हैं, या [वर्कफ़्लो सुविधा कॉन्फ़िग](https://docs.didit.me/hi/management-api/workflows/feature-configs.md#लाइवनेस) में `LIVENESS` या `AGE_ESTIMATION` नोड पर `face_search_enabled: false` के साथ बंद कर सकते हैं।स्विच बंद होने पर भी, लाइवनेस सेल्फ़ी को लाइवनेस के लिए स्कोर किया जाता है और चेहरा मिलान में दस्तावेज़ पोर्ट्रेट के विरुद्ध 1:1 तुलना की जाती है, लेकिन यह कभी भी फ़ेस इंडेक्स तक नहीं पहुंचती है:- कोई खोज नहीं चलती है, इसलिए सत्र को कोई डुप्लिकेट, ब्लॉकलिस्ट या अलाउलिस्ट निर्णय नहीं मिलता है और इसका `liveness_checks[].matches` खाली रहता है। **डुप्लिकेट चेहरा**, **नाम बेमेल**, **दस्तावेज़ बेमेल** और क्रॉस-संगठन चेहरा नियमों के पास कार्रवाई करने के लिए कुछ नहीं होता है और वे कंसोल में छिपे होते हैं।
- सेल्फ़ी के लिए कोई बायोमेट्रिक टेम्पलेट संग्रहीत नहीं किया जाता है, इसलिए बाद के सत्रों का इस सत्र से मिलान नहीं किया जा सकता है और सत्र हटाए जाने के बाद [बायोमेट्रिक-टेम्पलेट प्रतिधारण](https://docs.didit.me/hi/console/data-retention.md#बायोमेट्रिक-टेम्पलेट-प्रतिधारण) के लिए रखने के लिए कुछ नहीं होता है।
- क्रॉस-संगठन जाँच के लिए साझा बायोमेट्रिक व्यक्ति की पहचान निर्धारित करने के लिए सेल्फ़ी का उपयोग नहीं किया जाता है।
- दस्तावेज़ कैप्चर के दौरान ली गई सेल्फ़ी में भी खोज नहीं की जाती है (कोई `FRONT_CAMERA_*` ब्लॉकलिस्ट या डुप्लिकेट जोखिम नहीं): ऑप्ट-आउट सत्र की प्रत्येक सेल्फ़ी को कवर करता है। पहचान सत्यापन चरण का अपना स्विच (ऊपर देखें) भी अपने दम पर उस खोज को बंद कर सकता है।**स्विच किस चरण से संबंधित है।** स्विच उस चरण पर स्थित होता है जो सेल्फ़ी कैप्चर करता है, इसलिए **लाइवनेस जाँच** या **आयु अनुमान** चरण स्वयं इसके लिए उत्तरदायी होता है। **चेहरा मिलान** चरण का अपना कोई स्विच नहीं होता है: जब कोई उपयोगकर्ता वहां सेल्फ़ी दोबारा लेता है - उदाहरण के लिए, आपके द्वारा उस चरण को फिर से सबमिट करने के लिए कहने के बाद - तो दोबारा ली गई सेल्फ़ी लाइवनेस चरण की सेटिंग का पालन करती है, इसलिए एक ऑप्ट-आउट नई सेल्फ़ी को भी इंडेक्स से बाहर रखता है। यदि आपका वर्कफ़्लो एक से अधिक लाइवनेस चरणों में विभाजित होता है, तो जो सेटिंग लागू होती है वह उस शाखा की होती है जिससे सत्र वास्तव में गुजरा था, और क्रॉस-संगठन चेहरे की जाँच उसी चरण का पालन करती है।मौजूदा वर्कफ़्लो तब तक वर्तमान व्यवहार बनाए रखते हैं जब तक कि आप ऑप्ट आउट नहीं करते। यह बदलाव वर्कफ़्लो सहेजे जाने के बाद शुरू किए गए सत्रों पर लागू होता है; पहले के सत्रों द्वारा संग्रहीत टेम्पलेट तब तक इंडेक्स में बने रहते हैं जब तक कि वे सत्र हटाए (डिलीट) या पर्ज नहीं कर दिए जाते। यह स्विच स्टैंडअलोन [चेहरा खोज API](https://docs.didit.me/hi/standalone-apis/face-search.md) को प्रभावित नहीं करता है, जिसे आप स्पष्ट रूप से कॉल करते हैं।> [!WARNING]
>
> आपकी चेहरा ब्लॉकलिस्ट उसी 1:N खोज द्वारा सत्यापन के दौरान लागू की जाती है। लाइवनेस डिटेक्शन चरण पर चेहरा खोज बंद होने पर, ब्लॉकलिस्ट किया गया व्यक्ति न तो उस चरण में पकड़ा जाता है और न ही दस्तावेज़ कैप्चर के दौरान ली गई सेल्फ़ी द्वारा; पहचान सत्यापन चरण पर Silent Capture चेहरा खोज बंद होने पर, उस सेल्फ़ी द्वारा नहीं पकड़ा जाता है।### API एक्सेसचेहरा खोज कार्यक्षमता हमारे [API](https://docs.didit.me/hi/standalone-apis/face-search.md) के माध्यम से भी उपलब्ध है, जो आपको इसकी अनुमति देती है:- प्रोग्रामेटिक रूप से चेहरे की खोज सबमिट करें
- अपने स्वयं के एप्लिकेशन्स में चेहरा मिलान क्षमताओं को एकीकृत करें
- कस्टम धोखाधड़ी का पता लगाने वाले वर्कफ़्लो बनाएं
- डुप्लिकेट का पता लगाने के लिए स्वचालित सिस्टम बनाएं## मुख्य विशेषताएँ- **उच्च सटीकता**: उन्नत बायोमेट्रिक एल्गोरिदम विश्वसनीय मिलान परिणाम प्रदान करते हैं
- **कॉन्फ़िगर करने योग्य थ्रेशोल्ड**: अपनी जोखिम सहनशीलता के आधार पर मिलान संवेदनशीलता को कस्टमाइज़ करें
- **व्यापक स्कैनिंग**: अपने सभी सत्यापित उपयोगकर्ताओं में खोजें
- **त्वरित परिणाम**: बड़े उपयोगकर्ता डेटाबेस के साथ भी खोजों को तेज़ी से प्रोसेस करें
- **गोपनीयता-केंद्रित**: मिलान आपके एप्लिकेशन के दायरे में सीमित संख्यात्मक फ़ेस टेम्पलेट्स का उपयोग करता है; इंडेक्स कभी भी आपके टेनेंट से बाहर नहीं जाता है### कॉन्फ़िगर करने योग्य थ्रेशोल्डआप समानता स्कोर के लिए अलग-अलग थ्रेशोल्ड सेट करके खोज संवेदनशीलता को कस्टमाइज़ कर सकते हैं:> [!NOTE]
>
> इन थ्रेशोल्ड को आपकी जोखिम सहनशीलता और सुरक्षा आवश्यकताओं के आधार पर समायोजित किया जा सकता है।## यह कैसे काम करता है**1. चेहरा निष्कर्षण**जब कोई खोज शुरू की जाती है, तो सिस्टम संदर्भ छवि को प्रोसेस करता है:| प्रोसेस | विवरण |
| - | - |
| **फ़ीचर निष्कर्षण** | संदर्भ छवि से चेहरे की विशेषताओं को अलग करता है |
| **मानकीकरण** | सुसंगत तुलना के लिए चेहरे के डेटा को मानकीकृत करता है |
| **गुणवत्ता सत्यापन** | छवि गुणवत्ता और चेहरे की स्पष्टता की जांच करता है |
| **वेक्टर एन्कोडिंग** | चेहरे का एक गणितीय वेक्टर प्रतिनिधित्व बनाता है |**2. तुलना एल्गोरिदम**सिस्टम आपके सत्यापित सत्रों के पूरे डेटाबेस में खोज करता है:- संदर्भ फ़ेशियल वेक्टर की तुलना **आपके एप्लिकेशन में नामांकित प्रत्येक चेहरे** से करता है: सत्र के चेहरे, उपयोगकर्ता प्रोफ़ाइल पर अपलोड किए गए चेहरे, आपकी चेहरा सूचियाँ, और कोई भी बनाए रखा गया बायोमेट्रिक टेम्पलेट
- गति और सटीकता के लिए अनुकूलित उन्नत न्यूरल नेटवर्क आर्किटेक्चर का उपयोग करता है
- दो खोज मोड का समर्थन करता है: **सर्वाधिक समान** (रैंक की गई सूची) और **ब्लॉकलिस्टेड या स्वीकृत** (स्थिति के आधार पर फ़िल्टर की गई)
- अनुकूलित इंडेक्सिंग का उपयोग करके बड़े डेटाबेस को तेज़ी से प्रोसेस करता है**3. समानता स्कोरिंग**प्रत्येक तुलना के लिए, एक समानता प्रतिशत जनरेट किया जाता है:| स्कोर रेंज | व्याख्या |
| :-: | - |
| **90%+** | मज़बूत मिलान — अत्यधिक संभावना है कि वही व्यक्ति है |
| **70–89%** | संभावित मिलान — मैन्युअल समीक्षा की आवश्यकता हो सकती है |
| **70% से कम** | संभवतः अलग-अलग व्यक्ति |आपके कॉन्फ़िगर किए गए मिलान थ्रेशोल्ड यह निर्धारित करते हैं कि किन परिणामों को फ़्लैग किया जाए।**4. परिणाम डिलीवरी**सिस्टम एक व्यापक परिणाम सेट लौटाता है:- समानता स्कोर के आधार पर क्रमित संभावित मिलानों की **रैंक की गई सूची**
- सत्र ID, सत्यापन तिथि और वेंडर डेटा सहित **मिलान विवरण**
- प्रत्येक मिलान के लिए **समानता प्रतिशत**
- विज़ुअल समीक्षा के लिए उपलब्ध **मिलान छवियां**
- **ब्लॉकलिस्ट स्थिति** जो दर्शाती है कि क्या मिलान किया गया चेहरा ब्लॉकलिस्टेड है## हटाए गए सत्र और बनाए रखे गए बायोमेट्रिक टेम्पलेटसत्र को हटाने से डिफ़ॉल्ट रूप से उसका फ़ेस एम्बेडिंग हट जाता है, इसलिए वह व्यक्ति इंडेक्स से बाहर हो जाता है और बिना डुप्लिकेट फ़्लैग के फिर से सत्यापित कर सकता है। ऐसे एप्लिकेशन्स जो स्वीकृति के तुरंत बाद सत्रों को हटा देते हैं लेकिन फिर भी बार-बार साइन-अप पकड़ने की आवश्यकता होती है, वे [बायोमेट्रिक-टेम्पलेट प्रतिधारण](https://docs.didit.me/hi/console/data-retention.md#बायोमेट्रिक-टेम्पलेट-प्रतिधारण) सक्षम कर सकते हैं। Didit तब सत्र हटाए जाने के बाद उपयोगकर्ता से जुड़े एक छवि-मुक्त बायोमेट्रिक टेम्पलेट को बनाए रखता है, और वह टेम्पलेट बिल्कुल एक लाइव सत्र के चेहरे की तरह चेहरा खोज और स्वचालित डुप्लिकेट पहचान में भाग लेता है।बनाए रखे गए टेम्पलेट पर हिट की रिपोर्ट `source: "retained_template"`, उस उपयोगकर्ता के `vendor_user_id` और `vendor_data`, और एक `biometric_template_id` के साथ दी जाती है। इसमें कोई सत्र ID, मिलान छवि, पहचान विवरण, या सत्र स्थिति नहीं होती है, क्योंकि जिस सत्र से यह चेहरा प्राप्त हुआ था वह अब मौजूद नहीं है। बनाए रखे गए टेम्पलेट कभी भी ब्लॉकलिस्ट नहीं किए जाते हैं; चेहरा ब्लॉकलिस्ट प्रविष्टियाँ अपनी स्वतंत्र बायोमेट्रिक प्रविष्टि रखती हैं।टेम्पलेट अपनी निर्धारित समाप्ति तिथि, उपयोगकर्ता को हटाए जाने, गोपनीयता संबंधी डेटा मिटाने का अनुरोध, या [Biometric Templates API](https://docs.didit.me/hi/management-api/biometric-templates/overview.md) या कंसोल में **Lists → Biometric templates** के माध्यम से स्पष्ट रूप से पर्ज किए जाने तक बना रहता है।## समानता प्रतिशतसमानता प्रतिशत संभावित मिलानों को निर्धारित करने के लिए उपयोग किया जाने वाला मुख्य मीट्रिक है:- **उच्च प्रतिशत (आमतौर पर 90% और अधिक)**: एक मज़बूत संभावना को इंगित करता है कि चेहरे एक ही व्यक्ति के हैं।
- **मध्यम प्रतिशत (70-89%)**: संभावित मिलानों का सुझाव देता है जिन्हें आगे समीक्षा की आवश्यकता हो सकती है।
- **निम्न प्रतिशत (70% से कम)**: संभवतः अलग-अलग व्यक्तियों को इंगित करता है।"मिलान" क्या है, इसके लिए सटीक थ्रेशोल्ड को आपकी सुरक्षा आवश्यकताओं के आधार पर कॉन्फ़िगर किया जा सकता है। थ्रेशोल्ड बढ़ाने से फ़ॉल्स पॉज़िटिव कम होते हैं लेकिन फ़ॉल्स नेगेटिव बढ़ सकते हैं।## उपयोग के मामले- **फ़्रॉड प्रिवेंशन**: एकाधिक खाते बनाने का प्रयास करने वाले उपयोगकर्ताओं की पहचान करें
- **उन्नत KYC**: अपनी KYC प्रक्रिया में सत्यापन की एक अतिरिक्त परत जोड़ें
- **नियामक अनुपालन**: डुप्लिकेट खातों का पता लगाने के लिए आवश्यकताओं को पूरा करें
- **एक्सेस नियंत्रण**: उच्च-सुरक्षा वाले क्षेत्रों के लिए उपयोगकर्ता की प्रामाणिकता सत्यापित करें
- **कानून प्रवर्तन**: रुचि के व्यक्तियों की पहचान करने में अधिकृत एजेंसियों की सहायता करें


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.