KYC в торговой платформе

KYC в торговой платформе связывает лимиты и вывод средств со статусом проверки документов. Это не «форма загрузить паспорт», а процесс со статусами, очередью в админке и понятным ответом пользователю. Пока статус не виден в кабинете, трейдер считает, что файлы «пропали».

На white-label БО и Forex KYC обычно включает: личность, адрес иногда, иногда источник средств по политике оператора. Технически скрипт даёт загрузку, хранение, статусы и гейты; процедуру проверки ведёт команда заказчика или внешний провайдер.

Статусы, которые должны быть

• Не начато / черновик.
• На проверке.
• Запрос доработки (не хватает файла, плохое фото).
• Одобрено.
• Отказ с причиной в кабинете.

Заявка не пропадает после обновления страницы. Повторная отправка не создаёт хаос из пяти «висяков» без связи. Админ меняет статус из одной очереди. Кабинет: кабинет трейдера.

Гейты

Типично: вывод и повышение лимитов требуют approved. Демо-счёт и просмотр графика — нет. Если закрыть KYC всё, включая демо, воронка регистрации умрёт на первом экране. Демо: демо-счёт. Вывод: депозит и вывод.

1. Создайте тестового пользователя и загрузите файлы.
2. Переведите в «на проверке» — пользователь видит статус.
3. Откажите с причиной — причина видна, вывод закрыт.
4. Одобрите — вывод доступен по правилам.

Связь с платежами

Заявка на вывод без KYC approved должна останавливаться до выплаты, с понятным текстом «пройдите проверку». Не молчаливый fail. Депозит иногда открывают раньше KYC — решение бизнеса; зафиксируйте его в оферте и в UI одинаково.

Продукты: БО, Forex, white label, скрипты опционов и Forex.

Админка и SLA

Очередь с фильтром по статусу и дате, просмотр файлов, комментарий оператора (внутренний) и причина для клиента (внешняя). Метрика времени в «на проверке» нужна владельцу платформы. Без неё KYC превращается в чёрную дыру жалоб.

Логируйте смену статуса и кто нажал. Споры «мне одобрили, а потом снова отказ» без лога не разобрать.

Внешние провайдеры

Если статус приходит callback с KYC-сервиса, сделайте идемпотентность и ручной override в админке. Сеть падает — пользователь не должен зависнуть навечно без кнопки «связаться с поддержкой».

Не светите секреты API в фронте. Webhook только на backend с проверкой подписи.

UX загрузки

Ограничение типов и размера с человеческой ошибкой. Превью «файл принят». На мобиле камера должна отрабатывать без квеста. Подсказки: свет, края документа, без бликов — снижают долю доработки.

Приёмка

Прогон всех статусов, проверка гейта вывода, права доступа к файлам под чужой сессией (должны 403), уведомление на почту о смене статуса. Правки текстов причин: MicroEditor. Выкладка: MicroDrive.

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

Состав комплекта документов

Базовый набор: документ личности, иногда селфи/liveness, иногда proof of address. Набор зависит от политики оператора и юрисдикции — скрипт должен позволять конфигурировать обязательные типы файлов без деплоя кода. Подсказки к каждому типу снижают долю «на проверке → доработка».

Размер и MIME: jpeg/png/pdf обычно достаточно. Видеосессифики — только если провайдер требует; иначе раздуете диск. Антивирусная проверка загрузок желательна на уровне инфраструктуры.

Повторная верификация и истечение

Иногда статус approved имеет срок. Заложите поле expires_at и уведомление заранее. При истечении гейт вывода возвращается, доступ к демо не обязан отключаться. Пользователь должен видеть, что именно просрочено.

Смена персональных данных после approve — отдельный процесс, не «просто поправьте имя в профиле». Иначе KYC теряет смысл.

Разделение ролей

Оператор KYC не обязан иметь право двигать баланс. Аудитор читает. Суперadmin настраивает типы документов. Разделение снижает внутренний фрод. Все решения по заявке пишите в immutable log.

Отчёты: количество заявок в день, среднее время проверки, доля отказов по причинам. Это инструмент управления сменой, не «красота для инвестора».

Коммуникация с пользователем

Письма и inbox в кабинете дублируют смену статуса. Текст отказа без номера заявки бесполезен. Шаблоны причин стандартизируйте, но оставляйте поле комментария. Тон нейтральный: «не удалось подтвердить», без обвинений.

Часовой SLA проверки публикуйте только если реально держите. Ложный «24 часа» при факте трое суток токсичен. Внутри смены мониторьте возраст очереди и эскалируйте автоматически.

Селфи с документом: подсказка по кадру снижает долю доработки. Если liveness через провайдера — покажите прогресс «ожидаем ответ провайдера», чтобы не жмакали submit десять раз.

Готовность к проверке

До запуска рекламы: тестовые заявки всех статусов, гейт вывода, права на файлы, письма, отчёт очереди, провайдерский callback на staging. Зафиксируйте владельца процесса KYC — технического и операционного. Скрипт даёт статусы; люди дают решения.

Операционный ритм KYC

Утренняя очередь: возраст заявок, доля доработок, ответы провайдера с ошибкой. Фото-шаблоны причин обновляйте по факту частых отказов. Диск под документами — с квотами и алертами; архив старых файлов по политике хранения. Доступ сотрудников к документам пересматривайте при смене ролей.

Стык с выплатами проверяйте контрольным выводом на тестовом пользователе после каждого релиза гейтов. Регресс «вывод без KYC» недопустим.

Если документы хранятся на S3-совместимом хранилище, проверьте подписанные URL и срок жизни ссылок в админке. Протухшая ссылка выглядит как «файлы пропали». Кэш браузера админа тоже иногда путает — hard refresh в инструкции поддержки.

Закройте контур тестом «враждебного» пользователя: чужая сессия не читает файлы, прямые URL документов отдают 403, массовая загрузка гигабайтных файлов режется лимитом. Затем тест оператора: очередь, фильтр, решение, письмо клиенту. Только после этого KYC можно считать готовым к реальному выводу.

Сохраните в help скриншоты «хорошего» и «плохого» фото документа. Снижение доли доработок окупает час работы дизайнера. Обновляйте примеры, если меняете список принимаемых типов файлов.