कानूनी और Compliance टीमों के लिए Verification के प्रवाह

मुख्य बातें

• कानूनी प्रवाह रिकॉर्ड की परवाह करता है। हर जाँच के लिए रखिए कि आपने क्या पूछा, स्रोत ने क्या लौटाया, समय, transaction id, किसने देखा और आपने क्या तय किया।
• verification "प्रतिपक्ष कौन है और क्या वह ठीक स्थिति में है" में मदद करता है। यह नहीं बताता कि हस्ताक्षरकर्ता के पास अधिकार है, अनुबंध लागू होने योग्य है, या कोई व्यक्ति प्रतिबंधित या राजनीतिक रूप से उजागर है।
• कंपनियों के लिए CIN का response निदेशकों को DIN, नाम और पदनाम के साथ गिनाता है। हस्ताक्षरकर्ता को उस सूची से मिलाना अधिकार की उपयोगी पहली जाँच है, और board resolution या authority letter जैसा दस्तावेज़ ही असली सबूत रहता है।
• e-stamping को निष्पादन के चरण का हिस्सा मानिए। duty गणना endpoint से आती है, orders में आपका matter-संदर्भ जाता है, और जारी प्रमाणपत्र की सहेजी हुई प्रति matter फ़ाइल में रखी जाती है।
• गोपनीयता के लिए डिज़ाइन कीजिए। कम से कम पहचानकर्ता इस्तेमाल कीजिए, उन्हें सामान्य logs से बाहर रखिए, और ग्राहक के साथ तय कीजिए कि उन्हें आपके औज़ारों के बारे में क्या बताया जाए।
• pack में सबूत की अखंडता डालिए: समय-मुहरें, सहेजी फ़ाइलों के hash, समीक्षक की मंज़ूरी, और यह साफ़ नियम कि बाद का पाठक किस पर भरोसा कर सकता है।
• valid: false और found: false पूरे, billable जवाब हैं। इन्हें लूप में मत चलाइए। retry सिर्फ़ 429 और 502 पर।
• एक आम matter की जाँचों पर प्रकाशित दरों से कुछ रुपये लगते हैं। तीन मात्राओं का हिसाब नीचे है।

कानूनी matter में verification कहाँ बैठता है

कानूनी काम का एक जीवन-चक्र होता है, और verification उसके ख़ास बिंदुओं पर आता है। तालिका चरणों को जाँचों से जोड़ती है और बताती है कि हर एक का आम तौर पर मालिक कौन है।

जाँच जितनी जल्दी होती है, ग़लती उतनी सस्ती पड़ती है। intake पर पकड़ा गया ग़लत कानूनी नाम एक सुधार है। वही चूक निष्पादन के बाद दोबारा stamp और दोबारा दस्तख़त करवा सकती है।

verification का नतीजा क्या साबित कर सकता है और क्या नहीं

ईमानदार सूची दुरुपयोग रोकती है। verification का नतीजा ऐसे कथनों को सहारा दे सकता है: "इस तारीख़ को दिए गए PAN पर वैध रिकॉर्ड लौटा जिसका नाम प्रतिपक्ष के घोषित कानूनी नाम से इस score के साथ मेल खाया।" या: "इस तारीख़ को दिया गया GSTIN चालू था और उसका कानूनी नाम X था।" या: "इस तारीख़ को कंपनी की रजिस्ट्री-स्थिति चालू थी और निदेशकों में वह व्यक्ति शामिल था जिसने दस्तख़त किए।"

यह ऐसे कथनों को सहारा नहीं दे सकता: "हस्ताक्षरकर्ता अधिकृत था।" उसके लिए दस्तावेज़ और कानूनी विवेक चाहिए। या: "प्रतिपक्ष शोधन-क्षम है।" यहाँ कुछ भी शोधन-क्षमता नहीं नापता। या: "प्रतिपक्ष प्रतिबंधित या राजनीतिक रूप से उजागर नहीं है।" ये endpoints प्रतिबंध या उजागर होने की सूचियों से मिलान नहीं करते। या: "हमारे सामने बैठा व्यक्ति वही है जो दस्तावेज़ में है।" endpoints चेहरे का मिलान या लाइव पहचान नहीं करते, और Aadhaar-आधारित verification नहीं देते। अपने evidence-pack का साँचा ऐसे लिखिए कि वह बताए कि क्या जाँचा गया, उससे ज़्यादा कुछ नहीं।

