Organizations के बारे में

शुरू करने से पहले

Organization बनाने के लिए आपके पास KYB-verified कॉर्पोरेट Kraken अकाउंट होना आवश्यक है. व्यक्तिगत Kraken अकाउंट इसके लिए पात्र नहीं हैं.

केवल वही अकाउंट होल्डर Organization बना सकता है जिसने बिज़नेस वेरिफिकेशन पूरा किया हो. Organization बनने के बाद यह व्यक्ति Organization Owner बन जाता है.

Organization बनाने की प्रक्रिया को self-service के ज़रिए पूर्ववत नहीं किया जा सकता. Organization बन जाने के बाद उसे वापस करने के लिए मैन्युअल सहायता की आवश्यकता होती है.

ध्यान रखें: Organizations फिलहाल Beta में है. कुछ सुविधाओं की सीमाएं हो सकती हैं. विवरण के लिए Beta limitations देखें.

Organizations एक नज़र में

Organizations इंस्टीट्यूशनल क्लाइंट्स को टीम एक्सेस मैनेज करने और साझा अकाउंट में संवेदनशील कार्यों के लिए approval अनिवार्य करने की सुविधा देता है.

  • अपनी Organization में टीम सदस्यों को आमंत्रित करें
  • workflow और अकाउंट के अनुसार permissions असाइन करें
  • निकासी, एड्रेस बदलाव और permission अपडेट जैसे संवेदनशील कार्यों के लिए approval अनिवार्य करें
  • 2FA और सेशन टाइमआउट जैसे साझा सुरक्षा नियंत्रण लागू करें
  • गवर्नेंस को चरणबद्ध तरीके से लागू करें — पहले तेज़ी से शुरू करें, बाद में नियंत्रण कड़े करें

मुख्य भूमिकाएं

Organization Owner — वह अकाउंट होल्डर जिसने Organization बनाई. Owner के पास शुरू से पूर्ण प्रशासनिक permissions होती हैं और वह टीम के लिए एक्सेस और गवर्नेंस सेट अप करने के लिए ज़िम्मेदार होता है. को-ओनर की कोई भूमिका नहीं होती.

Member — Organization में विशिष्ट permissions के साथ आमंत्रित व्यक्ति. Members अपने Kraken क्रेडेंशियल्स से साइन इन करते हैं और Organization की साइन-इन 2FA पॉलिसी का पालन करना अनिवार्य है.

Service User — Organization के भीतर बनाया गया केवल API-आधारित ऑपरेटर. Service Users API key क्रेडेंशियल्स से authenticate करते हैं और अनुरोध शुरू कर सकते हैं, लेकिन उन्हें अनुमोदित नहीं कर सकते और न ही UI में साइन इन कर सकते हैं. विवरण के लिए Service Users देखें.

मुख्य शब्द

Organization — एक शीर्ष-स्तरीय संरचना जो Members, अकाउंट और गवर्नेंस को एक साथ समूहित करती है.

Account — ट्रेडिंग और फ़ंडिंग के लिए उपयोग की जाने वाली एक इकाई जिसमें अलग बैलेंस होते हैं. अनुमतियां प्रति अकाउंट दी जाती हैं — एक अकाउंट की पहुंच दूसरे अकाउंट पर लागू नहीं होती. मल्टी-अकाउंट ट्रेडिंग भविष्य के रिलीज़ में उपलब्ध होगी.

Permission — एक अधिकार जो यह निर्धारित करता है कि कोई Member या Service User क्या कर सकता है. अनुमतियां ऐडिटिव होती हैं: उपयोगकर्ताओं को शुरुआत में कोई एक्सेस नहीं होती और प्रत्येक अनुमति अलग से दी जानी चाहिए. विस्तृत जानकारी के लिए Permissions and workflows देखें.

Workflow — संबंधित ऑपरेशनों का एक समूह जो एक ही अनुमति मॉडल और पॉलिसी कॉन्फ़िगरेशन साझा करता है. Organizations में 4 workflows हैं. Initiate Withdrawal, Manage Addresses, Manage Access और Manage Policies.

Operation — किसी workflow के अंतर्गत एक विशिष्ट कार्रवाई. उदाहरण के लिए, «Create a crypto withdrawal» Initiate Withdrawal workflow का एक ऑपरेशन है.

Policy — किसी workflow के लिए गवर्नेंस कॉन्फ़िगरेशन. पॉलिसी यह निर्धारित करती है कि कितनी स्वीकृतियां आवश्यक हैं और क्या कुछ उपयोगकर्ता कार्रवाइयां तुरंत पूरी कर सकते हैं. विवरण के लिए Policies, approvals, and governance देखें.

Request — वह कार्य-आइटम जो किसी Member या Service User द्वारा किसी governed workflow पर कार्रवाई शुरू करने पर बनता है. अनुरोध या तो तुरंत पूरे होते हैं (जब पॉलिसी अनुमति दे) या समीक्षा के लिए अप्रूवल कतार में रखे जाते हैं.

Execute — एक अनुमति जो किसी Member को workflow पॉलिसी द्वारा अनुमत होने पर स्वीकृति की प्रतीक्षा किए बिना कार्रवाइयां पूरी करने देती है. जब «Always require approval» चालू हो, तो Execute का कोई प्रभाव नहीं होता.

