व्यवसाय सत्यापन रिस्पॉन्स स्कीमा: निर्णय payload रेफ़रेंस

शीर्ष-स्तर की संरचना

यह पेज व्यवसाय सत्यापन (KYB) सत्र के लिए GET /v3/session/{id}/decision/ द्वारा लौटाए गए पूरे पेलोड का दस्तावेज़ है। यह endpoint एकीकृत है: जब आप व्यवसाय का session_id पास करते हैं, तो रिस्पॉन्स में session_kind: "business" और नीचे दिए गए व्यवसाय-विशिष्ट सुविधाओं के ऐरे होते हैं।

{
  "session_id": "bs_01H...",
  "session_kind": "business",
  "session_number": 89,
  "session_url": "https://verify.didit.me/...",
  "status": "Approved",
  "status_override": null,
  "workflow_id": "wf_kyb_standard",
  "features": ["KYB_REGISTRY", "AML", "KYB_DOCUMENTS", "KYB_KEY_PEOPLE"],
  "vendor_data": "biz-acme-001",
  "metadata": { },
  "callback": null,

  "registry_checks": [ ... ],
  "aml_screenings": [ ... ],
  "document_verifications": [ ... ],
  "key_people_checks": [ ... ],

  "phone_verifications": null,
  "email_verifications": null,
  "questionnaire_responses": null,
  "ip_analyses": null,

  "reviews": [ ],
  "decision_trace": { ... },
  "linked_records": null,
  "contact_details": { ... },
  "expected_details": null,
  "created_at": "...",
  "expires_at": "..."
}

सभी सुविधाओं के ऐरे मल्टी-इंस्टेंस होते हैं: हर आइटम ग्राफ़ वर्कफ़्लो में एक नोड को दर्शाता है। Null का अर्थ है कि यह सुविधा इस सत्र के वर्कफ़्लो में मौजूद नहीं थी।

साझा शीर्ष-स्तर फ़ील्ड

फ़ील्ड	प्रकार	विवरण
`session_id`	UUID	सत्र का अनोखा पहचानकर्ता
`session_kind`	enum	KYB सत्रों के लिए हमेशा `"business"`
`session_number`	int	आवेदन के भीतर क्रमिक संख्या
`session_url`	URL	होस्टेड सत्यापन लिंक
`status`	enum	सत्र की कुल स्थिति (देखें स्थितियाँ)
`status_override`	object or null	`{ overridden_at, automatic_status }` तब, जब समीक्षक ने प्लेटफ़ॉर्म द्वारा सेट किए जाने वाले स्टेटस के विपरीत `status` मैन्युअली सेट किया हो (उदाहरण के लिए, किसी जुड़े हुए प्रमुख व्यक्ति के सत्यापन के अस्वीकृत होने पर भी व्यवसाय को स्वीकृत करना)। जब स्टेटस स्वचालित हो, तब `null`। मैन्युअल स्वीकृति और स्वचालित स्वीकृति में अंतर बताने के लिए इसका उपयोग करें
`decision_trace`	object	निर्णय कैसे लिया गया: `status`, `decided_by` (`manual`, `automatic` या `investigator`), `decided_at`, `automatic_status`, `terminal_node_id`, `actor`, `warning_counts` और `status_warnings` (वे चेतावनियाँ जिन्होंने स्टेटस सेट किया)
`linked_records`	object or null	सत्र से जुड़े अन्य रिकॉर्ड का सारांश। दिखाने के लिए कुछ न हो तो `null`
`workflow_id`	UUID	वह वर्कफ़्लो जिसने इस सत्र को चलाया
`features`	array of strings	सुविधा पहचानकर्ता जिन्हें वर्कफ़्लो ने चलाया (जैसे `KYB_REGISTRY`, `AML`, `KYB_DOCUMENTS`, `KYB_KEY_PEOPLE`, `PHONE`, `EMAIL`)
`vendor_data`	string	व्यवसाय के लिए आपका पहचानकर्ता
`metadata`	object	सत्र बनाते समय आपके द्वारा संलग्न किया गया फ़्री-फ़ॉर्म JSON
`callback`	URL or null	सत्यापन के बाद वैकल्पिक पुनर्निर्देशन URL
`contact_details`	object or null	`{ email, email_lang, send_notification_emails, phone }`। यह तब सेट होता है जब फ़्लो में ईमेल/फ़ोन सूचनाएँ शामिल हों
`expected_details`	object or null	निर्माण के समय आपके द्वारा पास किया गया व्यवसाय का अपेक्षित डेटा: `company_name`, `registry_country` (`XX`, या राज्य-स्तरीय रजिस्ट्री के लिए राज्य सहित `XX-YY`, जैसे `US-CA`), `registration_number`
`reviews`	array	सत्र पर समीक्षक की नवीनतम टिप्पणियाँ
`created_at`, `expires_at`	ISO timestamps	—

`registry_checks[]`

प्रत्येक आइटम एक कंपनी रजिस्ट्री जाँच है। आम तौर पर प्रति सत्र एक जाँच होती है, और ग्राफ़ वर्कफ़्लो में रिकर्सिव कॉर्पोरेट UBO KYB के साथ कई जाँचें हो सकती हैं।

{
  "status": "Approved",
  "node_id": "feature_kyb_registry",
  "data_resolved": true,
  "company": { ...see below... },
  "ownership_structure": { },
  "warnings": []
}

