О сервисе Organizations

Для создания Organization необходим корпоративный аккаунт Kraken с пройденной проверкой KYB<1>}. Личные аккаунты Kraken не подходят для этой цели.

Создать Organization может только держатель аккаунта, прошедший бизнес-верификацию. После создания этот пользователь становится Organization Owner<1>}.

Отменить создание Organization в режиме самообслуживания невозможно. После создания Organization её отмена требует обращения в службу поддержки.

Обратите внимание. Organizations в настоящее время находится в стадии бета-тестирования. Некоторые функции могут иметь ограничения. Подробнее см. в разделе Ограничения бета-версии<2>}.

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

• Приглашайте участников команды в свою Organization
• Назначайте права доступа по рабочему процессу и аккаунту
• Требуйте подтверждения для чувствительных операций: выводов, изменения адресов и обновления прав доступа
• Применяйте общие меры безопасности: двухфакторную аутентификацию и тайм-аут сеанса
• Внедряйте управление поэтапно — начните быстро, ужесточьте позже

Organization Owner<1>} — держатель аккаунта, создавший Organization. Owner получает полные административные права и отвечает за настройку доступа и управления для команды. Роль со-владельца не предусмотрена.

Member<1>} — пользователь, приглашённый в Organization с определёнными правами доступа. Участники (Members) входят в систему с помощью собственных учетных данных Kraken и обязаны соблюдать политику Organization в отношении 2FA для входа.

Service User<1>} — оператор, работающий исключительно через API и созданный в рамках Organization. Service Users проходят аутентификацию с помощью учетных данных API-ключа и могут создавать запросы, однако не могут их подтверждать или выполнять вход в интерфейс. Подробнее см. в разделе Service Users.

Organization — контейнер верхнего уровня, объединяющий участников, аккаунты и управление в единую структуру.

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

Permission — право доступа, определяющее, какие действия может выполнять участник или Service User. Разрешения суммируются: по умолчанию у пользователей нет никакого доступа, и каждое разрешение необходимо выдавать отдельно. Полный справочник см. в разделе Permissions and workflows.

Workflow — группа связанных операций с единой моделью разрешений и настройками политики. В Organizations предусмотрено четыре рабочих процесса: «Инициирование вывода» (Initiate Withdrawal), «Управление адресами» (Manage Addresses), «Управление доступом» (Manage Access) и «Управление политиками» (Manage Policies).

Operation — конкретное действие в рамках рабочего процесса. Например, «Создать вывод криптовалюты» (Create a crypto withdrawal) — это операция в рабочем процессе Initiate Withdrawal.

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

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

Execute — разрешение, позволяющее участнику выполнять действия без ожидания подтверждения, если это допускает политика рабочего процесса. Если включён параметр «Always require approval», разрешение Execute не действует.

Policy lock — механизм управления, запрещающий любому отдельному лицу изменять политику рабочего процесса. Любые последующие изменения требуют независимого подтверждения и возможны только при наличии достаточного числа утверждающих.

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

• Участники не могут одобрять собственные запросы. Принудительно соблюдается системой и не подлежит изменению.
• Разрешения суммируются. По умолчанию участники не имеют доступа — каждое разрешение предоставляется отдельно.
• Немедленное выполнение действия или необходимость одобрения зависят от разрешений участника и политики рабочего процесса. См. Разрешения и рабочие процессы.
• Заблокированные политики нельзя изменить без независимого одобрения — в том числе Владельцу.
• Требуется 2FA для входа в Organization. Политика устанавливается при создании и распространяется на всех текущих и будущих участников.
• Неактивные сессии истекают и требуют повторной аутентификации.

Organizations в настоящее время находится в стадии бета-тестирования. Ключевые ограничения:

• Доступен только режим одного аккаунта — торговля с несколькими аккаунтами пока не поддерживается
• Некоторые операции на платформе доступны только Владельцу (фьючерсы, OTC, конвертация, хранение)
• Журналы аудита для клиентов пока недоступны
• Пользовательские роли нельзя сохранять и повторно использовать
• Подтверждение по электронной почте при немедленном изменении адреса отправляется Владельцу, а не создателю запроса
• В период Beta некоторые операции могут различаться в UI и API

Полный список см. в разделе Ограничения Beta.

Organizations группирует действия по четырём рабочим процессам. У каждого рабочего процесса есть собственные разрешения и настройки политики.

Готовы настроить вашу организацию? Пошаговое руководство по созданию и первым шагам — включая приглашение участников, назначение разрешений, настройку политик одобрения и блокировку управления — см. в разделе Создание организации.