कर्मचारी Background Verification API: क्या कर सकती है, क्या नहीं

मुख्य बातें

• पहचान की API पहचान और भुगतान-खाते की जाँच करती है: PAN, driving licence, voter ID, passport file, ड्राइवरों के लिए वाहन पंजीकरण और वेतन का बैंक खाता। वह आपराधिक, अदालती, शिक्षा या पिछली नौकरी की जाँचें नहीं करती, और Aadhaar-आधारित verification नहीं देती।
• भूमिका के हिसाब से पैकेज बनाइए। दफ़्तर के कर्मचारी, ड्राइवर, ठेकेदार और वित्त वाली भूमिका को अलग-अलग जाँचें चाहिए, और हर पैकेज एक बार लिखकर एक-सा लागू होना चाहिए।
• कुछ भी जाँचने से पहले सहमति लीजिए और सूचना दीजिए। सिर्फ़ वही लीजिए जो पैकेज को चाहिए, उम्मीदवार को कारण बताइए, और उद्देश्य संकरा रखिए।
• भारतीय नाम सीधे मिलान को तोड़ देते हैं: आद्याक्षर, नामों का क्रम, वर्तनी, विवाह के बाद का नाम और लिप्यंतरण। score की सीमाएँ और समीक्षा का दायरा रखिए, और सीधी असमानता पर कभी अस्वीकार मत कीजिए।
• विफल जाँच को फ़ैसला नहीं, सवाल मानिए। उम्मीदवार को समझाने या सुधारने का मौक़ा दीजिए, क्योंकि स्रोत रिकॉर्ड ग़लत हो सकते हैं और टाइपो आम हैं।
• valid: false और found: false पूरे और billable जवाब हैं। retry सिर्फ़ 429 और 502 पर।
• प्रति नियुक्ति लागत पैकेज के हिसाब से कुछ रुपये से कुछ दर्जन रुपये तक है। तीन भर्ती-मात्राओं का हिसाब नीचे है।

background verification में क्या आता है, और पहचान की API क्या कर सकती है

ईमानदार नक्शे से शुरू कीजिए। बायाँ कॉलम वे चीज़ें हैं जो आम background-check प्रस्ताव में दिखती हैं, और दाहिना बताता है कि इस प्लेटफ़ॉर्म से उनके बारे में क्या हो सकता है।

तालिका से दो सावधानियाँ निकलती हैं। voter ID या licence के response में पता हो सकता है, पर वह रजिस्ट्री का रिकॉर्ड है, आज कोई कहाँ रहता है इसका सबूत नहीं। और पहचान की जाँच इतना साबित करती है कि दस्तावेज़ मौजूद है और किसी नाम से मेल खाता है, उससे व्यक्ति की ईमानदारी या हुनर के बारे में कुछ पता नहीं चलता। इसे अंदर "पहचान और भुगतान-खाते का सत्यापन" कहिए, ताकि कोई उसमें जितना है उससे ज़्यादा न पढ़ ले।

तीन पक्ष और कौन क्या तय करता है

हर जाँच में तीन पक्ष जुड़ते हैं, और उनकी भूमिकाएँ साफ़ हों तो बाद की परेशानी बचती है।

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

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

उम्मीदवार का सफ़र

भर्ती की कड़ी में बैठने वाला background-check प्रवाह ऐसा दिखता है। ऑफ़र दिया जाता है। उम्मीदवार को joining लिंक मिलता है, वह एक छोटी सूचना पढ़ता है जो बताती है कि कौन-सी जाँचें और क्यों चलेंगी, और सहमति देता है। वह पहचानकर्ता डालता है या दस्तावेज़ अपलोड करता है। आपका सिस्टम जाँचें चलाता है और उम्मीदवार को registry का डेटा खोले बिना स्थिति दिखाता है ("चल रही है", "आपका ध्यान चाहिए", "पूरी")। HR को हर जाँच के नतीजे के साथ पैकेज का नतीजा दिखता है। कुछ उम्मीदवार के ध्यान का हो तो उसे साफ़ संदेश और जवाब देने का रास्ता मिलता है। पैकेज पूरा हो जाए तो HR उम्मीदवार को joining के लिए मंज़ूर करता है और payroll को सत्यापित बैंक खाता मिलता है।

