Про Organizations

Перш ніж почати

Для створення Organization потрібен корпоративний обліковий запис Kraken із верифікацією KYB. Особисті облікові записи Kraken не відповідають вимогам.

Створити Organization може лише власник облікового запису, який пройшов бізнес-верифікацію. Після створення ця особа стає Organization Owner.

Скасувати створення Organization у режимі самообслуговування неможливо. Після створення Organization її скасування можливе лише через службу підтримки.

Примітка. Organizations наразі працює в режимі бета-тестування. Деякі можливості можуть мати обмеження. Детальніше — у розділі Обмеження бета-версії.

Organizations: короткий огляд

Organizations дає змогу інституційним клієнтам керувати доступом команди та вимагати погодження для критичних операцій у спільних облікових записах.

  • Запрошуйте членів команди до своєї Organization
  • Призначайте дозволи за робочим процесом і обліковим записом
  • Вимагайте погодження для критичних операцій: виведення, зміни адрес і оновлення дозволів
  • Застосовуйте спільні засоби безпеки: 2FA та тайм-аут сесії
  • Запроваджуйте управління поступово — починайте швидко, посилюйте згодом

Ключові ролі

Organization Owner — власник облікового запису, який створив Organization. Owner має повні адміністративні дозволи від початку та відповідає за налаштування доступу й управління для команди. Ролі співвласника не передбачено.

Member — особа, запрошена до Organization із певними дозволами. Members входять за власними обліковими даними Kraken і зобовʼязані дотримуватися політики 2FA для входу в Organization.

Service User — оператор, що працює виключно через API, створений у межах Organization. Service Users автентифікуються за допомогою API-ключа, можуть ініціювати запити, але не можуть їх схвалювати або входити через інтерфейс. Детальніше див. у розділі Service Users.

Ключові терміни

Organization — контейнер верхнього рівня, що обʼєднує учасників, облікові записи та управління в єдину структуру.

Account — одиниця з відокремленими балансами, що використовується для торгівлі та поповнення рахунку. Дозволи надаються окремо для кожного облікового запису — доступ до одного облікового запису не поширюється на інший. Торгівля з кількома обліковими записами буде доступна у майбутньому релізі.

Permission — дозвіл, що визначає, які дії може виконувати учасник або Service User. Дозволи є накопичувальними: за замовчуванням у користувачів немає жодного доступу — кожен дозвіл надається окремо. Повний довідник див. у розділі Permissions and workflows.

Workflow — група повʼязаних операцій зі спільною моделлю дозволів та конфігурацією політики. Organizations має чотири workflow: Initiate Withdrawal, Manage Addresses, Manage Access та Manage Policies.

Operation — конкретна дія в межах workflow. Наприклад, «Create a crypto withdrawal» — це операція у workflow Initiate Withdrawal.

Policy — конфігурація управління для workflow. Політика визначає, скільки затверджень потрібно та чи можуть певні користувачі виконувати дії негайно. Детальніше див. у розділі Policies, approvals, and governance.

Request — одиниця роботи, що створюється, коли учасник або Service User ініціює дію в межах керованого workflow. Запити або виконуються негайно (якщо це дозволено політикою), або потрапляють до черги на затвердження.

Execute — дозвіл, що дає учаснику змогу виконувати дії без очікування затвердження, якщо це дозволено політикою workflow. Якщо увімкнено «Always require approval», Execute не діє.

Policy lock — засіб управління, що не дає жодній окремій особі змінити політику workflow. Подальші зміни потребують незалежного затвердження та залежать від наявності достатньої кількості затверджувачів.

Separation of duties — правило, згідно з яким учасник не може затверджувати власний запит. Контролюється системою та не підлягає скасуванню.

Ключові правила та засоби контролю безпеки

  • Учасники не можуть схвалювати власні запити. Контролюється системою та не підлягає скасуванню.
  • Дозволи є адитивними. Учасники починають без жодного доступу — кожен дозвіл надається окремо.
  • Чи виконується дія негайно, чи потребує схвалення — залежить як від дозволів Учасника, так і від політики робочого процесу. Див. Дозволи та робочі процеси.
  • Заблоковані політики не можна змінити без незалежного схвалення — включно з Власником.
  • 2FA для входу в Organization є обовʼязковою. Політика встановлюється під час створення та поширюється на всіх поточних і майбутніх Учасників.
  • Неактивні сесії завершуються та потребують повторної автентифікації.

Зведення обмежень Beta

Organizations наразі працює в режимі бета-тестування. Ключові обмеження:

  • Доступний лише режим одного облікового запису — торгівля з кількома обліковими записами поки що не підтримується
  • Деякі операції на платформі доступні лише Власнику (ф'ючерси, OTC, конвертація, кастодіальне зберігання)
  • Журнали аудиту для клієнтів поки що недоступні
  • Користувацькі ролі не можна зберігати та повторно використовувати
  • Підтвердження електронною поштою для негайних змін адреси надсилається Власнику, а не ініціатору запиту
  • Деякі операції в інтерфейсі та через API можуть відрізнятися в період Beta

Повний перелік див. у обмеженнях Beta.

Що можна керувати

Organizations групує дії за чотирма робочими процесами. Кожен робочий процес має власні дозволи та налаштування політики.

Робочий процес

Що охоплює

Initiate Withdrawal

Хто може надсилати запити, погоджувати та здійснювати виведення грошових коштів і криптовалюти

Manage Addresses

Хто може додавати або видаляти внесені до білого списку адреси для виведення коштів

Manage Access

Хто може запрошувати учасників, керувати обліковими записами Service Users і змінювати дозволи

Manage Policies

Хто може змінювати правила погодження та блокувати налаштування управління

Повний довідник — у розділі Permissions and workflows.

Базові

Готові налаштувати Вашу Organization? Покрокові інструкції — у розділі Create an Organization: як запрошувати учасників, призначати дозволи, налаштовувати політики погодження та блокувати управління, коли будете готові.

Найчастіші питання

Ні. Organization Owner — це власник облікового запису, який створив Organization. Передати право власності через самообслуговування неможливо.

Ні. Створення Organization не можна скасувати через самообслуговування. Зверніться до Служби підтримки, якщо хочете обговорити варіанти міграції.

Owner зберігає повний доступ до облікового запису. Жодна з наявних функцій не зникає. Учасники отримують доступ лише до тих дій, для яких їм явно надано дозволи.

Наразі кожен учасник може належати лише до однієї Organization. У майбутньому Organizations підтримуватиме кілька юридичних осіб в одній структурі, що дасть учасникам змогу виконувати операції в межах різних юридичних осіб однієї Organization.

Service Users можуть ініціювати запити на виведення через API. Якщо політика Organization регулює процес Initiate Withdrawal, запит має бути схвалений учасниками (не сервісними користувачами) до набрання чинності. Service Users також можуть торгувати та керувати продуктами Earn залежно від дозволів свого API-ключа. Перегляньте Service Users.

Потрібна додаткова допомога?