KYC बनाम KYB: फ़र्क क्या है और दोनों कब चाहिए

मुख्य बातें

• KYC एक व्यक्ति के बारे में है: वह कौन है, पहचान उसकी है या नहीं, और उससे संपर्क कैसे होगा। KYB एक संस्था के बारे में है: वह मौजूद है, उसकी स्थिति क्या है, उसे कौन चलाता और कौन असल में उसका मालिक है, और उसकी तरफ़ से हस्ताक्षर कौन कर सकता है।
• कारोबारी ग्राहक पर दोनों लगती हैं। संस्था पर KYB, और आवेदन करने वाले व्यक्ति पर KYC के साथ अधिकार का सबूत।
• भारत में कानूनी तौर पर KYC और customer due diligence ही शब्द चलते हैं, व्यक्ति और संस्था दोनों के लिए। KYB नाम की अलग कोई वैधानिक चीज़ नहीं है।
• कौन-सी जाँच चलेगी, यह संस्था के प्रकार पर निर्भर है: प्रोपराइटरशिप मालिक के ज़रिए, कंपनी रजिस्ट्री और टैक्स रजिस्ट्रेशन के ज़रिए, ट्रस्ट डीड और ट्रस्टियों के ज़रिए।
• StampMitra पहचान और रजिस्ट्री की जाँच PAN, GSTIN, CIN, Udyam और bank account endpoint से देता है। वह Aadhaar आधारित verification नहीं देता, और बोर्ड प्रस्ताव, पार्टनरशिप डीड या beneficial ownership घोषणा जैसे दस्तावेज़ों की जगह नहीं लेता।
• Beneficial ownership KYB का सबसे कठिन हिस्सा है। रजिस्ट्री लुकअप में निदेशक दिखते हैं, वे लोग नहीं जो असल में मालिक या नियंत्रक हैं। इसलिए घोषणा और उसके सबूत लेने पड़ते हैं।
• दोनों को एक ही pipeline की तरह बनाइए, जहाँ "पक्ष" (party) या तो व्यक्ति है या संस्था और जाँचें प्रकार से चुनी जाती हैं। कोड को दो हिस्सों में मत बाँटिए।
• संस्थाओं की दोबारा जाँच व्यक्तियों से ज़्यादा मायने रखती है, क्योंकि संस्थाओं की स्थिति, निदेशक और रजिस्ट्रेशन बदलते रहते हैं।

सबसे पहले: किसे कौन-सी जाँच चाहिए

कोड से पहले हालात की तालिका देखिए, क्योंकि अक्सर सवाल "API कौन-सी" से पहले "ग्राहक कौन" का होता है।

KYC और KYB आमने-सामने

ये शब्द कहाँ से आए और डिज़ाइन पर इसका क्या असर है

भारत में KYC के दायित्व कई जगह से आते हैं। Prevention of Money-laundering Act, 2002 और उसके नियम रिकॉर्ड रखने और ग्राहक की पहचान का ढाँचा तय करते हैं। भारतीय रिज़र्व बैंक का KYC पर Master Direction उन संस्थाओं पर लागू होता है जिन्हें वह नियंत्रित करता है, जैसे बैंक और गैर-बैंकिंग वित्तीय कंपनियाँ। SEBI, IRDAI और दूसरे क्षेत्रीय नियामकों के अपने निर्देश हैं, और भुगतान पार्टनर तथा बैंक अनुबंध में और शर्तें जोड़ देते हैं।

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

अगर आप नियंत्रित संस्था नहीं हैं, मसलन मार्केटप्लेस, SaaS या पेरोल टूल चलाते हैं, तो वही जाँचें compliance नहीं, जोखिम प्रबंधन हैं। आप उन्हें धोखाधड़ी और ख़राब पार्टियों को बाहर रखने के लिए चुनते हैं और जोखिम के हिसाब से घटा-बढ़ा सकते हैं। यही आज़ादी अपनी नीति लिखकर रखने की वजह भी है: बाद में आप समझा पाएँ कि एक वेंडर को हल्की जाँच क्यों मिली और दूसरे को भारी क्यों।

यह कानूनी सलाह नहीं है। जहाँ किसी फ़ैसले में नियम या सीमा मायने रखती हो, वहाँ मौजूदा पाठ देखिए और वकील से पूछिए।

व्यक्ति पर KYC में क्या-क्या होता है