फ़ील्ड	विवरण
`status`	सुविधा की जीवनचक्र स्थिति (`Approved`, `Declined`, `In Review`, `Not Finished`, `Resub Requested`)
`node_id`	इस जाँच का ग्राफ़ नोड पहचानकर्ता
`data_resolved`	`true` तब जब रजिस्ट्री डेटा लोड होना पूरा हो गया हो या उपयोगकर्ता ने डेटा मैन्युअल रूप से दिया हो
`company`	पूरा रजिस्ट्री payload, नीचे `company` ब्लॉक देखें
`ownership_structure`	वह कैप टेबल जो रजिस्ट्री ने स्वामित्व स्तर दिए जाने के समय प्रमाणित की थी: `shareholders[]` और `beneficial_owners[]`, जिनमें से हर एक में वही रजिस्ट्री पहचान और हिस्सेदारी है जो `company.beneficial_owners[]` में है (`name`, `entity_type`, `roles`, `ownership_min_shares` / `ownership_max_shares`, …) और उसका मानक `shareholding`। रजिस्ट्री ने कोई स्वामित्व प्रमाणित न किया हो तो `null`। वर्तमान रिकॉर्ड के लिए `company.beneficial_owners` और `company.ownership` पढ़ें
`warnings`	इस रजिस्ट्री जाँच से जुड़ी संरचित चेतावनियाँ / लॉग प्रविष्टियाँ। देखें व्यवसाय सत्यापन (KYB) चेतावनियाँ।

`company` ब्लॉक

नेस्टेड कंपनी ऑब्जेक्ट रजिस्ट्री से प्राप्त कानूनी इकाई का पूरा विवरण है (और वैकल्पिक रूप से उपयोगकर्ता द्वारा संपादित):

{
  "uuid": "...",
  "node_id": "feature_kyb_registry",
  "status": "Approved",
  "registry_status": "active",
  "data_resolved": true,
  "company_name": "Acme Corporation Limited",
  "registration_number": "12345678",
  "country_code": "GBR",
  "company_type": "Private Limited",
  "incorporation_date": "2010-05-14",
  "registered_address": "1 Main Street, London EC1A 1AA, United Kingdom",
  "tax_number": "SAMPLE-TAX-12345",
  "risk_level": null,
  "verification_status": "verified",
  "is_from_registry": true,
  "fetch_status": "resolved",
  "alternative_names": "Acme Ltd",
  "nature_of_business": "Software publishing",
  "registered_capital": "100000 GBP",
  "website": "https://acme.example",
  "email": "alex.sample@example.com",
  "phone": "+15550101000",
  "legal_entity_identifier": "529900XXXXXXXXXXXXX",
  "location_of_registration": "London",
  "vat_number": "GB980780684",
  "vat_validation_status": "format_valid",
  "vat_validated_number": "GB980780684",
  "vat_validation_source": "format_rules",
  "vat_validated_name": null,
  "vat_validated_address": null,
  "vat_checked_at": "2026-04-16T10:10:00Z",
  "financial_summary": { },
  "officers": [ ... ],
  "beneficial_owners": [ ... ],
  "addresses": [
    {
      "type": "registered",
      "address": "1 Main Street, London EC1A 1AA, United Kingdom",
      "street": "1 Main Street",
      "city": "London",
      "postal_code": "EC1A 1AA",
      "region": null,
      "country_code": "GB",
      "description": null
    }
  ],
  "industries": [
    { "code": "58290", "description": "Other software publishing", "scheme": "UK SIC 2007", "is_primary": true }
  ],
  "accounts": { ... },
  "ownership": {
    "status": "delivered",
    "tier_requested": "ubo",
    "tier_delivered": "ubo",
    "unavailable_reason": null,
    "direct_ownership_complete": true,
    "unresolved": []
  },
  "registry_tier": "ubo",
  "registry_tier_delivered": "ubo",
  "registry_ownership_status": "delivered",
  "registry_monitoring": null,
  "registry_data": { },
  "user_provided_data": { },
  "confirmed_by_user_at": "2026-04-16T10:10:00Z",
  "last_console_edit_at": null,
  "is_editable": false
}