joining फ़ॉर्म के दौरान जाँच चलाने की वजह सीधी है: पहले दिन पकड़ा गया बेमेल सुधरी प्रविष्टि से ठीक हो जाता है, जबकि तीसरे हफ़्ते पकड़ा गया बेमेल उस व्यक्ति से असहज बातचीत बन चुका होता है जो पहले से payroll में है।

भूमिका के हिसाब से पैकेज

पैकेज लिख लीजिए ताकि एक-सी स्थिति वाले उम्मीदवारों को एक-सी जाँचें मिलें। ये उदाहरण हैं, अपने हिसाब से ढालिए।

• दफ़्तर या back-office कर्मचारी। नाम के साथ PAN, फिर वेतन का खाता। voter ID या passport की जाँच तभी जोड़िए जब आपकी नीति दूसरा पहचान-दस्तावेज़ माँगे।
• ड्राइवर या डिलीवरी राइडर। PAN, driving licence, राइडर अपनी गाड़ी चलाए तो वाहन पंजीकरण, और वेतन या payout का खाता।
• ठेकेदार या freelancer। PAN, बैंक खाता, और अगर वह GST पंजीकरण के साथ invoice देता है तो GSTIN की जाँच, सूक्ष्म या लघु उद्यम हो तो Udyam, और कंपनी हो तो CIN।
• वित्त, नकदी सँभालने या अत्यधिक भरोसे वाली भूमिका। दफ़्तर वाले पैकेज की सारी जाँचें, और आपराधिक व पिछली नौकरी के इतिहास के लिए वे जाँचें जो आपकी नीति विशेषज्ञ प्रदाताओं से माँगे। पहचान की API एक इनपुट है, बाक़ी उसके बाहर है।
• एजेंसी से आया कामगार। staffing फ़र्म पैकेज चलाती है, ग्राहक को नतीजा और कारण मिलते हैं, कच्चे दस्तावेज़ नहीं, जब तक ग्राहक को उनकी वाजिब ज़रूरत न हो।

प्रक्रिया, कदम-दर-कदम

1. भूमिका का पैकेज तय कीजिए। लिखिए कि हर भूमिका को कौन-सी जाँचें चाहिए। फ़ैसला: पैकेज नहीं तो जाँच नहीं। इससे मनमानी ज़्यादा-माँग रुकती है।
2. सूचना दिखाइए और सहमति दर्ज कीजिए। सूचना का संस्करण, समय और उम्मीदवार की पुष्टि रखिए। फ़ैसला: सहमति नहीं तो जाँच नहीं।
3. पहचानकर्ता लीजिए। PAN, बैंक खाता और IFSC, और भूमिका का दस्तावेज़: driving licence संख्या व जन्म-तिथि, voter ID, या passport file संख्या व जन्म-तिथि। ढाँचा अपनी तरफ़ जाँचिए। फ़ैसला: पैसा लगाने से पहले टाइपो ठीक कराइए।
4. उम्मीदवार के नाम के साथ PAN जाँचिए। POST /v1/verify/pan में pan और name। valid, type, registeredName, nameMatchScore पढ़िए। फ़ैसला: व्यक्तिगत नियुक्ति पर कंपनी या फ़र्म का type डेटा की ग़लती है, कमज़ोर score समीक्षा में।
5. भूमिका का दस्तावेज़ जाँचिए। ड्राइवरों के लिए POST /v1/verify/driving-license में dlNumber और dob, बाक़ियों के लिए आपके पैकेज के अनुसार voter ID या passport। फ़ैसला: समाप्त या निष्क्रिय स्थिति ड्राइविंग भूमिकाओं के लिए रुकावट है और दूसरों के लिए सवाल।
6. जहाँ ज़रूरी हो, वाहन जाँचिए। POST /v1/verify/rc में vehicleNumber। फ़ैसला: मालिक और स्थिति भूमिका के नियमों (अपनी गाड़ी, कंपनी की गाड़ी, पट्टा) से मिलाइए।
7. वेतन का खाता जाँचिए। POST /v1/verify/bank-account में खाता संख्या, IFSC और उम्मीदवार का नाम। फ़ैसला: payroll उस खाते को तभी ले जब नतीजा वैध हो और नाम का score स्वीकार्य।
8. पैकेज का नतीजा बनाइए। हर जाँच के नतीजों को एक स्थिति में मिलाइए: साफ़, टिप्पणी के साथ साफ़, ध्यान चाहिए, या रोक। फ़ैसला: HR को स्थिति और कारण दिखें, registry का कच्चा डेटा नहीं।
9. उम्मीदवार को जवाब का मौक़ा दीजिए। "ध्यान चाहिए" पर सीधा संदेश भेजिए कि क्या सुधारना है। फ़ैसला: इंसानी समीक्षा से पहले सुधार का एक दौर।
10. नीति के अनुसार दर्ज और संरक्षित कीजिए। referenceId, समय, मुख्य fields, फ़ैसला और समीक्षक रखिए, और अपने retention नियमों के हिसाब से मिटाने की तारीख़ तय कीजिए।