matter फ़ाइल और evidence pack

evidence pack को साँचे की तरह एक बार तय कीजिए और हर matter से वही भरवाइए। अच्छे pack के सात हिस्से होते हैं।

1. matter का शीर्षक। matter-संदर्भ, ग्राहक, प्रतिपक्ष, खुलने की तारीख़, ज़िम्मेदार वकील, समीक्षक।
2. घोषणा। ग्राहक या प्रतिपक्ष ने आपको क्या बताया: नाम, पहचानकर्ता, इकाई का प्रकार, पता, हस्ताक्षरकर्ता।
3. चलाई गई जाँचें। हर जाँच के लिए: endpoint, समय (UTC), transaction id (referenceId), key का environment, और जो पहचानकर्ता आपने भेजे वे ढके रूप में।
4. नतीजे। जिन response fields पर आपने भरोसा किया वे जैसे मिले वैसे कॉपी, और कच्चे response की सहेजी प्रति पहुँच-नियंत्रित भंडार में।
5. निष्कर्ष। क्या मेल खाया, क्या नहीं, और हर अंतर पर आपने कौन-सा नियम या तर्क लगाया।
6. फ़ैसला और मंज़ूरी। किसने किस आधार पर कब तय किया, और किसने समीक्षा की।
7. संलग्नक। अधिकार-दस्तावेज़, resolutions, वह पत्राचार जिसने निष्कर्ष सुलझाया, और जहाँ लागू हो e-Stamp का सहेजा प्रमाणपत्र।

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

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

1. matter खोलिए और घोषणा लीजिए। नाम ठीक वैसे लिखिए जैसे दिए गए, पहचानकर्ता, इकाई का प्रकार, पंजीकृत पता और हस्ताक्षरकर्ता। फ़ैसला: घोषणा नहीं तो जाँच नहीं।
2. ढाँचे की जाँचें अपनी तरफ़ चलाइए। PAN, GSTIN, CIN और Udyam के पैटर्न, और GSTIN के लिए यह कि उसके भीतर का PAN घोषित PAN के बराबर है। फ़ैसला: घोषणा सुधारिए या आगे बढ़िए।
3. व्यक्ति या इकाई का PAN जाँचिए। pan और घोषित कानूनी नाम के साथ POST /v1/verify/pan। valid, type, registeredName, nameMatchScore पढ़िए। फ़ैसला: अवैध रुकता है, घोषित इकाई-प्रकार से उलटा type समीक्षा में।
4. पंजीकरण जाँचिए। GST-पंजीकृत प्रतिपक्ष के लिए POST /v1/verify/gstin, कंपनी के लिए POST /v1/verify/cin, और अनुबंध के लिए MSME दावा मायने रखे तो POST /v1/verify/udyam। स्थिति वाले fields पढ़िए। फ़ैसला: निष्क्रिय पर matter तब तक रुकता है जब तक सुलझे या दर्ज न हो।
5. हस्ताक्षरकर्ता जाँचिए। कंपनी के लिए हस्ताक्षरकर्ता का नाम CIN के response की directors सूची से मिलाइए, और हस्ताक्षरकर्ता का अपना PAN उसके नाम के साथ जाँचिए। फ़ैसला: जो हस्ताक्षरकर्ता सूचीबद्ध निदेशक नहीं, उसके लिए निष्पादन से पहले अधिकार-दस्तावेज़।
6. समीक्षा और मंज़ूरी। आपकी तय गंभीरता से ऊपर के निष्कर्षों की दूसरा व्यक्ति समीक्षा करे। फ़ैसला: आगे बढ़ें, दस्तावेज़ माँगें या मना करें।
7. निष्पादन और stamp। duty की गणना कीजिए, matter-संदर्भ के साथ order बनाइए, पक्ष जोड़िए, भुगतान कीजिए और प्रमाणपत्र लाइए। फ़ैसला: पाठ अंतिम होने पर ही stamp कीजिए।
8. रखिए और बंद कीजिए। evidence pack और प्रमाणपत्र के bytes सहेजिए और retention वर्ग तय कीजिए।

नमूना request और response: हस्ताक्षरकर्ता का PAN जाँचना