फ़ील्ड	विवरण
`registry_status`	प्रदाता द्वारा बताई गई स्थिति (`active`, `dissolved`, `struck_off`, `inactive`, आदि)। देखें स्थितियाँ
`is_from_registry`	`true` जब डेटा किसी आधिकारिक रजिस्ट्री से आया हो; मैन्युअल प्रविष्टि के लिए `false`
`fetch_status`	`pending`, `resolved`, या `failed`, यानी रजिस्ट्री खोज की स्थिति
`verification_status`	`verified`, `failed`, या `unknown`
`risk_level`	रजिस्ट्री स्रोत से पास किया गया वैकल्पिक मान। आम तौर पर `null` होता है: Didit जोखिम स्तर की गणना नहीं करता, इसलिए निर्णय के लिए `warnings[]` और सत्र का `status` इस्तेमाल करें
`registry_monitoring`	कंपनी का नवीनतम रजिस्ट्री मॉनिटर, या कोई न होने पर `null`। यह तभी भरा जाता है जब रजिस्ट्री मॉनिटरिंग उपलब्ध हो। फ़ील्ड: `uuid`, `status`, `unavailable_reason`, `enrolled_at`, `cancelled_at`, `last_bill_date`, `next_bill_date`, `last_event_at`, `events_count`, `watched_fields`
`is_editable`	`true` जब तक अंतिम उपयोगकर्ता रजिस्ट्री से आए डेटा को अभी भी संपादित कर सकता है
`registry_data`	Didit का सामान्यीकृत रजिस्ट्री विवरण: स्वामित्व परिणाम (`ownership_error`, `section_errors`, `ubo_resolution`), update-data से किए गए सुधार, और वे रजिस्ट्री तथ्य जिनका अपना फ़ील्ड नहीं है। इसमें रजिस्ट्री स्रोत का अपना रिकॉर्ड कभी नहीं होता। इसकी कुंजियाँ कंपनी के अनुसार बदलती हैं और यह स्थिर अनुबंध नहीं है: इसके बजाय कैनोनिकल फ़ील्ड पढ़ें
`user_provided_data`	वे फ़ील्ड जो अंतिम उपयोगकर्ता ने दर्ज या संपादित किए (रजिस्ट्री मानों से ऑडिट तुलना के लिए उपयोगी)
`confirmed_by_user_at`	वह टाइमस्टैम्प जब अंतिम उपयोगकर्ता ने रजिस्ट्री डेटा की पुष्टि की / संपादित किया
`vat_number`	सबमिट किया गया VAT नंबर, जब वह एकत्र किया गया हो
`vat_validation_status`	VAT नंबर के सत्यापन का परिणाम, या कोई VAT नंबर न होने पर `tax_number` का परिणाम: `valid`, `invalid`, `format_valid`, `invalid_format`, `could_not_validate`, या `not_applicable`। देखें VAT और कर पहचान सत्यापन
`vat_validated_number` / `vat_validation_source`	जाँचा गया नंबर, जैसा स्रोत उसे जानता है, और वह स्रोत जिसने स्थिति तय की (कोई आधिकारिक रजिस्ट्री, या `format_rules`)
`vat_validated_name` / `vat_validated_address`	स्रोत के पास पंजीकृत नाम और पता, जब स्रोत उन्हें बताता है
`vat_checked_at`	जाँच का टाइमस्टैम्प; कोई जाँच न चली हो तो `null`
`officers[]`	अधिकारी, जिनमें एम्बेडेड KYC एनरिचमेंट है (नीचे देखें)
`beneficial_owners[]`	UBO, जिनमें एम्बेडेड KYC एनरिचमेंट है (नीचे देखें)
`addresses[]`	रजिस्ट्री द्वारा बताया गया हर पता, नीचे दी गई मानक पता संरचना में। कोई न बताया गया हो तो `null`
`industries[]`	वे गतिविधियाँ जिनके तहत रजिस्ट्री कंपनी का वर्गीकरण करती है, नीचे दी गई मानक उद्योग संरचना में। कोई न बताई गई हो तो `null`
`accounts`	रिपोर्ट की गई हों तो कॉर्पोरेट फ़ाइलिंग तिथियाँ: `last_annual_return_date` और `last_agm_date`। ये फ़ाइलिंग और बैठकों का वर्णन करती हैं, वित्तीय विवरणों का नहीं
`ownership`	स्वामित्व (शेयरधारक / UBO) स्तर का परिणाम, नीचे दी गई मानक संरचना में
`registry_tier` / `registry_tier_delivered` / `registry_ownership_status`	ऑर्डर किया गया स्तर, दिया गया (और बिल किया गया) स्तर, और स्वामित्व परिणाम। यही मान `ownership` में भी हैं

हर देश और रजिस्ट्री स्रोत के लिए एक प्रारूप

Didit कई देशों की कंपनी रजिस्ट्रियाँ कई रजिस्ट्री स्रोतों के माध्यम से पढ़ता है। हर स्रोत अपना लेआउट प्रकाशित करता है, लेकिन company ब्लॉक की संरचना हमेशा एक जैसी रहती है: नीचे दी गई कुंजियाँ हमेशा मौजूद रहती हैं, समान प्रकारों के साथ, चाहे कंपनी किसी भी देश और स्रोत से आई हो। जो तथ्य रजिस्ट्री प्रकाशित नहीं करती, वह null होता है; आपको देश या स्रोत के आधार पर अलग तर्क लिखने या registry_data पार्स करने की ज़रूरत नहीं होती। वही आकार निर्णय, स्वतंत्र KYB रजिस्ट्री endpoint और होस्टेड सत्यापन फ़्लो में भी लौटाया जाता है। पता (addresses का हर आइटम)

फ़ील्ड	विवरण
`type`	छोटे अक्षरों में। पंजीकृत कार्यालय के लिए `registered`; अन्य प्रकार वैसे ही जैसे रजिस्ट्री उन्हें नाम देती है (उदाहरण के लिए `postal`, `office`)। रजिस्ट्री यह न बताए कि पता किस प्रकार का है तो `null`
`address`	पूरा पता एक पंक्ति में। हमेशा मौजूद
`street`, `city`, `postal_code`, `region`	पता भागों में, जब रजिस्ट्री उन्हें प्रकाशित करे
`country_code`	ISO 3166-1 alpha-2
`description`	इस पते के लिए रजिस्ट्री का अपना लेबल, जब वह एक देती है

