NBFC के लिए KYC API: लोन के हर चरण पर कौन-सी जाँच

मुख्य बातें

• endpoints के हिसाब से नहीं, चरणों के हिसाब से सोचिए: आवेदन, क्रेडिट, disbursal से पहले, और बाद की समीक्षा। हर चरण में अलग check लगते हैं और हर check से एक ही फ़ैसला जुड़ा रहता है।
• आवेदन पर PAN, क्रेडिट पर कंपनी या गाड़ी की जाँच, और disbursal से ठीक पहले बैंक खाते की जाँच, यह एक ठोस शुरुआती क्रम है। Vehicle RC सिर्फ़ गाड़ी से जुड़े लोन में लगता है।
• हर verification POST /v1/verify/<product> पर एक synchronous call है। नकारात्मक जवाब भी पूरी और billable call है, इसलिए दोबारा कोशिश करने पर वही जवाब दोबारा ख़रीदना पड़ता है।
• नाम मिलान के नतीजे को ऐसे score की तरह लीजिए जिस पर आप सीमा तय करते हैं, और बीच में इंसान की समीक्षा का दायरा रखिए। एक कम score देखकर अपने-आप अस्वीकार न करें।
• queue, स्टेटस अपडेट और duplicate की रोकथाम आपको ख़ुद बनानी है। verification calls webhook नहीं भेजतीं, और referenceId एक transaction पहचान है, idempotency key नहीं।
• दो चेक वाली आम पर्सनल लोन फ़ाइल पर चंद रुपये ख़र्च आता है। प्रति फ़ाइल हिसाब नीचे दिखाया है ताकि आप अपना funnel लगाकर देख सकें।
• लोन रिकॉर्ड कितने समय रखें और सहमति कैसे लें, यह आपके regulator, आपकी नीति और आपके सलाहकार से तय होता है। यहाँ की बात सिर्फ़ सामान्य मार्गदर्शन है।

यह पेज किसके लिए है और किस समस्या को हल करता है

तीन तरह के लोग एक ही टीम में बैठे होते हैं, और यह पेज तीनों के लिए है। पहला, credit-operations का प्रमुख, जिसका लक्ष्य turnaround और ग़लतियों की दर है। दूसरा, प्रोडक्ट मैनेजर, जिसकी चिंता "आवेदन शुरू हुआ" और "लोन बँटा" के बीच की गिरावट है। तीसरा, इंजीनियर, जिसे verification को loan management system में इस तरह जोड़ना है कि हर ग्राहक की छोटी-सी ग़लती सपोर्ट टिकट न बन जाए।

समस्या सीधी है। लोन फ़ाइल में बहुत-से नंबर इंसान के हाथ से टाइप होते हैं: PAN, खाता संख्या, IFSC, GSTIN, गाड़ी का नंबर। हर नंबर ग़लत टाइप हो सकता है, पुराना हो सकता है, या जानबूझकर बदला हुआ हो सकता है। उन्हें आँख से या अपलोड की गई फोटो से मिलाना धीमा है, अलग-अलग विश्लेषक के हिसाब से अलग निकलता है, और बाद में उसका सबूत देना कठिन है। API से यही काम तेज़ और दोहराने लायक बन जाता है, और हर जाँच का एक transaction id फ़ाइल के साथ जुड़ जाता है। API यह तय नहीं कर सकती कि उधार लेने वाला स्वीकार्य है या नहीं। वह सिर्फ़ यह बताती है कि आपके भेजे नंबर के बारे में स्रोत क्या कहता है।

फिनटेक KYC पेज से फ़र्क़

फिनटेक और NBFC वाला पेज checks के इर्द-गिर्द बना है: कौन-सा किस क्रम में, retry कैसे, queue कैसे। यह पेज लोन के इर्द-गिर्द बना है: origination के हर चरण को क्या चाहिए, वाहन लोन और MSME लोन में क्या फ़र्क़ पड़ता है, partner से आई फ़ाइलों में क्या बदलता है, और अपवाद सँभालने वाली डेस्क कैसे चले। इंजीनियरिंग के पैटर्न वहाँ मिलेंगे, और credit-operations की रचना यहाँ।

RBI का KYC ढाँचा और आपके डिज़ाइन पर उसका असर

