Om Organizations

Du skal have en KYB-verified corporate Kraken account for at oprette en Organization. Personlige Kraken-konti er ikke berettigede.

Kun kontohaveren, der har gennemført virksomhedsverificering, kan oprette en Organization. Efter oprettelsen bliver denne person Organization Owner.

Du kan ikke fortryde oprettelsen af en Organization via selvbetjening. Når en Organization er oprettet, kræver annullering manuel support.

Bemærk: Organizations er i øjeblikket i Beta. Nogle funktioner kan have begrænsninger. Se Beta limitations for yderligere oplysninger.

Organizations giver institutionelle kunder mulighed for at administrere teamadgang og kræve godkendelser for følsomme handlinger på tværs af delte konti.

• Inviter teammedlemmer til din Organization
• Tildel tilladelser efter workflow og konto
• Kræv godkendelser for følsomme handlinger som udbetalinger, adresseændringer og opdateringer af tilladelser
• Anvend fælles sikkerhedskontroller som 2FA og sessionstimeout
• Indfør styring trinvist — start hurtigt, stram op senere

Organization Owner — Kontohaveren, der oprettede Organizationen. Ejeren starter med fulde administrative tilladelser og er ansvarlig for at opsætte adgang og styring for teamet. Der er ingen rolle som medejer.

Member — En person, der er inviteret til Organizationen med specifikke tilladelser. Medlemmer logger ind med deres egne Kraken-legitimationsoplysninger og skal overholde Organization Sign-in 2FA policy.

Service User — En API-only operator oprettet inden for Organizationen. Service Users godkender med API key credentials og kan igangsætte anmodninger, men kan ikke godkende dem eller logge ind på UI'et. Se Service Users for yderligere oplysninger.

Organization — Containeren på øverste niveau, der grupperer Members, konti og styring under en enkelt struktur.

Account — En enhed med adskilte saldi, der bruges til handel og finansiering. Tilladelser tildeles pr. konto — adgang til én konto overføres ikke til en anden. Multi-konto handel er planlagt til en fremtidig udgivelse.

Permission — En tilladelse, der definerer, hvad en Member eller Service User kan gøre. Permissions er additive: brugere starter uden adgang og skal tildeles hver tilladelse individuelt. Se Permissions and workflows for den fulde reference.

Workflow — En gruppe af relaterede operationer, der deler den samme tilladelsesmodel og policy-konfiguration. Organizations har fire workflows: Initiate Withdrawal, Manage Addresses, Manage Access, og Manage Policies.

Operation — En specifik handling inden for et workflow. For eksempel: „Create a crypto withdrawal“ er en operation i Initiate Withdrawal workflowet.

Policy — Styringskonfigurationen for et workflow. En policy definerer, hvor mange godkendelser der er påkrævet, og hvorvidt handlinger kan udføres med det samme af en delmængde af brugere. Se Policies, approvals, and governance for yderligere oplysninger.

Request — En arbejdsenhed, der oprettes, når en Member eller Service User igangsætter en handling på et styret workflow. Requests færdiggøres enten med det samme (når policy'en tillader det) eller placeres i godkendelseskøen til gennemgang.

Execute — En tilladelse, der giver en Member mulighed for at udføre handlinger uden at vente på godkendelse, når workflow-policy'en tillader det. Når „Always require approval“ er SLÅET TIL, har Execute ingen effekt.

Policy lock — En styringskontrol, der forhindrer enhver enkeltperson i at ændre et workflows policy. Fremtidige ændringer kræver en uafhængig godkendelse og afhænger af, at der fortsat er godkendere til rådighed.

Separation of duties — Reglen om, at en Member ikke kan godkende sin egen anmodning. Håndhæves af systemet og kan ikke tilsidesættes.

• Medlemmer kan ikke godkende deres egne anmodninger. Håndhæves af systemet og kan ikke tilsidesættes.
• Tilladelser er additive. Medlemmer starter uden adgang og skal tildeles hver tilladelse individuelt.
• Hvorvidt en handling udføres med det samme eller kræver godkendelse, afhænger af både medlemmets tilladelser og workflowets politik. Se Tilladelser og workflows.
• Låste politikker kan ikke ændres uden uafhængig godkendelse – heller ikke af ejeren.
• Organization Sign-in 2FA er påkrævet. Politikken fastsættes ved oprettelsen og gælder for alle nuværende og fremtidige medlemmer.
• Inaktive sessioner udløber og kræver genautentificering.

Organizations er i øjeblikket i Beta. Vigtigste begrænsninger:

• Kun enkeltkontotilstand er tilgængelig – handel med flere konti understøttes endnu ikke
• Nogle platformshandlinger forbliver kun for ejeren (Futures, OTC, Convert, Custody)
• Klientrettede revisionslogfiler er endnu ikke tilgængelige
• Brugerdefinerede roller kan ikke gemmes og genbruges
• E-mailbekræftelse for øjeblikkelige adresseændringer sendes til ejeren, ikke anmodningsopretteren
• Nogle handlinger kan afvige mellem UI og API under Beta

Se Beta-begrænsninger for den fulde liste.

Organizations grupperer handlinger i fire workflowområder. Hvert workflow har sine egne tilladelser og politikindstillinger.

Klar til at oprette din Organization? Se Create an Organization for den fulde gennemgang af oprettelse og de første trin – herunder hvordan du inviterer Members, tildeler permissions, konfigurerer godkendelsespolitikker og låser styring, når du er klar.