नमूना request और response: driving-licence की जाँच

ड्राइवर और डिलीवरी भूमिकाओं में licence केंद्रीय दस्तावेज़ है। request में licence संख्या और उम्मीदवार की जन्म-तिथि जाती है:

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/driving-license" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"dlNumber":"MH1420110012345","dob":"1990-01-01"}'

{
  "referenceId": "SMV-20260927-2Q56T8",
  "valid": true,
  "name": "RAHUL KUMAR",
  "fatherOrHusbandName": "SURESH KUMAR",
  "dob": "1990-01-01",
  "address": "123, MG Road, Bengaluru",
  "validUpto": "2030-12-31",
  "dlStatus": "ACTIVE"
}

driving-licence और passport endpoints संवेदनशील scopes हैं, इसलिए IP allowlist वाली production key की योजना बनाइए। समीक्षकों को सिर्फ़ ज़रूरी fields दिखाइए। इस response में पता और रिश्ते वाला नाम उस डेटा के अच्छे उदाहरण हैं जिसे आपको कम से कम रखना चाहिए।

भारतीय नाम और सीधा मिलान क्यों टूटता है

पहचान-जाँच में झूठे बेमेल का सबसे बड़ा स्रोत नाम है। एक ही व्यक्ति PAN, licence, बैंक खाते और joining फ़ॉर्म में जायज़ तौर पर "Rahul Kumar", "Kumar Rahul", "R. Kumar", "Rahul K", "Rahul Kumar Singh" या "Rahul Kumar S" दिख सकता है। शादी के बाद उपनाम बदलते हैं। क्षेत्रीय लिपियों से लिप्यंतरण एक ही नाम की अलग वर्तनियाँ बनाता है। कुछ लोगों का सिर्फ़ एक नाम होता है, और कुछ प्रणालियाँ लंबे नाम काट देती हैं।

इसकी तैयारी तीन तरह से कीजिए। पहली, PAN और bank-account endpoints जो match score लौटाते हैं उसे इस्तेमाल कीजिए, अपनी बराबरी की जाँच नहीं, और समीक्षा के दायरे वाली सीमाएँ रखिए। दूसरी, जिन endpoints में बिना score के नाम आता है (licence, voter ID, passport और registry lookups), वहाँ नामों की तुलना ऐसे सहनशील तरीक़े से ख़ुद कीजिए जो शब्दों का क्रम, आद्याक्षर और आम वर्तनी-भेद सँभाले। तीसरी, सिर्फ़ नाम के बेमेल पर कभी उम्मीदवार को अस्वीकार मत कीजिए: उसे दोनों नामों के साथ इंसान के पास भेजिए, जो अपना विवेक लगाए, शायद उम्मीदवार को एक छोटा फ़ोन करके।

import re

def normalise(name: str) -> list[str]:
    cleaned = re.sub(r"[^a-z ]", " ", name.lower())
    return [w for w in cleaned.split() if w]