किसी व्यक्ति के लिए सामान्य क्रम में चार हिस्से होते हैं।

पहचान। यह पक्का कीजिए कि पहचान असली है और उस नाम के व्यक्ति की है जो ग्राहक ने बताया। भारत में ज़्यादातर कारोबारी प्रवाहों में व्यावहारिक आधार PAN है: लुकअप रिकॉर्ड का नाम लौटाता है, और नाम भेजें तो मिलान का नतीजा भी। PAN न हो या काफ़ी न हो तो voter ID, driving licence और passport वही काम करते हैं, और हर एक का अपना StampMitra endpoint है।

पहचान पर मालिकाना। कठिन सवाल यह है कि सामने बैठा व्यक्ति धारक है या नहीं। PAN लुकअप अकेले इसका जवाब नहीं दे सकता, क्योंकि नंबर गुप्त नहीं होता। नीतियाँ इस ख़ाली जगह को अतिरिक्त कदमों से भरती हैं, जैसे दस्तावेज़ की फ़ोटो, liveness जाँच, या ग्राहक के नाम वाले खाते से लेन-देन। StampMitra के verification endpoint Aadhaar आधारित verification या चेहरे का मिलान नहीं देते, इसलिए आपकी नीति में ये ज़रूरी हों तो इन्हें कहीं और से लीजिए।

पता और संपर्क। पते का सबूत ग्राहक के दिए दस्तावेज़ों से आता है। संपर्क की पुष्टि कोड या लिंक भेजकर होती है, जो verification API के बाहर है।

भुगतान या फ़ंडिंग खाता। अगर ग्राहक को पैसा जाना है, तो पक्का कीजिए कि बैंक खाता मौजूद है और खाताधारक का नाम मेल खाता है। यह bank account verification endpoint का काम है, जिसे penny drop बनाम name match में विस्तार से समझाया गया है।

व्यक्ति पर KYC शायद ही कभी एक call होती है। वह एक छोटी कड़ी है, जिसमें सस्ती और निर्णायक जाँचें पहले चलती हैं। कर्ज़ के लिए यह कड़ी fintech और NBFC के लिए KYC वाले यूज़ केस में चलकर दिखाई गई है।

संस्था पर KYB में क्या-क्या होता है

संस्था की कड़ी लंबी होती है, और हर कड़ी अलग सवाल का जवाब देती है।

1. अस्तित्व। क्या संस्था किसी रजिस्ट्री में है? कंपनी के लिए CIN लुकअप कंपनी का रिकॉर्ड लौटाता है। LLP के लिए रजिस्ट्री नंबर LLPIN है। प्रोपराइटरशिप का कंपनी रजिस्ट्री में कोई रिकॉर्ड नहीं होता, इसलिए अस्तित्व मालिक की पहचान और सहायक रजिस्ट्रेशनों पर टिकता है। पार्टनरशिप और ट्रस्ट का सबूत उनकी डीड और जहाँ लागू हो, राज्य के पंजीकरण से मिलता है।
2. स्थिति। क्या वह चालू है? CIN के जवाब में cinStatus और companyStatus आते हैं। GSTIN के जवाब में registrationStatus। हटाई गई कंपनी, रद्द GST रजिस्ट्रेशन या निलंबित रजिस्ट्रेशन रुकने या समीक्षा के कारण हैं।
3. टैक्स पहचान। संस्था का PAN और GST रजिस्ट्रेशन क्या हैं, और क्या वे एक ही संस्था के हैं? दूसरे आधे का जवाब PAN to GSTIN लुकअप देता है।
4. लोग। निदेशक, पार्टनर या ट्रस्टी कौन हैं? CIN के जवाब में निदेशकों की सूची DIN, नाम और पदनाम के साथ आती है। पार्टनरशिप और ट्रस्ट दस्तावेज़ों पर निर्भर हैं।
5. अधिकार। क्या आवेदन करने वाला व्यक्ति संस्था को बाध्य कर सकता है? इसके लिए दस्तावेज़ चाहिए: बोर्ड प्रस्ताव, authorisation letter, पार्टनरशिप डीड की कोई धारा। कोई लुकअप यह नहीं लौटाता।
6. स्वामित्व और नियंत्रण। अंततः संस्था का मालिक या नियंत्रक कौन है? इसका अलग हिस्सा नीचे है।
7. फ़ंडिंग खाता। क्या संस्था के अपने नाम का बैंक खाता है? चालू खाते का सबूत, या bank account verification जहाँ खाताधारक का नाम संस्था के नाम से मिले।
8. उद्देश्य और जोखिम। कारोबार क्या करता है, और क्या वह ऐसी श्रेणी में है जिसे आपकी नीति ऊँचे जोखिम का मानती है? यह फ़ैसले का सवाल है, जिसमें उद्योग कोड जहाँ हैं वहाँ मदद करते हैं।

