Organizations के लिए Beta सीमाएं

Organizations Beta इंस्टीट्यूशनल क्लाइंट को उनके Kraken अकाउंट के लिए एक पूर्ण गवर्नेंस लेयर प्रदान करता है.

Beta में क्या शामिल है

Beta के दौरान आप यह कर सकते हैं:

एक Organization बनाएं और टीम के सदस्यों को आमंत्रित करें
ट्रेडिंग, फ़ंडिंग और प्रशासन के लिए अनुमतियां असाइन करें
प्रत्येक वर्कफ़्लो के लिए अप्रूवल पॉलिसी कॉन्फ़िगर करें
निकासी, एड्रेस बदलाव, एक्सेस बदलाव और पॉलिसी बदलाव के लिए मल्टी-पार्टी अप्रूवल अनिवार्य करें
एकतरफा बदलाव रोकने के लिए पॉलिसी लॉक करें
प्रोग्रामेटिक API एक्सेस के लिए Service Users बनाएं
Organization साइन-इन 2FA और सेशन टाइमआउट पॉलिसी लागू करें

वर्तमान सीमाएं

निम्नलिखित सीमाएं Beta के दौरान लागू होती हैं और भविष्य के रिलीज़ में बदली जाएंगी.

सिंगल-अकाउंट मॉडल

आपकी Organization Owner के प्राथमिक अकाउंट पर काम करती है. मल्टी-अकाउंट ट्रेडिंग — जिसमें Members अलग-अलग सब-अकाउंट पर स्वतंत्र बैलेंस के साथ काम करते हैं — अभी उपलब्ध नहीं है.

इसका मतलब: ट्रेडिंग अनुमति वाले सभी Members एक ही अकाउंट पर ट्रेड करते हैं और एक ही बैलेंस और पोज़िशन साझा करते हैं.

सीमित अनुमति दायरा

Members केवल वे ऑपरेशन कर सकते हैं जिनके लिए प्लेटफ़ॉर्म में कोई निर्धारित Organization अनुमति मौजूद है. उपलब्ध अनुमतियां निम्नलिखित हैं

ट्रेड (स्पॉट और मार्जिन)
Earn आवंटन / आवंटन कैंसल
निकासी अनुरोध
पते प्रबंधित करें
एक्सेस प्रबंधित करें
नीतियां प्रबंधित करें

केवल Owner के लिए ऑपरेशन

ऊपर सूचीबद्ध नहीं किए गए ऑपरेशन केवल Organization Owner के लिए आरक्षित हैं. इसमें शामिल हैं:

फ़्यूचर्स ट्रेडिंग
OTC ट्रेडिंग
कन्वर्ट करें
कस्टडी सेटलमेंट
कोई भी प्लेटफ़ॉर्म ऑपरेशन जिसके लिए कोई Organization अनुमति नहीं है

Owner इन्हें उसी तरह करते हैं जैसे Organization बनाने से पहले करते थे. Beta के दौरान अन्य Members इन ऑपरेशन को एक्सेस नहीं कर सकते.

क्लाइंट ऑडिट लॉग उपलब्ध नहीं

Beta के दौरान Member गतिविधि के लिए सुरक्षा इवेंट और ऑडिट लॉग उपलब्ध नहीं हैं. सेल्फ-सर्विस ऑडिट डैशबोर्ड की योजना है लेकिन यह अभी उपलब्ध नहीं है.

कस्टम रोल सेव नहीं किए जा सकते

आप रोल असाइन करते समय कस्टम अनुमति कॉन्फ़िगरेशन बना सकते हैं, लेकिन किसी कस्टम रोल को दोबारा उपयोग के लिए टेम्पलेट के रूप में सेव नहीं किया जा सकता. हर बार जब आप कोई कस्टम रोल असाइन करते हैं, तो आपको उसे शुरू से कॉन्फ़िगर करना होता है.

ईमेल कन्फ़र्मेशन Owner को भेजी जाती है