हस्ताक्षरकर्ता की जाँच वही है जो सबसे ज़्यादा छूटती है और सबसे ज़्यादा पछतावा देती है। request में PAN और वह नाम जाता है जो मसौदे में है:

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/pan" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"pan":"ABCDE1234F","name":"Rahul Kumar"}'

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

response में ऐसे fields हैं जिन्हें यह प्रवाह इस्तेमाल नहीं करता। फ़ैसले के लिए जो चाहिए वही सहेजिए, क्योंकि matter फ़ाइल में हर अतिरिक्त निजी field ऐसा field है जिसे आपको बचाकर रखना और बाद में मिटाना है।

नीचे का Python function response से evidence-pack की प्रविष्टि बनाता है, ढकने और कच्चे response के hash के साथ, ताकि बाद की छेड़छाड़ पकड़ी जा सके।

import hashlib
import json
from datetime import datetime, timezone

def mask(value: str, keep: int = 2) -> str:
    return value[:keep] + "*" * max(0, len(value) - keep - 1) + value[-1:]

def evidence_entry(matter_ref: str, endpoint: str, sent: dict, response: dict, decided_by: str, decision: str) -> dict:
    raw = json.dumps(response, sort_keys=True, separators=(",", ":"))
    return {
        "matter": matter_ref,
        "endpoint": endpoint,
        "checkedAtUtc": datetime.now(timezone.utc).isoformat(),
        "referenceId": response.get("referenceId"),
        "sent": {k: (mask(str(v)) if k in ("pan", "gstin", "cin", "accountNumber") else v) for k, v in sent.items()},
        "relied_on": {k: response.get(k) for k in ("valid", "type", "registeredName", "nameMatchScore", "panStatus")},
        "rawResponseSha256": hashlib.sha256(raw.encode()).hexdigest(),
        "decision": decision,
        "decidedBy": decided_by,
    }

अधिकार की जाँच: निदेशकों से दस्तावेज़ों तक

कंपनी के लिए CIN की call निदेशकों की सूची लौटाती है, हर एक DIN, नाम और पदनाम के साथ। हस्ताक्षरकर्ता के नाम को उस सूची से मिलाना एक संकरे सवाल का जवाब देता है: क्या यह व्यक्ति कंपनी की निदेशक-सूची में है, जैसा रजिस्ट्री दिखाती है? यह अच्छी पहली छन्नी है, क्योंकि जो हस्ताक्षरकर्ता सूचीबद्ध निदेशक नहीं, उसके लिए स्पष्टीकरण चाहिए।

यह इसका जवाब नहीं देती कि व्यक्ति इस लेन-देन के लिए अधिकृत है या नहीं। अधिकार articles, board resolution, power of attorney या प्रत्यायोजन से आ सकता है, और रकम या लेन-देन के प्रकार से सीमित हो सकता है। आपकी practice निदेशक-मिलान को दस्तावेज़ जाँचने का इशारा माने, उसकी जगह नहीं। हस्ताक्षरकर्ता निदेशक न हो तो वह दस्तावेज़ माँगिए जो उसे अधिकार देता है, और pack से लगाइए। जहाँ प्रतिपक्ष कंपनी नहीं है, जैसे साझेदारी फ़र्म, LLP या प्रोप्राइटरशिप, वहाँ इस प्लेटफ़ॉर्म पर अधिकार के लिए CIN जैसा endpoint नहीं है, इसलिए सबूत दस्तावेज़ी है: साझेदारी-विलेख, LLP क़रार, प्रोप्राइटर की घोषणा।

नीचे का Node function पहली-छन्नी वाली तुलना दिखाता है और pack के लिए निष्कर्ष लौटाता है।

export function signatoryFinding(signatoryName, cinResponse) {
  if (!cinResponse?.valid) return { result: "no_company_record", action: "request_documents" };
  const wanted = signatoryName.toLowerCase().split(/\s+/).filter(Boolean);
  const match = (cinResponse.directors ?? []).find((d) => {
    const name = d.name.toLowerCase();
    return wanted.every((w) => name.includes(w));
  });
  if (!match) return { result: "not_a_listed_director", action: "request_authority_document" };
  return { result: "listed_director", designation: match.designation, din: match.din, action: "check_authority_scope" };
}

stamp वाला कदम