लुकअप खुद GSTIN, CIN और Udyam से बिज़नेस वेरिफ़िकेशन में हैं, और हर पहचान क्या साबित कर सकती है और क्या नहीं, यह PAN, GSTIN और CIN में फ़र्क में समझाया है।

संस्था के प्रकार के हिसाब से KYB

कानूनी रूप बदलने के साथ चेकलिस्ट बदलती है। यह तालिका शुरुआती ढाँचा है, नियम नहीं: आपका नियामक या पार्टनर और माँग सकता है।

यह कोई काल्पनिक ढाँचा नहीं है। StampMitra अपने ग्राहकों से लगभग यही माँगता है। production access फ़ॉर्म आवेदक का प्रकार लेता है (व्यक्ति, प्रोपराइटरशिप, पार्टनरशिप फ़र्म, LLP, प्राइवेट लिमिटेड, पब्लिक लिमिटेड, ट्रस्ट या सोसाइटी), उम्मीद करता है कि PAN का चौथा अक्षर उस प्रकार से मेल खाए (P, F, C, T या A), LLP और कंपनी से CIN और कंपनी से GSTIN माँगता है, और दाएँ कॉलम वाले दस्तावेज़ लेता है। जब आवेदक कंपनी का निदेशक हो तो बोर्ड प्रस्ताव की शर्त हट जाती है। यह छोटी बात आपके अपने प्रवाह का नमूना है: जहाँ लुकअप पहले ही वही भरोसा दे चुका हो, वहाँ भारी सबूत छोड़ देने का नियम।

प्रोपराइटर: जहाँ KYC और KYB घुल जाते हैं

प्रोपराइटरशिप कोई अलग कानूनी व्यक्ति नहीं है। कारोबार वही व्यक्ति है जो किसी नाम से व्यापार करता है। इसलिए यह कारोबारी सबूत जुड़ा KYC का मामला है। एक उदाहरण लीजिए: "शर्मा ट्रेडर्स" नाम से कपड़े का थोक करने वाले सुरेश शर्मा।

• पहचान और टैक्स: सुरेश का PAN, वैसे ही जाँचा जाए जैसे किसी भी व्यक्ति का।
• कारोबार का अस्तित्व: GSTIN, Udyam पंजीकरण, दुकान और प्रतिष्ठान का लाइसेंस, या कारोबार के नाम का चालू खाता, जो भी वे दिखा सकें। हर प्रोपराइटर के लिए कोई एक अनिवार्य नहीं होता, और आप क्या माँगें यह आपकी नीति और कारोबार के काम पर निर्भर है।
• नाम का मिलान: PAN में सुरेश का नाम है, जबकि GSTIN में वही नाम legalName है और "शर्मा ट्रेडर्स" tradeName। नाम की तुलना legalName से कीजिए, ट्रेड नाम से कभी नहीं।
• फ़ंडिंग खाता: सुरेश के नाम का या कारोबार के नाम का बैंक खाता। दोनों मिलते हैं। पहले से तय कर लीजिए कि कौन-सा मानेंगे और बेमेल को कैसे सँभालेंगे।

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

Beneficial ownership और नियंत्रण

Beneficial ownership का सवाल "निदेशक कौन हैं" से अलग है। निदेशक कंपनी चलाते हैं। Beneficial owner वे प्राकृतिक व्यक्ति हैं जो अंततः उसके मालिक हैं या उस पर नियंत्रण रखते हैं, चाहे दूसरी संस्थाओं की परतों के ज़रिए। नियमों की परिभाषाएँ संस्था के प्रकार के अनुसार स्वामित्व की सीमाएँ इस्तेमाल करती हैं, जो समय-समय पर बदली गई हैं, इसलिए जो आप पर लागू हो उसका मौजूदा नियम देखिए।