NBFC भारतीय रिज़र्व बैंक के नियामक दायरे में आती हैं, और RBI का Know Your Customer Direction (2016 में जारी, बाद में अद्यतन) वह दस्तावेज़ है जिसका हवाला ज़्यादातर ऋणदाता देते हैं। मोटे तौर पर वह यह अपेक्षा रखता है कि नियंत्रित संस्था की बोर्ड से मंज़ूर ग्राहक-स्वीकृति और पहचान नीति हो, ग्राहकों का जोखिम के आधार पर वर्गीकरण हो, पहचान तय तरीक़ों से जाँची जाए, खातों की निगरानी हो और रिकॉर्ड रखे जाएँ। हम उसकी धाराओं का सार नहीं देंगे, क्योंकि आपको जवाब किसी vendor के सार को नहीं, मौजूदा मूल पाठ और उसके संशोधनों को देना है। उसे सीधे पढ़िए और अपने compliance अधिकारी से पूछिए कि आपके किस उत्पाद पर कौन-सा हिस्सा लागू होता है।

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

StampMitra किसी नियामक मंज़ूरी का दावा नहीं करता, और इन APIs के इस्तेमाल से कोई ऋणदाता अपने-आप compliant नहीं हो जाता। हम transaction id के साथ डेटा बिंदु देते हैं। आपकी नीति के तहत वे कैसे गिने जाएँगे, यह आपका फ़ैसला है।

जीवन-चक्र के हर चरण पर कौन-सा check

सबसे पहले एक तालिका जिस पर क्रेडिट प्रमुख, प्रोडक्ट मैनेजर और इंजीनियर तीनों उँगली रख सकें: चरण, सवाल, call और उससे निकलने वाला फ़ैसला।

व्यवहार में दो बातें याद रखिए। चरण जुड़ते-जुड़ते ख़र्च बढ़ता है, इसलिए सबसे सस्ता निर्णायक call पहले आए, ताकि जो आवेदन रुकने वाले हैं वे जितनी जल्दी हो सके सशुल्क रास्ते से बाहर हो जाएँ। और "समीक्षा" वाला चरण तकनीकी डिफ़ॉल्ट नहीं, लागत वाला नीतिगत फ़ैसला है। हर तिमाही सब कुछ दोबारा चलाने का ख़र्च अक्सर उसके नतीजे से ज़्यादा बैठता है।

उत्पाद के हिसाब से अलग सफ़र

सभी उत्पादों के लिए एक ही "KYC flow" बनाने से ऐसी जाँचों का पैसा जाता है जो फ़ैसला बदल ही नहीं सकतीं। हर उत्पाद का एक छोटा सफ़र बनाइए और पुर्ज़े साझा रखिए।

दोपहिया और दूसरे वाहन-आधारित लोन

यहाँ जमानत एक पंजीकृत गाड़ी है, इसलिए RC की जाँच मायने रखती है। आवेदन पर PAN चलाइए। क्रेडिट पर गाड़ी के नंबर से verify/rc बुलाइए और लौटे ownerName को अपने उत्पाद की अपेक्षा से मिलाइए। डीलर से ली जा रही नई गाड़ी का पंजीकरण अभी बना ही न हो, और पुरानी गाड़ी में मालिक अक्सर विक्रेता होता है, उधारकर्ता नहीं। rcStatus, registrationStatus, rcExpiryDate और insuranceUpto पढ़िए और हर एक के लिए नीति का जवाब लिख लीजिए: पुरानी गाड़ी पर बीमा की बीती तारीख़ शायद दस्तावेज़ी शर्त बने, जबकि चालू से अलग स्थिति रोक का कारण हो सकती है। बैंक खाते की जाँच disbursal से पहले कीजिए।

RC endpoint premium दर वाले वर्ग में है, और driving licence तथा passport की तरह संवेदनशील scope है। उसे IP allowlist वाली production key से चलाने की तैयारी रखिए।

वेतनभोगी पर्सनल लोन

यह सबसे सस्ता सफ़र है: आवेदन पर नाम के साथ PAN, और disbursal से ठीक पहले नाम के साथ bank-account। नियोक्ता और आय का सत्यापन इस प्लेटफ़ॉर्म पर रजिस्ट्री जाँच नहीं है, वह आपकी अपनी underwriting में होता है। यहाँ एक बारीकी है: फ़ॉर्म में लिखा नाम, PAN का नाम और बैंक का नाम तीनों जायज़ तौर पर अलग हो सकते हैं। इसके लिए अक्षरशः बराबरी की जगह सीमाएँ और समीक्षा का दायरा रखिए।

