> ## 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.

# मैन्युअल KYC समीक्षा: समीक्षक डैशबोर्ड

> Didit डैशबोर्ड से फ़्लैग किए गए पहचान सत्यापन सत्र देखें। स्वीकृत, अस्वीकृत करें या पुनः जमा का अनुरोध करें, ऑडिट ट्रेल के साथ।

मैन्युअल समीक्षा किसी भी मज़बूत पहचान सत्यापन और KYC अनुपालन वर्कफ़्लो का एक महत्वपूर्ण हिस्सा है। जब स्वचालित सिस्टम किसी सत्यापन सत्र को चेतावनियों या विसंगतियों के साथ चिह्नित करता है, तो वह **समीक्षाधीन** स्थिति में चला जाता है, और अंतिम निर्णय लेने के लिए एक प्रशिक्षित समीक्षक की ज़रूरत होती है।

यह गाइड आपको पूरी मैन्युअल समीक्षा प्रक्रिया के बारे में बताती है, जिसमें उपयोगकर्ताओं को दूसरा मौका देने के लिए **पुनः सबमिशन** सुविधा का उपयोग करने का तरीका भी शामिल है।

***

## सत्यापन डैशबोर्ड का अवलोकन

![मैन्युअल समीक्षा सत्यापन का अवलोकन](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-manual-review.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=4f16a753968d444bf4e917c08bcbbef5)

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

| स्थिति | अर्थ |
| - | - |
| **स्वीकृत** | उपयोगकर्ता ने सभी पहचान जाँचें पास कर ली हैं |
| **अस्वीकृत** | उपयोगकर्ता एक या अधिक सत्यापन जाँचों में विफल रहा |
| **समीक्षाधीन** | निर्णय लेने से पहले आपके मैन्युअल ध्यान की ज़रूरत है |
| **पुनः सबमिट किया गया** | उपयोगकर्ता से कुछ विशिष्ट सत्यापन चरण दोबारा करने के लिए कहा गया है |

> [!WARNING]
>
> **समीक्षाधीन** के रूप में चिह्नित सत्रों ने स्वचालित प्रसंस्करण के दौरान एक या अधिक चेतावनी संकेत ट्रिगर किए हैं। समीक्षा के लिए लंबित सत्रों की कुल संख्या सत्यापन डैशबोर्ड के शीर्ष पर दिखाई जाती है।

***

## प्रभावी मैन्युअल समीक्षा कैसे करें

**1. प्रारंभिक मूल्यांकन**

किसी भी सत्र पर क्लिक करके विस्तृत सत्र दृश्य खोलें:

1. सत्र के अवलोकन में प्रदर्शित **सभी चेतावनियों की समीक्षा करें**। ये वे विशिष्ट संकेत हैं जिनकी वजह से मैन्युअल समीक्षा शुरू हुई (जैसे कम लाइवनेस स्कोर, AML मिलान, दस्तावेज़ में असंगति)।
2. **उपयोगकर्ता के पिछले सत्यापन प्रयासों की समीक्षा करें**। सत्र इतिहास देखने और यह जाँचने के लिए कि उपयोगकर्ता के पहले से कोई सत्यापन सत्र हैं या नहीं, उपयोगकर्ता के विक्रेता डेटा पर क्लिक करें।
3. **सत्र इवेंट की समयरेखा की समीक्षा करें**। इवेंट सेक्शन में सत्र के दौरान की गई हर कार्रवाई का कालानुक्रमिक लॉग मिलता है।

**2. दस्तावेज़ निरीक्षण**

Didit की स्वचालित प्रणाली पहले से ही व्यापक दस्तावेज़ सत्यापन करती है, जिसमें सुरक्षा विशेषता पहचान, फ़ील्ड-स्तर की डेटा संगति जाँच, MRZ सत्यापन, समाप्ति तिथि सत्यापन और छवि गुणवत्ता विश्लेषण शामिल हैं। आपकी भूमिका है **चिह्नित चेतावनियों का मूल्यांकन** करना और ज़रूरत होने पर दस्तावेज़ की दृश्य रूप से पुष्टि करना।