रजिस्ट्री लुकअप से यह तय नहीं हो सकता। CIN के जवाब में निदेशक आते हैं, यह शेयरधारक रजिस्टर नहीं है। व्यवहार में KYB प्रवाह संस्था से beneficial ownership की घोषणा लेता है, शेयरहोल्डिंग पैटर्न जैसे दस्तावेज़ों के साथ, और घोषणा में नामित उन प्राकृतिक व्यक्तियों पर KYC चलाता है जो संबंधित सीमा से ऊपर हैं। जहाँ कोई मालिक खुद एक कंपनी हो, वहाँ आप उस कंपनी पर फिर KYB चलाते हैं, तब तक जब तक इंसान तक न पहुँच जाएँ।

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

दोनों प्रवाहों को एक pipeline बनाना

सबसे ज़्यादा इंजीनियरिंग समय इस ग़लती में जाता है कि KYC और KYB को अलग-अलग ऐप्लिकेशन बना दिया जाए। जाँचें वही बुनियादी इकाइयाँ हैं, अलग मेल में। इसलिए एक "पक्ष" (party) रखिए और उसका प्रकार जाँचें चुनने दीजिए।

import os, requests

BASE = "https://api-b2b.stampmitra.in/v1/verify"
HEADERS = {"Authorization": f"Bearer {os.environ['STAMPMITRA_API_KEY']}", "Content-Type": "application/json"}

def verify(path: str, body: dict) -> dict:
    r = requests.post(f"{BASE}/{path}", json=body, headers=HEADERS, timeout=10)
    data = r.json()
    if not r.ok:
        return {"ok": False, "status": r.status_code, "code": data["error"]["code"], "request_id": data["error"]["requestId"]}
    return {"ok": True, "data": data}

PLAN = {
    "INDIVIDUAL": lambda p: [("pan", {"pan": p["pan"], "name": p["name"]}), ("bank-account", p["bank"])],
    "PROPRIETORSHIP": lambda p: [("pan", {"pan": p["pan"], "name": p["name"]})]
        + ([("gstin", {"gstin": p["gstin"], "businessName": p.get("trade_name")})] if p.get("gstin") else []),
    "PRIVATE_LTD": lambda p: [
        ("pan", {"pan": p["pan"], "name": p["name"]}),
        ("gstin", {"gstin": p["gstin"], "businessName": p["name"]}),
        ("cin", {"cin": p["cin"]}),
    ],
}

def run_checks(party: dict) -> list:
    results = []
    for path, body in PLAN.get(party["type"], PLAN["INDIVIDUAL"])(party):
        r = verify(path, body)
        results.append({"path": path, **r})
        if not r["ok"] or r["data"].get("valid") is False:
            break  # पहली पक्की विफलता पर रुकिए, आगे की calls सिर्फ़ पैसा खर्च कराएँगी
    return results

और संस्था के लिए हस्ताक्षरकर्ता की जाँच cURL से, ताकि कच्चा अनुरोध साफ़ दिखे:

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/cin" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"cin":"U74999DL2015PTC284009"}'

जवाब में directors की सूची आती है। अगर हस्ताक्षरकर्ता का नाम उसमें मिल जाए, तो वह निदेशक है, और यही वह व्युत्पन्न तथ्य है जिससे आप भारी दस्तावेज़ की शर्त हटा सकते हैं, जैसे StampMitra का फ़ॉर्म बोर्ड प्रस्ताव के साथ करता है। नाम की यह तुलना जान-बूझकर मोटी रखी जाए तो ठीक है, पर production में नाम को पहले सामान्य रूप में लाइए और निदेशकों के DIN ऑडिट रिकॉर्ड में रखिए।

पक्ष और रिश्तों का डेटा मॉडल

पक्षों की एक तालिका और रिश्तों की एक तालिका रखिए। पक्ष व्यक्ति या संस्था है। रिश्ता दो पक्षों को एक भूमिका से जोड़ता है: हस्ताक्षरकर्ता, निदेशक, मालिक, प्रोपराइटर। यह सपाट ग्राहक पंक्ति से भारी लगता है, पर यही वह आकार है जिसमें एक व्यक्ति दो कंपनियों का हस्ताक्षरकर्ता बनकर दोहराया नहीं जाता, और एक कंपनी दूसरी कंपनी की मालिक हो सकती है।