MSME और कार्यशील पूँजी के लोन

यहाँ उधारकर्ता संस्था होती है। कौन-सा पहचानकर्ता पहले लगे, यह संस्था के प्रकार पर निर्भर है। कंपनी के पास CIN होता है, तो verify/cin कंपनी का नाम, स्थापना की तारीख़, cinStatus, companyStatus और निदेशकों की सूची (DIN व पदनाम के साथ) लौटाता है। GST में पंजीकृत फ़र्म के पास GSTIN होता है, तो verify/gstin से legalName, tradeName, registrationStatus और मुख्य कारोबारी पता मिलता है। सूक्ष्म या लघु उद्यम के पास Udyam संख्या हो सकती है, और verify/udyam बताता है कि वह मिली या नहीं, उसकी स्थिति, उद्यम का प्रकार और संगठन का प्रकार क्या है। प्रोप्राइटर को PAN से भी खोला जा सकता है: pan-to-gstin और pan-to-udyam उस PAN से जुड़े पंजीकरण गिनाते हैं, जो तब काम आता है जब आवेदक एक ही नंबर दे और आप जानना चाहें कि और क्या-क्या पंजीकृत है। फिर हर हस्ताक्षरकर्ता या गारंटर को व्यक्ति मानकर PAN और बैंक से जाँचिए।

हर पहचानकर्ता क्या साबित करता है और कोई दूसरे की जगह क्यों नहीं ले सकता, यह business verification गाइड में है।

Partner और co-lending से आई फ़ाइलें

जब फ़ाइल किसी sourcing partner, DSA या co-lender से आती है, तो आपको उनके इनपुट मिलते हैं, उनके सबूत नहीं। नीति में तय कीजिए कि आगमन पर जाँच दोबारा चलेगी या partner के साथ आए नतीजे मान लिए जाएँगे। दोबारा चलाएँ तो partner का डेटा "टाइप किया हुआ मान" है और आपकी अपनी call सत्यापन है। मान लें तो partner का संदर्भ अपने संदर्भ के बगल में रखिए और हर जाँच का स्रोत लिखिए, ताकि ऑडिटर देख सके कि कौन-सी जाँचें आपने ख़ुद चलाईं।

कदम-दर-कदम workflow

नीचे का क्रम खुदरा या MSME डेस्क के लिए ठीक-ठाक शुरुआत है। क्रम अपनी नीति के अनुसार बदलिए। हर कदम endpoint और फ़ैसले को साथ रखता है।

1. फ़ॉर्मेट अपनी तरफ़ जाँचिए। PAN, IFSC, GSTIN और गाड़ी के नंबर को trim और upper-case कीजिए और ढाँचा देखिए: PAN में दस अक्षर, IFSC में ग्यारह, GSTIN में पंद्रह, खाता संख्या में नौ से अठारह अंक। ग़लत इनपुट पर endpoint 400 देता है, पर जो call आपके सर्वर से निकली ही नहीं, उसका कोई ख़र्च नहीं और जवाब भी जल्दी आता है। फ़ैसला: आवेदक से ग़लती सुधरवाइए, या आगे बढ़िए।
2. नाम के साथ PAN जाँचिए। POST /v1/verify/pan में pan और name। valid, panStatus, type, registeredName, nameMatchResult और nameMatchScore पढ़िए। फ़ैसला: valid: false पर एक बार दोबारा भरवाने के बाद रुक जाइए, मज़बूत मिलान पर आगे बढ़िए, बीच के score को समीक्षा में भेजिए। यह भी देखिए कि type उत्पाद से मेल खाता है: व्यक्तिगत लोन पर कंपनी का PAN डेटा की गड़बड़ी है और किसी इंसान की नज़र माँगता है।
3. उधारकर्ता के प्रकार पर शाखा। व्यक्ति पाँचवें कदम पर जाएँ, संस्थाएँ चौथे पर।
4. संस्था की जाँच। जो लागू हो वह cin, gstin या udyam, फिर PAN को पंजीकरणों से मिलाने के लिए pan-to-gstin या pan-to-udyam। स्थिति वाले fields (cinStatus, companyStatus, registrationStatus, udyamStatus) पढ़िए और नाम मिलाइए। फ़ैसला: संस्था चालू हो और नाम समझाए जा सकें तभी आगे बढ़िए, वरना नीति में तय दस्तावेज़ माँगिए।
5. वाहन लोन में RC। vehicleNumber के साथ verify/rc। फ़ैसला: मालिक और स्थिति को अपने उत्पाद के नियमों से मिलाइए।
6. क्रेडिट का फ़ैसला। यह API का कदम नहीं है। आपकी underwriting दूसरे से पाँचवें कदम के सबूत और नीति की बाक़ी माँगों का इस्तेमाल करती है।
7. disbursal से पहले खाता। POST /v1/verify/bank-account में accountNumber, ifsc और name। valid, accountStatus, nameAtBank और nameMatchResult पढ़िए। फ़ैसला: छोड़िए, रोकिए, या दूसरा प्रमाण माँगिए।
8. सबूत का रिकॉर्ड लिखिए। हर call के लिए product, referenceId, समय, ढका या hash किया इनपुट, फ़ैसले में काम आए response fields और लिया गया फ़ैसला रखिए। इसी से महीनों बाद फ़ाइल का हाल दोबारा बनता है।
9. समीक्षा का समय तय कीजिए। नीति में समय-सीमित जाँचें हों तो उन्हें तारीख़, कारण और अनुमानित ख़र्च के साथ job queue में रखिए।