उद्योग (industries का हर आइटम)

फ़ील्ड	विवरण
`code`	गतिविधि कोड, जैसा रजिस्ट्री उसे छापती है
`description`	गतिविधि का लेबल, जब रजिस्ट्री एक प्रकाशित करे
`scheme`	वर्गीकरण प्रणाली, हर प्रणाली का एक ही नाम, चाहे किसी भी स्रोत ने उसे बताया हो (`UK SIC 2007`, `US SIC`, `NACE Rev. 2`, `NACE Rev. 2.1`, `NAF Rev. 2`, `CNAE`, `SBI`, `NOGA 2008`, `CAE Rev. 4`, `Canada SIC 1977`)। अन्य राष्ट्रीय प्रणालियाँ रजिस्ट्री का अपना नाम रखती हैं; रजिस्ट्री नाम न दे तो `null`
`is_primary`	मुख्य गतिविधि के लिए `true`। ठीक एक प्रविष्टि प्राथमिक होती है

जब रजिस्ट्री गतिविधियाँ बताती है लेकिन कोई व्यवसाय विवरण नहीं देती, तो nature_of_business गतिविधि लेबल से भरा जाता है। संपर्क विवरण और वैकल्पिक नाम उपलब्ध होने पर भरे जाते हैं, जबकि उपयोगकर्ता या समीक्षक द्वारा स्पष्ट रूप से किए गए संपादन हमेशा प्राथमिकता लेते हैं। स्वामित्व (ownership)

फ़ील्ड	विवरण
`status`	`delivered`; `not_held` जब स्वामित्व रजिस्ट्री ने उत्तर दिया और इस कंपनी को बिल्कुल सूचीबद्ध नहीं करती, इसलिए परोसने के लिए कोई स्वामित्व रिकॉर्ड नहीं है; `unavailable` जब डेटा किसी अन्य कारण से नहीं दिया गया (ऐसा रिकॉर्ड जो कोई मालिक नामित नहीं करता, स्वामित्व सेक्शन वापस नहीं आया, या ऐसा विक्रेता जिससे पूछा नहीं जा सका); `pending` जब रजिस्ट्री अभी भी स्वामित्व सेक्शन प्राप्त कर रही है; `not_requested` Basic स्तर पर
`tier_requested` / `tier_delivered`	`basic`, `shareholders` या `ubo`। UBO अनुरोध, जिसका उत्तर केवल सीधे शेयरधारकों के साथ दिया गया हो, उसे `shareholders` के रूप में दिया और बिल किया जाता है
`unavailable_reason`	अनुरोधित स्वामित्व स्तर क्यों नहीं दिया गया: `no_owners_on_record`, `no_natural_person_owner`, `ownership_section_unavailable`, `company_not_found`, `ambiguous_company_match`, `missing_registration_number`, `entity_type_not_covered`, `provider_unavailable` या `other`। स्वामित्व दिए जाने पर `null`
`direct_ownership_complete`	`true` जब सीधे शेयरधारकों के बताए गए हिस्से 100% तक जुड़ते हैं (गोलाई के लिए एक प्रतिशत अंक के भीतर), `false` जब नहीं जुड़ते, `null` जब स्वामित्व नहीं दिया गया या कोई हिस्सा बताया नहीं गया है
`unresolved[]`	स्वामित्व श्रृंखला के वे हिस्से जिन्हें रजिस्ट्री हल नहीं कर सकी, `{ reason, section }` के रूप में (उदाहरण के लिए `group_structure` के लिए `no_group_structure_on_record`: सीधे मालिक ज्ञात हैं, लेकिन उनसे ऊपर का कॉर्पोरेट समूह रिकॉर्ड में नहीं है)

रजिस्ट्री विवरण (registry_data) Didit का अपना विवरण, जो रजिस्ट्री जाँच के बारे में है, न कि रजिस्ट्री स्रोत का अपना रिकॉर्ड। हर कुंजी वैकल्पिक है और केवल तभी मौजूद होती है जब कंपनी के पास उसका कोई मान हो, और नई कुंजियाँ जोड़ी जा सकती हैं: जो ऊपर के कैनोनिकल फ़ील्ड में कवर होता है, उसके लिए उन्हें पढ़ें।

फ़ील्ड	विवरण
रजिस्ट्री तथ्य (`legal_address`, `registered_address`, `registration_date`, `dissolution_date`, `registry_status`, `verification_status`, `company_type`, और वे अन्य फ़ील्ड जिन्हें update-data स्वीकार करता है)	स्ट्रिंग। update-data से किए गए सुधार, और वे तथ्य जो रजिस्ट्री बताती है पर जिनका अपना कोई फ़ील्ड नहीं है (`registration_date`, `dissolution_date`)
`ownership_error`	अनुरोधित स्वामित्व स्तर क्यों नहीं दिया गया, वही कोड जो `ownership.unavailable_reason` में हैं (`no_owners_on_record`, `ownership_section_unavailable`, `company_not_found`, `provider_unavailable`, `other`, …)
`section_errors`	वे सेक्शन जिन्हें रजिस्ट्री ने वापस नहीं किया, सेक्शन के नाम से कुंजीबद्ध (`officers`, `shareholders`, `group_structure`), प्रत्येक `{ status_code }`
`ubo_resolution`	UBO स्तर ने श्रृंखला कैसे पार की: `parent_chain[]` और `subsidiaries[]` `{ name, country_code, registration_number }` के रूप में, और `unresolved[]` `{ reason, section }` के रूप में
`lite_enrichment`	खाली Lite फ़ील्ड जो देश के किसी अन्य रजिस्ट्री स्रोत ने भरे: `{ fields[], people_added }`
`registry_metadata`, `registry_sources[]`, `previous_names[]`, `parent_companies[]`, `documents_available`	केवल पुराने रजिस्ट्री रिकॉर्ड के लिए: रजिस्ट्री के अपने फ़ील्ड, आधिकारिक रजिस्टर जो पढ़े गए (`{ name, source_type }`, केवल आधिकारिक रजिस्टर नामित होते हैं), पिछले नाम, मूल कंपनी के नाम और उपलब्ध फ़ाइलिंग की संख्या