बहुत-से दस्तावेज़ों पर stamp लगना होता है, और सबसे आम कानूनी दस्तावेज़ वे हैं जो आपकी practice से रोज़ गुज़रते हैं: किराया और leave-and-licence क़रार, शपथपत्र, क्षतिपूर्ति-बॉन्ड, बिक्री-क़रार और ऐसे ही अन्य। e-Stamp endpoints से आप यह अपने matter के प्रवाह के भीतर कर सकते हैं। अपने entitled services की सूची लीजिए, lookups से राज्य और article तय कीजिए, POST /v1/estamp/duty/calculate से duty निकालिए, अपने matter-संदर्भ को externalOrderId बनाकर POST /v1/orders से order बनाइए, पक्ष जोड़िए, payment intent से भुगतान कीजिए, और order पूरा होने पर प्रमाणपत्र लाइए।

कानूनी practice के लिए तीन बातें। पहली, duty और article कानून के विषय हैं जो राज्य-दर-राज्य बदलते हैं और समय के साथ भी: API गणना करती है, और वकील article तय करता है। दूसरी, पाठ अंतिम होने और पक्षों के सत्यापित होने पर stamp कराइए, क्योंकि stamp लगा दस्तावेज़ चुपचाप बदला नहीं जा सकता। तीसरी, प्रमाणपत्र को matter फ़ाइल का हिस्सा मानिए: उसे उतारिए, bytes सहेजिए, document id और checksum दर्ज कीजिए, और कभी अस्थायी लिंक पर भरोसा मत कीजिए। e-stamp order flow गाइड हर endpoint पर चलती है, और किरायानामा e-stamping पेज बड़ी मात्रा के संचालन का ढाँचा देता है। पंजीकरण, जहाँ राज्य या दस्तावेज़ की प्रकृति माँगे, अलग कानूनी चरण है जिसे यह API नहीं करती।

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

गोपनीयता, विशेषाधिकार और कम से कम डेटा

कानूनी काम गोपनीय होता है, और पहचानकर्ताओं को किसी तीसरे पक्ष की सेवा में भेजने से ऐसे सवाल उठते हैं जिन पर आपके पेशे के अपने नियम हैं। तैनाती से पहले उन्हें सुलझाइए।

ग्राहक के साथ, engagement की शर्तों या किसी सूचना में, तय कीजिए कि आप verification औज़ार इस्तेमाल करते हैं और कौन-सा डेटा उन्हें जाता है। कम से कम भेजिए: PAN और नाम, पूरी फ़ाइल नहीं। किसी भी request में विशेषाधिकार-प्राप्त सामग्री मत डालिए, और इन endpoints में से किसी को उसकी ज़रूरत नहीं। verification का डेटा सामान्य-उपयोग वाले logs और chat चैनलों से बाहर रखिए, और पहुँच उन्हीं लोगों तक रखिए जो matter पर काम कर रहे हैं। प्रदाता की डेटा-प्रसंस्करण स्थिति समझिए: StampMitra एक data processing addendum और retention और deletion schedule प्रकाशित करता है जिसे आपके सलाहकार को पढ़ना चाहिए इससे पहले कि आप ग्राहक matters के लिए सेवा पर भरोसा करें।

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

थोक में due diligence

कुछ matters में एक साथ बहुत-से प्रतिपक्ष जाँचने पड़ते हैं: सैकड़ों ग्राहक-अनुबंधों वाला अधिग्रहण, vendor का समेकन, पोर्टफ़ोलियो की समीक्षा। तरीक़ा अकेले matter जैसा ही है, बस batch की यांत्रिकी जुड़ती है।

प्रतिपक्षों का रजिस्टर उनके पहचानकर्ताओं के साथ बनाइए, PAN से duplicate हटाइए, और इकाई के प्रकार से समूह बनाइए। पहले मुफ़्त स्थानीय जाँचें चलाइए। सशुल्क जाँचें अपने plan की rate limit के भीतर batch में चलाइए (दस्तावेज़ में दर्ज error का उदाहरण 60 सेकंड में 60 requests है, अपनी सीमा dashboard और pricing पेज से पढ़िए), हर नतीजा प्रतिपक्ष और जाँच की कुंजी पर सहेजिए ताकि restart में पूरा काम छूटे, और 402 wallet error पर रुकिए। निष्कर्ष-कोड के हिसाब से गिनती वाला सार, और समीक्षा चाहने वाले प्रतिपक्षों की सूची बनाइए। कच्चे responses सबूत-भंडार में रखिए और सार matter फ़ाइल में। याद रखिए कि नतीजे जाँच के समय की तस्वीर हैं: लेन-देन हफ़्तों बाद बंद हो तो तय कीजिए कि बंद होने से पहले अहम जाँचें ताज़ा करनी हैं या नहीं।

