In Review का अर्थ है कि ऑटोमेटेड चेक पूरे हो गए, पर कुछ फ़्लैग हुआ जिसे कोई व्यक्ति सुलझाए - यह अपने आप कभी नहीं सुलझता। क्यू खाली करने और रेट घटाने के उपाय।
In Review अपने आप कभी नहीं सुलझता। इसका मतलब है कि किसी चेक ने कुछ फ़्लैग किया और आपकी टीम के किसी व्यक्ति के अप्रूव, डिक्लाइन, या resubmission मांगने का इंतज़ार कर रहा है। अगर आपका review रेट ज़्यादा है, तो लगभग हमेशा इसकी वजह बहुत टाइट सेट किया गया थ्रेशहोल्ड होती है - धोखाधड़ी नहीं।
Didit सत्रों की समीक्षा नहीं करता। समीक्षाधीन (In Review) सत्र आपकी Business Console में आपकी टीम के किसी व्यक्ति की प्रतीक्षा कर रहा है, और Didit में कोई भी उसे नहीं देख रहा है। Didit की ओर से कोई कतार या समय का अनुमान नहीं है: यह तब तक समीक्षाधीन रहता है जब तक आपकी टीम का कोई व्यक्ति निर्णय नहीं लेता।
सभी स्टेटस में, In Review ही सबसे ज़्यादा सपोर्ट सवाल पैदा करता है, एक सीधी वजह से: यह ऐसा लगता है जैसे प्लेटफ़ॉर्म अभी भी काम कर रहा है, जबकि असल में प्लेटफ़ॉर्म खत्म कर चुका है और आपका इंतज़ार कर रहा है।
#In Review का असल मतलब क्या है
सभी ऑटोमेटेड चेक चल चुके हैं। इनमें से कम से कम एक ने एक warning उठाई जिसे आपकी वर्कफ़्लो किसी ऑटोमेटिक डिसीज़न की बजाय रिव्यू पर भेजती है। सेशन अब आपकी क्यू में तब तक बैठा रहता है जब तक कोई इंसान इसे नहीं सुलझाता। इसमें कोई टाइमआउट नहीं है जो आखिरकार आपके लिए फ़ैसला कर दे, और सिस्टम को दोबारा चेक चलाकर अपना मन बदलने का कोई तरीका नहीं है।
#एक सेशन को साफ़ करना
- रिव्यू क्यू खोलें
पहचान सत्यापन → उपयोगकर्ता सत्यापन → समीक्षा आवश्यक या इनबॉक्स → निर्णय खोलें। A से स्वीकृति, D से अस्वीकृति, R से पुनः जमा अनुरोध और J/K से नेविगेशन करें। पुष्टि से पहले संवाद जाँचें।
- सिर्फ़ स्टेटस नहीं, warnings पढ़ें
सेशन खोलें और देखें कि कौन से चेक ने इसे फ़्लैग किया और warning क्या कहती है। यही तय करता है कि आप असल में क्या फ़ैसला कर रहे हैं। देखें वेरिफिकेशन रिज़ल्ट कैसे पढ़ें।
- फ़ैसला लें
सिर्फ़ फेल हुए स्टेप का अप्रूव, डिक्लाइन, या resubmission मांगें। एक नोट जोड़ें - यह ऑडिट ट्रेल का हिस्सा बन जाता है।
- अपने बैकएंड को बताएं
फ़ैसले से एक
status.updatedwebhook चलता है, इसलिए आपका सिस्टम बिना हाथ से मिलान किए ही अंतिम स्टेटस पा लेता है।
#आपका review रेट ज़्यादा क्यों हो सकता है
लगभग इसी क्रम में संभावना के हिसाब से:
- फेस मैच थ्रेशहोल्ड बहुत पास-पास सेट होना। अगर आपका review बैंड चौड़ा है, तो सामान्य लाइटिंग का फ़र्क़ भी उसमें आ जाता है। देखें फेस मैच स्कोर और थ्रेशहोल्ड।
- AML review थ्रेशहोल्ड बहुत कम मैच स्कोर पर सेट होना। आम नाम कम मैच स्कोर पर कैंडिडेट हिट पैदा करते हैं। review थ्रेशहोल्ड बहुत कम रखने से लगभग सभी रिव्यू में चले जाते हैं। देखें AML हिट सुलझाना।
- प्रूफ़ ऑफ़ एड्रेस पार्शियल मैच। एड्रेस फ़ॉर्मेट देश-दर-देश बहुत अलग होते हैं; एक शॉर्ट-फ़ॉर्म का फ़र्क़ भी एक पार्शियल मैच जैसा पढ़ा जाता है। जानबूझकर तय करें कि क्या पार्शियल मैच को रिव्यू में जाना चाहिए या पास हो जाना चाहिए।
- डेटाबेस वैलिडेशन पार्शियल मैच। वही वजह - किसी अधिकृत स्रोत में नाम अलग तरह से दर्ज होना।
- असली लौटे हुए यूज़र पर डुप्लिकेट-फेस फ़्लैग। अगर वही असली व्यक्ति एक से ज़्यादा बार वेरिफाई करता है, तो वे खुद से मैच कर जाएंगे। देखें डुप्लिकेट डिटेक्शन।
- "सुरक्षा के लिए" हर warning को रिव्यू पर भेजना। सब कुछ रिव्यू करना कुछ भी रिव्यू न करने जैसा ही है, क्योंकि क्यू पर काम होना बंद हो जाता है। सिर्फ़ वही warnings चुनें जिनमें सचमुच निर्णय-क्षमता चाहिए।
#वर्कफ़्लो को पहले और सस्ता रिव्यू करने के लिए फिर से क्रम में लगाना
अगर आपका फ्लो महंगा है और फिर भी बहुत सारे सेशन रिव्यू में चले जाते हैं, तो सस्ते रिस्क चेक को आगे ले जाने का मतलब है कि महंगे चेक चलने से पहले ही फ्लो रुक जाता है। पूरे KYC फ्लो के आगे $0.03 वाला डिवाइस और IP एनालिसिस उस ट्रैफ़िक पर खर्च कम करेगा जो कभी पास होने वाला ही नहीं था।
इसका ट्रेडऑफ़ यूज़र एक्सपीरियंस है: पहले स्टेप पर रोका गया व्यक्ति कुछ भी निवेश नहीं करता, लेकिन उसे यह भी पता नहीं चलता कि क्यों। अपने फ़नल के लिए तय करें कि क्या ज़्यादा मायने रखता है।
#Four-eyes review
यदि केस प्रबंधन और दो व्यक्तियों की समीक्षा सक्षम हैं, तो प्रक्रिया दूसरे समीक्षक की पुष्टि माँगती है। उपलब्धता केस सेटिंग और अनुमतियों पर निर्भर करती है।
#In Review क्या नहीं है
- यह "अभी भी प्रोसेस हो रहा" नहीं है। अगर आप प्लेटफ़ॉर्म के खत्म होने का इंतज़ार कर रहे हैं, तो जो स्टेटस आप चाहते हैं वह है In Progress।
- यह कोई सॉफ़्ट डिक्लाइन नहीं है। एक In Review सेशन का अभी तक कोई वर्डिक्ट नहीं है, इसलिए इसे अपने सिस्टम में "rejected" पर मैप न करें - इसे इसकी अपनी pending स्थिति पर मैप करें।
- यह ऐसा कुछ नहीं जिसका फ़ैसला सपोर्ट आपके लिए ले सके। सिर्फ़ आपकी टीम के पास अपने कस्टमर को अप्रूव या डिक्लाइन करने का अधिकार है। सपोर्ट यह समझा सकता है कि कोई सेशन क्यों फ़्लैग हुआ, और इसके लिए उन्हें
session_idचाहिए होगी।
#ऑनगोइंग मॉनिटरिंग एक अप्रूव्ड सेशन को वापस रिव्यू में भेज सकती है
अगर आपने AML मॉनिटरिंग ऑन कर रखी है, तो एक पहले से अप्रूव्ड सेशन बाद में In Review में जा सकता है, जब कोई डेली री-स्क्रीन आपके review थ्रेशहोल्ड को पार करने वाली नई हिट खोजे। यह अपेक्षित व्यवहार है, कोई रिग्रेशन नहीं - और यही मॉनिटरिंग का पूरा मकसद है। देखें ऑनगोइंग AML मॉनिटरिंग।
अभी भी अटके हैं? किसी व्यक्ति से बात करें।
अपने संगठन की ID और जिस सेशन के बारे में पूछ रहे हैं उसकी ID शामिल करें।