def tolerant_match(a: str, b: str) -> str:
    wa, wb = normalise(a), normalise(b)
    if not wa or not wb:
        return "review"
    full_b = {w for w in wb if len(w) > 1}
    initials_b = {w[0] for w in wb}
    hits = 0
    for w in wa:
        if len(w) > 1 and w in full_b:
            hits += 1
        elif len(w) == 1 and w in initials_b:
            hits += 1
    ratio = hits / len(wa)
    if ratio >= 0.9:
        return "agree"
    if ratio >= 0.5:
        return "review"
    return "disagree"

यह function शुरुआत है, तैयार matcher नहीं। इसे अपने इतिहास के कुछ सौ असली नाम-जोड़ों पर आज़माइए, झूठे सही और झूठे ग़लत देखिए और ढालिए। हर फ़ैसले के समय लागू सीमाओं का रिकॉर्ड रखिए।

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

ध्यान दीजिए कि तालिका में कुछ भी किसी व्यक्ति की अपने-आप अस्वीकृति नहीं है। रुकने का मतलब है कि समस्या सुलझने तक पैकेज मंज़ूर नहीं हो सकता। ऑफ़र वापस लेने का फ़ैसला इंसान का है और आपकी HR नीति और कानूनी सलाह के अनुसार होना चाहिए।

सहमति, सूचना और निष्पक्षता

background checks उन लोगों के निजी डेटा का इस्तेमाल करते हैं जो मोल-भाव में कमज़ोर स्थिति में हैं। इसे सावधानी से सँभालिए।

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

भारत का Digital Personal Data Protection Act, 2023 निजी डेटा पर सूचना, सहमति, उद्देश्य की सीमा, सटीकता और अवधि के सिद्धांत तय करता है। कर्मचारी-छँटाई पर वह कैसे लागू होता है, नियोक्ताओं के लिए किसी वैध-उपयोग के प्रावधान समेत, यह उस पाठ और नियमों पर निर्भर है जो आपके पढ़ते समय लागू हैं। अपने सलाहकार से पूछिए, किसी vendor के सार पर भरोसा मत कीजिए।

प्रतिकूल नतीजे और उम्मीदवार का पक्ष

स्रोत डेटा ग़लत हो सकता है। licence रिकॉर्ड पर पुराना नाम हो सकता है, PAN पर अलग वर्तनी, और बैंक में नाम उस रूप में जो उम्मीदवार अब इस्तेमाल नहीं करता। जाँच विफल हो तो उसे बात करने का कारण मानिए, फ़ैसले का नहीं।

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

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

staffing एजेंसी का थोक में काम

जो staffing फ़र्म किसी ग्राहक के लिए एक दिन में सैकड़ों कामगार जोड़ती है, उसकी throughput की समस्याएँ अकेली HR टीम की नहीं होतीं।

जाँचें queue से asynchronous चलाइए। workers उम्मीदवार उठाते हैं, endpoints बुलाते हैं, नतीजे लिखते हैं और उम्मीदवार की स्थिति अपडेट करते हैं। concurrency अपने plan की rate limit के भीतर रखिए (दस्तावेज़ में दर्ज error का उदाहरण 60 सेकंड में 60 requests है, अपनी सीमाएँ dashboard और pricing पेज से पढ़िए)। 429 और 502 पर backoff कीजिए, 402 पर अलर्ट, और नकारात्मक जवाबों को दोहराइए मत। हर ग्राहक का डेटा और रिपोर्ट अलग रखिए ताकि कोई ग्राहक दूसरे के उम्मीदवार कभी न देखे, और हर जाँच पर ग्राहक व पैकेज का टैग लगाइए ताकि invoicing और audit trail मेल खाएँ।

उछाल की उम्मीद रखिए: shift-आधारित भर्ती में किसी परियोजना की शुरुआत में भीड़ आती है। intake फ़ॉर्म में ढाँचे पहले ही जाँचिए ताकि ख़राब डेटा सशुल्क calls न खाए, और हर उम्मीदवार पर retry की सीमा रखिए ताकि जो उम्मीदवार वही ग़लत नंबर डालता रहे वह ख़र्च न बढ़ा दे। ग्राहक को ऐसा स्थिति-dashboard दीजिए जो नतीजे के हिसाब से गिनती और उम्मीदवारों के इंतज़ार में पड़े मामलों की उम्र दिखाए, क्योंकि "उम्मीदवार का इंतज़ार" देरी की सबसे आम वजह है और आपके बस में नहीं।