नमूना request और response: disbursal से पहले का बैंक check

यही वह call है जो सबसे ज़्यादा बार ग़लत disbursal से बचाती है। request में खाता संख्या, IFSC और आपकी फ़ाइल वाला नाम जाता है:

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/bank-account" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"accountNumber":"000123456789","ifsc":"ICIC0001234","name":"Ravi Kumar"}'

दस्तावेज़ में दर्ज response का रूप (नमूना मानों के साथ):

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

Python में यही फ़ैसला कुछ ऐसा दिखेगा। सीमाएँ नमूना हैं, अपने डेटा पर ट्यून कीजिए।

import os
import requests

BASE = "https://api-b2b.stampmitra.in"

def disbursal_decision(account_number, ifsc, name):
    r = requests.post(
        f"{BASE}/v1/verify/bank-account",
        headers={"Authorization": f"Bearer {os.environ['STAMPMITRA_API_KEY']}"},
        json={"accountNumber": account_number, "ifsc": ifsc, "name": name},
        timeout=15,
    )
    if r.status_code in (429, 502):
        return {"decision": "retry_later", "status": r.status_code}
    if r.status_code == 402:
        return {"decision": "ops_alert", "reason": "wallet"}
    body = r.json()
    if not r.ok:
        return {"decision": "fix_input", "requestId": body.get("error", {}).get("requestId")}
    if not body.get("valid"):
        return {"decision": "hold", "reason": "account_not_valid", "ref": body["referenceId"]}
    score = float(body.get("nameMatchScore", 0))
    if score >= 90:
        return {"decision": "release", "ref": body["referenceId"]}
    if score >= 60:
        return {"decision": "review", "reason": "name_partial", "ref": body["referenceId"]}
    return {"decision": "hold", "reason": "name_mismatch", "ref": body["referenceId"]}

फ़ैसले की तालिका: valid, मेल नहीं, निष्क्रिय, नहीं मिला

हर चरण पर वही चार नतीजे लौटते हैं, इसलिए डेस्क को एक ही तालिका दीजिए।

आख़िरी पंक्ति जल्दबाज़ी वाले integration में सबसे पहले खोती है। विफल call पास नहीं है। पहले से तय कर लीजिए कि जिस फ़ाइल की disbursal-पूर्व जाँच पूरी नहीं हो सकी, उस पर पैसा नहीं जाएगा, और सिस्टम से यह लागू भी करवाइए।

डेस्क पर आने वाली चार स्थितियाँ

ये काल्पनिक मामले हैं, पर दिखाते हैं कि जवाब और नीति कैसे साथ चलते हैं।

साफ़-सुथरी फ़ाइल