अधिकारी आइटम का आकार (`company.officers` के भीतर)

{
  "uuid": "...",
  "name": "Jane Doe",
  "first_name": "Jane",
  "last_name": "Doe",
  "date_of_birth": null,
  "date_of_birth_year": 1983,
  "date_of_birth_month": 2,
  "address": "1 Example Street, London",
  "appointment_date": "2024-07-01",
  "termination_date": null,
  "designation": "Director",
  "role": "director",
  "nationality": "USA",
  "is_active": true,
  "kyc_status": "Approved",
  "kyc_session_url": "https://verify.didit.me/..."
}

date_of_birth केवल तभी भरा जाता है जब रजिस्ट्री पूरी तारीख देती है। यदि रजिस्ट्री केवल वर्ष या महीना और वर्ष बताती है, तो date_of_birth_year और date_of_birth_month का उपयोग करें; लुप्त दिन का अनुमान कभी नहीं लगाया जाता। नाम, जन्म विवरण, पता और नियुक्ति की तिथियाँ कंपनी अधिकारी सूची और प्रमुख व्यक्ति रजिस्ट्री सूची, दोनों में उपलब्ध रहते हैं।

वास्तविक स्वामी आइटम का आकार (`company.beneficial_owners` के भीतर)

{
  "uuid": "...",
  "name": "John Doe",
  "first_name": "John",
  "last_name": "Doe",
  "entity_type": "person",
  "date_of_birth": null,
  "country_of_birth": null,
  "email": null,
  "company_name": null,
  "registration_number": null,
  "nationality": null,
  "designation": null,
  "appointment_date": null,
  "voting_min_shares": null,
  "voting_max_shares": null,
  "roles": ["ubo"],
  "ownership_min_shares": "40",
  "ownership_max_shares": "40",
  "is_active": true,
  "kyc_status": "Pending",
  "kyc_session_url": "https://verify.didit.me/...",
  "effective_ownership_percent": 40.0,
  "shareholding": {
    "share_class": "Ordinary",
    "number_of_shares": 40,
    "currency": "GBP",
    "nominal_value": 1,
    "total_value": null,
    "percentage": 40
  }
}

kyc_status एक B2C-सुरक्षित प्रक्षेपण का उपयोग करता है: Approved, Declined, या Pending (पूर्ण सत्र स्थितियाँ KYC पूरा होने तक Pending में बदल जाती हैं)। shareholding बताता है कि मालिक के पास क्या स्वामित्व है, और यह हर देश और रजिस्ट्री स्रोत के लिए एक ही आकार में होता है: share_class, number_of_shares, currency, nominal_value, total_value और percentage (सटीक हिस्सा, चार दशमलव स्थानों तक व्यक्त किया जाता है)। जब रजिस्ट्री कोई होल्डिंग नहीं बताती, तो यह null होता है। एक बैंड, जैसे UK PSC का 25-50%, हिस्सा नहीं है: इसमें percentage null होता है और बैंड ownership_min_shares / ownership_max_shares में रहता है। शेयरधारक और UBO, दोनों beneficial_owners में सूचीबद्ध होते हैं; roles उन्हें अलग करता है।

`key_people_checks[]`

यह सत्र के सभी अधिकारियों और UBO पर समग्र जाँच है। इसमें दो बकेट होते हैं, ताकि कंसोल “रजिस्ट्री से निकाला गया” और “व्यवसाय द्वारा जमा किया गया” विवरण साथ-साथ दिखा सके, साथ ही एक उच्च-स्तरीय UBO KYC सारांश भी मिलता है।

{
  "status": "Approved",
  "node_id": "feature_kyb_key_people",
  "registry": {
    "officers": [ ...registry-derived officers... ],
    "beneficial_owners": [ ...registry-derived UBOs... ]
  },
  "submitted": {
    "parties": [ ...user-submitted key-people records... ]
  },
  "ubo_kyc_summary": {
    "total": 2,
    "approved": 1,
    "flagged": 0,
    "pending": 1
  },
  "warnings": []
}

registry.officers / registry.beneficial_owners: रजिस्ट्री जाँच से निकाले गए पक्ष।
submitted.parties: वे पक्ष जिन्हें व्यवसाय के एडमिन ने प्रमुख व्यक्ति प्रक्रिया के दौरान स्पष्ट रूप से जोड़ा है (source = "USER" वाले रिकॉर्ड)।

`registry.officers[]` / `registry.beneficial_owners[]`