1. **दस्तावेज़ चेतावनियों की समीक्षा करें**: प्रणाली ने जो विशिष्ट चेतावनियाँ उठाई हैं, उन्हें जाँचें। आम चेतावनियों में फ़ील्ड के बीच डेटा असंगतियाँ, MRZ चेक डिजिट सत्यापन में विफलता, समाप्त हो चुके दस्तावेज़ या छेड़छाड़ का संदेह शामिल हैं।
2. **जब चेतावनियाँ अस्पष्ट हों तो दृश्य सत्यापन करें**: यदि कोई चेतावनी संभावित छेड़छाड़ या कम छवि गुणवत्ता की ओर इशारा करती है, तो दस्तावेज़ की छवियों का सीधे निरीक्षण करें। डिजिटल संपादन, क्रॉपिंग, स्क्रीन कैप्चर या भौतिक हेरफेर के संकेत देखें।
3. **निकाले गए OCR डेटा की जाँच करें**: प्रणाली ने दस्तावेज़ से जो डेटा निकाला है, उसकी समीक्षा करें और पुष्टि करें कि वह संगत लगता है। जिन फ़ील्ड में विश्वास कम है, प्रणाली उन्हें हाइलाइट करती है।
4. **डिकोड किए गए QR कोड और बारकोड की समीक्षा करें**: जब Document AI दस्तावेज़ पर QR कोड या बारकोड पहचानता है, तो सत्र दृश्य छवि या PDF पूर्वावलोकन में उसकी स्थिति हाइलाइट करता है और डिकोड किया गया payload दिखाता है। जो कोड मिला तो है लेकिन डिकोड नहीं हो सका, उसे केवल पहचाना गया के रूप में दिखाया जाता है, और उसके लिए कोई payload होने का दावा नहीं किया जाता। यह स्थान-ओवरले दस्तावेज़ छेड़छाड़ की चेतावनी वाली हाइलाइट से अलग है, और उनका मौजूदा उपचार वैसा ही रहता है।
5. **दस्तावेज़ मिलान की समीक्षा करें**: यदि **चेहरा खोज** या डुप्लिकेट पहचान सक्षम है, तो जाँचें कि यह उपयोगकर्ता पहले किसी अलग पहचान के तहत सत्यापित हो चुका है या नहीं, और क्या यह दस्तावेज़ आपकी **ब्लॉकलिस्ट** में है।

> [!TIP]
>
> Didit कंसोल में दस्तावेज़ छवियों पर माउस घुमाकर **ज़ूम सुविधा** का उपयोग करें और पिक्सेल-स्तर पर विस्तृत निरीक्षण करें। माइक्रोप्रिंटिंग और होलोग्राम की जाँच के समय यह विशेष रूप से उपयोगी है।

**3. बायोमेट्रिक और लाइवनेस सत्यापन**

Didit स्वचालित रूप से **चेहरा मिलान**, **लाइवनेस डिटेक्शन** और, यदि सक्षम हो, **चेहरा खोज** करता है। आपकी भूमिका है चिह्नित होने पर परिणामों की समीक्षा करना।

