> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

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

> Didit का KYB निर्णय payload: रजिस्ट्री जाँच, प्रमुख व्यक्ति, UBO KYC सारांश, दस्तावेज़, AML स्क्रीनिंग और साझा फ़ील्ड। प्रति जाँच $2.00 से।

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

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

```json theme={null}
{
  "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 | सत्र की कुल स्थिति (देखें [स्थितियाँ](https://docs.didit.me/hi/business-verification/statuses.md)) |
| `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 के साथ कई जाँचें हो सकती हैं।

```json theme={null}
{
  "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) चेतावनियाँ](https://docs.didit.me/hi/business-verification/warnings.md)। |

### `company` ब्लॉक

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

```json theme={null}
{
  "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`, आदि)। देखें [स्थितियाँ](https://docs.didit.me/hi/business-verification/statuses.md#रजिस्ट्री-स्थिति-प्रदाता-से) |
| `is_from_registry` | `true` जब डेटा किसी आधिकारिक रजिस्ट्री से आया हो; मैन्युअल प्रविष्टि के लिए `false` |
| `fetch_status` | `pending`, `resolved`, या `failed`, यानी रजिस्ट्री खोज की स्थिति |
| `verification_status` | `verified`, `failed`, या `unknown` |
| `risk_level` | रजिस्ट्री स्रोत से पास किया गया वैकल्पिक मान। आम तौर पर `null` होता है: Didit जोखिम स्तर की गणना नहीं करता, इसलिए निर्णय के लिए `warnings[]` और सत्र का `status` इस्तेमाल करें |
| `registry_monitoring` | कंपनी का नवीनतम रजिस्ट्री मॉनिटर, या कोई न होने पर `null`। यह तभी भरा जाता है जब [रजिस्ट्री मॉनिटरिंग](https://docs.didit.me/hi/business-verification/ownership.md#शेयरधारकों-और-ubo-की-निगरानी) उपलब्ध हो। फ़ील्ड: `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](https://docs.didit.me/hi/sessions-api/update-data.md) से किए गए सुधार, और वे रजिस्ट्री तथ्य जिनका अपना फ़ील्ड नहीं है। इसमें रजिस्ट्री स्रोत का अपना रिकॉर्ड कभी नहीं होता। इसकी कुंजियाँ कंपनी के अनुसार बदलती हैं और यह स्थिर अनुबंध नहीं है: इसके बजाय कैनोनिकल फ़ील्ड पढ़ें |
| `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 और कर पहचान सत्यापन](https://docs.didit.me/hi/business-verification/company-data.md#vat-और-टैक्स-id-सत्यापन) |
| `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` पार्स करने की ज़रूरत नहीं होती। वही आकार [निर्णय](https://docs.didit.me/hi/sessions-api/retrieve-session.md), स्वतंत्र [KYB रजिस्ट्री](https://docs.didit.me/hi/standalone-apis/kyb-registry-ubo.md) 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](https://docs.didit.me/hi/sessions-api/update-data.md) स्वीकार करता है) | स्ट्रिंग। 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` के भीतर)

```json theme={null}
{
  "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` के भीतर)