रजिस्ट्री के तथ्य ऊपर दिए गए company.officers / company.beneficial_owners से मेल खाते हैं। प्रमुख व्यक्ति जाँच में इसके अतिरिक्त AML स्थिति और विस्तृत सत्यापन लिंकिंग भी शामिल होती है, जैसे kyc_session_id और सत्यापन वर्कफ़्लो फ़ील्ड। कंपनी की सूचियाँ अपनी मौजूदा सरल KYC स्थिति और सत्यापन URL बनाए रखती हैं।

`submitted.parties[]`

उपयोगकर्ता द्वारा जोड़े गए पक्ष अपनी KYC या चाइल्ड-KYB लिंकिंग के साथ आते हैं:

{
  "uuid": "...",
  "entity_type": "person",
  "name": "Alice Chen",
  "first_name": "John",
  "last_name": "Doe",
  "email": "alex.sample@example.com",
  "role": "ubo",
  "ownership_percent": 35.0,
  "nationality": "USA",
  "position": "CEO",
  "date_of_birth": "1990-01-01",
  "phone_number": "+34612345678",
  "source": "USER",
  "requires_verification": true,
  "is_skipped": false,
  "kyc_session_id": "sess-xyz...",
  "kyc_session_status": "Not Started",
  "kyc_session_url": "https://verify.didit.me/...",
  "kyc_session_deleted": false,
  "custom_fields": { }
}

कॉर्पोरेट पक्ष (entity_type: "company") इसके अलावा company_name, registration_number, और kyb_sub_session_id / kyb_sub_session_status / kyb_sub_session_deleted भी रखते हैं, जब कॉर्पोरेट UBO के लिए नेस्टेड KYB सक्षम हो। kyc_session_deleted (और इसका कॉर्पोरेट समकक्ष kyb_sub_session_deleted) true होता है, जब पक्ष का चाइल्ड सत्र हटाया गया हो। हटाया गया चाइल्ड सत्र हटाने के समय की अपनी स्थिति ही रखता है और कभी सेटल नहीं हो सकता, इसलिए स्थिति के बजाय इस फ़्लैग को पढ़ें। संबंधित *_session_url null लौटाया जाता है, क्योंकि लिंक अब काम नहीं करता, और प्रमुख व्यक्ति जाँच हमेशा इंतज़ार करने के बजाय In Review पर आ जाती है। चाइल्ड सत्र हटाना कभी पास नहीं माना जाता। KYB को सेटल होने देने के लिए पक्ष को PATCH /v3/session/{id}/kyb/parties/{party_uuid}/ से छूट दें।

`ubo_kyc_summary`

कुल UBO KYC प्रगति, एक ही डैशबोर्ड कार्ड के लिए उपयोगी:

फ़ील्ड	अर्थ
`total`	सक्रिय UBO की संख्या जिनके पास लिंक किया हुआ KYC सत्र है
`approved`	वे UBO जिनका KYC सत्र `Approved` है
`flagged`	वे UBO जिनका KYC सत्र `Declined` या `In Review` है
`pending`	बाकी सभी (जो अभी पूरे नहीं हुए)

जब किसी UBO का लिंक किया हुआ KYC सत्र न हो, तब यह null लौटाता है।

`document_verifications[]`

नोड के अनुसार समूहित दस्तावेज़:

{
  "status": "Approved",
  "node_id": "feature_kyb_documents",
  "items": [
    {
      "uuid": "...",
      "document_type": "LEGAL_PRESENCE",
      "document_subtype": "CERTIFICATE_OF_INCORPORATION",
      "document_group": "LEGAL_PRESENCE",
      "status": "Approved",
      "file_url": "https://didit-storage.s3...",
      "document_metadata": {
        "file_size": 246810,
        "content_type": "application/pdf",
        "creation_date": "2024-05-15",
        "modified_date": "2024-05-15",
        "overlay_manipulation": null
      },
      "ocr_data": {
        "company_name": "Acme Corporation Limited",
        "registration_number": "12345678",
        "incorporation_date": "2010-05-14"
      }
    }
  ],
  "groups": {
    "LEGAL_PRESENCE": { "total": 1, "approved": 1, "pending": 0, "declined": 0, "in_review": 0, "other": 0, "missing": 0 },
    "OWNERSHIP_STRUCTURE": { "total": 1, "approved": 1, "pending": 0, "declined": 0, "in_review": 0, "other": 0, "missing": 0 }
  },
  "required_groups": ["LEGAL_PRESENCE", "OWNERSHIP_STRUCTURE"],
  "warnings": []
}

फ़ील्ड	विवरण
`items[]`	अलग-अलग दस्तावेज़ की पंक्तियाँ। हर एक के पास अपना `status`, `document_type` और `document_group` (समूह), `document_subtype`, `file_url` (साइन किया हुआ), `document_metadata` और OCR से निकाला गया डेटा होता है
`groups`	समूह मान के आधार पर प्रति-समूह प्रगति काउंटर (`LEGAL_PRESENCE`, `COMPANY_DETAILS`, `OWNERSHIP_STRUCTURE`, `REPRESENTATIVES_AUTHORIZATION`, साथ ही अवर्गीकृत दस्तावेज़ों के लिए `OTHER`)। हर समूह में `total`, `approved`, `pending`, `declined`, `in_review`, `other` और `missing` होते हैं। देखें KYB दस्तावेज़ समूह
`required_groups`	वे समूह जिन्हें आपके वर्कफ़्लो ने आवश्यक चिह्नित किया है। सत्र स्वीकृति तभी होती है जब इन सभी की आवश्यकताएँ पूरी हों