वेतनभोगी आवेदक PAN और नाम डालता है। PAN वैध निकलता है और मिलान मज़बूत है, तो फ़ाइल क्रेडिट पर जाती है। मंज़ूरी के बाद बैंक जाँच में खाता वैध और नाम का मिलान मज़बूत आता है, और लोन छूट जाता है। दो calls, दो transaction id, सबूत के रिकॉर्ड में दो फ़ैसले।

नाम जो मेल नहीं खाता

उधारकर्ता के PAN पर पूरा नाम है, और बैंक में खाता नाम के आद्याक्षरों व उपनाम से है। score बीच के दायरे में पड़ता है। सिस्टम फ़ाइल को समीक्षा queue में भेजता है, दोनों नाम और दोनों referenceId साथ-साथ दिखाते हुए। समीक्षक उधारकर्ता से बात करके पुष्टि करता है, कारण दर्ज करता है और रोक हटा देता है। कोई call दोहराई नहीं जाती।

निष्क्रिय पंजीकरण

MSME आवेदक GSTIN देता है। registrationStatus चालू नहीं है। डेस्क सिर्फ़ स्थिति देखकर अस्वीकार नहीं करती: वह मौजूदा पंजीकरण का दस्तावेज़ माँगती है, उसका नतीजा फ़ाइल पर लिखती है और क्रेडिट को फ़ैसला करने देती है। स्थिति के field ने डेस्क को एक सवाल पूछने का कारण दिया, जवाब नहीं।

ऊपरी स्रोत का ठप होना

महीने के आख़िरी भीड़ वाले दिनों में PAN की call 502 देने लगती है। सेवा प्रभावित आवेदनों को "जाँच बाक़ी" स्थिति में रखती है, सीमित backoff के साथ फिर कोशिश करती है, और आवेदक को संदेश दिखाती है कि जाँच में सामान्य से ज़्यादा समय लग रहा है। स्रोत ठीक होते ही रुकी फ़ाइलें बिना दोबारा भरे आगे बढ़ जाती हैं। किसी को डिफ़ॉल्ट मंज़ूरी नहीं मिलती, और प्लेटफ़ॉर्म की ग़लती पर किसी को अस्वीकार भी नहीं किया जाता।

जोखिम और review के नियम जिन्हें आप अपना सकते हैं

नीचे के नियम सुझाव हैं, अपनाने की बाध्यता या सलाह नहीं। हर संख्या अपने डेटा पर परखिए और अंतिम रूप क्रेडिट व compliance प्रमुखों से पास करवाइए।

• अपने-आप आगे बढ़ें जब PAN वैध हो, type उत्पाद से मेल खाए और नाम का score ऊँची सीमा या उससे ऊपर हो। ऊँची सीमा की शुरुआत नब्बे के आसपास से की जा सकती है, असली बेमेल नमूनों पर कसते हुए।
• समीक्षा का दायरा ऊँची सीमा और एक निचली सीमा के बीच, जो साठ के आसपास हो सकती है। समीक्षक को दोनों नाम, स्थिति के fields और referenceId दिखें।
• पक्की रोक एक बार दोबारा भरवाने के बाद भी अवैध PAN, सहायक दस्तावेज़ के बिना निष्क्रिय संस्था, या ऐसा disbursal खाता जो वैध नहीं है।
• वरिष्ठ समीक्षक तक भेजें जब दूसरा समीक्षक पहले से असहमत हो, एक खाता एक से ज़्यादा उधारकर्ताओं पर दिखे, या एक उधारकर्ता एक से ज़्यादा PAN के साथ दिखे।
• override पर दो जोड़ी आँखें। पक्की रोक हटाने के लिए दूसरे मंज़ूरीकर्ता और लिखित कारण की ज़रूरत हो।
• नकारात्मक जवाब पर चुप retry नहीं। सिस्टम 429 या 502 पर फिर कोशिश कर सकता है, valid: false को नहीं दोहरा सकता।
• disbursal पर बंद दरवाज़ा। आख़िरी खाता-जाँच न हो, विफल हो, या आपकी ताज़गी की सीमा से पुरानी हो, तो रकम छोड़ने का कदम रुका रहे।

टीम कैसे चलाएँ: queue, भूमिकाएँ और समय-सीमा