1. **चेहरा मिलान स्कोर**: प्रणाली सेल्फ़ी और दस्तावेज़ के पोर्ट्रेट के बीच बायोमेट्रिक समानता स्कोर की गणना करती है। चिह्नित चेहरा मिलान की समीक्षा करते समय आँखों के आकार, नाक की संरचना, जबड़े की रेखा और विशिष्ट निशानों जैसी संरचनात्मक विशेषताओं पर ध्यान दें।
2. **लाइवनेस डिटेक्शन स्कोर**: लाइवनेस प्रणाली प्रिंटेड फ़ोटो, स्क्रीन रीप्ले, डीपफ़ेक और 3D मास्क जैसे प्रेज़ेंटेशन अटैक का पता लगाती है। खराब कैमरा गुणवत्ता या कम रोशनी से असली उपयोगकर्ताओं के लिए भी कभी-कभी कम स्कोर आ सकते हैं। ऐसे मामलों में अस्वीकार करने के बजाय **पुनः सबमिशन का अनुरोध** करने पर विचार करें।
3. **चेहरा खोज परिणाम**: किसी भी मिलान की ध्यान से समीक्षा करें:
   * **डुप्लिकेट पहचान**: किसी अलग सत्र के साथ मिलान से संकेत मिल सकता है कि वही व्यक्ति कई पहचानों के तहत सत्यापन कर रहा है।
   * **ब्लॉकलिस्ट मिलान**: यदि चेहरा किसी ब्लॉकलिस्ट किए गए उपयोगकर्ता से मेल खाता है, तो आमतौर पर अस्वीकार करना उचित होता है।
   * **फ़ॉल्स पॉज़िटिव**: अलग-अलग लोगों के बीच चेहरे की समानता होना संभव है। विश्वास स्कोर का मूल्यांकन करें और छवियों की दृश्य तुलना करें।

**4. जोखिम और संकेतों की समीक्षा**

संदर्भगत जोखिम का आकलन करने के लिए **AML**, **डिवाइस और IP विश्लेषण** और **डेटाबेस सत्यापन** सेक्शन में जाएँ।

![मैन्युअल समीक्षा में AML स्क्रीनिंग परिणाम](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-manual-review-aml.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=f08862b7abc947edb57e81b87ff8ecac)

**AML स्क्रीनिंग**