{
  "parties": [
    { "id": "p1", "kind": "ENTITY", "type": "PRIVATE_LTD", "name": "Jane Doe Enterprises Private Limited", "pan": "ABCDE1234F", "cin": "U74999DL2015PTC284009" },
    { "id": "p2", "kind": "PERSON", "name": "Rahul Kumar", "pan": "PQRSX1234L" }
  ],
  "relationships": [
    { "from": "p2", "to": "p1", "role": "DIRECTOR", "evidence": "SMV-20260927-6R38Y3" },
    { "from": "p2", "to": "p1", "role": "AUTHORISED_SIGNATORY", "evidence": "doc_authorisation_letter_0142" }
  ]
}

दो बातें ध्यान देने की हैं। evidence फ़ील्ड या तो API के referenceId की तरफ़ इशारा करता है या दस्तावेज़ की id की, यानी समीक्षक को स्रोत चाहे जो हो, सबूतों की एक ही सूची दिखती है। और निदेशक वाला रिश्ता लुकअप से निकला है जबकि हस्ताक्षरकर्ता वाला दस्तावेज़ पर टिका है, यह फ़र्क आपके टूल में दिखता रहना चाहिए।

एक पूरा उदाहरण: कंपनी की कर्ज़ अर्ज़ी और उसका हस्ताक्षरकर्ता

मान लीजिए एक काल्पनिक ऋणदाता को Jane Doe Enterprises Private Limited की अर्ज़ी मिलती है, जिस पर Rahul Kumar के हस्ताक्षर हैं।

1. आवेदक का प्रकार प्राइवेट लिमिटेड है, इसलिए योजना है: संस्था का PAN, GSTIN और CIN, फिर हस्ताक्षरकर्ता का PAN।
2. संस्था के PAN का चौथा अक्षर C है, यानी संगत। PAN लुकअप valid: true लौटाता है और पंजीकृत नाम मेल खाता है।
3. GSTIN लुकअप registrationStatus: Active लौटाता है। उसमें बैठा PAN संस्था के PAN के बराबर है। principal place of business वही शहर है जो अर्ज़ी में है।
4. CIN लुकअप 2015 में बनी चालू कंपनी दिखाता है, जिसके निदेशकों में Rahul Kumar नाम का एक निदेशक है।
5. हस्ताक्षरकर्ता के निजी PAN का लुकअप Rahul Kumar से मेल खाता है। वह सूचीबद्ध निदेशक भी है, इसलिए नीति बोर्ड प्रस्ताव की शर्त छोड़ देती है और सिर्फ़ authorisation letter माँगती है।
6. Beneficial ownership घोषणा में सीमा से ऊपर के दो शेयरधारकों के नाम हैं। दोनों पर व्यक्तिगत KYC चलती है। एक का नाम PAN रिकॉर्ड से थोड़ा अलग निकलता है: स्कोर सीमा पर है और मामला समीक्षक के पास जाता है, जो PAN कार्ड की तस्वीर देखकर उसे मंज़ूर कर देता है।
7. फ़ंडिंग खाता कंपनी के नाम का चालू खाता है। bank account verification से लौटा नाम कंपनी के नाम से मेल खाता है।

सात जाँचें, जिनमें दो हाथ से। सब कुछ हर call के referenceId के साथ अर्ज़ी से जोड़कर रखा गया है। छह महीने बाद वही कर्ज़दार लौटे तो सिर्फ़ स्थिति वाले लुकअप दोहराने पड़ेंगे।

बनाने से पहले नियामक या पार्टनर बैंक से पूछने लायक सवाल

चेकलिस्ट कोड के बाद आए तो इंजीनियरिंग का समय बर्बाद होता है। ये सवाल पहले पूछिए और जवाब अपनी नीति में लिख लीजिए।

1. हर तरह के ग्राहक के लिए कौन-से पहचान दस्तावेज़ और रजिस्ट्री जाँचें अनिवार्य हैं और कौन-सी वैकल्पिक?
2. क्या डेटा प्रदाता के लुकअप को सबूत माना जाता है, या दस्तावेज़ की प्रति रखनी ही होगी? कई नीतियों में दोनों चाहिए, जिसमें लुकअप पहला फाटक है।
3. कंपनियों, पार्टनरशिप फ़र्मों और ट्रस्टों के लिए beneficial ownership की सीमा क्या है, और उसका सबूत कैसे देना है?
4. KYC रिकॉर्ड कितने समय तक रखने हैं, किस तारीख़ से गिनकर, और किस रूप में?
5. रिकॉर्ड कितनी बार ताज़ा करने हैं, और क्या अंतराल जोखिम की श्रेणी पर निर्भर है?
6. जाँच फ़ेल हो तो क्या होना चाहिए: reject, समीक्षा के लिए रोकना, या रिपोर्ट करना?
7. असली निजी डेटा कौन देख सकता है, और क्या उस पहुँच का लॉग रखना है?

