ऐसी KYC रिव्यू क्यू डिज़ाइन करना जो स्केल हो सके

KYC रिव्यू क्यू वह बैक-ऑफ़िस वर्कफ़्लो है जिसमें वे पहचान-जाँचें किसी इंसान के सामने रखी जाती हैं जिन्हें मशीन अपने आप क्लियर नहीं कर सकी। ज़्यादातर आवेदन अपने आप पास होने चाहिए; क्यू उन्हीं के लिए है जो नहीं होते। इसके डिज़ाइन का पूरा लक्ष्य इसे छोटा रखना है, यानी इसमें सिर्फ़ सचमुच की अस्पष्टता रहे और कुछ नहीं। जो क्यू उन मामलों से भर जाए जिनका फ़ैसला मशीन को करना चाहिए था, वह नियंत्रण नहीं, एक अड़चन है जो signup के साथ रैखिक रूप से बढ़ती है। क्यू सही बन जाए तो बैक ऑफ़िस वॉल्यूम के साथ नहीं, exception के साथ स्केल होता है।

यही एक गुण, जान-बूझकर छोटा रखना, आगे के हर फ़ैसले को दिशा देता है। शुरुआत उस बँटवारे से कीजिए जो इसे ऐसा बनाए रखता है।

Straight-through लक्ष्य है, क्यू अपवाद है

Straight-through processing (STP) का मतलब है कि आवेदन बिना किसी इंसानी दख़ल के शुरू से अंत तक क्लियर हो जाए: दस्तावेज़ पढ़े गए, पहचान मिलाई गई, sanctions और PEP स्क्रीनिंग साफ़ रही, liveness पास हुई, फ़ैसला दर्ज हुआ। यही आम राह होनी चाहिए, और इस राह से निकलने वाले आवेदनों का हिस्सा, यानी STP रेट, वही एक आँकड़ा है जो बताता है कि क्यू स्केल करेगी या नहीं। अगर नब्बे-पचानवे प्रतिशत अपने आप क्लियर होते हैं, तो इंसानी क्यू में मामूली-सी धार पहुँचती है। अगर आधे रिव्यू में गिरते हैं, तो आप बढ़त के साथ-साथ रिव्यूअर भर्ती करते जा रहे हैं। KYC क्यू में नहीं होती। क्यू वह जगह है जहाँ स्वचालित KYC मानता है कि उसे यक़ीन नहीं है। STP रेट ऊपर ले जाइए तो बाक़ी हर आँकड़ा मुफ़्त में सुधरता है: कम केस क्यू में, छोटा इंतज़ार, कम रिव्यूअर रखने पड़ेंगे। इस पर सीधे काम करना बनता है, जैसे क्लाइंट पर बेहतर दस्तावेज़ कैप्चर, फ़ोटो खींचने से पहले साफ़ निर्देश, और मैचिंग थ्रेशोल्ड इस तरह ट्यून करना कि असली ग्राहक किसी ज़रूरत से ज़्यादा सतर्क नियम से लौटाए न जाएँ। वहाँ बचाया गया हर प्रतिशत अंक एक ऐसा केस है जो कभी किसी की पूरी दोपहर नहीं बनेगा।

क्यू में क्या आता है, और क्यों

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

एक क्यू काफ़ी नहीं: कारण के आधार पर बाँटिए

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

रिव्यू क्यू को रिव्यूअर बढ़ाकर स्केल नहीं किया जाता। वह तब स्केल होती है जब आप सही तरीके से तय कर लें कि किन केसों को रिव्यू की ज़रूरत ही नहीं थी — और जिन्हें ज़रूरत है, वे कारण के आधार पर पहले से छँटकर पहुँचें।

कारण अनिवार्य, ऑडिट की जाने वाली कार्रवाइयाँ

रिव्यूअर का हर निर्णय — approve, reject, escalate, या और दस्तावेज़ माँगना — कारण के साथ होना चाहिए और दर्ज होना चाहिए। कारण बाद में जोड़ा गया फ़्री-टेक्स्ट नहीं, बल्कि एक संरचित चयन हो, जो कार्रवाई के क्षण पर ही बताए कि वह क्यों की गई। यह नौकरशाही नहीं है; इसी से क्यू पर सवाल उठने पर जवाब दिया जा सकता है। जब कोई रेगुलेटर, ऑडिटर या बाद का रिव्यूअर पूछे कि फ़्लैग के बावजूद कोई अकाउंट क्यों approve हुआ, तो जवाब में एक नामित रिव्यूअर, टाइमस्टैम्प और दर्ज कारण होता है — कंधे उचकाना नहीं। ऑडिट ट्रेल append-only है, इसलिए किसी निर्णय को बाद में चुपचाप बदला नहीं जा सकता; सुधार नई एंट्री के रूप में होते हैं, पुरानी एंट्री पर बदलाव के रूप में नहीं। हमारे स्टैक में यह क्यू और इसका ऑडिट मॉडल Protocore Center (/products/center) में है — यह ऑपरेटर कंसोल है जहाँ हर विशेषाधिकार वाली कार्रवाई के लिए कारण ज़रूरी है और वह ऐसे लॉग में दर्ज होती है जिसे चुपचाप बदला नहीं जा सकता।

फ़ोर-आइज़ वाले केस