* **कोई मिलान नहीं**: कम जोखिम। वैश्विक वॉचलिस्ट, प्रतिबंध सूचियों या PEP डेटाबेस में कोई हिट नहीं मिला।
* **मिलान मिले**: हर मिलान की प्रविष्टि की समीक्षा करें। जाँचें कि वह सही सकारात्मक है या फ़ॉल्स पॉज़िटिव, मिलान श्रेणी देखें (PEP, प्रतिबंध, वॉचलिस्ट, प्रतिकूल मीडिया), और डेटा के स्रोत और ताज़गी पर विचार करें।
* **केवल लेबल नहीं, स्कोर का उपयोग करें**: सेक्शन के हेडर में **जोखिम स्कोर** दिखता है, जिससे AML स्थिति निकाली गई थी (उन हिट्स में सबसे ऊँचा जोखिम स्कोर जो फ़ॉल्स पॉज़िटिव के रूप में चिह्नित नहीं हैं, जिसकी तुलना वर्कफ़्लो की स्वीकृति और समीक्षा थ्रेशोल्ड से होती है)। हर पंक्ति में हिट का **मिलान स्कोर** (पहचान विश्वास) और **जोखिम स्कोर** (इकाई जोखिम) दिखता है। किसी पर भी माउस ले जाकर देखें कि उसकी गणना कैसे हुई। ये वही `score`, `match_score` और `risk_score` हैं जो आपका इंटीग्रेशन [निर्णय payload](https://docs.didit.me/hi/core-technology/aml-screening/report-aml-screening.md#एक-नहीं-तीन-स्कोर) में प्राप्त करता है।

**डिवाइस और IP विश्लेषण तथा डिवाइस इंटेलिजेंस**

* **भौगोलिक संगति**: दस्तावेज़ का जारीकर्ता देश, उपयोगकर्ता का बताया गया पता और IP जियोलोकेशन की तुलना करें।
* **VPN / प्रॉक्सी पहचान**: जाँचें कि उपयोगकर्ता VPN, प्रॉक्सी या Tor नेटवर्क से कनेक्ट है या नहीं।
* **डिवाइस मेटाडेटा**: असामान्यताओं के लिए डिवाइस का प्रकार, ऑपरेटिंग सिस्टम और ब्राउज़र जानकारी की समीक्षा करें।

***

## निर्णय लेना

अपनी समीक्षा पूरी करने के बाद आपके पास तीन विकल्प होते हैं: **अनुमोदित करें**, **अस्वीकार करें**, या **पुनः सबमिशन का अनुरोध करें**।

> [card] अनुमोदित करें
>
> * दस्तावेज़ प्रामाणिक और अपरिवर्तित दिखता है
> * सभी डेटा फ़ील्ड सुसंगत और पठनीय हैं
> * सेल्फ़ी बायोमेट्रिक मिलान पुष्टि करता है कि वह एक ही व्यक्ति है
> * लाइवनेस जाँच स्कोर स्वीकार्य सीमा में है
> * कोई प्रासंगिक AML, प्रतिबंध, या PEP मिलान नहीं है
> * डिवाइस और स्थान डेटा सुसंगत हैं

> [card] अस्वीकार करें
>
> * दस्तावेज़ में छेड़छाड़, जालसाज़ी, या बदलाव के संकेत दिखते हैं
> * सेल्फ़ी दस्तावेज़ की फ़ोटो से मेल नहीं खाती
> * उच्च-विश्वास वाले AML या प्रतिबंध मिलान की पुष्टि हुई
> * प्रेज़ेंटेशन अटैक के मज़बूत संकेत मिले
> * धोखाधड़ीपूर्ण पहचान पैटर्न का पता चला
> * डिवाइस या स्थान में गंभीर असंगतियाँ हैं

> [card] पुनः सबमिशन का अनुरोध करें
>
> * धुंधली या कम गुणवत्ता वाली दस्तावेज़ छवियाँ
> * तकनीकी समस्याओं के कारण लाइवनेस जाँच विफल रही
> * गलत दस्तावेज़ सबमिट किया गया
> * सत्यापन चरण अधूरे या समय-सीमा समाप्त हो चुके हैं
> * ऐसी सुधार योग्य समस्याएँ जिन्हें उपयोगकर्ता ठीक कर सकता है

![अस्वीकृति मानदंड चयन संवाद](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-decline-criteria.png?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=1b6056a86de8250e5e4a5cd786de4171)

> [!NOTE]
>
> किसी सत्र को अस्वीकार करते समय हमेशा **अस्वीकृति का कारण चुनें** और विस्तृत **समीक्षा नोट्स** जोड़ें। इससे गुणवत्ता आश्वासन, नियामक ऑडिट, और आंतरिक विश्लेषण में मदद मिलती है।

***

## पुनः सबमिशन का अनुरोध करना

जब किसी सत्र को स्पष्ट रूप से न स्वीकृत किया जा सके और न अस्वीकार किया जा सके, आमतौर पर सुधार योग्य समस्याओं के कारण, तब आप उपयोगकर्ता से कुछ विशेष सत्यापन चरण फिर से सबमिट करने का अनुरोध कर सकते हैं।

### पुनः सबमिशन का अनुरोध कैसे करें

**1. सत्र खोलें**

Didit कंसोल में सत्र पर जाएँ।

**2. पुनः सबमिशन का अनुरोध करें चुनें**

सत्र स्थिति नियंत्रण खोलें, **पुनः सबमिट किया गया** चुनें, फिर **जारी रखें** चुनें।

**3. पुनः सबमिट करने के लिए सुविधाएँ चुनें**

संवाद में सभी गैर-स्वीकृत सुविधाएँ उनकी वर्तमान स्थिति के साथ दिखती हैं। व्यक्तिगत चरण चुनें या उनका चयन हटाएँ। जिन सुविधाओं को शुरू ही नहीं किया गया था, वे स्वतः आवश्यक हो जाती हैं।

**4. वैकल्पिक रूप से ईमेल सूचना भेजें**

यदि उपयोगकर्ता का ईमेल उपलब्ध है, तो उन्हें स्थानीय भाषा में एक सूचना भेजें जिसमें जारी रखने के लिए सीधा लिंक हो। ईमेल हर चरण का कारण बताता है; जब हर चरण इसलिए माँगा गया हो क्योंकि दस्तावेज़ की समय-सीमा समाप्त हो गई है, तो ईमेल यह बताता है और एक वैध दस्तावेज़ माँगता है, न कि सामान्य "पुनः प्रयास करें"। ईमेल का शब्दांकन प्रत्येक लोकेल के लिए [व्हाइट लेबल → टेक्स्ट](https://docs.didit.me/hi/console/white-label.md#कस्टम-टेक्स्ट) में अनुकूलित किया जा सकता है।

**5. पूर्वावलोकन करें और पुष्टि करें**

प्राप्तकर्ता, प्रेषक, विषय और स्थानीय भाषा के ईमेल की समीक्षा के लिए **पूर्वावलोकन** चुनें।
व्हाइट लेबल सत्र कॉन्फ़िगर की गई ब्रांडिंग और सत्यापित प्रेषक का उपयोग करते हैं।
जाँच, प्राप्तकर्ता, या भाषा बदलने के लिए **संपादित करें** चुनें, फिर एक नया पूर्वावलोकन बनाएँ।
**पुष्टि** करने पर पुनः सबमिशन का अनुरोध किया जाता है; केवल पूर्वावलोकन करने से सत्र नहीं बदलता और मेल नहीं भेजा जाता।
यदि स्वचालित जाँच उपयोगकर्ता की और कार्रवाई के बिना सत्यापन पूरा कर देती है, तो कार्रवाई-अनुरोध ईमेल नहीं भेजा जाता।

### पुनः सबमिशन के बाद क्या होता है

1. **पिछले परिणाम पढ़ने योग्य रहते हैं**: केवल चुने गए चरण नए सिरे से शुरू होते हैं। उनके पहले लौटाए गए परिणाम पिछला सबमिशन बन जाते हैं: सत्र उन्हें हर चरण के सबमिशन टैब में दिखाता है ("सबमिशन 2 · नवीनतम", "सबमिशन 1"), और API उन्हें [सत्र प्राप्त करें](https://docs.didit.me/hi/sessions-api/retrieve-session.md) पर `?include=resubmissions` के साथ लौटाता है।
2. **उपयोगकर्ता सत्यापन प्रवाह में फिर से प्रवेश करता है**: उन्हें केवल वे विशिष्ट चरण पूरे करने होते हैं जिनका अनुरोध किया गया था।
3. **सत्र पुनः सबमिट की गई स्थिति में रहता है**: यह **प्रगति में** से अलग है, जिससे आप पुनः सबमिशन वाले सत्रों को अलग से ट्रैक कर सकते हैं।
4. **स्वचालित पुनर्मूल्यांकन**: जब सभी पुनः सबमिट की गई सुविधाएँ पूरी हो जाती हैं, तो सिस्टम अंतिम स्थिति स्वतः पुनर्गणना करता है।
5. **नया webhook भेजा जाता है**: आपके सर्वर को अद्यतन अंतिम स्थिति के साथ एक webhook प्राप्त होता है।

> [!TIP]
>
> एक ही सत्र पर आप कई बार पुनः सबमिशन का अनुरोध कर सकते हैं। हर अनुरोध क्रमांकित होता है, और हर पिछला सबमिशन पढ़ने योग्य रहता है, जिसमें यह भी दर्ज रहता है कि किसने और क्यों अनुरोध किया। किसी एक चरण के भीतर के प्रयास (उदाहरण के लिए, प्रवाह द्वारा माँगी गई दूसरी फ़ोटो) सबमिशन नहीं हैं: सत्र नवीनतम प्रयास दिखाता है, और इवेंट्स हर प्रयास को सूचीबद्ध करते हैं। सत्र हटाने पर हर सबमिशन हट जाता है।

### पुनः सबमिशन बनाम नया सत्र बनाना

| | पुनः सबमिशन | नया सत्र |
| - | - | - |
| **सत्र ID** | वही सत्र ID बनी रहती है | नई सत्र ID बनाई जाती है |
| **इतिहास** | पिछले प्रयास उसी सत्र के भीतर संग्रहीत रहते हैं | अलग सत्र, कोई जुड़ा हुआ इतिहास नहीं |
| **उपयोगकर्ता का प्रयास** | केवल विफल या चुने गए चरण फिर से करने होते हैं | शुरू से पूरा सत्यापन |
| **रूपांतरण पर प्रभाव** | पूर्णता दर अधिक होती है | उपयोगकर्ताओं के छोड़ देने का जोखिम |
| **Webhook** | वही सत्र ID, स्थिति पुनः सबमिट किया गया → अंतिम स्थिति में बदलती है | ‘शुरू नहीं हुआ’ स्थिति से नया सत्र जीवनचक्र |
| **ऑडिट रिकॉर्ड** | पूरा इतिहास एक ही जगह | कई सत्रों में बिखरा हुआ |

***

## समीक्षा की सर्वोत्तम पद्धतियाँ

> [accordion] एक जैसे मानदंड अपनाएँ
>
> हर समीक्षा में एक ही मानदंड लागू करें। अपने तर्क का दस्तावेज़ीकरण करें, ताकि टीम के अन्य सदस्य आपके निर्णयों को समझ सकें और उन्हें दोहरा सकें।

> [accordion] सुधारे जा सकने वाली समस्याओं के लिए अस्वीकार करने के बजाय पुनः प्रस्तुति का अनुरोध करें
>
> यदि समस्या धुंधली फ़ोटो या तकनीकी त्रुटि है, तो पुनः प्रस्तुति का अनुरोध करने से सत्र बना रहता है और वास्तविक उपयोगकर्ताओं को अनावश्यक परेशानी से बचाया जाता है।

> [accordion] ज़ूम सुविधा का उपयोग करें
>
> सामान्य ज़ूम स्तर पर दिखाई न देने वाली सूक्ष्म छेड़छाड़, माइक्रोप्रिंटिंग या सुरक्षा विशेषताओं की जाँच के लिए दस्तावेज़ की छवियों को हमेशा ज़ूम करके देखें।

> [accordion] डेटा बिंदुओं का आपस में मिलान करें
>
> संकेतों का अलग-अलग मूल्यांकन न करें। कम लाइवनेस स्कोर, VPN कनेक्शन और मेल न खाने वाला जियोलोकेशन मिलकर किसी एक कारक से कहीं अधिक चिंताजनक होते हैं।

> [accordion] सब कुछ दस्तावेज़ित करें
>
> हर निर्णय के लिए, विशेष रूप से अस्वीकृति के लिए, विस्तृत समीक्षा नोट्स जोड़ें। ये नोट्स आंतरिक QA, नियामक ऑडिट में सहायक होते हैं और नए टीम सदस्यों के प्रशिक्षण में भी काम आते हैं।

> [accordion] अलर्ट सेट करें
>
> ईमेल या Slack अलर्ट कॉन्फ़िगर करें, ताकि सत्र **समीक्षाधीन** स्थिति में जाते ही आपको तुरंत सूचना मिल जाए। तेज़ प्रतिक्रिया समय अनुपालन और उपयोगकर्ता अनुभव दोनों को बेहतर बनाता है।

> [accordion] पुनः प्रस्तुति के पैटर्न पर नज़र रखें
>
> यदि किसी उपयोगकर्ता के कई पुनः प्रस्तुति चक्र हुए हैं, तो पूरे इतिहास की ध्यानपूर्वक समीक्षा करें। एक ही सुविधा पर बार-बार विफलता किसी व्यवस्थागत समस्या का संकेत हो सकती है।


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