एक काम का matter, intake से समापन तक

एक काल्पनिक सेवा-क़रार लीजिए जो आपके ग्राहक, एक मध्यम आकार की कंपनी, और एक सप्लायर के बीच है जो प्राइवेट लिमिटेड कंपनी है। matter सोमवार को सप्लायर के नाम, PAN, GSTIN और CIN, और उस प्रबंधक के नाम के साथ खुलता है जो उसकी ओर से दस्तख़त करेगा।

intake पर paralegal घोषणा दर्ज करती है और स्थानीय जाँचें चलाती है। GSTIN के भीतर का PAN घोषित PAN के बराबर है, और CIN का ढाँचा अपेक्षित है। फिर तीन सशुल्क जाँचें: सप्लायर के कानूनी नाम के साथ PAN, GSTIN और CIN। PAN कंपनी-प्रकार का वैध रिकॉर्ड और नाम का मज़बूत score लौटाता है। GSTIN चालू है और उसका कानूनी नाम मेल खाता है। CIN चालू कंपनी दिखाता है जिसके निदेशकों में दो लोग हैं। दस्तख़त करने वाला प्रबंधक उनमें नहीं है।

निष्कर्ष सीधा है: हस्ताक्षरकर्ता सूचीबद्ध निदेशक नहीं है। associate इसे सप्लायर की समस्या नहीं मानती, उसे छूटा हुआ दस्तावेज़ मानती है। सप्लायर से वह board resolution या authority letter माँगा जाता है जो प्रबंधक को इस क़रार के लिए अधिकार देता है। वह बुधवार को आता है। associate उसे पढ़ती है, दायरा और रकम की कोई सीमा नोट करती है, उसे pack में लगाती है और दर्ज करती है कि अधिकार रजिस्ट्री से नहीं, दस्तावेज़ से स्थापित हुआ।

partner वृहस्पतिवार को pack की समीक्षा करता है। समीक्षा मिनटों में हो जाती है, क्योंकि pack दिखाता है कि क्या जाँचा गया, कब, किन transaction id के साथ, और हर निष्कर्ष से क्या निकला। शुक्रवार को मसौदा सत्यापित कानूनी नाम के साथ अंतिम होता है, e-Stamp प्रवाह से दस्तावेज़ पर stamp लगता है जिसमें order का संदर्भ matter-संदर्भ है, और प्रमाणपत्र उतारकर checksum के साथ सहेजा जाता है। retention वर्ग तय करके pack बंद होता है।

छह महीने बाद ग्राहक पूछता है कि दस्तख़त के समय सप्लायर ठीक स्थिति में था या नहीं। associate pack खोलती है और उसी से जवाब देती है। जवाब सटीक है क्योंकि रिकॉर्ड सटीक है: उस तारीख़ को रजिस्ट्री-स्थिति चालू थी और निदेशक वे थे जो सूचीबद्ध थे। associate रिकॉर्ड से ज़्यादा कुछ नहीं कहती, और यह दावा नहीं करती कि उसके बाद भी सप्लायर ठीक स्थिति में बना रहा, जो pack नहीं दिखा सकता।

compliance को पहचान-जाँचों के आगे क्या चाहिए

compliance अधिकारियों से अक्सर ऐसी जाँचों की पुष्टि माँगी जाती है जिन्हें इस तरह की API कवर नहीं करती, और कमियाँ साफ़ हों तो किसी को वह कवरेज नहीं मान बैठता जो है ही नहीं।

प्रतिबंध और watch-list की जाँच, प्रतिकूल-मीडिया की जाँच और राजनीतिक रूप से उजागर व्यक्तियों की जाँच के लिए अलग स्रोत और प्रक्रियाएँ चाहिए। यहाँ के verification endpoints पहचानकर्ताओं के बारे में रजिस्ट्री के तथ्य लौटाते हैं। लाभार्थी स्वामित्व के विश्लेषण को दस्तावेज़ और विवेक चाहिए। धन के स्रोत की समीक्षाएँ किसी व्यक्ति के मामलों की पूछताछ हैं, रजिस्ट्री की खोज नहीं। लेन-देन की निगरानी व्यवहार का चलता विश्लेषण है। जिन संस्थाओं पर नियामकीय रिपोर्टिंग के दायित्व हैं, वे संबंधित नियामक के नियमों से आते हैं।

