Про Organizations

Останнє оновлення: 17 серпня 2026 р.
Примітка.

Якщо Вашу Organization було створено за моделлю Beta-доступу, де дозволи надавали кожному учаснику окремо, див. Moving from Beta. У ній описано, що змінюється, і які роботи з інтеграції API слід виконати заздалегідь.

Organizations: огляд

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

Створення Organization дає Вам змогу:

  • Керувати кількома обліковими записами з відокремленими балансами, ордерами та історією
  • запрошувати учасників команди та призначати доступ через ролі та профілі багаторазового використання
  • вимагати багатостороннього затвердження для виведення коштів, переказів та адміністративних змін
  • перебалансовувати облікові записи за допомогою переказів, які не виходять за межі Organization, — кожен такий переказ проходить перевірку та затвердження, як і будь-який інший рух коштів
  • створювати API-ключі для автоматизованої торгівлі — зокрема з підключенням FIX до спотових ринків — і для звітності; область дії кожного ключа обмежено обліковими записами, з якими він працює
  • переглядати журнал подій безпеки з усіма діями у Вашій Organization

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

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

Member — особа, запрошена до Organization. Учасники входять із власними обліковими даними Kraken, повинні дотримуватися політики 2FA для входу в Organization та мають рівно один Workflow Profile і будь-яку кількість Account Roles.

Accounts — відокремлені операційні одиниці всередині Organization, кожна з власним балансом, відкритими ордерами та історією. Organization починає роботу з одним основним обліковим записом і може містити кілька; доступ до одного облікового запису не поширюється на інші. Дивіться Облікові записи.

API key — облікові дані для програмного доступу, які використовують торгові системи та засоби автоматизації. API-ключі мають власну модель дозволів, окрему від учасників. Докладніше: API keys.

Усі дії Учасника в Організації належать до однієї з двох категорій. Розуміння цього розподілу спрощує сприйняття решти моделі.

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

Керовані операції виконуються як запити на схвалення. Виведення коштів, перекази між обліковими записами та будь-які адміністративні зміни (керування доступом команди, ключами API, обліковими записами, адресами та політиками) — це керовані операції. Ініціювання такої операції створює запит, а політика робочого процесу визначає, чи виконається він одразу, чи очікуватиме схвалення від інших Учасників.

Прямі операції

Керовані операції

Приклади

Перегляд балансів, торгівля, розподіл і виведення коштів з розподілу в Earn

Виводити кошти, здійснювати переказ, запрошувати Учасника, створювати ключ API, змінювати політику

Контролюється

Дозволи на обліковий запис, надані для кожного облікового запису через Ролі облікового запису

Рівні Профілю робочого процесу та політика схвалення відповідного робочого процесу

Завершення

Негайні

Негайно або після схвалення — залежно від конфігурації політики

Керовані операції організовано у робочі процеси. Кожен робочий процес має власну політику схвалення та власні рівні «Перегляд / Ініціювання / Схвалення / Виконання» у Профілі робочого процесу кожного Учасника.

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

Що контролює

Запит на виведення

Виведення коштів на зовнішні адреси з білого списку

Запит на переказ

Переміщення коштів між обліковими записами Організації

Керування командою та доступом

Запрошення учасників, активація, ролі облікових записів і профілі робочих процесів

Керування API-ключами

Створення, редагування та відкликання API-ключів

Керування обліковими записами

Життєвий цикл облікових записів: додавання, редагування, вимкнення й видалення облікових записів

Керування адресами

Білий список адрес для виведення коштів

Керування політиками

Правила підтвердження, які регулюють усі інші робочі процеси

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

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

Main account — обліковий запис, що існував на момент створення Organization. Він підтримує спот-торгівлю та маржинальну торгівлю для учасників; додаткові облікові записи наразі підтримують лише спот-торгівлю. Див. Наявність та обмеження.

Account permission — дозвіл, що авторизує конкретну операцію на конкретному обліковому записі: Read, Trade, Earn Allocate, Earn Deallocate, Withdraw або Transfer.

Account Role — багаторазовий набір дозволів облікового запису, що застосовується до групи облікових записів. Учасник може мати кілька Account Roles; їхні дозволи поєднуються.

Workflow — група повʼязаних керованих операцій, що підпадають під одну політику погодження: Withdrawal Request, Transfer Request, Manage Team & Access, Manage API Keys, Manage Accounts, Manage Addresses та Manage Policies.

Workflow Profile — єдиний профіль кожного учасника, що визначає його рівень (View, Initiate, Approve, Execute) у кожному workflow. Рівні Workflow Profile діють у межах усієї Organization.

Policy — конфігурація погодження одного workflow: скільки погоджень потребує запит і чи кожен запит має проходити погодження. Policies налаштовуються окремо для кожного workflow — один раз для всієї Organization.

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

Security event — запис про дію, що сталася у Вашій Organization: хто її виконав, звідки, на якому обліковому записі та з яким результатом. Див. Події безпеки.

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

  • Учасники не можуть схвалювати власні запити — в жодному робочому процесі та за жодних налаштувань.
  • Доступ є накопичувальним. Учасники починають без будь-якого доступу й отримують лише те, що надає їхній Профіль робочого процесу та Ролі облікового запису.
  • Те, чи виконується керована операція негайно, чи очікує на схвалення, визначається Профілем робочого процесу Учасника та політикою робочого процесу, але ніколи — самою операцією.
  • Зміна або розблокування заблокованої політики завжди очікує на незалежне схвалення від Учасників, чий Профіль робочого процесу надає право схвалення в розділі «Управління політиками». Жодна особа, включно з Власником, не може самостійно змінити заблоковану політику.
  • 2FA для входу в Організацію є обовʼязковою для кожного Учасника. Політика встановлюється під час створення й поширюється на всіх поточних і майбутніх Учасників.
  • Неактивні сесії завершуються й потребують повторної автентифікації.
  • Кожен вхід, зміна дозволів, переміщення коштів і зміна політики фіксуються як подія безпеки.
  • Для створення Організації необхідний обліковий запис Kraken із верифікацією для бізнесу на Kraken Pro. Облікові записи Standard і Початкові облікові записи не підходять.
  • Створити Організацію може лише власник облікового запису, який пройшов бізнес-верифікацію. Після створення ця особа стає Власником Організації.
  • Адресу електронної пошти Власника можна змінити пізніше через стандартну процедуру зміни електронної пошти. У рамках цього процесу очікуйте на верифікацію особи та, можливо, ручну перевірку.
  • Скасування Організації потребує звернення до Служби підтримки, може зайняти час і відбувається лише після виконання необхідних умов.
Примітка.

Деякі можливості ще впроваджуються. Перегляньте Доступність і обмеження, щоб дізнатися, що доступно вже сьогодні.

Почніть із Створення Організації, потім ознайомтеся з Ролями, профілями та дозволами, Політиками, схваленнями та управлінням і Впровадженням управління. Решту статей використовуйте, коли потрібно керувати окремою частиною Вашої Організації.

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