जब कोई Member पते में बदलाव तुरंत पूरा करने के लिए Execute का उपयोग करता है, तो सिस्टम ईमेल कन्फ़र्मेशन आवश्यक करता है. Beta के दौरान यह कन्फ़र्मेशन हमेशा Organization Owner को भेजी जाती है, न कि बदलाव शुरू करने वाले Member को. अनुरोध निर्माता को सीधे कन्फ़र्मेशन भेजने की सुविधा भविष्य के रिलीज़ में शामिल करने की योजना है.

कोई सार्वजनिक Organizations मैनेजमेंट API नहीं

Beta के दौरान, सदस्य आमंत्रण, अनुमति प्रबंधन, पॉलिसी कॉन्फ़िगरेशन या पॉलिसी लॉकिंग के लिए कोई सार्वजनिक Organizations मैनेजमेंट API उपलब्ध नहीं है. प्रोग्रामेटिक एक्सेस केवल उन Service Users तक सीमित है जो सपोर्टेड फ्लो पर API key अनुमतियों के ज़रिए काम करते हैं.

ज्ञात अंतर:

सदस्य आमंत्रण और अनुमति प्रबंधन — केवल UI में उपलब्ध
पॉलिसी कॉन्फ़िगरेशन और लॉकिंग — केवल UI में उपलब्ध
निकासी अनुरोध — Service Users / API keys के माध्यम से उपलब्ध; जब कोई Organization पॉलिसी कॉन्फ़िगर की जाती है तो अनुरोध अप्रूवल कतार में चला जाता है
Service Users के माध्यम से ट्रेडिंग और Earn ऑपरेशन — केवल API keys के माध्यम से उपलब्ध (Service Users UI एक्सेस नहीं कर सकते)

सपोर्टेड API key ऑपरेशन की नवीनतम जानकारी के लिए Kraken API दस्तावेज़ देखें.

अगर आपको जिस ऑपरेशन की ज़रूरत है वह अभी आपके पसंदीदा चैनल पर उपलब्ध नहीं है तो दूसरा चैनल देखें या मार्गदर्शन के लिए सहायता से संपर्क करें.

निकासी API रिस्पॉन्स शेप में बदलाव

जब कोई अकाउंट किसी Organization में नामांकित होता है तो withdrawFunds EAPI रिस्पॉन्स का स्ट्रक्चर बदल जाता है. नामांकन से पहले स्टैंडर्ड स्ट्रक्चर को पार्स करने वाले इंटीग्रेशन में कोड अपडेट की आवश्यकता है.

यह केवल एक्सटेंडेड डोमेन में Organization उपयोगकर्ताओं पर लागू होता है. गैर-Organization अकाउंट में कोई बदलाव नहीं होता.

स्टैंडर्ड रिस्पॉन्स:

<code>{
 "error": [],
 "result": {
  "refid": "FTRqeuR-9Is99qcv54n0Y0535oPXxb"
 }
}</code>

Organization रिस्पॉन्स:

<code>{
 "error": [],
 "result": {
  "refid": "FTcLNGa-4ZWmo4GCo8wrBNZz5v53v9",
  "approval_request_id": "656a021a-1d55-42c9-853a-aea57bf5abd1"
 }
}</code>

व्यवहार:

refid अनुरोध बनाने पर अभी भी वापस किया जाता है और निकासी की पहचान करता रहता है.
approval_request_id जोड़ा गया है और उस अप्रूवल अनुरोध की पहचान करता है जो इस निकासी को नियंत्रित करता है.
निकासी केवल अप्रूवल अनुरोध स्वीकृत होने के बाद ही पूरी होती है. अस्वीकृत या एक्सपायर्ड अप्रूवल अनुरोधों से refid के विरुद्ध निकासी पूर्ण नहीं होती.

नामांकन से पहले अनुशंसित कार्रवाई:

withdrawFunds रिस्पॉन्स को पार्स करने वाले कोड को ऑडिट करें.
अतिरिक्त approval_request_id फ़ील्ड को स्वीकार करने और completion को approval-gated के रूप में हैंडल करने के लिए parsing अपडेट करें.