कॉर्पोरेट दस्तावेज़ मेटाडेटा

PDF कॉर्पोरेट दस्तावेज़ों के लिए, items[].document_metadata.overlay_manipulation में ओवरले-टेक्स्ट संपादन के संदिग्ध मामलों का फ़ॉरेंसिक साक्ष्य शामिल हो सकता है। जब यह मौजूद होता है, तो इसमें ये फ़ील्ड होते हैं:

फ़ील्ड	विवरण
`analysis_incomplete`	केवल तब मौजूद और `true` होता है जब फ़ाइल की पूरी जाँच नहीं हो सकी। जो जाँचा जा सका, उसके निष्कर्ष जहाँ संभव हो वहाँ बने रहते हैं, और दस्तावेज़ `KYB_DOCUMENT_UNPROVEN_TEXT_REPLACEMENT` ट्रिगर करता है।
`detected`	यह बताता है कि ओवरले-टेक्स्ट में हेरफेर का साक्ष्य मिला या नहीं
`analyzed`	यह बताता है कि PDF का विश्लेषण हो सका या नहीं
`signals`	फ़ॉरेंसिक संकेत जो सक्रिय हुए, जैसे `duplicate_font_subset` या `glyph_fragmentation`
`manipulated_regions`	संदिग्ध रूप से संपादित टेक्स्ट के चारों ओर PDF पृष्ठ-निर्देशांक आयतें: `page`, `x`, `y`, `width`, `height`, `page_width`, `page_height`

यह फ़ील्ड null होता है जब कोई ओवरले साक्ष्य नहीं मिला, जब दस्तावेज़ PDF नहीं है, या जब PDF का विश्लेषण नहीं हो सका।

`aml_screenings[]`

कंपनी-स्तर और (जब वर्कफ़्लो इन्हें जोड़ता है) व्यक्ति-स्तर AML स्क्रीनिंग।

{
  "node_id": "feature_aml",
  "status": "Approved",
  "total_hits": 0,
  "score": 0,
  "entity_type": "COMPANY",
  "screened_data": {
    "company_name": "Acme Corporation Limited",
    "country_code": "GBR"
  },
  "is_ongoing_monitoring_enabled": true,
  "next_ongoing_monitoring_bill_date": "2027-04-16",
  "last_ongoing_screening_at": "2026-09-12T04:03:11Z",
  "last_ongoing_screening_datasets_updated_at": null,
  "hits": [],
  "warnings": []
}

जब total_hits > 0 हो, तब हर हिट में मिलान स्कोर, जोखिम स्कोर, वॉचलिस्ट स्रोत और प्रति-हिट review_status शामिल होता है, जिसे आप update-aml-hit-status endpoint से अपडेट कर सकते हैं। हिट की संरचना के लिए देखें AML स्क्रीनिंग रिपोर्ट।

साझा सुविधा ऐरे

phone_verifications, email_verifications, questionnaire_responses, ip_analyses प्रति-आइटम वही संरचनाएँ इस्तेमाल करते हैं जो उपयोगकर्ता (KYC) सत्रों में होती हैं। जब वर्कफ़्लो इन्हें शामिल नहीं करता, तब ये null होते हैं। आइटम स्कीमा के लिए देखें KYC रिस्पॉन्स। signatures तब मौजूद होता है जब वर्कफ़्लो में ई-हस्ताक्षर चरण हो। व्यवसाय सत्र में हर उस प्रमुख व्यक्ति के लिए एक आइटम होता है जो कंपनी की ओर से हस्ताक्षर करता है, जिसमें signer.capacity: "company", कंपनी का नाम और प्रमुख व्यक्ति की भूमिकाएँ होती हैं। देखें ई-हस्ताक्षर रिपोर्ट।

चेतावनी सुविधा समूह

व्यवसाय सत्यापन की चेतावनियाँ उस सुविधा के अनुसार समूहित होती हैं जिसने उन्हें उत्पन्न किया:

KYB_REGISTRY रजिस्ट्री उपलब्धता, स्वामित्व, कंपनी गतिविधि और देश-प्रतिबंध संबंधी समस्याओं के लिए।
KYB_DOCUMENTS कॉर्पोरेट दस्तावेज़ निष्कर्षण, क्रॉस-चेक, मेटाडेटा, छेड़छाड़, सबटाइप, आयु और प्रयास-सीमा संबंधी समस्याओं के लिए।
AML कंपनी AML स्क्रीनिंग के मिलानों या गायब स्क्रीनिंग डेटा के लिए।
KYB_KEY_PEOPLE निदेशकों, अधिकारियों, UBO या प्रतिनिधियों से जुड़ी व्यक्ति-स्तर समस्याओं के लिए।
PHONE फ़ोन नंबर जोखिम, डुप्लिकेशन, ब्लॉकलिस्ट और सत्यापन-कोड प्रयास संबंधी समस्याओं के लिए।
EMAIL ईमेल जोखिम, डिलीवरेबिलिटी, डुप्लिकेशन, ब्लॉकलिस्ट और सत्यापन-कोड प्रयास संबंधी समस्याओं के लिए।
QUESTIONNAIRE प्रश्नावली के उत्तरों से संचालित कस्टम स्थिति नियमों के लिए।
LOCATION डिवाइस और IP विश्लेषण, प्राइवेट नेटवर्क, IP ब्लॉकलिस्ट, डिवाइस ब्लॉकलिस्ट और डुप्लिकेट डिवाइस/IP समस्याओं के लिए।
SIGNATURE ई-हस्ताक्षर की अस्वीकृति, विफल कोड पुष्टि, हस्ताक्षरकर्ता के नाम का मेल न खाना, असत्यापित हस्ताक्षरकर्ता, बदले गए दस्तावेज़ और गायब फ़ील्ड डेटा के लिए। देखें ई-हस्ताक्षर चेतावनियाँ।

