KYB टेस्टिंग चेकलिस्ट उन टीमों के लिए है जो ऐसा प्रवाह बना रही हैं जिसमें कोई कारोबार अपनी पहचान साबित करता है और आगे के लिए मंज़ूरी मांगता है। KYB का मतलब Know Your Business है, और चुनौती यह है कि यहां सत्यापन किसी व्यक्ति से नहीं, इकाई से किया जाता है, जिसकी कोई जन्मतिथि, कोई दस्तावेज़ और कोई एक पहचान नहीं होती।
इस लेख में वह ढांचा है जिससे यह फ़्लो टेस्ट के लायक बनता है: यह असल में क्या सत्यापित करता है, यह व्यक्ति के सत्यापन से मुश्किल क्यों है, आवेदक को क्या देना पड़ता है, अस्वीकृति और समीक्षा का बर्ताव कैसा हो, और इसे स्थितियों, सबूतों तथा रिटेंशन के हिसाब से कैसे मॉडल करें।
KYB फ़्लो असल में क्या सत्यापित करता है?
इकाई के बारे में कुछ ठोस तथ्य, जो अलग अलग स्रोतों से जुटाए जाते हैं और आपस में मिलाए जाते हैं।
- अस्तित्व — कहीं कोई ऐसी इकाई दर्ज है जिसका वह दावा कर रहा है।
- पहचान — कंपनी का नाम, उसका पंजीकरण नंबर और उसका कानूनी स्वरूप आपस में सुसंगत हैं।
- स्थान — उसका पंजीकृत पता उसी अधिकार क्षेत्र से मेल खाता है जिसका दावा किया गया है।
- स्वामित्व और नियंत्रण — असल में किसका नियंत्रण है, कानूनी मालिकों से आगे जाकर।
- गतिविधि — कारोबार वह करता है जो वह कहता है, और वह उस दायरे में है जिसे आपकी प्रक्रिया स्वीकार करती है।
- प्रतिनिधित्व — जो इंसान यह अनुरोध कर रहा है वह इकाई की तरफ़ से बोलने के लिए वाकई अधिकृत है।
यह छह अलग सवाल हैं, और उनका जवाब अक्सर अलग अलग रजिस्टरों में बिखरा होता है। इसी वजह से KYB को एक जांच के रूप में नहीं, कई जांचों के जमाव के रूप में मॉडल करना चाहिए, जिनमें से हर एक का अपना स्रोत, अपना भरोसा-स्तर और अपना असफलता का तरीका हो।
बिज़नेस का सत्यापन किसी व्यक्ति से मुश्किल क्यों है?
तीन ढांचागत वजहों से, और तीनों डेटा मॉडल को सीधे तौर पर प्रभावित करती हैं।
पहली, स्वामित्व एक परत के बजाय एक श्रृंखला है। कोई कंपनी किसी दूसरी कंपनी के स्वामित्व में हो सकती है, जो आगे किसी ट्रस्ट की हो, और इसी तरह कई परतें बनती हैं। असली नियंत्रण खोजने के लिए इस श्रृंखला को चलना पड़ता है, और हर परत के साथ जुड़े दस्तावेज़ भी जुटाने पड़ते हैं।
दूसरी, सबूत बिखरे होते हैं। एक दस्तावेज़ इकाई के अस्तित्व की पुष्टि करता है, दूसरा कर स्थिति का, तीसरा पते का, और कोई इन तीनों को एक साथ नहीं बताता। इसलिए सत्यापन का मतलब किसी एक प्रमाणपत्र की ओर देखना नहीं, बल्कि कई दस्तावेज़ों में से एक सुसंगत तस्वीर जोड़ना है।
तीसरी, सत्यापन एक बार का काम नहीं है। इकाइयां नाम बदलती हैं, विलय करती हैं, पते बदलती हैं, और बंद हो जाती हैं। जो नतीजा आज सही है, वह दो साल बाद सही नहीं भी होगा, इसलिए हर निष्कर्ष के साथ यह भी दर्ज रहना चाहिए कि वह कब निकाला गया था।
आवेदक को क्या जमा करना पड़ता है?
आम तौर पर इनमें से कुछ चीज़ें, और वह चुनाव अधिकार क्षेत्र तथा जोखिम के स्तर से तय होता है।
| दस्तावेज़ का प्रकार | क्या साबित करता है |
|---|---|
| निगमन प्रमाणपत्र | अस्तित्व और पंजीकरण की तारीख़ |
| कर या VAT पंजीकरण का सबूत | कर स्थिति और जारी करने वाला प्राधिकरण |
| पंजीकृत पते का सबूत | स्थान और उसका वर्तमान होना |
| स्वामित्व या नियंत्रण की जानकारी | कौन असल में फ़ैसले लेता है |
| नियंत्रकों के पहचान दस्तावेज़ | उन व्यक्तियों की पहचान जो पर्दे के पीछे हैं |
| लाइसेंस या अनुमति | उस काम के लिए नियामकीय योग्यता |
इस सूची पर एक ज़रूरी चेतावनी लगी है। इनमें से कई मदें वैध रूप से वैकल्पिक हो सकती हैं। हर अधिकार क्षेत्र हर दस्तावेज़ जारी नहीं करता, हर इकाई को लाइसेंस की ज़रूरत नहीं होती, और कुछ केसों में कोई निगमन प्रमाणपत्र मौजूद ही नहीं होता। इसलिए किसी दस्तावेज़ का गायब होना अपने आप कोई कमी नहीं है, और जो प्रणाली हर मद को अनिवार्य कर देती है, वह असली कारोबारों को ऐसे कारण से रोक देती है जिसका कोई अर्थ नहीं।
अस्वीकृति और समीक्षा का बर्ताव कैसा होना चाहिए?
दोनों को सामान्य स्थितियों की तरह, असाधारण नहीं।
हर फ़्लो में ऐसे आवेदन आएंगे जिनकी जानकारी अधूरी है, जिनमें कोई विरोधाभास है, या जो ऐसे देश से आए हैं जहां आपके पास सीधी पूछताछ का रास्ता नहीं है। इनके लिए अलग अलग रास्ते होने चाहिए: अधिक जानकारी मांगने वाला अनुरोध जिसे आवेदक पूरा कर सके, मैनुअल समीक्षा की सूची जहां कोई इंसान देखे, और अस्वीकृति जिसके साथ ऐसा कारण हो जिस पर आवेदक कुछ कर सके।
इस डिज़ाइन के चार नियम व्यावहारिक हैं।
- अस्वीकृति के कारण नियंत्रित शब्दावली से आएं, मुक्त टेक्स्ट से नहीं। इससे वे गिने जा सकते हैं, अनुवादित हो सकते हैं, और उनका विश्लेषण हो सकता है।
- बंद आवेदन जमा न किया जाए। अस्वीकृत आवेदन को नई जानकारी के साथ आगे बढ़ाया जा सकना चाहिए, क्योंकि ज़्यादातर अस्वीकृतियां डेटा की समस्या हैं, धोखे की नहीं।
- मैनुअल समीक्षा को कोई त्रुटि न मानें। वह एक वैध स्थिति है, और उसका कोई समय-बजट होना चाहिए।
- और सबसे ज़रूरी: किसी टेस्ट को पास कराने के लिए कभी कोई जांच बंद न करें। अगर कोई चेक टेस्ट में रुकावट बन रहा है, तो इलाज फ़िक्स्चर है, जांच नहीं।
डेवलपर्स के लिए: स्थितियां, सबूत और रिटेंशन
इस फ़्लो को एक स्पष्ट स्थिति-मशीन के रूप में मॉडल करें, न कि बूलियन के ढेर के रूप में। शुरू नहीं हुआ, जमा किया गया, समीक्षा में, जानकारी की प्रतीक्षा में, मंज़ूर, और अस्वीकृत — ये छह स्थितियां लगभग हर KYB फ़्लो का वर्णन कर लेती हैं, और हर बदलाव के साथ यह दर्ज करें कि कब, किसने और किस कारण से वह हुआ।
सबूत को अपना अलग मॉडल दें। हर दस्तावेज़ के लिए यह रखें कि उसका प्रकार क्या है, किसने या किस देश ने उसे जारी किया, कब जारी हुआ, और कब तक मान्य है। मेटाडेटा को फ़ाइल से अलग रखें, ताकि कोई जांच उस फ़ाइल को खोले बिना भी चल सके, और ताकि भंडारण की नीतियां साफ़ रहें।
स्वामित्व को एक ग्राफ़ की तरह रखें, सूची की तरह नहीं। इकाइयां और व्यक्ति नोड बनें, और स्वामित्व तथा नियंत्रण उनके बीच के किनारे, जिनके साथ यह दर्ज हो कि किस प्रकार का संबंध है और किस स्रोत से पता चला। यही एकमात्र तरीका है जिससे किसी लंबी श्रृंखला में वास्तविक नियंत्रण खोजा जा सकता है।
रिटेंशन को शुरू से ही डिज़ाइन करें। सबूत सीमित समय तक रखें, उन तक पहुंच सीमित रखें, और अलग वातावरणों को अलग रखें — टेस्ट वातावरण में कभी कोई असली दस्तावेज़ या असली आवेदक न हो। इस साइट का कंपनी डेटा जनरेटर ऐसे काल्पनिक रिकॉर्ड बनाता है जिनसे यह पूरा फ़्लो बिना किसी असली इकाई को छुए टेस्ट किया जा सके। सीमाओं पर फ़र्ज़ी कंपनी डेटा वाला लेख और कंपनी रिकॉर्ड में मौजूद चीज़ों पर टेस्ट कंपनी डेटा वाला लेख आगे पढ़ें।
अगले कदम
अपने KYB फ़्लो से छह स्थितियां निकालें और देखें कि उनमें से कोई छूट गई है या नहीं। जो भी आवेदन किसी ऐसी स्थिति में फंसा रह जाए जहां से आगे का कोई रास्ता न हो, वह डिज़ाइन दोष है, सीमा का मामला नहीं। फिर काल्पनिक आवेदनों से एक पूरा रास्ता चलाएं — जमा से लेकर मंज़ूरी तक — और एक जानबूझकर अस्वीकृति वाला भी, ताकि यह साबित हो कि अस्वीकृति के बाद दोबारा कोशिश का रास्ता वाकई खुलता है।