verification परत अपवाद पैदा करती है, और अपवाद का एक मालिक होना चाहिए। तीन queue चल जाती हैं। पहली समीक्षा queue, बेमेल और बीच के score के लिए, जिसे credit-operations के विश्लेषक देखते हैं। दूसरी अपवाद queue, उन पक्की रोकों के लिए जिन्हें कोई खोलना चाहता है, जिसे वरिष्ठ विश्लेषक या क्रेडिट मैनेजर देखता है। तीसरी प्लेटफ़ॉर्म queue, विफल calls और wallet के अलर्ट के लिए, जिसे इंजीनियरिंग या on-call ऑपरेटर सँभालता है।

समय-सीमाओं के लिए सुझाव के तौर पर कुछ लक्ष्य रखिए और अपनी मात्रा के हिसाब से बदलते रहिए: समीक्षा queue के लिए उसी कार्य-दिवस में निपटारा, disbursal-पूर्व रोकों के लिए और कम समय क्योंकि उधारकर्ता पैसे का इंतज़ार कर रहा है, और wallet तथा आउटेज के अलर्ट के लिए मिनटों में कार्रवाई। हर फ़ाइल एक समय में एक विश्लेषक को सौंपिए, और स्क्रीन के ऊपर सबसे पुराने लंबित मामले की उम्र दिखाइए ताकि कुछ भी चुपचाप न पड़ा रहे।

maker-checker उन सब पर लागू होता है जो फ़ैसला बदलता है: जिसने बेमेल हटाया वही उसके override को मंज़ूर न करे। हर भूमिका को ज़रूरत भर की पहुँच दीजिए, और API keys सेवा के पास रखिए, किसी व्यक्ति के browser में नहीं।

क्या रखें और कितने समय तक

इतना रखिए कि फ़ैसला दोबारा बनाया जा सके, उससे ज़्यादा नहीं। हर जाँच के लिए: बुलाया गया product, referenceId, समय, key का environment, इनपुट का ढका या hash किया रूप, फ़ैसले में इस्तेमाल हुए response fields, फ़ैसला ख़ुद, उस समय लागू नियम या सीमा का संस्करण, और हर मैनुअल कार्रवाई के लिए विश्लेषक व कारण। कच्चे पहचान-नंबर logs में न रखिए, और पूरा सबूत उसी सिस्टम में रखिए जहाँ पहुँच नियंत्रण और audit trail है, application logs में नहीं।

कितने समय रखें, यह इंजीनियरिंग का सवाल नहीं है। RBI का KYC ढाँचा, नियंत्रित संस्थाओं पर लागू धन-शोधन रोकथाम के नियम, Digital Personal Data Protection Act, 2023 और आपकी अपनी नीति, सब इस पर असर डालते हैं, और अवधियाँ सामान्यतः वर्षों में मापी जाती हैं जो ग्राहक-संबंध समाप्त होने से गिनी जाती हैं। सटीक अवधि और मिटाने की ज़िम्मेदारी अपने सलाहकार और compliance अधिकारी से पक्की कीजिए, फिर उन्हें अपने सिस्टम में retention वर्गों की तरह लिख दीजिए। StampMitra अपने स्तर पर डेटा कैसे सँभालता है, यह data retention और deletion schedule और data processing addendum में है।

StampMitra की तरफ़ से आप अपने खाते की पुरानी calls भी देख सकते हैं: GET /v1/logs आपके संगठन के request logs service और status के filters के साथ देता है, और GET /v1/usage/summary उपयोग का सार। इन logs को कितने दिन रखा जाता है, वह plan पर निर्भर है, जैसा pricing पेज पर लिखा है। इन्हें संचालन का सहायक मानिए, अपना आधिकारिक रिकॉर्ड नहीं।

लागत: तीन आकार के पोर्टफ़ोलियो पर हिसाब

प्रति call की दरें pricing पेज के rate card से आती हैं। यहाँ pay as you go पर PAN की दर ₹5 है, bank-account जाँच की ₹4 और vehicle RC की ₹9। Growth और Scale plan standard व premium दरें घटाते हैं और महीने की plan फ़ीस जोड़ते हैं, जबकि bank-account की दर हर plan पर एक-सी है। सभी राशियाँ 18 प्रतिशत GST से पहले की हैं।

पहले एक फ़ाइल की लागत, GST से पहले: वाहन लोन जिसमें PAN, बैंक खाता और RC तीनों चलते हैं, और पर्सनल लोन जिसमें सिर्फ़ PAN और बैंक खाता।

