Présentation des Organizations

Avant de commencer

Vous devez disposer d'un compte Kraken d'entreprise vérifié KYB pour créer une Organization. Les comptes Kraken personnels ne sont pas éligibles.

Seul le détenteur du compte ayant effectué la vérification d'entreprise peut créer une Organization. Une fois la création effectuée, cette personne devient l'Organization Owner.

La création d'une Organization ne peut pas être annulée en libre-service. Une fois une Organization créée, toute annulation nécessite l'intervention du support.

Remarque : Organizations est actuellement en version bêta. Certaines fonctionnalités peuvent présenter des limitations. Consultez Limitations de la version bêta pour plus de détails.

Organizations en bref

Organizations permet aux clients institutionnels de gérer les accès de leur équipe et d'exiger des approbations pour les actions sensibles sur les comptes partagés.

  • Invitez des membres de votre équipe dans votre Organization
  • Attribuez des permissions par workflow et par compte
  • Exigez des approbations pour les actions sensibles telles que les retraits, les modifications d'adresse et les mises à jour de permissions
  • Appliquez des contrôles de sécurité partagés tels que la 2FA et l'expiration de session
  • Introduisez la gouvernance progressivement : démarrez vite, renforcez-la ensuite

Rôles clés

Organization Owner – Le détenteur du compte qui a créé l'Organization. L'Owner dispose d'emblée de toutes les permissions administratives et est responsable de la configuration des accès et de la gouvernance pour l'équipe. Il n'existe pas de rôle de co-propriétaire.

Member – Une personne invitée dans l'Organization avec des permissions spécifiques. Les Members se connectent avec leurs propres identifiants Kraken et doivent respecter la politique de connexion 2FA de l'Organization.

Service User – Un opérateur exclusivement API, créé au sein de l'Organization. Les Service Users s'authentifient via des identifiants de clé API et peuvent initier des demandes, mais ne peuvent pas les approuver ni se connecter à l'interface. Consultez Service Users pour plus de détails.

Termes clés

Organization – Le conteneur de niveau supérieur qui regroupe les membres, les comptes et la gouvernance au sein d'une structure unique.

Account – Une unité dotée de soldes ségrégués, utilisée pour le trading et le financement. Les permissions sont accordées par compte : l'accès à un compte ne s'étend pas aux autres. Le trading multi-comptes est prévu pour une version ultérieure.

Permission – Un droit qui définit ce qu'un membre ou un Service User peut effectuer. Les permissions sont additives : les utilisateurs démarrent sans aucun accès et chaque permission doit leur être accordée individuellement. Consultez Permissions and workflows pour la référence complète.

Workflow – Un groupe d'opérations liées partageant le même modèle d'autorisation et la même configuration de politique. Organizations comprend quatre workflows : Initiate Withdrawal, Manage Addresses, Manage Access et Manage Policies.

Operation – Une action spécifique au sein d'un workflow. Par exemple, "Create a crypto withdrawal" est une opération du workflow Initiate Withdrawal.

Policy – La configuration de gouvernance d'un workflow. Une politique définit le nombre d'approbations requises et selon que certaines actions peuvent être exécutées immédiatement par un sous-ensemble d'utilisateurs. Consultez Policies, approvals, and governance pour plus de détails.

Request – Une unité de travail créée lorsqu'un membre ou un Service User initie une action sur un workflow soumis à gouvernance. Les demandes sont soit exécutées immédiatement (si la politique le permet), soit placées dans la file d'approbation pour examen.

Execute – Une permission permettant à un membre d'effectuer des actions sans attendre d'approbation, lorsque la politique du workflow le permet. Lorsque "Always require approval" est activé, Execute n'a aucun effet.

Policy lock – Un contrôle de gouvernance qui interdit à quiconque de modifier seul la politique d'un workflow. Toute modification ultérieure requiert une approbation indépendante et dépend du maintien d'un nombre suffisant d'approbateurs disponibles.

Separation of duties – La règle selon laquelle un membre ne peut pas approuver sa propre demande. Appliquée par le système et non contournable.

Règles clés et contrôles de sécurité

  • Les membres ne peuvent pas approuver leurs propres demandes. Appliquée par le système et non contournable.
  • Les permissions sont additives. Les membres n'ont aucun accès par défaut ; chaque permission doit être accordée individuellement.
  • L'exécution immédiate ou l'obligation d'approbation d'une action dépend à la fois des permissions du membre et de la politique du workflow. Voir Permissions and workflows.
  • Les politiques verrouillées ne peuvent pas être modifiées sans approbation indépendante, même par le propriétaire.
  • La connexion 2FA de l'Organization est obligatoire. La politique est définie à la création et s'applique à tous les membres, actuels et futurs.
  • Les sessions inactives expirent et nécessitent une nouvelle authentification.

Récapitulatif des limitations bêta

Organizations est actuellement en version bêta. Principales limitations :

  • Seul le mode mono-compte est disponible – le trading multi-comptes n'est pas encore pris en charge
  • Certaines opérations de la plateforme restent réservées au propriétaire (contrats à terme, OTC, convertir, garde)
  • Les journaux d'audit destinés aux clients ne sont pas encore disponibles
  • Les rôles personnalisés ne peuvent pas être enregistrés ni réutilisés
  • La confirmation par email des modifications d'adresse à effet immédiat est envoyée au propriétaire, et non au créateur de la demande.
  • Certaines opérations peuvent différer entre l'interface et l'API durant la période bêta

Voir Beta limitations pour la liste complète.

Actions disponibles

Organizations regroupe les actions en quatre workflows. Chaque workflow dispose de ses propres permissions et configuration de politique.

Workflow

Ce qu'il contrôle

Initiate Withdrawal

Qui peut initier, approuver et effectuer des retraits en monnaie fiduciaire et en crypto-monnaies

Manage Addresses

Qui peut ajouter ou supprimer des destinations de retrait sur liste blanche

Manage Access

Qui peut inviter des Members, gérer les Service Users et modifier les permissions

Manage Policies

Qui peut modifier les règles d'approbation et verrouiller les paramètres de gouvernance

Consultez Permissions and workflows pour la référence complète.

Bien commencer

Prêt à configurer votre Organization ? Consultez Create an Organization pour le guide de création complet et les premières étapes – notamment comment inviter des Members, attribuer des permissions, configurer les politiques d'approbation et verrouiller la gouvernance le moment venu.

Foire aux questions

Non. L'Organization Owner est le détenteur du compte qui a créé l'Organization. Le transfert de propriété n'est pas possible en libre-service.

Non. La création d'une Organization n'est pas réversible en libre-service. Contactez le support si vous souhaitez discuter des options de migration.

L'Owner conserve un accès complet au compte. Aucune fonctionnalité existante n'est supprimée. Les Members n'ont accès qu'aux actions pour lesquelles des permissions leur ont été explicitement accordées.

Actuellement, chaque Member appartient à une seule Organization. Dans une prochaine version, Organizations prendra en charge plusieurs entités au sein d'une même structure, permettant aux Members d'effectuer des opérations entre entités de la même Organization.

Les Service Users peuvent soumettre des demandes de retrait via l'API. Lorsqu'une politique de l'Organization régit le workflow Initiate Withdrawal, la demande doit être approuvée par des Members humains avant de prendre effet. Les Service Users peuvent également trader et gérer des produits Gains selon les autorisations de leur clé API. Consultez Service Users.

Besoin d'aide supplémentaire ?