केस प्रबंधन - केस और जीवनचक्र

केस प्रबंधन Didit Console का जांच केंद्र है। हर AML हिट, चिह्नित सत्यापन या संदिग्ध लेन-देन एक केस बन सकता है, जिस पर आपकी अनुपालन टीम खुलने से लेकर समाधान तक काम करती है, पूरे ऑडिट ट्रेल के साथ।

---

​

जीवनचक्र

एक केस ठीक तीन स्थितियों से होकर गुज़रता है: केस का समाधान करने के लिए एक रिज़ॉल्यूशन ज़रूरी है: हर केस के साथ एक प्राथमिकता (Low, Medium, High, डिफ़ॉल्ट Medium) और एक वैकल्पिक देय तिथि जुड़ी होती है, जो SLA के अनुसार क्रम और अतिदेय चिह्नों का आधार बनती है।

​

प्रति केस एक संबंधित इकाई

हर केस ठीक एक उपयोगकर्ता या एक व्यवसाय से जुड़ा होता है। आप एक ही केस में अलग-अलग संबंधित इकाइयाँ नहीं मिला सकते, और आप केस के विषय से भिन्न किसी विषय का सत्र, व्यवसाय सत्र या लेन-देन नहीं जोड़ सकते। ऐसा करने पर एक स्पष्ट त्रुटि मिलती है। इससे हर केस पेज केंद्रित रहता है: विषय कार्ड, जोखिम अवलोकन, दस्तावेज़ और वित्तीय डेटा, सभी उसी व्यक्ति या व्यवसाय का वर्णन करते हैं जिसकी जांच केस में हो रही है। किसी दूसरी इकाई की समीक्षा के लिए एक अलग केस खोलें (या बनाएँ)।

​

Fraud Check स्रोत संदर्भ

किसी Fraud Check सत्र से केस बनाने पर उसका चेक ID, अनुरोध ID और वह अनुभाग सुरक्षित रहता है जिसे समीक्षक ने खोला था। स्रोत कार्ड केस बनने के समय सत्र की विश्लेषक स्थिति भी दर्ज करता है। केस का निर्णय और स्रोत का निर्णय अलग-अलग रहते हैं। API क्लाइंट केस बनाते समय source_context के साथ check_id, request_id और source_section दे सकते हैं। इस अनुरोध को links में एक session प्रविष्टि के रूप में शामिल करें। चेक और जुड़ा हुआ सत्र चुने गए एप्लिकेशन से संबंधित होने चाहिए, और एक-दूसरे से भी। इस संदर्भ में API विश्लेषक की स्थिति स्वयं पढ़ता है, और क्लाइंट द्वारा भेजी गई स्थिति, अनुशंसा या स्रोत-प्रकार फ़ील्ड को अस्वीकार करता है।

​

सूचियाँ

केस प्रबंधन अपने शीर्ष नेविगेशन में केस, अवलोकन और असाइनमेंट उपलब्ध रखता है। केस वर्कस्पेस में खुले, उपयोगकर्ता की प्रतीक्षा में, समाधानित और सभी स्थिति व्यू मिलते हैं। डेस्कटॉप पर किसी केस को खोलने पर केस कतार उसके विवरण के बगल में बनी रहती है। मोबाइल पर कतार में लौटने के लिए ब्रेडक्रंब का उपयोग करें। खोज विषय के नाम या ID, टैग, केस नंबर, केस शीर्षक, जुड़ा सत्र ID और जुड़ा लेन-देन ID से मिलान करती है। इसलिए आप किसी सत्र या लेन-देन का UUID चिपकाकर सीधे उसके केस तक पहुँच सकते हैं। फ़िल्टर चिप्स: ब्लूप्रिंट, निर्माण, स्रोत, असाइनी, टैग, साथ ही प्राथमिकता और देय के लिए फ़िल्टर जोड़ें। कॉलम: निर्माण (तिथि और निर्माता), केस विवरण (शीर्षक), स्थिति, ब्लूप्रिंट, विषय (नाम और ID), विषय के टैग, सौंपा गया, प्राथमिकता और देय तिथि। इनके अलावा और कॉलम क्षैतिज स्क्रॉल और कॉलम कॉन्फ़िगरेशन से उपलब्ध हैं।