इसमें से कुछ भी पहचान और रजिस्ट्री की जाँचों को कम उपयोगी नहीं बनाता। इसका मतलब है कि वे नियंत्रणों के समूह की एक परत हैं, और आपकी नीति बताए कि कौन-सी परत किस जोखिम को ढकती है। अपने compliance मैनुअल की एक सरल तालिका, जिसमें हर जोखिम, उसे सँभालने वाला नियंत्रण और उसका मालिक हो, दिखाएगी कि verification कहाँ बैठता है और कहाँ कुछ और खड़ा होना चाहिए।

आप नियंत्रित संस्था हैं तो याद रखिए कि आपके ग्राहक-परिश्रम के लिए क्या काफ़ी है, यह आपका नियामक तय करता है, कोई vendor नहीं। API के नतीजे को ऐसा सबूत मानिए जिसे आपकी नीति इस्तेमाल कर सकती है, और अपने compliance अधिकारी से दर्ज करवाइए कि उसका कैसे इस्तेमाल होता है।

कानूनी-संचालन डेस्क की पाँच स्थितियाँ

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

रजिस्टर से हटा प्रतिपक्ष

एक associate सेवा-क़रार से पहले कंपनी की जाँच करती है। CIN का response कंपनी की स्थिति चालू नहीं दिखाता। matter रुकता है, associate partner को बताती है, और ग्राहक को कहा जाता है कि रजिस्ट्री पर प्रतिपक्ष ठीक स्थिति में नहीं है। कुछ भी दस्तख़त नहीं होता।

जो हस्ताक्षरकर्ता निदेशक नहीं है

एक प्रबंधक प्राइवेट कंपनी की ओर से दस्तख़त करता है। निदेशकों की सूची में उसका नाम नहीं है। associate authority letter माँगती है, उसे pack में लगाती है, और दर्ज करती है कि अधिकार रजिस्ट्री से नहीं, दस्तावेज़ से स्थापित हुआ।

बदला हुआ नाम

एक पक्ष के PAN पर नाम मसौदे से अलग है क्योंकि शादी के बाद नाम बदला है। नाम का score बीच का है। associate दस्तावेज़ लेती है, कारण pack में दर्ज करती है और मसौदे को सत्यापित नाम से सुधारती है, पुराना नाम उपनाम की तरह दर्ज रखते हुए।

duplicate matter

दो associates एक हफ़्ते में एक ही प्रतिपक्ष के लिए matters खोलती हैं। PAN के keyed hash से duplicate पकड़ में आता है, दूसरी associate नीति की तय ताज़गी-सीमा के भीतर पहले matter का सबूत दोबारा इस्तेमाल करती है, और एक टिप्पणी इस दोबारा इस्तेमाल को दर्ज करती है।

समापन के दिन ठप

निष्पादन की सुबह रजिस्ट्री की call 502 लौटाती है। matter बाक़ी रहता है, paralegal backoff से retry करती है, और partner तय करता है कि दर्ज टिप्पणी के साथ पहले की जाँच पर आगे बढ़ना है या इंतज़ार करना है। फ़ैसला partner का है और लिखा जाता है।

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

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

• दर्ज प्रतिपक्ष-जाँच के बिना निष्पादन नहीं, उन matters के लिए जो आपके तय मूल्य या जोखिम से ऊपर हैं।
• हस्ताक्षरकर्ता का अधिकार दस्तावेज़ से। निदेशकों की सूची इशारा है, अधिकार नहीं।
• दूसरे व्यक्ति की समीक्षा किसी गंभीरता से ऊपर के निष्कर्ष के लिए, और निष्क्रिय स्थिति के बावजूद आगे बढ़ने के हर फ़ैसले के लिए।
• partner की मंज़ूरी pack के अपवादों के लिए, और उन इकाइयों वाले matters के लिए जिनकी स्थिति की समस्याओं का इतिहास है।
• evidence pack अनिवार्य है। साँचा भरे बिना कोई matter बंद नहीं होता।
• काफ़ी ताज़ा। आपकी ताज़गी-सीमा से पुरानी जाँच निष्पादन से पहले दोहराई जाए।
• request में विशेषाधिकार वाली सामग्री नहीं। सिर्फ़ पहचानकर्ता।
• जाँच से आगे भरोसा नहीं। किसी नतीजे को उससे ज़्यादा दिखाने वाला न बताइए जितना वह दिखाता है।