पहली payroll से पहले वेतन का खाता

वेतन का लौटा हुआ credit कर्मचारी के लिए छोटा संकट है और payroll के लिए बड़ी झंझट। payroll set-up से पहले कर्मचारी के नाम के साथ verify/bank-account चलाइए और नतीजे पर कार्रवाई कीजिए: वैध खाता और मज़बूत नाम-score payroll master में जाता है, बीच का score छोटी इंसानी जाँच में, और अवैध खाते पर अलग ब्योरा माँगा जाता है। संयुक्त या पारिवारिक खातों को स्वीकार करना है या नहीं और कौन-सा प्रमाण माँगना है, यह आपकी नीति तय करती है। चूँकि इस जाँच का शुल्क हर plan पर bank-account की एक-सी दर है, हर नियुक्ति पर इसे करना लौटे हुए वेतन के मुक़ाबले सस्ता पड़ता है।

बाद के खाता-बदलावों को पहली बार जैसा ही मानिए: payroll master बदलने से पहले दोबारा जाँचिए और कर्मचारी से ऐसे माध्यम पर पुष्टि लीजिए जिस पर आप पहले से भरोसा करते हैं। वेतन-मोड़ने की ठगी इसी पर टिकती है कि कोई बिना जाँचे बदलाव का अनुरोध मान ले।

HR-operations डेस्क की पाँच स्थितियाँ

ये काल्पनिक मामले हैं।

साफ़-सुथरा joiner

दफ़्तर की एक नियुक्ति सहमति देती है, PAN और बैंक ब्योरा डालती है, और दोनों जाँचें मज़बूत score के साथ वैध लौटती हैं। पैकेज एक मिनट में साफ़ हो जाता है, payroll खाता ले लेता है, और HR को एक पंक्ति दिखती है: मंज़ूर।

विवाह के बाद का नाम

उम्मीदवार के PAN पर उसका पैतृक उपनाम है जबकि बैंक खाता विवाह के बाद के नाम पर है। बैंक का score समीक्षा के दायरे में पड़ता है। समीक्षक को दोनों नाम और उम्मीदवार का अपलोड किया विवाह-प्रमाणपत्र दिखता है, वह कारण दर्ज करता है और जाँच साफ़ कर देता है। कोई call दोहराई नहीं जाती।

समाप्त licence

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

रिश्तेदार की गाड़ी

एक राइडर अपने पिता की मोटरसाइकिल इस्तेमाल करता है। RC जाँच किसी और नाम पर वैध पंजीकरण लौटाती है। राइडरों का पैकेज मालिक की लिखित अनुमति के साथ इसे मानता है। समीक्षक अनुमति जोड़ता है और जाँच को टिप्पणी के साथ साफ़ चिह्नित करता है।

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

भर्ती-अभियान के दौरान licence की call 502 देती है। उम्मीदवारों को error नहीं, "जाँच चल रही है" दिखता है। queue backoff से retry करती है और स्रोत लौटते ही पूरा करती है। किसी उम्मीदवार को डिफ़ॉल्ट रूप से मंज़ूर नहीं किया जाता और प्लेटफ़ॉर्म की गड़बड़ी पर किसी पर निशान नहीं लगता।

HR टीम के लिए अपनाने लायक़ समीक्षा-नियम

ये सुझाव हैं जिन्हें आपकी नीति ढाले।