​

क्रमबद्ध करना और SLA

निर्माण दिनांक (डिफ़ॉल्ट) या देय तिथि के अनुसार क्रमबद्ध करें। देय तिथि से क्रमबद्ध करने पर अतिदेय केस सबसे पहले दिखते हैं। कोई केस तब अतिदेय होता है जब उसकी देय तिथि बीत चुकी हो और वह अब भी खुले या उपयोगकर्ता की प्रतीक्षा में स्थिति में हो। ऐसे केस पर लाल देय चिप दिखता है।

​

सहेजे गए व्यू

फ़िल्टर और कॉलम के वर्तमान संयोजन को व्यू सहेजें से एक नामित व्यू के रूप में सहेजें, एक व्यू चुनें से व्यू बदलें, और फ़िल्टर हटाएँ से रीसेट करें। व्यू व्यक्तिगत होते हैं और कंसोल की अन्य तालिका प्राथमिकताओं की तरह बने रहते हैं।

​

थोक कार्रवाइयाँ

एक से अधिक केस चुनकर:

• किसी अधिकारी को असाइन करें। चुने गए सभी केस एक ही ब्लूप्रिंट के होने चाहिए, और यदि ऐसा नहीं है तो सबमिट करने से पहले कंसोल चेतावनी देता है।
• स्थिति सेट करें से स्थिति को उपयोगकर्ता की प्रतीक्षा में सेट करें, केस पुनः खोलें, या उसे समाधान करें (रिज़ॉल्यूशन और वैकल्पिक नोट के साथ)। हर केस अलग से जांचा जाता है, इसलिए अधूरी चेकलिस्ट या आवश्यक नोट न होने के कारण रुका केस अलग से दर्ज होता है, और बाकी बैच विफल नहीं होता।

​

एक्सपोर्ट

सूची मेनू दो CSV एक्सपोर्ट देता है, जो रिपोर्ट पेज के माध्यम से प्रदान होते हैं:

• सभी केस रिपोर्ट, जिसमें हर केस की एक पंक्ति होती है, और उसकी स्थिति, रिज़ॉल्यूशन, प्राथमिकता, टैग, जुड़े लेन-देन और दाखिल की गई आखिरी FIU रिपोर्ट शामिल होती है।
• SLA रिपोर्ट, प्रति केस समय के मेट्रिक्स: असाइनमेंट तक के घंटे, समाधान तक के घंटे, अतिदेय और SLA पूरा हुआ, इन फ़्लैग के साथ।

​

विषय पर कार्रवाइयाँ और पुनः प्रयास

विषय कार्ड अधिकृत समीक्षकों को विषय की स्थिति बदलने, टैग जोड़ने, आंतरिक नोट जोड़ने, या विषय को ब्लॉकलिस्ट में डालने की सुविधा देता है। ये कार्रवाइयाँ केस को समाधान करने से अलग हैं। विषय पर कार्रवाइयाँ अनुभाग हर अनुरोधित कार्रवाई को लागू या असफल के रूप में दर्ज करता है, और उसके समीक्षक और समय की पहचान करता है। विषय की वर्तमान स्थिति की समीक्षा करने के बाद असफल कार्रवाई को फिर से चलाने के लिए कार्रवाई फिर आज़माएँ का उपयोग करें। जो कार्रवाई पहले से लागू हो चुकी है, उसका अनुरोध फिर से भेजे जाने पर वह दोबारा नहीं चलाई जाती। API क्लाइंट को केस के entity-actions/ endpoint पर हर अनुरोध के साथ एक अद्वितीय client_reference भेजना चाहिए। कनेक्शन त्रुटि के बाद अनुरोध दोबारा भेजते समय वही reference और वही इनपुट रखें। उसी reference के साथ बदला हुआ इनपुट 409 लौटाता है। जब reference दिया गया हो, तो receipt.status जांचें: 200 रिस्पॉन्स में असफल रसीद हो सकती है, जिसका अर्थ है कि कार्रवाई लागू नहीं हुई। असफल अनुरोध को फिर से चलाने के लिए retry: true देना ज़रूरी है, या उसके action-receipts/{receipt_uuid}/retry/ endpoint को कॉल करना होगा। इतिहास endpoint प्रति पेज अधिकतम 20 रसीदें लौटाता है, और अतिरिक्त परिणामों के लिए next_offset देता है। जो मौजूदा API क्लाइंट client_reference छोड़ते हैं, वे पहले जैसा रिस्पॉन्स व्यवहार बनाए रखते हैं।

