> ## 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.

# प्रमुख व्यक्ति KYB API: UBO और अधिकारी

> Didit में एक KYB फ़्लो में वास्तविक स्वामी, शेयरधारक, निदेशक और अधिकारियों की जाँच करें। प्रति जाँच $2.00 से, कोई अनुबंध नहीं।

**प्रमुख व्यक्ति** Didit का एकीकृत मॉडल है, जो उस व्यवसाय से जुड़े हर प्राकृतिक व्यक्ति और कॉर्पोरेट इकाई को दर्शाता है जिसे आप सत्यापित कर रहे हैं: UBO, शेयरधारक (व्यक्तिगत और कॉर्पोरेट), निदेशक, प्रतिनिधि और अन्य अधिकारी भूमिकाएँ। एक ही प्रमुख व्यक्ति फ़्लो इन सभी को कवर करता है, जिसमें भूमिका-आधारित सत्यापन डिस्पैच और रजिस्ट्री से प्राप्त तथा उपयोगकर्ता द्वारा जमा किए गए पक्षों की पूरी साथ-साथ तुलना शामिल है।

> [!NOTE]
>
> व्यवसाय-इकाई दृष्टिकोण से प्रमुख व्यक्तियों को देखने के लिए, यानी यह कि अधिकारी और UBO कई सत्रों में कैसे एकत्रित होते हैं, [व्यवसाय → प्रमुख व्यक्ति](https://docs.didit.me/hi/entities/businesses/key-people.md) देखें।

## कैसे काम करता है

**1. रजिस्ट्री प्री-फ़िल (वैकल्पिक)**

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

**2. होस्टेड फ़्लो से जमा करना**

अंतिम उपयोगकर्ता होस्टेड सत्यापन फ़्लो के माध्यम से प्रमुख व्यक्तियों की अंतिम सूची जमा करता है। डिफ़ॉल्ट रूप से यह चरण आपको स्वयं कॉल नहीं करना होता; यह उस KYB फ़्लो के भीतर होता है जिसका URL आपने [सत्र बनाएँ](https://docs.didit.me/hi/sessions-api/create-session.md) से दिया था।
इसके बजाय अपना फ़्रंट एंड रखने के लिए, [पक्ष ड्राफ़्ट](https://docs.didit.me/hi/sessions-api/kyb-create-party-draft.md) और [पक्ष जमा करें](https://docs.didit.me/hi/sessions-api/kyb-submit-parties.md) endpoint का उपयोग करें।

**3. भूमिका-आधारित सत्यापन रूटिंग**

हर जमा किए गए पक्ष के लिए, Didit भूमिका की कॉन्फ़िगर की गई सत्यापन सेटिंग्स जाँचता है:

* वर्कफ़्लो की स्वामित्व थ्रेशोल्ड लागू करता है: कॉन्फ़िगर किए गए प्रतिशत से कम हिस्सेदारी वाले UBO और शेयरधारकों को व्यक्तिगत सत्यापन की आवश्यकता नहीं होती।
* उपयोगकर्ता द्वारा सेट किए गए "skip verification" फ़्लैग का सम्मान करता है, यदि भूमिका सत्यापन छोड़ने की अनुमति देती है।
* KYC की आवश्यकता वाले व्यक्तिगत पक्षों के लिए चाइल्ड उपयोगकर्ता सत्यापन (KYC) सत्र बनाता है।
* वर्कफ़्लो पर नेस्टेड KYB सक्षम होने पर कॉर्पोरेट UBO के लिए चाइल्ड KYB उप-सत्र बनाता है।

**4. स्थिति की प्रगति**

जब तक कोई आवश्यक चाइल्ड सत्र चल रहा है, प्रमुख व्यक्ति सुविधा की स्थिति `Awaiting User` रहती है। जब सभी चाइल्ड सत्र पूरे हो जाते हैं, तो परिणामों के आधार पर स्थिति `Approved`, `Declined` या `In Review` में एकत्रित हो जाती है।

## एकत्र की गई भूमिकाएँ

प्रमुख व्यक्ति एक या अधिक निम्नलिखित भूमिकाएँ रख सकते हैं; एक ही व्यक्ति एक साथ कई भूमिकाएँ रख सकता है (उदाहरण के लिए, निदेशक **और** शेयरधारक)। पूरी वर्गीकरण सूची:

| श्रेणी | भूमिकाएँ |
| - | - |
| **स्वामित्व** | `ubo`, `shareholder`, `beneficiary`, `settlor`, `protector`, `investor` |
| **शासन / प्रतिनिधित्व** | `director`, `non_executive_director`, `chairman`, `secretary`, `representative`, `authorized_signatory`, `trustee`, `company_officer`, `founder`, `legal_advisor`, `other` |

हर भूमिका को वर्कफ़्लो में अलग से कॉन्फ़िगर किया जा सकता है: सक्षम या अक्षम, KYC के लिए अनिवार्य या वैकल्पिक, किसी विशिष्ट KYC वर्कफ़्लो से मैप की गई, और वैकल्पिक रूप से छोड़ने योग्य। सत्यापन डिस्पैच के विवरण के लिए [स्वामित्व](https://docs.didit.me/hi/business-verification/ownership.md) देखें।

## प्रति प्रमुख व्यक्ति एकत्र किया गया डेटा

होस्टेड फ़्लो फ़ील्ड्स का एक डिफ़ॉल्ट सेट और वर्कफ़्लो में कॉन्फ़िगर किए गए अतिरिक्त कस्टम फ़ील्ड्स माँगता है। पूरी सूची के लिए [स्वामित्व → एकत्र किए गए फ़ील्ड्स](https://docs.didit.me/hi/business-verification/ownership.md#हर-प्रमुख-व्यक्ति-के-लिए-एकत्र-किया-गया-डेटा) देखें।

## रजिस्ट्री पुष्टि

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

* Didit द्वारा रजिस्ट्री जाँच से सामान्यीकृत किया गया **रजिस्ट्री विवरण** (`registry_data`)।
* **उपयोगकर्ता द्वारा पुष्ट डेटा** (`user_provided_data`), जिसमें वह समय-चिह्न होता है जब उपयोगकर्ता ने पुष्टि की।
* शीर्ष-स्तरीय कंपनी फ़ील्ड्स पर एक मिला हुआ कैनोनिकल दृश्य: मौजूद होने पर उपयोगकर्ता द्वारा पुष्ट, अन्यथा रजिस्ट्री का विकल्प।

पूरे मॉडल के लिए [कंपनी डेटा → रजिस्ट्री बनाम उपयोगकर्ता द्वारा प्रदान किया गया डेटा](https://docs.didit.me/hi/business-verification/company-data.md#रजिस्ट्री-डेटा-बनाम-उपयोगकर्ता-प्रदत्त-डेटा) देखें।

## निर्णय प्रतिक्रिया में संरचना

जमा करने के बाद, एकत्र किए गए प्रमुख व्यक्ति KYB निर्णय में `key_people_checks[]` के अंतर्गत दिखाई देते हैं, जो दो हिस्सों में बँटे होते हैं: **रजिस्ट्री** (जो प्रदाता ने खुलासा किया) और **जमा किया गया** (जिसे व्यवसाय व्यवस्थापक ने फ़्लो के माध्यम से पुष्ट किया)। साथ ही `ubo_kyc_summary` UBO KYC प्रगति का सारांश देता है। पूरे संदर्भ के लिए [key\_people\_checks संदर्भ](https://docs.didit.me/hi/business-verification/response-schema.md#key_people_checks) देखें।

## फिर से जमा करने का व्यवहार

* **प्रमुख व्यक्ति** और **रजिस्ट्री जाँच** को सीधे फिर से जमा नहीं किया जा सकता। किसी विशिष्ट व्यक्ति को फिर से सत्यापित करने के लिए, उसका व्यक्तिगत चाइल्ड KYC सत्र फिर से जमा करें।
* जब कोई चाइल्ड KYC सत्र फिर से जमा होता है, तो मूल प्रमुख व्यक्ति सुविधा की स्थिति अपने-आप `Awaiting User` पर लौट आती है।
* जब फिर से जमा किया गया चाइल्ड सत्र पूरा होता है, तो मूल स्थिति सभी चाइल्ड स्थितियों के आधार पर फिर से एकत्रित होती है।
* जिस चाइल्ड सत्र को हटाया गया था, या जिसकी समय-सीमा व्यक्ति द्वारा उसे शुरू करने से पहले समाप्त हो गई थी, उसे फिर से जमा नहीं किया जा सकता: उसी पक्ष पर नया लिंक जारी करने के लिए [पक्ष को पुनः जनरेट करें](https://docs.didit.me/hi/sessions-api/regenerate-kyb-party.md)।

## किसी प्रमुख व्यक्ति का सत्यापन लिंक कितने समय तक मान्य रहता है

किसी प्रमुख व्यक्ति का चाइल्ड KYC सत्र उस KYC वर्कफ़्लो के सत्र समाप्ति समय का पालन करता है जो उनकी भूमिका के लिए कॉन्फ़िगर किया गया है, न कि KYB वर्कफ़्लो का। यदि आप किसी भूमिका को ऐसे KYC वर्कफ़्लो से मैप करते हैं जो चार सप्ताह की अनुमति देता है, तो उस व्यक्ति का लिंक चार सप्ताह तक उपयोग में रहेगा, भले ही व्यवसाय सत्र उससे पहले समाप्त होने के लिए सेट हो।

यह मान प्रति-वर्कफ़्लो सेटिंग है, जो 1 घंटे से 4 सप्ताह तक हो सकता है (`session_expiration_time`, सेकंड में), और इसे *Workflows → \[KYC workflow] → Settings* में सेट किया जाता है।

समाप्ति इस बात को बदल देती है कि आप पक्षकार के साथ क्या कर सकते हैं। जो लिंक व्यक्ति के शुरू करने से पहले समाप्त हो गया, जैसे वह लिंक जिसका सत्र हटा दिया गया था, उसे [Regenerate Key People KYC Session](https://docs.didit.me/hi/sessions-api/regenerate-kyb-party.md) से दोबारा जारी किया जा सकता है। हटाए गए सत्र तब भी योग्य हैं, भले ही व्यक्ति ने सत्यापन शुरू कर दिया हो या पूरा कर लिया हो। आयात किए गए सत्र समाप्ति के आधार पर योग्य नहीं होते; उन्हें हटाया गया होना चाहिए। ऐसा सत्र जो हटाया नहीं गया है और जिसे व्यक्ति ने पहले ही शुरू कर लिया है, समाप्ति के आधार पर योग्य नहीं होता।

## कॉन्फ़िगरेशन विकल्प

Key People का सारा व्यवहार Business Console से प्रति वर्कफ़्लो कॉन्फ़िगर किया जाता है:

| सेटिंग | यह क्या नियंत्रित करती है |
| - | - |
| **रजिस्ट्री प्रीफ़िल** | रजिस्ट्री डेटा से Key People फ़ॉर्म पहले से भरें |
| **अतिरिक्त फ़ील्ड — व्यक्ति** | हर व्यक्ति पक्षकार के लिए एकत्र करने वाले कस्टम फ़ील्ड |
| **अतिरिक्त फ़ील्ड — कंपनियाँ** | हर कॉर्पोरेट पक्षकार के लिए एकत्र करने वाले कस्टम फ़ील्ड |
| **UBO स्वामित्व सीमा** | किसी को UBO के रूप में वर्गीकृत करने के लिए न्यूनतम स्वामित्व प्रतिशत |
| **शेयरधारक स्वामित्व सीमा** | किसी को शेयरधारक के रूप में वर्गीकृत करने के लिए न्यूनतम स्वामित्व प्रतिशत |
| **प्रति-भूमिका सेटिंग्स** | हर भूमिका के लिए: सक्षम/अक्षम, KYC आवश्यक, उपयोग किया जाने वाला KYC वर्कफ़्लो, छोड़े जाने योग्य |
| **कॉर्पोरेट UBO नेस्टेड KYB** | सक्षम होने पर, कॉर्पोरेट UBO अपना चाइल्ड KYB सत्र शुरू करते हैं |
| **सत्यापित व्यक्तियों का पुन: उपयोग** | नीचे [KYB जाँचों में सत्यापित व्यक्तियों का पुन: उपयोग](#kyb-जाँचों-में-सत्यापित-व्यक्तियों-का-पुन-उपयोग) देखें |
| **ईमेल द्वारा पक्षकारों को सूचित करें** | हर प्रमुख व्यक्ति को उसका सत्यापन लिंक स्वचालित रूप से ईमेल करें |

कंसोल में *Workflows → \[KYB workflow] → Key People* खोलकर कॉन्फ़िगर करें।

## KYB जाँचों में सत्यापित व्यक्तियों का पुन: उपयोग

जब किसी वर्कफ़्लो पर **सत्यापित व्यक्तियों का पुन: उपयोग** सक्षम होता है (डिफ़ॉल्ट रूप से), तो किसी प्रमुख व्यक्ति को हर बार नई KYB जाँच में आने पर KYC दोबारा नहीं करना पड़ता। Didit पिछली KYB जाँच से मौजूदा स्वीकृत KYC खोजता है और उसे नए पक्षकार से जोड़ता है, नया चाइल्ड KYC सत्र बनाने के बजाय।

> [!NOTE]
>
> यह [पुनः प्रयोज्य KYC](https://docs.didit.me/hi/core-technology/reusable-kyc/overview.md) से अलग तंत्र है, जो एक *अंतिम उपयोगकर्ता* को शेयर/इंपोर्ट token के माध्यम से एक पूर्ण सत्र को अलग-अलग Didit-एकीकृत एप्लिकेशन में स्वेच्छा से ले जाने देता है। इस पृष्ठ की KYB पुन: उपयोग सेटिंग स्वचालित है, वर्कफ़्लो में कॉन्फ़िगर होती है, और एक ही एप्लिकेशन के भीतर प्रमुख व्यक्तियों तक सीमित है - इसमें कोई शेयर token नहीं है और अंतिम उपयोगकर्ता की ओर से कोई कार्रवाई आवश्यक नहीं है।

**मिलान।** प्रस्तुत व्यक्ति का पूरा नाम (केस-इनसेंसिटिव, व्हाइटस्पेस-ट्रिम्ड) एप्लिकेशन की अन्य KYB जाँचों के प्रमुख व्यक्तियों से तुलना करके एक संभावित मिलान खोजा जाता है। कोई अतिरिक्त मिलान संकेत नहीं है - दस्तावेज़ संख्या, ईमेल या फ़ोन का मिलान न आवश्यक है और न ही जाँचा जाता है। अलग वर्तनी, मध्य नाम या लिप्यंतरण वाला नाम मेल नहीं खाएगा, और दुर्लभ मामलों में एक ही नाम वाले दो अलग व्यक्ति मेल खा सकते हैं; इसे ध्यान में रखते हुए अपने Key People परिणामों की समीक्षा करें।

**दायरा।** मिलान *उसी एप्लिकेशन* से संबंधित हर अन्य KYB जाँच में किया जाता है, केवल वर्तमान KYB जाँच में नहीं और आपकी संस्था के अन्य एप्लिकेशनों में नहीं। Company A में UBO के रूप में सत्यापित व्यक्ति, बाद में Company B में निदेशक के रूप में दिखाई देने पर मेल खा सकता है, बशर्ते दोनों जाँचें एक ही एप्लिकेशन के तहत चलें।

**योग्य स्थितियाँ।** किसी पक्षकार का केवल सबसे हाल का **स्वीकृत** KYC ही पुन: उपयोग के लिए योग्य है। उस नाम के लिए **अस्वीकृत** KYC पुन: उपयोग को पूरी तरह रोक देता है - पक्षकार चिह्नित किया जाता है और अस्वीकृत KYC पर लौटने के बजाय नया KYC माँगा जाता है। जो KYC अभी भी **समीक्षाधीन** है, उसे कभी उम्मीदवार नहीं माना जाता।

**प्रतिधारण अवधि।** मिलान केवल लगभग पिछले एक वर्ष में बनाए गए उन KYC सत्रों पर विचार करता है जो हटाए नहीं गए हैं। यदि एकमात्र मिलने वाला सत्र इस अवधि से बाहर है, या व्यक्ति या संस्था ने उसे हटा दिया है, तो जाँच कोई योग्य मिलान नहीं पाती और चुपचाप नया KYC माँगती है - यह कभी विफल नहीं होती और न ही Key People सबमिशन को रोकती है।

**बिलिंग।** पुन: उपयोग किए गए KYC का दोबारा बिल नहीं होता। पहले से स्वीकृत सत्र को नए पक्षकार से जोड़ने पर कोई अतिरिक्त शुल्क नहीं लगता; आपसे केवल एक बार, मूल KYC पर, शुल्क लिया जाता है।

```txt Example theme={null}
Company A: Jane Doe submitted as UBO, KYC approved.
Company B (same application): Jane Doe submitted as a director.
"Reuse verified individuals" is enabled, so Company B's Key People
check links Jane's existing approved KYC instead of requesting a
new one - free, and instantly Approved for that party.
```

## आगे के चरण

> [card] [स्वामित्व](https://docs.didit.me/hi/business-verification/ownership.md)
>
> एकत्र किए गए फ़ील्ड, कस्टम डेटा, और रजिस्ट्री बनाम सबमिट किए गए डेटा का मिलान।

> [card] [अधिकारी और प्रतिनिधि](https://docs.didit.me/hi/business-verification/officers.md)
>
> Key People मॉडल के भीतर शासन भूमिकाएँ।

> [card] [रिस्पॉन्स स्कीमा](https://docs.didit.me/hi/business-verification/response-schema.md#key_people_checks)
>
> `key_people_checks[]` फ़ील्ड-दर-फ़ील्ड संदर्भ।


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