Organizations Beta की सीमाएं

Organizations फ़िलहाल बीटा में है और हो सकता है कि यह आपके बिज़नेस अकाउंट के लिए अभी उपलब्ध न हो.

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

बीटा में क्या शामिल है

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

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

मौजूदा सीमाएं

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

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

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

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

सीमित पर्मिशन स्कोप

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

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

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

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

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

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

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

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

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

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

Owner को ईमेल कन्फ़र्मेशन

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

कोई पब्लिक Organizations मैनेजमेंट API नहीं

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

ज्ञात अंतर:

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

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

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

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

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

यह केवल एक्सटेंडेड डोमेन के Organization क्लायंट्स पर लागू होता है. Non-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 फ़ील्ड स्वीकार हो और कम्पलीशन को अप्रूवल-गेटेड माना जाए.