इन जवाबों से आपका डेटा मॉडल किसी भी API से ज़्यादा तय होता है। जो नीति दस्तावेज़ की प्रति माँगे, उसे ऑब्जेक्ट स्टोरेज और रिटेंशन के नियम चाहिए। जो नीति लुकअप को सबूत मान ले, उसे बस referenceId, तारीख़ और वे फ़ील्ड चाहिए जिन पर आपने भरोसा किया। किसी सामान्य गाइड से इनका अंदाज़ा मत लगाइए।

सही चीज़ें सही शब्दों में माँगना

पहली स्क्रीन के शब्द तय करते हैं कि कितने आवेदक पूरा करेंगे। तीन आदतें मदद करती हैं।

संस्था वाला सवाल सीधे शब्दों में पूछिए। "क्या आप व्यक्ति के रूप में आवेदन कर रहे हैं या किसी कारोबार की तरफ़ से?" सबको समझ आता है। "Constitution चुनिए" नहीं आता। जवाब के बाद सिर्फ़ वही फ़ील्ड दिखाइए जो उस प्रकार को चाहिए, जैसे StampMitra का ऑनबोर्डिंग फ़ॉर्म आवेदक के प्रकार के साथ अपने ज़रूरी फ़ील्ड बदलता है।

बताइए कि क्यों पूछ रहे हैं। PAN फ़ील्ड के नीचे एक पंक्ति कि आप नाम को सरकारी रिकॉर्ड से मिलाते हैं, और दस्तावेज़ अपलोड के नीचे एक पंक्ति कि उसका क्या इस्तेमाल होगा, बीच में छोड़ जाने वालों को घटाती है और वही उद्देश्य का कथन भी है जो आपके privacy notice को चाहिए।

जहाँ नीति इजाज़त दे, वहाँ लुकअप को दस्तावेज़ की जगह लेने दीजिए। अगर CIN लुकअप में आवेदक निदेशक दिखता है, तो बोर्ड प्रस्ताव माँगना भरोसा बढ़ाए बिना रुकावट बढ़ाता है। इसे नियम की तरह लिखिए और आवेदक को बताइए कि अब उसे क्या अपलोड नहीं करना।

बेमेल को सवाल की तरह लीजिए, एरर की तरह नहीं। "इस PAN पर नाम आपके भरे नाम से थोड़ा अलग है। क्या यही आपका पूरा कानूनी नाम है?" "Verification failed" से ज़्यादा आवेदकों को वापस लाता है। सख़्त विफलता अवैध पहचानों और निष्क्रिय संस्थाओं के लिए रखिए।

समीक्षा की कतार में केस आए तो समीक्षक को क्या दिखे

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

जोखिम के हिसाब से गहराई

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

स्तर के नियम लिखकर रखिए और उनके संस्करण बनाइए। जब नियामक या ऑडिटर पूछे कि किसी ग्राहक को यह गहराई क्यों मिली, तो जवाब कोई नियम और उसका संस्करण होना चाहिए, किसी की याददाश्त नहीं। StampMitra का production access फ़ॉर्म भी कुछ ऐसा ही करता है: वहाँ bank account verification और e-Sign को ऊँचे जोखिम वाले प्रोडक्ट के रूप में चिह्नित किया गया है, जबकि PAN, GSTIN, CIN, Udyam और e-Stamp को कम जोखिम का माना गया है।

कितनी बार दोबारा जाँचें

व्यक्ति धीरे बदलते हैं। संस्थाएँ नहीं। GST रजिस्ट्रेशन रद्द हो सकता है, कंपनी हटाई जा सकती है या उसके निदेशक बदल सकते हैं, और PAN की स्थिति बदल सकती है। हर स्तर और हर पहचान के लिए ताज़ा करने का अंतराल तय कीजिए: रजिस्ट्रेशन और कंपनी की स्थिति ज़्यादा बार, PAN कम बार। घड़ी के साथ-साथ घटनाओं पर भी दोहराइए: नए बैंक खाते में भुगतान, हस्ताक्षरकर्ता का बदलाव, बड़ा लेन-देन, ग्राहक की शिकायत।