ये उस फ़ाइल की लागत हैं जो हर कदम पूरा करे। funnel में हर आवेदक हर कदम तक नहीं पहुँचता, इसलिए नीचे का मासिक मॉडल एक उदाहरण-भरा funnel मानता है: हर आवेदन पर PAN जाँच, 30 प्रतिशत मंज़ूरी पर बैंक जाँच तक पहुँचते हैं, और 15 प्रतिशत वाहन लोन हैं जिन्हें RC जाँच चाहिए। ये प्रतिशत मान्यताएँ हैं, अपने आँकड़ों से बदलिए। तीन स्तर हैं: महीने में 2,000, 10,000 और 50,000 आवेदन।

2,000 आवेदन पर: 2,000 PAN, 600 बैंक और 300 RC जाँचें।

10,000 आवेदन पर: 10,000 PAN, 3,000 बैंक और 1,500 RC जाँचें।

50,000 आवेदन पर: 50,000 PAN, 15,000 बैंक और 7,500 RC जाँचें।

तीनों तालिकाओं को ऐसे पढ़िए: सबसे छोटी मात्रा पर plan फ़ीस प्रति call की बचत से ज़्यादा पड़ती है, इसलिए Scale से सस्ता pay as you go या Growth बैठता है। मात्रा बढ़ने पर कम दरें जीतती हैं, और सबसे बड़े स्तर पर मासिक ख़र्च उस सीमा से बहुत ऊपर है जहाँ StampMitra Enterprise व्यवस्था का सुझाव देता है, इसलिए वह plan चुनने की नहीं, contact पेज पर बातचीत की बात है। तालिकाएँ मानती हैं कि GST plan फ़ीस पर भी उसी तरह लगता है जैसे उपयोग पर, पर सही व्यवहार के लिए अपना invoice देखिए। जो call 4xx या 5xx error पर ख़त्म हो उस पर कुछ नहीं कटता, क्योंकि उपयोग सफल response के बाद दर्ज होता है, लेकिन valid: false भी सफल call है। wallet के top-up की एक न्यूनतम सीमा pricing पेज पर दी है, और sandbox की calls से wallet कभी नहीं कटता।

रोलआउट: sandbox, pilot, production

तीन चरणों में चलाइए और हर एक के लिए लिख लीजिए कि "पूरा" का मतलब क्या है।

Sandbox। key बनाइए और sandbox पर बनाइए, जहाँ हर call नमूना डेटा लौटाती है जो असली लोगों का नहीं है, और कुछ ख़ास test values अनुमानित नतीजे देते हैं। इस लेख के समय sandbox PAN SNDBX0000A पर वैध और SNDBX9999F पर अवैध नतीजा देता है, और GSTIN की जोड़ी 09SNDBX0000A1Z5 व 09SNDBX9999F1Z5 है। बाक़ी किसी भी इनपुट पर स्थिर पर मनमाना नतीजा आता है, इसलिए उस पर assertion मत लगाइए। test लिखने से पहले dashboard में ताज़ा test values देख लीजिए। पूरा होने की शर्त: ऊपर की फ़ैसले-तालिका की हर पंक्ति का automated test हो, जिसमें 402, 429 और 502 के रास्ते भी हों।

Pilot। production access माँगिए, जो आपके संगठन की KYC मंज़ूरी और product-वार production आवेदन पर निर्भर है, फिर pilot के समूह को production keys पर ले जाइए जबकि विश्लेषक साथ-साथ हाथ से जाँच करते रहें। नतीजे मिलाइए। जहाँ API और विश्लेषक में फ़र्क़ हो, कोई भी स्वचालित नियम कसने से पहले उसका कारण खोजिए। keys और IP allowlist की बारीकियों के लिए sandbox बनाम production keys गाइड देखिए।

Production। समूह धीरे-धीरे बढ़ाइए। समीक्षा queue चालू रखिए, नीचे के मापदंड देखते रहिए, और wallet का balance शून्य से बहुत पहले अलर्ट करवाइए।

किन मापदंडों पर नज़र रखें