• अपने-आप मंज़ूर जब पैकेज की हर जाँच वैध हो, नाम के score ऊँची सीमा से ऊपर हों, जन्म-तिथियाँ मेल खाएँ और स्थितियाँ चालू हों।
• समीक्षा जब नाम का score बीच के दायरे में पड़े, जन्म-तिथि अलग हो, वाहन का मालिक उम्मीदवार से अलग हो, या कोई दस्तावेज़ समाप्ति के पास हो।
• सुलझाने तक रुकें जब ज़रूरी भूमिका के लिए दस्तावेज़ समाप्त या निष्क्रिय हो, PAN का प्रकार भूमिका से उलटा हो, या वेतन का खाता वैध न हो।
• कभी अपने-आप अस्वीकार नहीं। ऑफ़र का फ़ैसला इंसान करता है, सबूत और उम्मीदवार के जवाब को देखकर।
• इंसानी समीक्षा से पहले सुधार का एक दौर, और उम्मीदवार के जवाब की समय-सीमा जो उम्मीदवार को बताई जाए।
• दूसरा समीक्षक override के लिए और किसी जाँच-नतीजे के आधार पर ऑफ़र वापस लेने वाले हर फ़ैसले के लिए।
• कम से कम पहुँच। समीक्षकों को वही fields दिखें जो चाहिए, प्रबंधकों को स्थिति और कारण।

टीम का ढाँचा

दो queue चलाइए। उम्मीदवार queue में वे मामले हैं जो उम्मीदवार पर टिके हैं: उसका काम याद दिलाना, सवालों के जवाब देना और पीछा करना है, और उसे recruiters या HR coordinators सँभालते हैं। समीक्षा queue में वे मामले हैं जिनमें विवेक चाहिए: उसे HR operations विश्लेषक सँभालते हैं और वृद्धि के लिए एक नामित वरिष्ठ समीक्षक रहता है। विफल calls और wallet अलर्ट के लिए तीसरी, platform queue इंजीनियरिंग की है।

अपनी भर्ती की रफ़्तार के हिसाब से समय-सीमाएँ रखिए, जैसे joining के दिन समीक्षा के मामलों के लिए उसी दिन निपटारा, और हर queue के सबसे पुराने मामले की उम्र नापिए। हर ग्राहक या business unit को अपने मापदंडों का दृश्य दीजिए ताकि देरी पर बातचीत आँकड़ों पर टिके।

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

सूचना का संस्करण और सहमति का रिकॉर्ड, पैकेज की परिभाषा, हर जाँच का referenceId, समय, key का environment, ढके हुए पहचानकर्ता, फ़ैसले में काम आए response fields, फ़ैसला, समीक्षक और override का कारण रखिए। कच्चे दस्तावेज़ नंबर application logs से बाहर रखिए। उम्मीदवार के दस्तावेज़, अगर आप लेते हैं, अलग पहुँच-नियंत्रित भंडार में रखिए।

जो उम्मीदवार जुड़े और जो नहीं जुड़े, उनके लिए retention अलग होता है। आम सिद्धांत यह है कि जहाँ कोई चालू संबंध नहीं वहाँ डेटा कम समय रखा जाए और जहाँ रोज़गार व वैधानिक रिकॉर्ड-रखाव लागू हों वहाँ ज़्यादा, पर असली अवधियाँ रोज़गार कानून, कर और payroll नियमों, अनुबंध की ज़रूरतों और डेटा-सुरक्षा कानून पर निर्भर हैं। अवधियाँ अपने सलाहकार से लीजिए, retention schedule में लिखिए और मिटाना स्वचालित कीजिए। StampMitra का अपना तरीक़ा उसके retention और deletion schedule और data processing addendum में है।

लागत: तीन भर्ती-मात्राएँ

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

एक नियुक्ति की लागत पैकेज पर निर्भर है। दफ़्तर की नियुक्ति (PAN और बैंक खाता) और ड्राइवर (PAN, licence, वाहन RC और बैंक खाता):

मासिक मॉडलों के लिए मान लीजिए 70 प्रतिशत नियुक्तियाँ दफ़्तर की हैं और 30 प्रतिशत ड्राइवरों की। N नियुक्तियों पर यह N PAN जाँचें, 0.3N licence जाँचें, 0.3N वाहन जाँचें और N बैंक जाँचें हैं, यानी 1.3N standard calls, 0.3N premium calls और N बैंक जाँचें। महीने में 200 नियुक्तियों पर: 260 standard calls, 60 premium calls और 200 बैंक जाँचें।

महीने में 2,000 नियुक्तियों पर: 2,600 standard calls, 600 premium calls और 2,000 बैंक जाँचें।

