Как настроить уведомления о движении средств для рабочего аккаунта

Настроить уведомления о движении средств для рабочего аккаунта значит отдать их человеку, который платёж не готовил и не подписывал. Иначе сообщение превращается в квитанцию для самого исполнителя и ничего не контролирует. Рабочая схема такая: инициатор готовит транзакцию, подписант её подписывает, а оповещение уходит третьему — контролёру, у которого ключа нет. Журнал этих сообщений хранится отдельно и служит доказательством при разборе.

Как настроить уведомления о движении средств для рабочего аккаунта: кому адресовать сообщение

В личном кошельке получатель оповещения один — владелец. В рабочем контуре людей несколько, у каждого своя роль и свой интерес, поэтому адресация сообщений перестаёт быть удобством и становится частью схемы контроля. Ошибка типовая: подписку заводит тот, кто платит. Он же её настраивает, он же читает, он же решает, что считать нормой.

Стандарты подсказывают, как разложить роли. BIP-174 со статусом Deployed описывает формат частично подписанной транзакции и прямо перечисляет шесть ролей: создатель, обновляющий, подписант, объединяющий, финализатор входов и извлекающий транзакцию. Разделение здесь не организационная выдумка, а свойство формата: подписант работает только с данными, которые пришли в файле, и не получает доступа к набору непотраченных выходов целиком.

Наблюдатель в этот список не входит. Он седьмая роль, внешняя по отношению к формату, и именно поэтому её удобно отдать человеку без подписывающего ключа: контролёр видит результат операции, но не способен её провести сам. Из редакционной практики: там, где контролёр совпадает с подписантом, разбор инцидента неизбежно упирается в слово одного сотрудника против слова другого.

Сравнение схем адресации оповещений

Четвёртая строка таблицы — разумный минимум для контура, где платежи идут регулярно и где спорная операция рано или поздно потребует доказательств, а не воспоминаний. Третья строка — минимум вообще. Первые две контролем не являются.

Порядок настройки шаг за шагом

1. Распишите роли на бумаге: кто готовит платёж, кто подписывает, кто получает оповещения и кто реагирует на расхождения.
2. Заведите наблюдение по дескриптору рабочего кошелька от учётной записи контролёра, а не от учётной записи подписанта.
3. Снимите порог по сумме для исходящих событий и включите оповещения о смене конфигурации наблюдения.
4. Настройте выгрузку журнала сообщений во внешнее хранилище, где у подписанта нет права изменять записи.
5. Опишите срок реакции: за какое время контролёр обязан сверить сообщение с планом платежей и к кому идёт эскалация.
6. Проведите учебный прогон: платёж по плану и платёж вне плана, оба с фиксацией времени обнаружения.

Два требования складываются в понятное правило для рабочего контура. Доступ к наблюдению — такой же учётный актив, как подписывающий ключ, и обращаться с ним следует по тем же правилам выдачи, учёта и своевременного отзыва. Уволился сотрудник — привязка его аппарата отзывается в тот же день, вместе с паролем и вторым фактором.

Журнал сообщений как доказательство

Оповещение ценно не в момент прочтения, а при разборе спорной операции через месяцы, когда участники помнят события по-разному и каждый уверен в своей версии. Чтобы журнал работал доказательством, он должен удовлетворять трём условиям. Первое: запись содержит время, идентификатор транзакции и сумму. Второе: хранилище допускает дозапись, но не правку. Третье: доступ на изменение не принадлежит ни инициатору, ни подписанту.

Сверяемость — отдельное требование. Сообщение службы наблюдения сверяется с записью в цепочке по идентификатору транзакции, и любое расхождение между этими двумя источниками означает либо подделку сообщения, либо отказ самой службы наблюдения. Как устроен дескриптор, по которому контролёр ведёт наблюдение, мы разбирали в материале о том, как устроен расширенный публичный ключ в мультиподписи.

Типовые ошибки, которые стоят денег

• Подписка заведена с учётной записи подписанта. Он же её и выключит, если понадобится.
• Журнал сообщений живёт в том же мессенджере, где сотрудники переписываются и удаляют историю.
• Порог по сумме оставлен для исходящих событий, и вывод частями проходит ниже границы.
• Привязки уволившихся сотрудников не отозваны, и события уходят на их аппараты.

Четвёртая ошибка всплывает при проверках чаще остальных: список привязанных получателей в службе наблюдения никто не ревизует, и через год там обнаруживаются аппараты людей, давно сменивших работу, вместе с действующими правами на чтение истории операций. Что именно переносится при смене устройства, мы описывали в разборе о том, как правильно мигрировать активы на аппаратное устройство.

Что делать при расхождении

Расхождение — это операция, которой нет в плане платежей. Порядок действий жёсткий. Контролёр фиксирует идентификатор транзакции и время обнаружения, сверяет запись с цепочкой через независимый обозреватель и уведомляет эскалацию по заранее составленному списку, не дожидаясь объяснений от подписанта. Подписант не участвует в фиксации — он участвует в объяснении. Если расхождение подтверждено, остаток переводится на кошелёк с новым набором участников, прежние ключи выводятся из схемы, а привязки получателей пересобираются с нуля.

Схема с несколькими подписантами упрощает этот разговор: право подписи распределено, и одна утраченная подпись не двигает средства. Как собрать такую схему для небольшой команды, мы описывали в материале о том, как настроить мультисиг-хранилище для семьи или небольшой команды.

Чек-лист

• Роли расписаны: инициатор, подписант, контролёр, эскалация.
• Наблюдение заведено с учётной записи контролёра без подписывающего ключа.
• Порог по сумме для исходящих событий снят.
• Журнал сообщений выгружается во внешнее хранилище без права правки.
• Срок реакции контролёра и порядок эскалации записаны.
• Список привязанных получателей ревизуется при каждом кадровом изменении.
• Учебный прогон с платежом вне плана проведён, время обнаружения зафиксировано.

Частые вопросы