​

टैग

संबंधित जांचों को समूहित करने के लिए केस के हेडर से (टैग जोड़ें) उसमें टैग जोड़ें, या सूची से टैग के आधार पर फ़िल्टर और खोज करें। टैग में हुए बदलाव केस की टाइमलाइन पर दर्ज होते हैं।

​

संबंधित पेज

​

ग्राहक संदेश

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

​

चर्चा और पिन किए गए नोट

जाँच को जस की तस रखते हुए नोट देखने के लिए केस की स्थिति के बगल में मौजूद चर्चा बटन खोलें। किसी नोट के मेनू से उस पर जवाब देने या उसे पिन करने का विकल्प चुनें। पिन किए गए नोट सबसे पहले दिखते हैं, और जवाबों में उनके मूल नोट का एक छोटा अंश दिखता है। पिन करने में हुए बदलाव केस गतिविधि में दर्ज होते हैं और स्रोत निर्णयों को नहीं बदलते। हटाने की पुष्टि करने पर नोट और जवाबों में उसका उद्धृत अंश स्थायी रूप से हट जाते हैं। जवाब स्वयं उपलब्ध रहते हैं। अनुलग्नक तभी हटाए जाते हैं जब कोई दूसरा नोट उनका उपयोग न कर रहा हो। नोट जोड़ते समय API क्लाइंट client_reference UUID दे सकते हैं। बिना बदलाव के किया गया पुनः प्रयास मौजूदा नोट लौटाता है और सूचनाओं को डुप्लिकेट नहीं करता। बदली हुई सामग्री या हटाए गए नोट के लिए वही संदर्भ दोबारा इस्तेमाल करने पर 409 लौटता है। उसी केस के किसी सक्रिय नोट का संदर्भ देने के लिए reply_to दें, और नोट के PATCH endpoint के ज़रिए is_pinned अपडेट करें।

​

मौजूदा जाँच देखें

साझा Create Case डायलॉग चुने गए उपयोगकर्ता, व्यवसाय या जुड़े स्रोत के लिए मौजूदा जाँचों की तलाश करता है। समीक्षा जारी रखने के लिए मौजूदा केस खोलें। बंद केस दिखते रहते हैं, ताकि आप उन्हें खोलकर तय कर सकें कि उन्हें फिर से खोलना है या नहीं। अलग जाँच बनाने के लिए, यह कारण लिखें कि इसे एक अलग घटना क्यों माना जा रहा है। यह कारण नए केस के साथ सहेजा जाता है और उसके अवलोकन में दिखता है। सबमिट करते समय कंसोल डुप्लिकेट की दोबारा जाँच करता है, जिसमें डायलॉग खुले रहने के दौरान किसी दूसरे समीक्षक द्वारा बनाए गए केस भी शामिल हैं। API इंटीग्रेशन POST .../cases/duplicates/ की समीक्षा कर सकते हैं और केस बनाते समय review_duplicates=true सेट कर सकते हैं। मौजूदा जाँच मिलने पर, separate_incident_reason दिए बिना केस बनाने पर 409 लौटता है। डुप्लिकेट समीक्षा endpoint प्रति पेज अधिकतम 20 केस लौटता है, और अधिक परिणामों के लिए next_offset देता है। जो मौजूदा API इंटीग्रेशन यह विकल्प नहीं भेजते, उनका केस बनाने का मौजूदा व्यवहार वैसा ही रहता है।