Om Organizations

Du trenger en KYB-verifisert bedrifts-Kraken-konto for å opprette en Organization. Personlige Kraken-kontoer er ikke kvalifiserte.

Kun kontoinnehaveren som har fullført bedriftsverifisering kan opprette en Organization. Etter opprettelsen blir denne personen Organization Owner.

Du kan ikke angre opprettelsen av en Organization via selvbetjening. Etter at en Organization er opprettet, krever reversering manuell støtte.

Merk: Organizations er for øyeblikket i Beta. Enkelte funksjoner kan ha begrensninger. Se Beta limitations for detaljer.

Organizations lar institusjonelle klienter administrere teamtilgang og kreve godkjenning for sensitive handlinger på tvers av delte kontoer.

• Inviter teammedlemmer til din Organization
• Tildel tillatelser per arbeidsflyt og konto
• Krev godkjenning for sensitive handlinger som uttak, adresseendringer og tillatelsesoppdateringer
• Anvend delte sikkerhetskontroller som 2FA og tidsavbrudd for økt
• Innføre styring trinnvis – start raskt, stram inn senere

Organization Owner — Kontoinnehaveren som opprettet Organization. Eieren starter med fulle administrative tillatelser og er ansvarlig for å sette opp tilgang og styring for teamet. Det finnes ingen medeierrolle.

Member — En person invitert til Organization med spesifikke tillatelser. Members logger på med sine egne Kraken-legitimasjoner og må overholde Organization Sign-in 2FA-policyen.

Service User — En API-only operator opprettet innenfor Organization. Service Users autentiserer med API key credentials og kan starte forespørsler, men kan ikke godkjenne dem eller logge på UI. Se Service Users for detaljer.

Organization — Toppnivåbeholderen som grupperer Members, kontoer og styring under en enkelt struktur.

Konto — En enhet med segregerte balanser som brukes for handel og finansiering. Tillatelser gis per konto – tilgang til én konto overføres ikke til en annen. Multi-account trading er planlagt for en fremtidig utgivelse.

Tillatelse — En tildeling som definerer hva en Member eller Service User kan gjøre. Tillatelser er additive: brukere starter uten tilgang og må tildeles hver tillatelse individuelt. Se Permissions and workflows for full referanse.

Workflow — En gruppe relaterte operasjoner som deler samme tillatelsesmodell og policykonfigurasjon. Organizations har fire workflows: Initiate Withdrawal, Manage Addresses, Manage Access og Manage Policies.

Operasjon — En spesifikk handling innenfor en workflow. For eksempel er «Create a crypto withdrawal» en operasjon i Initiate Withdrawal workflowen.

Policy — Styringskonfigurasjonen for en workflow. En policy definerer hvor mange godkjenninger som kreves og om handlinger kan fullføres umiddelbart av en delmengde av brukere. Se Policies, approvals, and governance for detaljer.

Forespørsel — En arbeidsenhet opprettet når en Member eller Service User initierer en handling på en styrt workflow. Forespørsler enten fullføres umiddelbart (når tillatt av policyen) eller plasseres i godkjenningskøen for gjennomgang.

Execute — En tillatelse som tillater en Member å fullføre handlinger uten å vente på godkjenning, når workflow-policyen tillater det. Når «Always require approval» er PÅ, har Execute ingen effekt.

Policy lock — En styringskontroll som forhindrer at en enkelt person endrer en workflows policy. Fremtidige endringer krever en uavhengig godkjenning og avhenger av at godkjennerdekningen forblir tilgjengelig.

Separation of duties — Regelen om at en Member ikke kan godkjenne sin egen forespørsel. Håndheves av systemet og kan ikke overstyres.

• Medlemmer kan ikke godkjenne sine egne forespørsler. Dette håndheves av systemet og kan ikke overstyres.
• Tillatelser er additive. Medlemmer starter uten tilgang og må tildeles hver tillatelse individuelt.
• Om en handling fullføres umiddelbart eller krever godkjenning, avhenger av både medlemmets tillatelser og arbeidsflytens retningslinjer. Se Tillatelser og arbeidsflyter.
• Låste retningslinjer kan ikke endres uten uavhengig godkjenning – inkludert av Eieren.
• 2FA for organisasjonspålogging er påkrevd. Retningslinjene settes ved opprettelse og gjelder for alle nåværende og fremtidige medlemmer.
• Inaktive sesjoner utløper og krever ny autentisering.

Organisasjoner er for tiden i Beta. Viktige begrensninger:

• Kun enkeltkontomodus er tilgjengelig – handel med flere kontoer støttes ennå ikke
• Noen plattformoperasjoner forblir kun for Eier (Futures, OTC, Convert, Custody)
• Klientrettede revisjonslogger er ennå ikke tilgjengelig
• Egendefinerte roller kan ikke lagres og gjenbrukes
• E-postbekreftelse for umiddelbare adresseendringer sendes til Eier, ikke forespørselens oppretter
• Noen operasjoner kan avvike mellom UI og API under Beta

Se Beta-begrensninger for hele listen.

Organisasjoner grupperer handlinger i fire arbeidsflytområder. Hver arbeidsflyt har sine egne tillatelser og retningslinjer.

Klar til å sette opp din organisasjon? Se Opprett en organisasjon for fullstendig veiledning for opprettelse og første skritt – inkludert hvordan du inviterer medlemmer, tildeler tillatelser, konfigurerer godkjenningsretningslinjer og låser styringen når du er klar.