टीम का ढाँचा

हर भूमिका को साफ़ हिस्सा दीजिए। paralegal और intake स्टाफ़ मानक जाँचें चलाते हैं और pack भरते हैं। associates निष्कर्षों की समीक्षा करती हैं, अधिकार परखती हैं और मसौदे बनाती हैं। partner या ज़िम्मेदार वकील अपवादों को मंज़ूर करते हैं और तय करते हैं कि कब आगे बढ़ना है। operations स्टाफ़ stamp और भुगतान सँभालता है। compliance या records स्टाफ़ retention और packs का audit सँभालता है। इंजीनियरिंग, अगर आपके पास है, keys, wallet अलर्ट और platform queue की मालिक है।

हर हफ़्ते कोड के हिसाब से निष्कर्षों और अपवादों की समीक्षा चलाइए, साँचे और नियमों को सुधारने के लिए। हर तिमाही बंद matters का नमूना-audit चलाइए, यह देखते हुए कि pack पूरे हैं और संदर्भित transaction id सहेजे नतीजों तक पहुँचते हैं।

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

evidence pack, पहुँच-नियंत्रित भंडार में कच्चे responses, hash, अधिकार-दस्तावेज़ और stamp का प्रमाणपत्र रखिए। जो कुछ भी घूमता है उसमें निजी पहचानकर्ता ढके रखिए, और बिना ढके मान सिर्फ़ उस भंडार में जिसे चाहिए। retention वर्ग के हिसाब से मिटाइए।

कानूनी रिकॉर्ड की अवधि आपके पेशेवर रिकॉर्ड-रखाव दायित्वों, engagement की शर्तों, परिसीमा-अवधियों, कर नियमों, ग्राहक की ज़रूरतों और डेटा-सुरक्षा कानून पर निर्भर है। आँकड़े हम नहीं दे सकते। सवाल अपने सलाहकार या ज़िम्मेदार partner के पास ले जाइए, जवाब को schedule में लिखिए और उसे स्वचालित कीजिए। StampMitra का अपना डेटा-संचालन उसके retention और deletion schedule में है। आप GET /v1/logs से अपने खाते के request logs और GET /v1/usage/summary से उपयोग के योग भी देख सकते हैं, logs का रखाव plan पर निर्भर है और pricing पेज पर वर्णित है।

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

pay-as-you-go पर PAN, GSTIN, CIN, Udyam और cross-lookups की दर ₹5 प्रति call है, और e-Stamp API फ़ीस ₹5 प्रति order। Growth और Scale ये दरें घटाते हैं और महीने की plan फ़ीस जोड़ते हैं। सभी राशियाँ 18 प्रतिशत GST से पहले की हैं। e-Stamp के आँकड़ों में वैधानिक stamp duty और राज्य की procurement फ़ीस शामिल नहीं हैं, जो हर plan पर एक-सी हैं और order से पहले बताई जाती हैं, और duty-calculation की calls आपके wallet से मीटर होती हैं, इसलिए quote की मात्रा का मॉडल बनाने से पहले उनका भाव सपोर्ट से पक्का कीजिए, तालिकाओं में वे शामिल नहीं हैं।

एक matter की प्रतिपक्ष-जाँचों की लागत (दो PAN जाँचें और एक रजिस्ट्री जाँच), और वही एक e-Stamp order के साथ:

मासिक मॉडलों के लिए मान लीजिए हर matter पर तीन standard जाँचें होती हैं और 60 प्रतिशत matters को e-Stamp order चाहिए। महीने में 100 matters पर: 300 standard calls और 60 orders।

महीने में 1,000 matters पर: 3,000 standard calls और 600 orders।

महीने में 10,000 matters पर, जैसा कोई बहुत बड़ा कानूनी-सेवा संचालन देख सकता है: 30,000 standard calls और 6,000 orders।

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

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

