Доступність і обмеження

Organizations наразі підтримує:

• Кілька облікових записів в одній організації з відокремленими балансами, ордерами та історією
• Повний життєвий цикл облікового запису: додавання, редагування, вимкнення, увімкнення та видалення
• Командний доступ через ролі облікових записів і профілі робочих процесів із системними опціями, готовими одразу після створення
• Сім керованих робочих процесів із власними політиками затвердження та блокуванням політик
• Перекази між обліковими записами та виведення коштів на адреси з білого списку — обидві операції під повним управлінням
• Спот-торгівля на кожному обліковому записі; маржинальна торгівля — лише на головному
• Розподіл і скасування розподілу коштів у Earn
• API-ключі, привʼязані до одного або кількох облікових записів, із керованим адмініструванням ключів і FIX-підключенням для спот-торгівлі
• Події безпеки: входи, рух коштів і всі адміністративні зміни
• Політики 2FA для входу в Organizations і тайм-ауту сесії

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

Учасники з дозволом «Торгувати» можуть вести спотову та маржинальну торгівлю на головному обліковому записі, а спотову — на додаткових облікових записах. Підтримку маржі для додаткових облікових записів заплановано; після її впровадження маржа на кожному обліковому записі відповідатиме тій самій моделі дозволів, що й інші дозволи облікового запису.

Що це означає на практиці: маржинальні стратегії виконуйте з головного облікового запису, а спотову активність — з додаткових. Той самий дозвіл «Торгувати» діє по-різному на головному та додаткових облікових записах — позначайте записи чітко, щоб команда не плуталася.

Операції, доступні лише Власнику

Деякі операції на платформі поки не мають дозволів у межах Organizations і залишаються доступними виключно Власнику організації на головному обліковому записі:

• Дбайте про ліквідність активів
• Торгівля фʼючерсами TradFi
• Торгівля акціями
• Торгівля xStocks
• Торгівля опціонами
• Позабіржова торгівля
• Обмін
• DeFi Earn
• Кредитні кошти

Торгівля через WebSocket на будь-якому обліковому записі, крім головного, також доступна лише Власнику.

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

До 100 облікових записів на організацію

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

Один профіль робочого процесу на учасника

Кожен учасник має рівно один профіль робочого процесу. Якщо команді потрібне поєднання рівнів, якого не забезпечує жоден наявний профіль, створіть власний профіль — не намагайтеся обʼєднувати кілька. Ролі облікових записів, навпаки, можна поєднувати без обмежень.

Учасник належить до однієї організації

Наразі кожен учасник може входити лише до однієї організації.

Вихід з Organizations потребує звернення до підтримки

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

Зміна електронної пошти Власника організації не передає право власності

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

Правила погодження однакові для всіх облікових записів

Політики встановлюються для кожного робочого процесу на рівні всієї організації. Права на погодження (рівень «Погодження») діють у межах усієї організації: учасник, який може погоджувати запити на виведення, може робити це з будь-якого облікового запису. Конфігурації на кшталт «погоджувати лише для певних облікових записів» або «вимагати додаткових погоджень для одного конкретного облікового запису» наразі не підтримуються. Контролюйте, хто погоджує, обмежуючи коло учасників із рівнем «Погодження»; контролюйте переміщення коштів, обмежуючи відповідні дозволи.

API-ключі застосовують дозволи однаково

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

Кошти не резервуються під час очікування погодження запиту

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

Резервування коштів у момент створення запиту заплановане. До того часу вважайте подані запити зарезервованим балансом. Див. Зберігайте кошти доступними до підтвердження.

Видалення облікового запису архівує його дані

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

Публічний API для керування Organizations відсутній

Запрошення учасників, призначення доступу, керування життєвим циклом облікових записів і налаштування політик доступні лише через інтерфейс. Програмний доступ обмежено API-ключами, які працюють у межах підтримуваних потоків: торгівля, Earn, запити, експорт даних, а також ініціювання виведень і запитів на адреси. Актуальне охоплення API дивіться в документації Kraken API.

Напрями, над якими ми активно працюємо:

• Маржинальна торгівля на додаткових облікових записах із виділеним дозволом для кожного облікового запису
• Кредитні ліміти для кожного облікового запису
• Резервування коштів для запитів в очікуванні: після подання запиту на виведення або переказ сума блокуватиметься, тож затверджені запити не відхилятимуться через зміну балансу під час перевірки
• Групи облікових записів — іменовані, повторно використовувані набори облікових записів для масштабованого розподілу ролей
• Розширений перелік дозволів для більшої кількості операцій на платформі
• API керування Organizations для програмного адміністрування

Інформація про терміни та доступність публікується через офіційні канали Kraken.