crm
Как настроить процесс двойного подтверждения для крупных OTC-переводов
Один скомпрометированный оператор OTC-деска может увести шестизначную сумму до того, как кто-то заметит. Вот как выстроить процесс двойного подтверждения, который это остановит.
Трейдер на OTC-деске получает сообщение в Telegram, которое выглядит точь-в-точь как запрос от обычного клиента. Адрес кошелька, сумма, срочность — всё на месте. Он отправляет 40 BTC раньше, чем кто-либо ещё в команде вообще видит этот запрос. К моменту, когда кто-то бьёт тревогу, средства уже прошли три хопа через миксер.
Именно такой сценарий убивает OTC-деск: один человек, одно подтверждение, один необратимый перевод. Ни одна крипто-транзакция не имеет кнопки "отменить платёж". Если ваш деск не требует второй пары глаз на крупные переводы, вы в одном фишинговом сообщении или одном неверном решении от потери, которую уже не отменить.
Что считается "крупным" переводом, требующим двойного подтверждения?
Большинство OTC-десков устанавливают порог двойного подтверждения где-то между $10 000 и $50 000 за транзакцию, либо на уровне фиксированного процента от дневного торгового оборота — обычно 1-5%. Точная цифра зависит от размера вашего деска, но принцип один: всё, что превышает обычную розничную сделку, должно проходить через второго подписанта перед отправкой.
Небольшие дески иногда ставят планку ниже — $5 000 — если один неудачный перевод реально ударит по балансу. Крупные дески, двигающие миллионы ежедневно, могут установить порог от $100 000+, чтобы подтверждения не тормозили обычный поток. Выберите цифру, которую сможете обосновать аудитору, зафиксируйте её письменно и не позволяйте никому отменять правило устно "только в этот раз".
Как на самом деле выстроить процесс двойного подтверждения?
Механика важнее, чем сам документ с политикой. Правило, которое существует только в корпоративном справочнике, пропускается в первый же раз, когда кто-то спешит. Правило должно жить внутри инструмента, которым команда реально пользуется для перемещения денег.
Определите триггер — установите жёсткий денежный порог (или эквивалент в монетах), который автоматически помечает перевод как "требует второго подтверждения".
Разделите инициатора и подтверждающего — человек, создающий запрос на перевод, никогда не может быть тем, кто его подписывает. Без исключений, включая владельца деска.
Требуйте независимой проверки — подтверждающий заново сверяет адрес кошелька назначения с адресом клиента в базе, а не с тем, что ввёл инициатор.
Фиксируйте каждый шаг с меткой времени — кто запросил, кто подтвердил, во сколько, какой кошелёк, какая сумма.
Установите период охлаждения для рискованных флагов — если контактный способ связи с клиентом изменился (новый телефон, новый Telegram-аккаунт) за последние 48 часов, требуйте третий звонок для верификации, прежде чем кто-либо из подписантов одобрит перевод.
Ротируйте роль подтверждающего — не позволяйте одной и той же паре людей всегда работать вместе; ротация снижает риск сговора или потери бдительности.
Как управлять этим, если ваш деск работает через Telegram?
Большинство OTC-десков ведут общение с клиентами через Telegram, потому что именно там живут крипто-клиенты — но у личных переписок в Telegram нет встроенной цепочки подтверждений, нет журнала аудита и нет способа остановить трейдера, действующего в одиночку. Именно этот пробел становится причиной потерь, а не отсутствие политики как таковой.
CRMChat решает это, помещая каждую переписку с OTC-клиентом в общий пайплайн, где запрос на перевод превращается в карточку сделки, а не остаётся приватным чатом, видимым только одному человеку. Трейдер-инициатор перемещает сделку на этап "Ожидает подтверждения", и второй член команды должен проверить и продвинуть её дальше, прежде чем что-либо выполнится. Никто не подтверждает по памяти или по скриншоту, пересланному в групповой чат — все смотрят на одну и ту же карточку сделки, одну и ту же историю, одни и те же заметки по кошельку.
CRMChat также включает заметки и напоминания, привязанные напрямую к каждой сделке, так что подтверждающий видит именно то, что отметил инициатор: адрес кошелька, ID клиента, историю предыдущих переводов и любые тревожные моменты, отмеченные тем, кто последним общался с клиентом. Если вы читали нашу статью о написании скрипта чаттера, который звучит как вы сами, та же логика применима и здесь — последовательность и документирование позволяют второму человеку подключиться, не теряя контекста.
Почему общий пайплайн лучше сообщения в Slack или группового чата
Многие дески пытаются закрыть эту проблему сообщением в Slack: "эй, кто-нибудь может подтвердить этот перевод?" Проблема в том, что сообщения в Slack прокручиваются и исчезают, никто не отвечает за последующий контроль, и нет постоянной записи, привязанной к конкретной транзакции. Когда аудитор или клиент в споре спрашивает "кто это подтвердил и когда", уже прокрученное сообщение — не ответ.
А этап в пайплайне — ответ. У каждой карточки сделки есть история: кто её трогал, что изменилось и когда она перешла из "Ожидает подтверждения" в "Подтверждено" и затем в "Отправлено". Это разница между политикой, на которую можно указать, и политикой, которую можно доказать.
Что реально должен проверять подтверждающий перед одобрением?
Двойное подтверждение работает только если второй человек делает реальную проверку, а не просто ставит штамп, потому что доверяет коллеге. Дайте подтверждающему конкретный чек-лист, а не размытую инструкцию "проверь ещё раз".
Убедитесь, что адрес кошелька назначения точно совпадает с адресом клиента в базе — ошибки копирования-вставки и атаки через отравление адресов прячутся в одном несовпадающем символе.
Проверьте личность клиента через второй канал, если запрос пришёл с нового или недавно изменённого Telegram-аккаунта.
Проверьте, что сумма перевода совпадает с той, что была озвучена и согласована, а не с изменённой цифрой.
Убедитесь, что клиент не был помечен из-за предыдущих чарджбэков, споров или подозрительной активности в истории сделок.
Отклоняйте и эскалируйте немедленно, если что-то кажется странным — время, тон, необычная срочность — вместо того, чтобы подтверждать "на всякий случай".
Как сделать так, чтобы процесс двойного подтверждения не стал узким местом?
Главное возражение против двойного подтверждения — скорость: OTC-клиенты ждут быстрого исполнения, и добавление шага проверки ощущается как трение. Решение не в том, чтобы пропустить проверку, а в том, чтобы сделать её быстрой, сделав информацию доступной мгновенно.
CRMChat позволяет командам держать полный контекст CRM и переписку с клиентом на одном экране, так что подтверждающему не нужно рыскать по пяти приложениям, чтобы проверить адрес кошелька или поднять историю переводов. Уже одно это превращает 20-минутную ручную проверку в то, что занимает две минуты, потому что всё, что нужно подтверждающему, уже прикреплено к сделке. Вы можете увидеть, как похожая многопользовательская, многоаккаунтная настройка работает в условиях высокой нагрузки, в нашем кейсе по управлению отношениями с VIP-клиентами в Telegram, где скорость и подотчётность должны были сосуществовать, не жертвуя друг другом.
Настройте доступность подтверждающих так, чтобы всегда был хотя бы один резервный подписант онлайн в торговые часы — система с двумя людьми, где доступен только один подтверждающий в пиковые часы, просто воссоздаёт ту же проблему единой точки отказа, которую вы пытались решить.
Что ещё стоит задокументировать вокруг процесса подтверждения?
Зафиксируйте денежный порог и точные шаги подтверждения в однострочной политике, которую подписывает каждый член команды.
Ведите постоянный журнал каждого перевода с двойным подтверждением, экспортируемый для аудитов или споров с клиентами.
Пересматривайте порог ежеквартально — если средний размер сделки растёт, планка подтверждения должна расти вместе с ним.
Обучайте каждого нового сотрудника пути эскалации, прежде чем он коснётся хотя бы одного реального перевода.
Периодически тестируйте процесс с помощью пробного прогона, чтобы убедиться, что никто тихо не начал пропускать шаги.
Если вы выстраиваете более широкий стек операций на базе Telegram, загляните в Help Center CRMChat за деталями настройки пайплайнов и прав доступа команды, или в CRMChat API, если нужно подключить подтверждения переводов к внутренней бухгалтерской книге или системе комплаенса.
Главный вывод
Процесс двойного подтверждения — это не бюрократия ради бюрократии, а тот самый контроль, который превращает необратимый крипто-перевод в нечто, что второй живой человек реально может остановить до того, как это произойдёт. Установите чёткий денежный порог, разделите инициатора и подтверждающего, документируйте каждый шаг и пропускайте всё через систему, созданную для командной видимости, а не через приватные переписки. Дески, которые пропускают этот шаг, узнают о его важности только тогда, когда перевод уже ушёл безвозвратно.