Sandbox। pack का साँचा, निष्कर्ष के नियम और stamp वाला कदम sandbox keys पर बनाइए, जहाँ responses नमूना डेटा हैं और wallet नहीं कटता। sandbox responder PAN SNDBX0000A पर वैध और SNDBX9999F पर अवैध नतीजा देता है, और GSTIN के लिए 09SNDBX0000A1Z5 वैध और चालू है जबकि 09SNDBX9999F1Z5 अवैध और रद्द। बाक़ी इनपुट पर स्थिर पर मनमाना नतीजा आता है, इसलिए उन पर assertion मत लगाइए। dashboard में ताज़ा test values देखिए। फ़ैसला-तालिका की हर पंक्ति, evidence-प्रविष्टि बनाने वाले function, batch के restart और 402, 429, 502 के रास्तों का test कीजिए।

Pilot। production access माँगिए, जिसके लिए आपके संगठन की KYC मंज़ूरी और product-वार आवेदन चाहिए। किसी एक practice group के नए matters इस प्रवाह से चलाइए जबकि पुरानी प्रक्रिया कुछ हफ़्ते साथ चले। packs मिलाइए और partners से नमूने की समीक्षा करवाइए।

Production। practice group के हिसाब से बढ़ाइए। पहली तिमाही से ही तिमाही pack-audit चलाइए। wallet balance पर अलर्ट रखिए, और scopes व IP allowlist के लिए sandbox बनाम production keys गाइड हाथ में रखिए।

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

• समापन पर पूरे evidence pack वाले matters का हिस्सा, जो सब होने चाहिए।
• कोड के हिसाब से निष्कर्ष, और उनमें दस्तावेज़ माँगने तक पहुँचे का हिस्सा।
• matter खुलने से प्रतिपक्ष-समीक्षा के साफ़ होने तक का समय।
• अपवाद: अनसुलझे निष्कर्ष के बावजूद निष्पादित matters, दर्ज मंज़ूरी के साथ। यह दुर्लभ और पूरी तरह दस्तावेज़ी होना चाहिए।
• तिमाही audit में विफल packs, और क्यों।
• ताज़ा करने की दर: वे matters जहाँ पुरानी पड़ चुकी जाँच दोहराई गई।
• प्रति matter calls, जो duplicate और retry loops उजागर करती हैं।
• लगाए गए orders के मुक़ाबले सहेजे प्रमाणपत्र वाले stamp किए दस्तावेज़।

जो ग़लतियाँ कानूनी verification प्रक्रिया को कमज़ोर करती हैं

• रजिस्ट्री के नतीजे को अधिकार का प्रमाण मानना। वह पहली छन्नी है।
• रिकॉर्ड की जगह screenshot रखना। transaction id और सहेजे responses रखिए।
• पूरे responses matter फ़ाइलों में कॉपी करना। सिर्फ़ वे fields रखिए जिन पर भरोसा किया।
• ताज़गी का नियम छोड़ना। महीनों पुरानी जाँच आज की स्थिति नहीं है।
• पहचानकर्ताओं से ज़्यादा भेजना। विशेषाधिकार वाली सामग्री कभी मत डालिए।
• पाठ अंतिम होने से पहले stamp कराना। duty पहले चुकती है।
• अस्थायी download लिंक को रिकॉर्ड मानकर सहेजना। bytes सहेजिए।
• नतीजों को उनसे ज़्यादा दिखाने वाला बताना। लिखिए कि क्या जाँचा गया, उससे ज़्यादा कुछ नहीं।
• packs का audit न करना। जिस साँचे को कोई जाँचता नहीं, वह सड़ जाता है।

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

इस पेज के endpoints verification API reference और e-Stamp API documentation में हैं: PAN, GSTIN, CIN, Udyam, bank account, duty calculation, orders और documents। संबंधित पढ़ाई के लिए इकाई की जाँचों के लिए B2B प्लेटफ़ॉर्म के लिए KYB पेज, किरायानामा e-stamping पेज, e-stamp order flow गाइड, business verification गाइड और 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-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"
    }
  ]
}

{
  "externalOrderId": "ord_ext_123",
  "createdAt": "2026-10-15T09:41:07.000Z",
  "serviceCode": "estamp.instrument.rent_agreement"
}

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