महीने में 20,000 नियुक्तियों पर, जैसा कोई बड़ा staffing प्लेटफ़ॉर्म देख सकता है: 26,000 standard calls, 6,000 premium calls और 20,000 बैंक जाँचें।

तीनों तालिकाएँ ऐसे पढ़िए: महीने में 200 नियुक्तियों पर pay as you go सबसे सस्ता है क्योंकि plan फ़ीस कम दरों से भारी पड़ती है, 2,000 पर Growth सबसे सस्ता है, और 20,000 पर Scale, जहाँ ख़र्च उस सीमा से ऊपर है जिस पर StampMitra enterprise व्यवस्था का सुझाव देता है, जिसकी बात आप contact पेज पर कर सकते हैं। तालिकाएँ मानती हैं कि GST plan फ़ीस पर भी लगता है, invoice से पक्का कीजिए। उपयोग सफल response के बाद दर्ज होता है, इसलिए error पर ख़त्म हुई calls का शुल्क नहीं लगता, पर valid: false सफल जवाब है और उसका शुल्क लगता है। ये आँकड़े सिर्फ़ StampMitra की calls के हैं: background-check के बाक़ी तत्वों की दूसरे प्रदाताओं से लागत अलग है, और समीक्षा में लगा कर्मचारी-समय भी।

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

Sandbox। उम्मीदवार का सफ़र, पैकेज का तर्क और समीक्षा queue sandbox keys पर बनाइए। responses नमूना डेटा हैं और wallet कभी नहीं कटता। sandbox PAN SNDBX0000A पर वैध और SNDBX9999F पर अवैध नतीजा देता है, और बाक़ी किसी इनपुट पर स्थिर पर मनमाना नतीजा आता है, इसलिए उस पर assertion मत लगाइए। dashboard में ताज़ा test values देखिए। फ़ैसले-तालिका के हर खाने, नाम-matcher, सहमति-द्वार, सुधार-के-एक-दौर वाले नियम और 402, 429, 502 के रास्तों का test कीजिए।

Pilot। production access के लिए आवेदन कीजिए, जिसके लिए आपके संगठन की KYC मंज़ूरी और product-वार आवेदन चाहिए। licence और passport scopes संवेदनशील हैं और IP allowlist वाली key माँगते हैं। किसी एक ग्राहक या business unit के joiners को इस प्रवाह से गुज़ारिए जबकि HR कुछ हफ़्ते हाथ से भी जाँचता रहे, और नतीजे मिलाइए।

Production। ग्राहक और भूमिका के हिसाब से बढ़ाइए। पहले महीने के बाद असली बेमेल-डेटा से सीमाएँ दोबारा देखिए। wallet balance पर अलर्ट रखिए, और scopes और allowlist के लिए sandbox बनाम production keys गाइड हाथ के पास रखिए।

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

• बिना इंसानी समीक्षा के मंज़ूर हुए पैकेजों का हिस्सा, पैकेज के प्रकार के हिसाब से।
• उम्मीदवार के जमा करने से पैकेज के नतीजे तक का समय, और नतीजे से joining तक का।
• "ध्यान चाहिए" में उम्मीदवारों का हिस्सा, और जवाब देने का मध्यक समय।
• नामों के लिए समीक्षा-दायरे की दर, और समीक्षा के बाद कितने साफ़ हुए।
• भूमिका के हिसाब से पक्की रुकावटों के कारण: समाप्त licence, अवैध खाता, PAN का प्रकार।
• वे अपीलें या सुधार जिनसे नतीजा बदला।
• प्रति उम्मीदवार calls। संख्या ऊँची हो तो retry loops या बार-बार ग़लत डेटा भरा जा रहा है।
• अस्वीकार करके पलटे गए फ़ैसले, जो दिखाते हैं कि प्रक्रिया कहाँ ज़्यादा सख़्त है।

जो ग़लतियाँ उम्मीदवारों को चोट पहुँचाती हैं या प्रक्रिया को कमज़ोर करती हैं