कुछ निर्णय इतने गंभीर होते हैं कि उन्हें अकेले एक व्यक्ति पर नहीं छोड़ा जा सकता। किसी वास्तविक sanctions हिट को क्लियर करना, हाई-रिस्क प्रोफ़ाइल को approve करना, या किसी स्वचालित reject को पलटना — इन सबमें दूसरे रिव्यूअर की पुष्टि ज़रूरी होनी चाहिए: maker-checker, यानी four-eyes। पहला रिव्यूअर प्रस्ताव रखता है और कारण बताता है; दूसरा, जिसके पास इसका अधिकार हो, पुष्टि या अस्वीकार करता है और अपना कारण बताता है। दोनों कार्रवाइयाँ लॉग होती हैं। यह रिव्यूअर पर अविश्वास नहीं है; यह इस बात की स्वीकृति है कि सबसे जोखिम भरी मंज़ूरियों में एक चूक सबसे महँगी पड़ती है, और दूसरी जोड़ी आँखें उसके विरुद्ध सबसे सस्ता बीमा हैं। क्यू के डिज़ाइन में ऐसे केस कारण के आधार पर अपने-आप दो-चरणीय प्रक्रिया में जाने चाहिए, रिव्यूअर की याददाश्त पर निर्भर रहे बिना। फिर भी दो-चरणीय प्रक्रिया सोच-समझकर केवल गंभीर केसों के लिए रखें; उसे हर चीज़ पर लगाने से पूरी क्यू की लागत दोगुनी हो जाती है और रिव्यूअर दूसरे हस्ताक्षर पर आँख मूँदकर मुहर लगाने लगते हैं, जो उसके होने का मकसद ही चुपचाप खत्म कर देता है।

वॉल्यूम के लिए डिज़ाइन: एजिंग, प्राथमिकता, SLA

जो क्यू सिर्फ़ बढ़ती है, वह क्यू विफल हो चुकी है। उसे चलाए रखने वाला दबाव डिज़ाइन में ही शामिल करें। केस की एजिंग साफ़ दिखे, ताकि कुछ भी भुला कर पड़ा न रहे; हर सेगमेंट का अपना service-level लक्ष्य हो, ताकि धुँधली फ़ोटो वाला केस जो कुछ मिनटों का SLA तोड़ रहा है, उस sanctions केस से अलग दिखे जो अपने लंबे SLA के भीतर है। प्राथमिकता तय करना एक वास्तविक चुनाव है: oldest-first निष्पक्ष और सरल है, लेकिन risk-first — यानी सबसे बड़ा संभावित जोखिम सबसे ऊपर — अक्सर सही फ़ैसला होता है, और एजिंग टाई-ब्रेकर का काम करती है ताकि कम जोखिम वाले केस भी निपटें, भूखे न रहें। रिव्यूअर की स्क्रीन पर अगला केस पहले से रूट और प्राथमिकता तय होकर आना चाहिए, चुनने के लिए सूची नहीं — क्योंकि जिस क्यू में लोग चुनकर काम उठाते हैं, उसमें कठिन केस कभी नहीं उठाए जाते। जिस क्यू में एजिंग दिखाई नहीं देती, वह चुपचाप सड़ती है: कठिन केस नीचे डूब जाते हैं, आसान केस ऊपर घूमते रहते हैं, और जो एक मीट्रिक इसे उजागर कर देती — सबसे पुराने खुले केस की उम्र — वही संख्या है जिसे कोई तब तक नहीं देखता जब तक कोई ग्राहक शिकायत न करे।

क्यू को मापना

चार संख्याएँ बताती हैं कि डिज़ाइन काम कर रहा है या नहीं। STP रेट बताती है कि कितने केसों को इंसान की ज़रूरत ही नहीं पड़ी; क्यू की गहराई और उसका ट्रेंड बताता है कि आप रफ़्तार बनाए हुए हैं या पीछे छूट रहे हैं; time-to-decision, हर सेगमेंट के SLA के मुकाबले ट्रैक किया गया, बताता है कि ग्राहकों को ऑनबोर्ड होने के लिए ज़रूरत से ज़्यादा इंतज़ार तो नहीं करना पड़ रहा; और reopen रेट — जो निर्णय बाद में पलटे गए — बताती है कि रिव्यूअर सही फ़ैसले ले रहे हैं या सिर्फ़ जल्दी। इन्हें साथ-साथ देखें, क्योंकि ये एक-दूसरे के विरुद्ध काम करती हैं: reopen रेट बढ़ते हुए time-to-decision घटाने का मतलब है कि आपने गलतियों के बदले रफ़्तार खरीदी। एक स्वस्थ क्यू छोटी होती है, चलती रहती है, सही निर्णय लेती है, और अपने भीतर खुले केसों के बारे में ईमानदार रहती है।

बैक ऑफ़िस की जो छवि लोग सोचते हैं — कर्मचारियों से भरे कमरे जो आवेदन दर आवेदन हाथ से भरते जा रहे हैं — वही तब मिलती है जब ऑटोमेशन बहुत कम केस निपटाता है और क्यू एक बेतरतीब ढेर होती है। जो बैक ऑफ़िस स्केल करता है, वह इसका उलट है: ज़्यादातर आवेदन किसी इंसान तक पहुँचते ही नहीं, जो पहुँचते हैं वे कारण और प्राथमिकता के हिसाब से छँटकर आते हैं, हर कार्रवाई कारण के साथ append-only लॉग में जाती है, और four-eyes उन निर्णयों की रखवाली करता है जिन्हें इसकी ज़रूरत है। क्यू को अपवादों के लिए बनाइए, तो आपके बढ़ने पर भी वह छोटी रहेगी। उसे ऐसी जगह बनाइए जहाँ KYC होता है, तो वह हर नए साइनअप के साथ बढ़ती जाएगी।