```json theme={null}
{
  "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 सारांश भी मिलता है।

```json theme={null}
{
  "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 लिंकिंग के साथ आते हैं:

```json theme={null}
{
  "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}/`](https://docs.didit.me/hi/sessions-api/update-data#प्रमुख-व्यक्ति-पक्ष-को-छोड़ें) से छूट दें।

### `ubo_kyc_summary`

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

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

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

## `document_verifications[]`

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

```json theme={null}
{
  "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 दस्तावेज़ समूह](https://docs.didit.me/hi/business-verification/documents.md#दस्तावेज़-समूह) |
| `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 स्क्रीनिंग।

```json theme={null}
{
  "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 स्क्रीनिंग रिपोर्ट](https://docs.didit.me/hi/core-technology/aml-screening/report-aml-screening.md)।

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

`phone_verifications`, `email_verifications`, `questionnaire_responses`, `ip_analyses` प्रति-आइटम वही संरचनाएँ इस्तेमाल करते हैं जो उपयोगकर्ता (KYC) सत्रों में होती हैं। जब वर्कफ़्लो इन्हें शामिल नहीं करता, तब ये `null` होते हैं। आइटम स्कीमा के लिए देखें [KYC रिस्पॉन्स](https://docs.didit.me/hi/sessions-api/retrieve-session.md)।

`signatures` तब मौजूद होता है जब वर्कफ़्लो में [ई-हस्ताक्षर](https://docs.didit.me/hi/core-technology/electronic-signature/overview.md) चरण हो। व्यवसाय सत्र में हर उस प्रमुख व्यक्ति के लिए एक आइटम होता है जो कंपनी की ओर से हस्ताक्षर करता है, जिसमें `signer.capacity: "company"`, कंपनी का नाम और प्रमुख व्यक्ति की भूमिकाएँ होती हैं। देखें [ई-हस्ताक्षर रिपोर्ट](https://docs.didit.me/hi/core-technology/electronic-signature/report-electronic-signature.md)।

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

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

* `KYB_REGISTRY` रजिस्ट्री उपलब्धता, स्वामित्व, कंपनी गतिविधि और देश-प्रतिबंध संबंधी समस्याओं के लिए।
* `KYB_DOCUMENTS` कॉर्पोरेट दस्तावेज़ निष्कर्षण, क्रॉस-चेक, मेटाडेटा, छेड़छाड़, सबटाइप, आयु और प्रयास-सीमा संबंधी समस्याओं के लिए।
* `AML` कंपनी AML स्क्रीनिंग के मिलानों या गायब स्क्रीनिंग डेटा के लिए।
* `KYB_KEY_PEOPLE` निदेशकों, अधिकारियों, UBO या प्रतिनिधियों से जुड़ी व्यक्ति-स्तर समस्याओं के लिए।
* `PHONE` फ़ोन नंबर जोखिम, डुप्लिकेशन, ब्लॉकलिस्ट और सत्यापन-कोड प्रयास संबंधी समस्याओं के लिए।
* `EMAIL` ईमेल जोखिम, डिलीवरेबिलिटी, डुप्लिकेशन, ब्लॉकलिस्ट और सत्यापन-कोड प्रयास संबंधी समस्याओं के लिए।
* `QUESTIONNAIRE` प्रश्नावली के उत्तरों से संचालित कस्टम स्थिति नियमों के लिए।
* `LOCATION` डिवाइस और IP विश्लेषण, प्राइवेट नेटवर्क, IP ब्लॉकलिस्ट, डिवाइस ब्लॉकलिस्ट और डुप्लिकेट डिवाइस/IP समस्याओं के लिए।
* `SIGNATURE` ई-हस्ताक्षर की अस्वीकृति, विफल कोड पुष्टि, हस्ताक्षरकर्ता के नाम का मेल न खाना, असत्यापित हस्ताक्षरकर्ता, बदले गए दस्तावेज़ और गायब फ़ील्ड डेटा के लिए। देखें [ई-हस्ताक्षर चेतावनियाँ](https://docs.didit.me/hi/core-technology/electronic-signature/warnings-electronic-signature.md)।

चेतावनी कोड की पूरी सूची के लिए देखें [व्यवसाय सत्यापन चेतावनियाँ](https://docs.didit.me/hi/business-verification/warnings.md)।

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

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

## अगले चरण

> [card] [स्टेटस](https://docs.didit.me/hi/business-verification/statuses.md)
>
> हर स्टेटस मान का अर्थ।

> [card] [जोखिम मूल्यांकन](https://docs.didit.me/hi/business-verification/risk-assessment.md)
>
> KYB परिणाम को क्या प्रभावित करता है।

> [card] [AML रिपोर्ट](https://docs.didit.me/hi/core-technology/aml-screening/report-aml-screening.md)
>
> AML हिट payload का पूरा संदर्भ।

> [card] [प्रमुख व्यक्ति](https://docs.didit.me/hi/business-verification/key-people.md)
>
> पक्ष रजिस्ट्री से और उपयोगकर्ता द्वारा सबमिट की गई जानकारी से `registry` / `submitted` बकेट में कैसे जाते हैं।

> [card] [दस्तावेज़](https://docs.didit.me/hi/business-verification/documents.md)
>
> दस्तावेज़ समूह, OCR और क्रॉस-रेफ़रेंस।

> [card] [सत्र पुनः प्राप्त करें](https://docs.didit.me/hi/sessions-api/retrieve-session.md)
>
> उदाहरण रिस्पॉन्स सहित endpoint का पूरा संदर्भ।


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.