• पहचान की API से पूरी background check की उम्मीद। वह सिर्फ़ पहचान और भुगतान-खाते की जाँच करती है।
• ज़रूरत से ज़्यादा लेना। हर भूमिका के लिए हर दस्तावेज़ माँगना।
• नामों की अक्षरशः बराबरी। सामान्य भारतीय नामों पर झूठे बेमेल बनते हैं।
• विफल जाँच पर अपने-आप अस्वीकार। स्रोत रिकॉर्ड ग़लत हो सकते हैं।
• उम्मीदवारों या प्रबंधकों को registry का डेटा दिखाना। निजी डेटा खुलता है और विवाद बढ़ते हैं।
• नकारात्मक जवाब पर retry। वही जवाब, फिर बिल।
• सहमति और सूचना छोड़ना। दोनों निष्पक्ष प्रसंस्करण के केंद्र में हैं।
• डेटा हमेशा रखना। retention तय कीजिए और स्वचालित कीजिए।
• staffing प्लेटफ़ॉर्म में ग्राहकों का डेटा मिलाना। पहले दिन से ग्राहक के हिसाब से अलग रखिए।
• जाँच को चरित्र-प्रमाण समझना। वह ईमानदारी या हुनर के बारे में कुछ नहीं कहती।

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

इस पेज के endpoints verification API reference में हैं: PAN, driving licence, voter ID, passport, vehicle RC और bank account। संबंधित पढ़ाई के लिए payout से पहले bank account verification देखिए जो वेतन के खातों पर भी उतना ही लागू होता है, gig और डिलीवरी पार्टनरों के लिए marketplace seller verification पेज, PAN verification गाइड, vehicle RC गाइड और errors गाइड। सारे उद्योग-वार पेज solutions पेज पर हैं, और दरें pricing पेज पर।

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-2Q56T8",
  "verificationId": "VRF-4H8Z2M6TQ9KW",
  "valid": true,
  "dlNumber": "KA51201900089895",
  "dob": "1994-08-05",
  "status": "VALID",
  "dlStatus": "VALID",
  "name": "JOHN DOE",
  "fatherOrHusbandName": "JOHN DOE",
  "address": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103",
  "validUpto": "09/05/2039",
  "badgeDetails": [
    {
      "badgeIssueDate": null,
      "badgeNo": null,
      "classOfVehicle": [
        "LMV"
      ]
    }
  ],
  "dlValidity": {
    "nonTransport": {
      "to": "09/05/2039",
      "from": "10/05/2019"
    },
    "hazardousValidTill": null,
    "transport": {
      "to": null,
      "from": null
    },
    "hillValidTill": null
  },
  "detailsOfDrivingLicence": {
    "dateOfIssue": "10/05/2019",
    "dateOfLastTransaction": null,
    "status": null,
    "lastTransactedAt": null,
    "name": "JOHN DOE",
    "fatherOrHusbandName": "JOHN DOE",
    "addressList": [
      {
        "completeAddress": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103",
        "type": "permanent",
        "splitAddress": {
          "district": [
            "BANGALORE"
          ],
          "state": [
            "KARNATAKA",
            "KA"
          ],
          "city": [
            "BELLANDUR"
          ],
          "pincode": "560103",
          "country": [
            "IN",
            "IND",
            "INDIA"
          ],
          "addressLine": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103"
        }
      },
      {
        "completeAddress": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103",
        "type": "temporary",
        "splitAddress": {
          "district": [
            "BANGALORE"
          ],
          "state": [
            "KARNATAKA",
            "KA"
          ],
          "city": [
            "BELLANDUR"
          ],
          "pincode": "560103",
          "country": [
            "IN",
            "IND",
            "INDIA"
          ],
          "addressLine": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103"
        }
      }
    ],
    "address": "FLAT NO D-901 SUN,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103",
    "photoUrl": "https://example.com/dl-photos/KA51201900089895.jpeg",
    "splitAddress": {
      "district": [
        "BANGALORE"
      ],
      "state": [
        ""
      ],
      "city": [
        "BELLANDUR"
      ],
      "pincode": "560103",
      "country": [
        "IN",
        "IND",
        "INDIA"
      ],
      "addressLine": "FLAT NO D-901 SUNCITY,BELLANDUR, BANGALORE SOUTH,BANGALORE,KA 560103"
    },
    "covDetails": []
  }
}

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

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