Policy lock — एक गवर्नेंस नियंत्रण जो किसी एक व्यक्ति को workflow की पॉलिसी बदलने से रोकता है. भविष्य में बदलावों के लिए स्वतंत्र स्वीकृति आवश्यक होगी और यह पर्याप्त approvers की उपलब्धता पर निर्भर करेगा.

Separation of duties — यह नियम कि कोई Member अपने स्वयं के अनुरोध को स्वीकृत नहीं कर सकता. सिस्टम द्वारा लागू, इसे बदला नहीं जा सकता.

मुख्य नियम और सुरक्षा नियंत्रण

  • Members अपने स्वयं के अनुरोधों को अप्रूव नहीं कर सकते. सिस्टम द्वारा लागू, इसे बदला नहीं जा सकता.
  • Permissions संचयी होती हैं. Members को शुरुआत में कोई एक्सेस नहीं मिलती — प्रत्येक permission अलग से दी जानी चाहिए.
  • कोई action तत्काल पूरा होगा या उसके लिए अप्रूवल की आवश्यकता होगी, यह Member की permissions और workflow की policy दोनों पर निर्भर करता है. Permissions and workflows देखें.
  • लॉक की गई policies को स्वतंत्र अप्रूवल के बिना बदला नहीं जा सकता — Owner सहित.
  • Organization साइन-इन 2FA अनिवार्य है. Policy बनाते समय सेट की जाती है और सभी मौजूदा तथा भविष्य के Members पर लागू होती है.
  • निष्क्रिय sessions समाप्त हो जाती हैं और पुनः ऑथेंटिकेशन की आवश्यकता होती है.

Beta सीमाओं का सारांश

Organizations फिलहाल Beta में है. मुख्य सीमाएं:

  • केवल single-account mode उपलब्ध है — multi-account ट्रेडिंग अभी समर्थित नहीं है
  • कुछ platform operations केवल Owner के लिए हैं (फ़्यूचर्स, OTC, Convert, कस्टडी)
  • Client-facing audit logs अभी उपलब्ध नहीं हैं
  • Custom roles को सहेजा और पुनः उपयोग नहीं किया जा सकता
  • तत्काल address परिवर्तन के लिए ईमेल कन्फ़र्मेशन अनुरोध बनाने वाले को नहीं, बल्कि Owner को भेजी जाती है
  • Beta के दौरान UI और API में कुछ operations भिन्न हो सकते हैं

पूरी सूची के लिए Beta limitations देखें.

आप क्या प्रबंधित कर सकते हैं

Organizations क्रियाओं को चार workflow क्षेत्रों में समूहित करता है. प्रत्येक workflow की अपनी permissions और policy सेटिंग होती हैं.

वर्कफ़्लो

यह क्या नियंत्रित करता है

निकासी शुरू करना

कौन फ़िएट और क्रिप्टो निकासी का अनुरोध कर सकता है, उसे अनुमोदित कर सकता है और पूरा कर सकता है

Manage Addresses

कौन व्हाइटलिस्टेड निकासी पते जोड़ या हटा सकता है

Manage Access

कौन Members को आमंत्रित कर सकता है, Service Users प्रबंधित कर सकता है और अनुमतियां बदल सकता है

Manage Policies

कौन अनुमोदन नियम बदल सकता है और गवर्नेंस सेटिंग्स लॉक कर सकता है

पूर्ण संदर्भ के लिए Permissions and workflows देखें.

शुरू कर रहा है

अपना Organization सेट अप करने के लिए तैयार हैं? पूरी सेटअप प्रक्रिया और पहले चरणों के लिए Create an Organization देखें — जिसमें Members को आमंत्रित करना, अनुमतियां असाइन करना, अनुमोदन नीतियां कॉन्फ़िगर करना और तैयार होने पर गवर्नेंस लॉक करना शामिल है.

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

नहीं. Organization Owner वह अकाउंट होल्डर होता है जिसने Organization बनाया है. Ownership सेल्फ-सर्विस से ट्रांसफ़र नहीं की जा सकती.

नहीं. Organization बनाना सेल्फ-सर्विस द्वारा पूर्ववत नहीं किया जा सकता. माइग्रेशन विकल्पों पर चर्चा के लिए सहायता से संपर्क करें.

Owner का अकाउंट तक पूरा एक्सेस बना रहता है. कोई भी मौजूदा कार्यक्षमता नहीं हटाई जाती. Members को केवल उन्हीं कार्यों का एक्सेस मिलता है जिनके लिए उन्हें स्पष्ट रूप से अनुमतियां दी गई हैं.

फ़िलहाल, हर Member एक ही Organization का हिस्सा होता है. भविष्य के रिलीज़ में, Organizations एक ही ढांचे में कई बिज़नेस entities को सपोर्ट करेगा, जिससे Members एक ही Organization के भीतर अलग-अलग entities में operations कर सकेंगे.

Service Users API के माध्यम से निकासी अनुरोध शुरू कर सकते हैं. जब कोई Organization नीति Initiate Withdrawal workflow को नियंत्रित करती है, तो अनुरोध प्रभावी होने से पहले मानव Members की मंज़ूरी ज़रूरी होती है. Service Users अपनी API key अनुमतियों के आधार पर ट्रेड कर सकते हैं और Earn उत्पाद भी प्रबंधित कर सकते हैं. Service Users देखें.

क्या आपको और मदद चाहिए?