हर दोबारा जाँच production दर पर नई बिल होने वाली call है और नया referenceId बनाती है, इसलिए उसका बजट रखिए। अपने सक्रिय संस्था-आधार पर स्थिति वाले लुकअप दोहराने की लागत अक्सर उस संस्था को भुगतान करने की लागत के सामने छोटी होती है जो अब मौजूद नहीं।

जहाँ ख़र्च बढ़ता है

तीन निदेशकों, दो beneficial owners और एक हस्ताक्षरकर्ता वाली कंपनी में छह व्यक्ति और एक संस्था दायरे में हैं, और हर एक लुकअप खड़ा कर सकता है। लागत ग्राहकों की संख्या से नहीं, पक्षों की संख्या से बढ़ती है। पहले से योजना बनाइए। पहले संस्था जाँचिए और विफल हो तो रुक जाइए, ताकि बंद हो चुकी कंपनी से जुड़े लोगों की जाँच पर पैसा न लगे। सिर्फ़ उन लोगों की जाँच कीजिए जिन्हें आपकी नीति माँगती है: हस्ताक्षरकर्ता और सीमा से ऊपर के मालिक, हर निदेशक नहीं। standard pay-as-you-go पर PAN का लुकअप ₹5 और bank account की जाँच ₹4 प्रति call है, प्लान में दरें और कम हैं; मौजूदा आँकड़े pricing पेज पर हैं। sandbox की calls मुफ़्त हैं और wallet से कभी नहीं कटतीं, इसलिए पूरी pipeline पहले वहीं बनाइए और टेस्ट कीजिए।

API क्या कवर नहीं करती

किनारे साफ़ बता दीजिए, क्योंकि ऑडिट में दिक़्क़तें यहीं मिलती हैं।

• Aadhaar आधारित verification नहीं दी जाती।
• Verification endpoint में sanctions, politically exposed person या adverse media की स्क्रीनिंग नहीं है।
• Beneficial ownership का कोई लुकअप नहीं है; CIN के जवाब में निदेशक आते हैं, शेयरधारक नहीं।
• दस्तावेज़ (बोर्ड प्रस्ताव, डीड, पते का सबूत) आप खुद इकट्ठा और समीक्षित करते हैं। StampMitra का अपना production access प्रवाह अपने ग्राहकों के दस्तावेज़ों की समीक्षा करता है, पर वह भीतरी ऑनबोर्डिंग प्रक्रिया है, आपके लिए बुलाने लायक API नहीं।
• नतीजे डेटा स्रोत की आख़िरी ताज़गी को दिखाते हैं, इसलिए बहुत हाल का बदलाव शायद अभी न दिखे। देखिए API और सरकारी पोर्टल के नतीजों में फ़र्क।

दोनों प्रवाहों में निजी डेटा का रखरखाव

KYC और KYB दोनों निजी डेटा इकट्ठा करते हैं: नाम, PAN, बैंक खाता संख्या, निदेशकों के नाम और DIN, ईमेल पते। उतना ही लीजिए जितना जाँच को चाहिए, नोटिस में कारण बताइए, उसे उतने ही समय रखिए जितना आपकी नीति या कानून माँगे, और देखने वालों को सीमित कीजिए। Digital Personal Data Protection Act, 2023 निजी डेटा का सामान्य ढाँचा है, और क्षेत्रीय नियम KYC रिकॉर्ड के लिए लंबा रिटेंशन जोड़ सकते हैं, इसलिए रिटेंशन की अवधि अपने compliance मालिक से तय कीजिए, "हमेशा के लिए" या "तुरंत मिटाएँ" को डिफ़ॉल्ट मत बनाइए। लॉग में पहचानें मास्क कीजिए। फ़ील्ड-दर-फ़ील्ड बात verification कॉल से क्या लॉग करें में है।

आम ग़लतियाँ

