Beta-Einschränkungen für Organisationen

Während der Beta-Phase können Sie:

• Eine Organisation erstellen und Teammitglieder einladen
• Berechtigungen für Handel, Finanzierung und Verwaltung zuweisen
• Genehmigungsrichtlinien pro Workflow konfigurieren
• Eine Mehrparteien-Genehmigung für Abhebungen, Adressänderungen, Zugriffsänderungen und Richtlinienänderungen anfordern
• Richtlinien sperren, um einseitige Änderungen zu verhindern
• Service-Benutzer für den programmatischen API-Zugriff erstellen
• Organisations-Anmeldung 2FA und Sitzungs-Timeout-Richtlinien durchsetzen

Die folgenden Einschränkungen gelten während der Beta-Phase und werden voraussichtlich in zukünftigen Versionen geändert.

Ihre Organisation operiert auf dem primären Konto des Eigentümers. Multi-Konto-Handel – bei dem Mitglieder über separate Unterkonten mit unabhängigen Salden agieren – ist noch nicht verfügbar.

Was das bedeutet: Alle Mitglieder mit Handelsberechtigungen handeln auf demselben Konto und teilen sich dieselben Salden und Positionen.

Mitglieder können Operationen nur dort durchführen, wo die Plattform eine definierte Organisationsberechtigung besitzt. Die verfügbaren Berechtigungen sind:

• Handel (Spot und Margin)
• Earn Zuweisung / Rücknahme
• Abhebung initiieren
• Adressen verwalten
• Zugriff verwalten
• Richtlinien verwalten

Nicht oben aufgeführte Operationen bleiben dem Organisationseigentümer vorbehalten. Dies umfasst:

• Futures-Handel
• OTC-Handel
• Konvertieren
• Custody-Abwicklungen
• Jede Plattform-Operation ohne entsprechende Organisationsberechtigung

Der Eigentümer führt diese mit denselben Abläufen durch wie vor der Erstellung der Organisation. Andere Mitglieder können während der Beta-Phase nicht auf diese Operationen zugreifen.

Sicherheitsereignisse und Audit-Logs für Mitgliederaktivitäten sind während der Beta-Phase nicht verfügbar. Ein Self-Service-Audit-Dashboard ist geplant, aber noch nicht verfügbar.

Sie können benutzerdefinierte Berechtigungskonfigurationen beim Zuweisen von Rollen erstellen, aber Sie können eine benutzerdefinierte Rolle nicht als wiederverwendbare Vorlage speichern. Jedes Mal, wenn Sie eine benutzerdefinierte Rolle zuweisen, konfigurieren Sie diese von Grund auf neu.

Wenn ein Mitglied „Ausführen“ verwendet, um eine Adressänderung sofort abzuschließen, erfordert das System eine E-Mail-Bestätigung. Während der Beta-Phase wird diese Bestätigung immer an den Organisationseigentümer gesendet, nicht an das Mitglied, das die Änderung initiiert hat. Das direkte Senden der Bestätigung an den Anforderer ist für eine zukünftige Version geplant.

Während der Beta-Phase gibt es keine öffentliche Verwaltungs-API für Organisationen für Mitgliedereinladungen, Berechtigungsverwaltung, Richtlinienkonfiguration oder Richtliniensperrung. Der programmatische Zugriff ist auf Service Users beschränkt, die über API-Key-Berechtigungen in unterstützten Abläufen agieren.

Bekannte Unterschiede:

• Mitgliedereinladung und Berechtigungsverwaltung — nur in der Benutzeroberfläche verfügbar
• Richtlinienkonfiguration und -sperrung — nur in der Benutzeroberfläche verfügbar
• Auszahlungsanfragen — über Service Users / API Keys verfügbar; wenn eine Organisationsrichtlinie konfiguriert ist, gelangt die Anfrage in die Genehmigungswarteschlange
• Trading- und Earn-Operationen über Service Users — nur über API Keys verfügbar (Service Users können nicht auf die Benutzeroberfläche zugreifen)

Aktuelle Informationen zu unterstützten API-Key-Operationen finden Sie in der Kraken API-Dokumentation.

Wenn ein Konto in einer Organisation angemeldet wird, ändert sich die Antwortstruktur der withdrawFunds EAPI. Integrationen, die die Standardstruktur parsen, benötigen vor der Anmeldung Code-Updates.

Gilt nur für Organisationsbenutzer in der erweiterten Domäne. Nicht-Organisationskonten bleiben unverändert.

Standardantwort:

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

Organisationsantwort:

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

Verhalten:

• refid wird weiterhin bei der Anfragenerstellung zurückgegeben und identifiziert die Auszahlung.
• approval_request_id wird hinzugefügt und identifiziert die Genehmigungsanfrage, die diese Auszahlung steuert.
• Die Auszahlung wird erst abgeschlossen, nachdem die Genehmigungsanfrage genehmigt wurde. Abgelehnte oder abgelaufene Genehmigungsanfragen führen nicht zu einer abgeschlossenen Auszahlung mit der refid.

Empfohlene Aktion vor der Anmeldung:

• Prüfen Sie den Code, der withdrawFunds-Antworten parst.
• Aktualisieren Sie das Parsing, um das zusätzliche Feld approval_request_id zu akzeptieren und den Abschluss als genehmigungsgesteuert zu behandeln.

Das Organisationen-Team arbeitet aktiv daran, den Funktionsumfang über die Beta-Phase hinaus zu erweitern. Zu den in Entwicklung befindlichen Bereichen gehören:

• Multi-Konto-Support mit getrennten Salden
• Erweiterte Berechtigungsabdeckung für zusätzliche Plattformoperationen
• Client-seitige Audit-Logs und Aktivitäts-Dashboard
• Wiederverwendbare benutzerdefinierte Rollenvorlagen

Spezifische Zeitpläne und Verfügbarkeit werden über die offiziellen Kraken-Kanäle kommuniziert.