Виведення надсилає кошти з Вашої Організації на зовнішні адреси з білого списку. Перекази переміщують кошти між власними обліковими записами Вашої Організації. Обидві операції є керованими: кожна виконується як запит згідно з політикою робочого процесу та прив’язана до облікових записів — тож контроль над тим, хто і звідки може переміщати кошти, є чітким. Переміщення коштів — це точка перетину двох моделей доступу: воно завжди потребує дозволу від кожної з них — дозволу на рівні облікового запису, що визначає задіяні рахунки, і рівня Workflow Profile, що охоплює сам запит. У цій статті описано, як кожен із процесів виконується від початку до кінця.
Кожне виведення та переказ проходить ті самі три перевірки. Розуміння різниці між ними — запорука правильного налаштування та діагностики переміщення коштів у Вашій Організації.
Перевірка 1 — Дозвіл на рівні облікового запису (які облікові записи?). Учасник повинен мати дозвіл на переміщення коштів для задіяних облікових записів:
Перевірка 2 — Рівень робочого процесу (чи можна ініціювати?). Workflow Profile учасника повинен мати рівень Initiate (або Execute) для відповідного робочого процесу — Withdrawal Request або Transfer Request.
Перевірка 3 — Політика (як запит завершується?). Далі вступає в дію політика робочого процесу. Якщо учасник має рівень Execute, а параметр «Завжди вимагати підтвердження» вимкнено, запит виконується одразу. В іншому разі він очікує необхідної кількості підтверджень від інших учасників.
Перевірки 1 і 2 є незалежними дозволами, і для переміщення коштів потрібні обидва. Учасник із дозволом «Виводити» на обліковому записі, але без Initiate на Withdrawal Request, не зможе виконати жодного виведення; так само не зможе діяти учасник, який може ініціювати запити, але не має дозволу «Виводити» на жодному обліковому записі.
Перевірки навмисно розміщено в різних місцях. Дозволи на рівні облікових записів визначаються Ролями облікових записів учасника і відповідають на питання «звідки»; Workflow Profile — на питання «чи можна»; політика — на питання «як». Будь-який із цих елементів можна змінити незалежно від інших: звузити перелік облікових записів, з яких трейдер може виводити кошти, не змінюючи правил підтвердження, або посилити вимоги до підтвердження, не зачіпаючи доступу до облікових записів.
Організація має три облікові записи: A, B і C. Priya, один із її учасників, має:
Що може робити Priya:
Дія | Результат | Чому |
|---|---|---|
Переказ A → B | Запит створено, очікує 1 підтвердження | Право Transfer є для обох облікових записів; Initiate є; політика вимагає підтвердження |
Виведення з A | Запит створено, очікує 2 підтверджень | Право Withdraw для джерела є; Initiate є; політика вимагає 2 підтверджень |
Виведення з B | Неможливо | Немає права Withdraw для B, перевірка 1 не пройдена |
Переказ A → C | Неможливо | Немає права Transfer для цільового облікового запису, перевірка 1 не пройдена |
Підтвердити виведення колеги | Неможливо | Її профіль містить Initiate, а не Approve |
Виведення здійснюється виключно на адреси зі списку дозволених адрес Вашої Організації, яким керує окремий процес Manage Addresses. Запит на виведення містить вихідний обліковий запис, актив і суму, а також адресу призначення зі списку дозволених.
Оскільки виведення переміщує кошти за межі Організації, політику запитів на виведення зазвичай посилюють і блокують першою. Більшість Організацій вимагають щонайменше одного незалежного підтвердження для кожного виведення, включно з підтвердженням від Власника. Див. Впровадження управління.
Список дозволених адрес
Додавання або видалення адреси зі списку дозволених є керованою операцією в межах Manage Addresses з власною політикою. Адреси не можна редагувати — щоб змінити адресу, видаліть її та додайте нову.
Список дозволених адрес і затвердження виведення взаємно доповнюють одне одного. Навіть Учасник, який може виконувати виведення негайно, може надсилати кошти лише на адреси, попередньо схвалені Вашою командою у списку дозволених.
Перекази переміщують кошти між обліковими записами Вашої Організації — для ребалансування між відділами, поповнення нового рахунку або консолідації прибутку. Кошти не виходять за межі Організації, проте перекази змінюють, яка команда має до них доступ, — саме тому вони регулюються так само ретельно, як і виведення.
Варто окремо підкреслити правило двох сторін: дозвіл «Переказ» потрібен як для вихідного, так і для цільового облікового запису. Учасник не може вивести кошти з підконтрольного йому облікового запису на той, який він не контролює, а також не може залучити кошти на свої рахунки з інших підрозділів Організації. Обидві сторони кожного переказу вимагають явно наданих дозволів.
Перекази та виведення мають окремі дозволи. Оператору, який цілий день виконує ребалансування між обліковими записами, потрібен дозвіл «Переказ», але немає підстав надавати йому дозвіл «Виведення». Надання одного дозволу ніколи не означає надання іншого.
Обидва робочі процеси можна запустити з двох місць — перевірки та результати однакові в обох випадках:
Запит у стані очікування не резервує кошти. Баланс вихідного облікового запису перевіряється в момент виконання запиту — після фінального підтвердження, а не в момент його створення. Якщо кошти за цей час перемістилися (угода, ще одне виведення або переказ), запит не виконується і потребує повторного подання.
Для більшості команд це не актуально. Коли це можливо: активний торговий обліковий запис, з якого також здійснюються виведення, або кілька запитів на переміщення коштів, що одночасно спираються на один баланс. Поки функцію резервування коштів не запроваджено (докладніше нижче), дотримуйтеся двох правил для безперебійного проходження підтверджень:
Резервування коштів у момент створення запиту заплановано: після запуску функції подання запиту автоматично відкладатиме суму, і підтверджений запит більше не відхилятиметься через зміну балансу під час перевірки.
Перевірка 2 не пройдена: профіль робочого процесу цього учасника не містить дозволу «Ініціювати» для робочого процесу «Запит на виведення». Дозвіл облікового запису «Виводити» лише визначає, з яких облікових записів можна виводити кошти; профіль вирішує, чи може учасник взагалі створювати запити. Попередній перегляд ефективного доступу на сторінці учасника відображає саме таке розмежування.
«Виводити» та «Переказувати» — окремі дозволи; дозвіл «Переказувати» має бути призначено як для вихідного, так і для цільового облікового запису. Перевірте ролі облікового запису цього учасника на наявність дозволу «Переказувати» для обох задіяних облікових записів, а також профіль — на наявність дозволу «Ініціювати» для «Запиту на переказ».
У Вас є дозвіл «Переказувати» для вихідного облікового запису, але не для цільового. Дозволи мають охоплювати обидва кінці переказу. Зверніться до адміністратора, щоб розширити Вашу роль облікового запису на цільовий обліковий запис.
Ініціатор має дозвіл «Виконати» для «Запиту на виведення», а параметр «Завжди вимагати підтвердження» в політиці вимкнено. Таке поєднання за задумом передбачає негайне виконання запитів. Щоб перевірка була обовʼязковою для всіх, увімкніть параметр «Завжди вимагати підтвердження» — див. Політики, підтвердження та управління.
Недостатньо уповноважених підтверджувачів здійснили дію. Перевірте, хто має право «Підтвердити» для запиту на переказ, виключаючи себе — Ви не можете підтвердити власний запит, — і переконайтеся, що ці учасники активні. Якщо підтверджувача було деактивовано після подання запиту, для запиту зберігається та кількість підтверджень, що діяла на момент його створення; надайте право «Підтвердити» іншому учаснику, щоб розблокувати запит.
На момент виконання запиту балансу рахунку-джерела вже не вистачало для покриття суми. Баланс перевіряється в момент виконання, а не в момент створення, і запит, що очікує на розгляд, не резервує кошти — тому будь-яка активність на рахунку під час перевірки може залишити недостатньо коштів. Переконайтеся, що кошти повернено на рахунок-джерело, і подайте новий запит. Див. «Зберігайте кошти доступними до підтвердження».