• Auto-continue दर, product और स्रोत चैनल के हिसाब से। अचानक गिरावट आम तौर पर फ़ॉर्म या स्रोत की समस्या होती है, ख़राब उधारकर्ता नहीं।
• समीक्षा दायरे की दर और सबसे पुराने मामले की उम्र। पहली आपकी सीमाओं की क़ीमत बताती है, दूसरी यह कि डेस्क पीछे तो नहीं छूट रही।
• पक्की रोक की दर, कारण के हिसाब से। अवैध PAN, निष्क्रिय संस्था और अवैध खाता अलग समस्याएँ हैं जिनके इलाज अलग हैं।
• override की दर और कौन करता है। किसी एक नियम पर ऊँची दर का मतलब या नियम ग़लत है या समीक्षक थके हैं।
• error दर, code के हिसाब से। 402 (wallet), 429 (rate limit) और 502 (upstream) को अलग देखिए और हर एक का requestId सँभालिए।
• बँटे हुए लोन पर verification का ख़र्च। ख़र्च को आवेदनों से नहीं, असल में बँटे लोन से भाग दीजिए, ताकि funnel संख्या में दिखे।
• एक ही PAN पर बार-बार call। किसी अवधि में एक PAN पर एक से ज़्यादा सशुल्क call cache या duplicate रोकथाम की ख़ामी है।

ऋणदाता verification API के साथ कौन-सी ग़लतियाँ करते हैं

• "valid" को "मंज़ूर" समझना। वैध PAN का मतलब सिर्फ़ इतना है कि वह स्रोत में है। उससे साख या सामने बैठे इंसान के बारे में कुछ नहीं पता चलता।
• विफल जाँच के बाद रकम छोड़ देना। retry करके "फिर भी आगे बढ़ो" वाली wiring जीवन-चक्र की सबसे महँगी ख़ामी है।
• हर उत्पाद पर एक ही सीमा। जो नाम-मिलान सीमा वेतनभोगी लोन के लिए ठीक है, वह बड़ी रकम वाले व्यवसाय खाते के लिए ढीली हो सकती है।
• नामों की अक्षरशः बराबरी। आद्याक्षर, क्रम, लिप्यंतरण और उपाधियाँ झूठे बेमेल पैदा करती हैं। score और समीक्षा-दायरा इस्तेमाल कीजिए।
• नकारात्मक जवाब पर retry। पैसा लगता है और वही नतीजा लौटता है।
• कच्चे पहचानकर्ता logs में लिखना। application logs में निजी डेटा दूर तक फैलता है और उसे मिटाना कठिन होता है।
• PAN का प्रकार अनदेखा करना। type field व्यक्ति को दूसरे धारकों से अलग करता है, पर्सनल लोन पर कंपनी का PAN देखने की वजह है।
• sandbox की मान्यताएँ production में ले जाना। sandbox का डेटा कृत्रिम है और उसकी सीमाएँ अलग हैं, छोटे production समूह पर अपना व्यवहार दोबारा परखिए।
• प्लेटफ़ॉर्म queue का कोई मालिक न होना। wallet और आउटेज अलर्ट के लिए एक नामित व्यक्ति और runbook चाहिए।

संबंधित API और गाइड

इस पेज के endpoints verification API reference में दर्ज हैं: PAN, bank account, vehicle RC, GSTIN, CIN और Udyam, साथ में PAN to GSTIN resolver। आस-पास के विषयों के लिए payout से पहले bank account verification पेज, PAN verification गाइड, errors और handling गाइड और vehicle RC गाइड पढ़िए। पहले आज़माना चाहें तो sandbox key के साथ API playground इस्तेमाल कीजिए या quickstart से शुरू कीजिए। उद्योग-वार सारे पेजों की सूची solutions पेज पर है।

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-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"
  }
}

{
  "referenceId": "SMV-20260927-3D71Q9",
  "regNo": "MH12AB1234",
  "registrationStatus": "VALID",
  "ownerName": "RAHUL KUMAR",
  "ownerFatherName": "SURESH KUMAR",
  "vehicleClass": "LMV",
  "vehicleManufacturerName": "MARUTI SUZUKI",
  "model": "SWIFT",
  "vehicleColor": "WHITE",
  "chassis": "MA3ERLF1S00123456",
  "engine": "K12MN1234567",
  "registrationDate": "2019-05-14",
  "rcStatus": "ACTIVE",
  "rcExpiryDate": "2034-05-13",
  "insuranceUpto": "2025-05-13",
  "isCommercial": false
}

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