अपनी भाषा चुनें
फिनटेक और ऋण
ऋण आवेदक की पहचान का सत्यापन जो ब्राउज़र या ऐप में चलता है, उधार की या नकली (सिंथेटिक) पहचान को अंडरराइटिंग तक पहुँचने से पहले पकड़ लेता है, और हर जाँच को ऐसे रिकॉर्ड में लिखता है जिसे आप नियामक या ऑडिटर को सौंप सकते हैं। हमारे नियंत्रण वाले इंफ्रास्ट्रक्चर पर होस्ट किया गया। Sandbox सेशन का कभी बिल नहीं बनता।
समस्या
जो ऋण उत्पाद मिनटों में मंज़ूरी देता है, उसे ऐसी पहचान जाँच चाहिए जो उसकी रफ़्तार से चले, और मैन्युअल समीक्षा की कतार में न बदल जाए।
नाम, जन्म तिथि, पता और SIN, सब कागज़ पर सही निकलते हैं। लेकिन उनके पीछे का दस्तावेज़ चोरी की या ख़रीदी हुई पहचान है, या एक से अधिक असली लोगों के फ़ील्ड जोड़कर बनाया गया है।
जिस भी आवेदन को आपकी टीम अपने-आप मंज़ूर नहीं कर पाती, वह एक ऐसा व्यक्ति बन जाता है जो PDF खोलता है, फ़ोटो ID को ग़ौर से देखता है और अंदाज़ा लगाता है। यह धीमा है, समीक्षकों के बीच असंगत है, और मार्केटिंग ख़र्च के साथ नहीं बढ़ पाता।
ऋण स्वीकृत होने के महीनों बाद कोई पूछता है कि उधारकर्ता की पहचान कैसे पुष्ट की गई थी। "हमने उनके लाइसेंस की एक फ़ोटो देखी थी" ऐसा जवाब है जिसे कोई कंप्लायंस प्रमुख दोबारा नहीं देना चाहेगा।
एक काल्पनिक उदाहरण
काल्पनिक, केवल प्रक्रिया का स्वरूप दिखाने के लिए। इसमें कोई असली आवेदक, ऋणदाता या ऋण शामिल नहीं है।
ऋण देने के लिए सबसे ज़रूरी बातें
नीचे दी गई हर जाँच हर सत्यापन में चलती है। इनमें से कुछ भी ऐसा सशुल्क स्तर नहीं है जिसे चालू करना आपको याद रखना पड़े।
विवादों और ऑडिट के लिए
ऋण की फ़ाइल दोबारा खुलती है: कोई उधारकर्ता अस्वीकृति पर विवाद करता है, कोई परीक्षक एक तिमाही के आवेदनों का नमूना लेता है, आंतरिक ऑडिट पूछता है कि किसने क्या छुआ। वह बातचीत Activity Ledger से शुरू होती है।
प्रविष्टियाँ जोड़ी जा सकती हैं। उन्हें संपादित या हटाया नहीं जा सकता — न आपकी टीम द्वारा, न ShieldID द्वारा। यह डेटाबेस का अपना गुण है, कोई नीति नहीं जिसे कोई चुपचाप पलट दे।
हर प्रविष्टि कर्ता — कोई व्यक्ति या API key — कार्रवाई, परिणाम और टाइमस्टैम्प दर्ज करती है, ताकि "इस आवेदक को किसने सत्यापित किया और इंजन ने क्या रिपोर्ट किया" का सीधा उत्तर मिले, पुनर्निर्मित अनुमान नहीं।
कर्ता, कार्रवाई, परिणाम या तिथि सीमा के अनुसार फ़िल्टर करें, ताकि अनुपालन समीक्षा या उधारकर्ता विवाद के लिए ठीक वही प्रविष्टियाँ निकाली जा सकें, न कि सब कुछ एक्सपोर्ट करके हाथ से रिडैक्ट करना पड़े।
आज ledger सफल और विफल सत्यापन परिणाम, साइन-इन और API-key गतिविधि, तथा ऑडिट एक्सपोर्ट दर्ज करता है। ID इमेज के प्रति-व्यू और प्रति-डाउनलोड इवेंट, एक समर्पित निर्णय इवेंट, purge रसीदें और आपकी टीम के लिए स्वयं-सेवा CSV एक्सपोर्ट जल्द आ रहे हैं।
इंटीग्रेशन विकल्प
ज़्यादातर ऋण टीमें उस बिंदु पर होस्टेड फ़्लो से शुरू करती हैं जहाँ वे अन्यथा दस्तावेज़ अपलोड माँगतीं, और वॉल्यूम उचित ठहराने पर API पर चली जाती हैं।
साफ़-साफ़ शब्दों में
सीधे कहना ज़रूरी है, क्योंकि फिनटेक ख़रीदार यह पूछेगा ही।
यह एक सवाल का अच्छा जवाब देता है: क्या यह कोई असली व्यक्ति है, जो अपनी असली सरकारी ID पकड़े हुए है। यह आपके अंडरराइटिंग नियमों, आपके क्रेडिट-ब्यूरो पुल और आपके अपने फ्रॉड मॉडल के नीचे बैठता है, उनकी जगह नहीं लेता।
प्रतिबंध (sanctions) और वॉचलिस्ट जाँच उन खातों के लिए उपलब्ध है जो इन्हें जोड़ते हैं; ये डिफ़ॉल्ट रूप से हर प्लान में शामिल नहीं हैं।
ShieldID आज बैंक खातों या आय का सत्यापन नहीं करता; यह सुविधा जल्द आ रही है। यदि आपके कार्यक्रम को यह अभी चाहिए, तो ShieldID की पहचान जाँच को अपने मौजूदा बैंक-सत्यापन या आय-सत्यापन प्रदाता के साथ इस्तेमाल करें।
गोपनीयता नोट
ऋण आवेदक का ID अपने आप में संवेदनशील होता है। उसके साथ ठीक-ठीक क्या होता है, यहाँ देखें।
मैन्युअल तरीके के मुक़ाबले
श्रेणियों की तुलना, किसी विशेष विक्रेता के बारे में दावा नहीं।
| क्षमता | ShieldID | सामान्य एंटरप्राइज़ IDV | मैन्युअल जाँचें |
|---|---|---|---|
| दस्तावेज़ पढ़ा गया और आवेदन से मिलान किया गया | हाँ | आम तौर पर | समीक्षक का विवेकाधीन निर्णय |
| लाइवनेस चुनौती, सिर्फ़ स्थिर सेल्फ़ी नहीं | हाँ | आम तौर पर | नहीं |
| हर धोखाधड़ी संकेत अलग से रिपोर्ट किया जाता है | हाँ | अक्सर स्तरीय (tiered) | ट्रैक नहीं किया जाता |
| हर समीक्षक और हर शिफ़्ट में एक समान मानक | हाँ | आम तौर पर | नहीं |
| केवल-जोड़ने वाला Activity Ledger जिसे आप विवाद के लिए खोज सकते हैं | हाँ | ग्राहक को उपलब्ध नहीं कराया जाता | एक ईमेल थ्रेड, अगर किस्मत अच्छी हो |
| आवेदक की गति से, इंतज़ार के लिए कोई मैन्युअल कतार नहीं | हाँ | आम तौर पर | नहीं |
| ऐसा sandbox जिसका कभी बिल नहीं बनता | हाँ | कभी-कभी | n/a |
आपत्तियाँ
"आपके SOC 2 और ISO बैज कहाँ हैं?"
वे अभी हमारे पास नहीं हैं, और जो हमने अर्जित नहीं किए उन्हें हम नहीं छापते। आज आप क्या सत्यापित कर सकते हैं: स्वयं-प्रबंधित होस्टिंग, सार्वजनिक क्लाउड नहीं, इमेज का स्वतः purge, स्टोरेज में एन्क्रिप्टेड इमेज और एक केवल-जोड़ने वाला ledger जिसे आप उत्पाद के भीतर पढ़ सकते हैं।
"क्या यह हमारे FINTRAC या AML पहचान-सत्यापन दायित्वों को पूरा करता है?"
ShieldID आपको एक प्रलेखित, दोहराने योग्य पहचान जाँच देता है जिसके पीछे रिकॉर्ड होता है। यह किसी विशिष्ट नियामक पद्धति को पूरा करता है या नहीं, यह आपके अपने कंप्लायंस प्रोग्राम और वकील को तय करना है — हम क़ानूनी सलाह नहीं देते, और हम यह नहीं कहेंगे कि यह खाना पहले से भरा हुआ है।
"हमारी फ्रॉड टीम बैंक-खाता सत्यापन भी चाहती है।"
यह आज ShieldID में उपलब्ध नहीं है; जल्द आ रहा है। तब तक ShieldID की पहचान जाँच को अपने मौजूदा बैंक या आय-सत्यापन टूल के साथ इस्तेमाल करें — हम यह दिखावा नहीं करते कि हम इसे अभी कवर करते हैं।
"अगर आवेदक की ID अपरिचित हो — जैसे किसी नए आए व्यक्ति का विदेशी लाइसेंस — तो क्या होगा?"
इसे सीधे अस्वीकार करने के बजाय फ़ील्ड-दर-फ़ील्ड पढ़ा जाता है, और नियम-आधारित स्कैनर ठीक यहीं असली आवेदकों को बाहर कर देते हैं। आप फ़ील्ड के अनुसार देखते हैं कि क्या सत्यापित हुआ और क्या नहीं।
आप क्या देखते हैं
उधारकर्ता आवेदन के दौरान ही सत्यापन करता है। आपकी टीम हर फ़ील्ड का स्रोत और हर जाँच अलग-अलग देखती है, भरोसा करने या अनदेखा करने के लिए कोई एक स्कोर नहीं।
प्रश्न
शुरू करें
एक sandbox सेशन बनाएँ, अपने फ़ोन पर सत्यापन चलाएँ, और देखें कि यह Activity Ledger में कौन-सी प्रविष्टि लिखता है।
Sandbox सेशन का कभी बिल नहीं बनता।