• कंपनी के GSTIN को इस बात का सबूत मान लेना कि हस्ताक्षरकर्ता को अधिकार है। वह दिखाता ही नहीं कि दस्तख़त कौन कर सकता है।
• कारोबारी ग्राहक पर सिर्फ़ संस्था की जाँचें चलाना और आवेदन करने वाले व्यक्ति को कभी न जाँचना।
• कंपनी के PAN पर उपभोक्ता जैसी PAN जाँच चलाकर उसे KYB कह देना।
• हस्ताक्षरकर्ता के नाम को निदेशक सूची की जगह कंपनी के नाम से मिलाना।
• प्रोपराइटर को बिना किसी कारोबारी सबूत के निकल जाने देना, क्योंकि फ़ॉर्म में सिर्फ़ उपभोक्ता वाला रास्ता है।
• सिर्फ़ पास या फ़ेल का नतीजा रखना, ताकि बाद की ताज़ा जाँच दिखा न सके कि क्या बदला।
• डेमो में sandbox के नतीजों को असली जाँच की तरह दिखाना। sandbox सैंपल डेटा लौटाता है।

शब्दावली

आगे क्या करें

अपने संस्था प्रकार चुनिए, ऊपर की तालिका अपनी नीति में उतारिए और निशान लगाइए कि कौन-सी जाँचें लुकअप हैं और कौन-सी दस्तावेज़। quickstart से sandbox key लीजिए, फिर verification docs से PAN, GSTIN और CIN की calls आज़माइए। वेंडर पर जाँचों के क्रम के लिए वेंडर ऑनबोर्डिंग फ़्लो पढ़िए। live जाने से पहले sandbox बनाम production: क्या टेस्ट हो सकता है पढ़ लीजिए। जो इनपुट यहाँ नहीं आया, उसका सवाल support को भेजिए।

API reference एक नज़र में

{
  "referenceId": "SMV-20260927-8F42K7",
  "pan": "ABCDE1234F",
  "type": "Individual",
  "valid": true,
  "registeredName": "RAHUL KUMAR",
  "fatherName": "SURESH KUMAR",
  "panStatus": "VALID",
  "panStatusCode": "E",
  "panStatusDescription": "Existing and valid PAN",
  "nameMatchResult": "MATCH",
  "nameMatchScore": "100",
  "aadhaarSeedingStatus": "y",
  "aadhaarSeedingStatusDescription": "Aadhaar linked",
  "lastUpdatedAt": "2023-04-01",
  "message": "PAN is Valid"
}

{
  "referenceId": "SMV-20260927-6R38Y3",
  "verificationId": "VRF-6C2N9V4HQ7ZE",
  "valid": true,
  "status": "VALID",
  "cin": "U72900KA2015PTC082988",
  "companyName": "COMPANY NAME",
  "registrationNumber": 82987,
  "incorporationDate": "2015-09-23",
  "cinStatus": "ACTIVE",
  "email": "[email protected]",
  "incorporationCountry": "INDIA",
  "directorDetails": [
    {
      "din": "07168822",
      "name": "Frank Kelvin",
      "dob": "1997-07-21",
      "designation": "DIRECTOR",
      "address": "ST BED KORAMANGALA, BANGALORE, KARNATAKA, INDIA, 566634"
    },
    {
      "din": "07168826",
      "name": "John Doe",
      "dob": "1997-02-07",
      "designation": "DIRECTOR",
      "address": "GAUTAM NAGAR, NOIDA, UTTAR PRADESH, INDIA, 211361"
    }
  ],
  "companyStatus": "ACTIVE",
  "directors": [
    {
      "din": "07168822",
      "name": "Frank Kelvin",
      "designation": "DIRECTOR"
    },
    {
      "din": "07168826",
      "name": "John Doe",
      "designation": "DIRECTOR"
    }
  ]
}

{
  "referenceId": "SMV-20260927-3B71A0",
  "valid": true,
  "nameAtBank": "RAVI KUMAR",
  "bankName": "ICICI Bank",
  "utr": "017952100012345",
  "city": "Mumbai",
  "branch": "Andheri West",
  "micr": "400229002",
  "nameMatchScore": "100",
  "nameMatchResult": "GOOD_MATCH",
  "accountStatus": "ACCOUNT_IS_VALID",
  "accountStatusCode": "1",
  "ifscDetails": {
    "bank": "ICICI Bank",
    "ifsc": "ICIC0001234",
    "micr": "400229002",
    "address": "Andheri West, Mumbai",
    "city": "Mumbai",
    "state": "Maharashtra",
    "branch": "Andheri West"
  }
}

अक्सर पूछे जाने वाले सवाल