चेतावनी कोड की पूरी सूची के लिए देखें व्यवसाय सत्यापन चेतावनियाँ।

वर्कफ़्लो-आधारित फ़ील्ड फ़िल्टरिंग

वर्कफ़्लो response_attributes के ज़रिए हर फ़ीचर आइटम में दिखने वाले नेस्टेड फ़ील्ड सीमित कर सकते हैं। status, warnings और node_id हमेशा शामिल रहते हैं। बाकी सभी फ़ील्ड, जो अनुमति सूची में नहीं हैं, शून्य (null) कर दिए जाते हैं। स्कीमा की स्थिरता के लिए उनकी कुंजी रिस्पॉन्स में बनी रहती है।

अगले चरण

स्टेटस

हर स्टेटस मान का अर्थ।

जोखिम मूल्यांकन

KYB परिणाम को क्या प्रभावित करता है।

AML रिपोर्ट

AML हिट payload का पूरा संदर्भ।

प्रमुख व्यक्ति

पक्ष रजिस्ट्री से और उपयोगकर्ता द्वारा सबमिट की गई जानकारी से registry / submitted बकेट में कैसे जाते हैं।

दस्तावेज़

दस्तावेज़ समूह, OCR और क्रॉस-रेफ़रेंस।

सत्र पुनः प्राप्त करें

उदाहरण रिस्पॉन्स सहित endpoint का पूरा संदर्भ।

शुरुआत करें

सुविधाएँ

व्यवसाय प्रोफ़ाइल

संदर्भ

कंसोल

व्यवसाय सत्यापन रिस्पॉन्स स्कीमा: निर्णय payload रेफ़रेंस

शीर्ष-स्तर की संरचना

साझा शीर्ष-स्तर फ़ील्ड

`registry_checks[]`

`company` ब्लॉक

हर देश और रजिस्ट्री स्रोत के लिए एक प्रारूप

अधिकारी आइटम का आकार (`company.officers` के भीतर)

वास्तविक स्वामी आइटम का आकार (`company.beneficial_owners` के भीतर)

`key_people_checks[]`

`registry.officers[]` / `registry.beneficial_owners[]`

`submitted.parties[]`

`ubo_kyc_summary`

`document_verifications[]`

कॉर्पोरेट दस्तावेज़ मेटाडेटा

`aml_screenings[]`

साझा सुविधा ऐरे

चेतावनी सुविधा समूह

वर्कफ़्लो-आधारित फ़ील्ड फ़िल्टरिंग

अगले चरण

स्टेटस

जोखिम मूल्यांकन

AML रिपोर्ट

प्रमुख व्यक्ति

दस्तावेज़

सत्र पुनः प्राप्त करें

​शीर्ष-स्तर की संरचना

​साझा शीर्ष-स्तर फ़ील्ड

​registry_checks[]

​company ब्लॉक

​हर देश और रजिस्ट्री स्रोत के लिए एक प्रारूप

​अधिकारी आइटम का आकार (company.officers के भीतर)

​वास्तविक स्वामी आइटम का आकार (company.beneficial_owners के भीतर)

​key_people_checks[]

​registry.officers[] / registry.beneficial_owners[]

​submitted.parties[]

​ubo_kyc_summary

​document_verifications[]

​कॉर्पोरेट दस्तावेज़ मेटाडेटा

​aml_screenings[]

​साझा सुविधा ऐरे

​चेतावनी सुविधा समूह

​वर्कफ़्लो-आधारित फ़ील्ड फ़िल्टरिंग

​अगले चरण

स्टेटस

जोखिम मूल्यांकन

AML रिपोर्ट

प्रमुख व्यक्ति

दस्तावेज़

सत्र पुनः प्राप्त करें

शीर्ष-स्तर की संरचना

साझा शीर्ष-स्तर फ़ील्ड

`registry_checks[]`

`company` ब्लॉक

हर देश और रजिस्ट्री स्रोत के लिए एक प्रारूप

अधिकारी आइटम का आकार (`company.officers` के भीतर)

वास्तविक स्वामी आइटम का आकार (`company.beneficial_owners` के भीतर)

`key_people_checks[]`

`registry.officers[]` / `registry.beneficial_owners[]`

`submitted.parties[]`

`ubo_kyc_summary`

`document_verifications[]`

कॉर्पोरेट दस्तावेज़ मेटाडेटा

`aml_screenings[]`

साझा सुविधा ऐरे

चेतावनी सुविधा समूह

वर्कफ़्लो-आधारित फ़ील्ड फ़िल्टरिंग

अगले चरण