
14 сентября 2026 г.4 минуты чтенияАдминистратор
Разбор противоречий при KYB-проверке мерчанта
Как запрашивать и проверять документы мерчанта, не превращая требования одного провайдера в универсальный список для всех стран.
У мерчанта три названия: одно на сайте, другое в реестре, третье в реквизитах для выплат. Иногда это объяснимая структура бизнеса. Иногда заявка собрана неправильно. Само число загруженных документов не помогает выбрать между этими вариантами. Проверка становится содержательной, когда каждый запрос закрывает конкретное противоречие.
Удобнее начинать подключение с вопросов, а затем подбирать подтверждения для каждого ответа. Ниже приведён рабочий подход к организации проверки. Конкретные требования нужно определять по применимому законодательству, правилам платёжного партнёра и модели бизнеса.
Разделите компанию, владельцев и представителя
В платёжной практике термин KYB обычно относится к проверке бизнеса, а KYC часто используют для проверки связанных с ним физических лиц. Эти сокращения не задают одинаковый пакет документов во всех странах. Рекомендации FATF являются международными стандартами, которые государства реализуют с учётом национальных условий. Это разграничение поясняет FATF.
Выстройте проверку вокруг четырёх вопросов: существует ли компания, кто её контролирует, кто вправе действовать от её имени и какую деятельность будет обслуживать платёжный сервис. Регистрационная выписка помогает ответить на первый вопрос. Сама по себе она не закрывает остальные три.
Владение и полномочия тоже нельзя смешивать. Договор может подписывать уполномоченный руководитель, который не владеет долей. В определении FATF конечное бенефициарное владение связано с физическими лицами, в конечном счёте владеющими клиентом или контролирующими его. Поэтому название компании-акционера не обязательно завершает проверку структуры. Определение в глоссарии FATF.
У каждого запроса должна быть цель
- Существование компании: установить юридическое название, регистрационный номер и соответствующий реестр.
- Структура владения: понять цепочку собственников и определить лиц, проверка которых требуется по применимым правилам.
- Полномочия представителя: выяснить, на каком основании человек действует от имени заявителя.
- Деятельность: описать товары, исполнение заказов, географию покупателей и участие других продавцов.
- Получатель выплат: проверить связь платёжных реквизитов с согласованной договорной моделью.
Это карта вопросов, а не требование собрать все возможные документы. Например, у Stripe состав сведений зависит от конфигурации подключаемого аккаунта, включая страну и тип бизнеса. Такая документация иллюстрирует вариативность проверки, но не заменяет правила другого провайдера. Информация Stripe о проверке.
Как разобрать несовпадения без лишних подозрений
Рассмотрим вымышленного продавца мебели. На сайте используется торговое название, в заявке указано юридическое лицо, а для выплат предложен счёт другой компании. Первые два названия могут относиться к одному бизнесу, если связь подтверждается. Для третьего необходимо отдельное объяснение до активации.
Хороший запрос звучит конкретно: «Поясните связь заявителя с указанным получателем выплат и предоставьте необходимые подтверждения через защищённый кабинет». В нём обозначен пробел, но нет обвинения и подсказки, как обойти требование. После ответа проверяющий фиксирует использованный источник и основание решения.
Не поручайте менеджерам по продажам согласовывать исключения в личной переписке. Нужен понятный порядок передачи сложного случая ответственному сотруднику. Если схема обслуживания не поддерживается, заявитель должен получить ясный ответ, а не бесконечную последовательность новых запросов.
Полезно также разделять неполноту и противоречие. Нечитаемая страница означает, что сведения пока нельзя проверить. Разные владельцы в двух актуальных документах создают другой вопрос. Для этих ситуаций нужны разные формулировки запроса и разные основания завершения проверки.
Сделайте процесс выполнимым
Заранее объясните, какие страницы требуются, какие форматы принимаются, как исправить ошибку и куда загружать чувствительные сведения. Показывайте понятный статус: ожидаются документы, идёт проверка, требуется уточнение, подключение одобрено. Тогда заявителю не приходится повторно отправлять один и тот же файл, а поддержке проще давать точный ответ.
У заявителя должен быть один ответственный контакт. Он не обязан самостоятельно принимать решение, но должен знать, у кого находится вопрос и какое уточнение действительно нужно. Это особенно важно, когда в подключении одновременно участвуют продажи, поддержка и риск-команда.
Одобрение должно иметь границы
Практический результат проверки удобно описать коротким профилем одобренной деятельности: какое лицо продаёт какие товары, кому, через какие каналы и кто получает расчёт. Это рабочая модель для команды, а не попытка заменить договор. Если менеджер через месяц подключит другое направление, профиль позволит заметить, что обсуждается уже изменившийся бизнес.
Назначьте события для повторного рассмотрения: смена получателя выплат, владельцев, сайта или характера исполнения заказов. Конкретный перечень и обязательность проверки определяются применимыми правилами. Операционная рекомендация проще: значимое изменение должно попадать к ответственному сотруднику, а не бесследно перезаписывать старое поле в CRM. Сохраните прежнее значение, новое значение и основание принятого решения в пределах утверждённого хранения.
Досье, которое переживёт отпуск проверяющего
Возьмите завершённую заявку и дайте её коллеге без устного введения. Он должен различить сведения заявителя, проверенные внешние факты и профессиональное суждение проверяющего. Фраза «всё нормально, говорил с основателем» объединяет эти три слоя и плохо переносится между сменами. Лучше кратко указать, что именно подтвердили, каким источником и какой вопрос остался открытым.
Отдельно фиксируйте исключения из внутреннего процесса: кто вправе их одобрить, почему случай допустим и какое ограничение компенсирует риск. Это не разрешение обходить закон или требования партнёра. Коммерческий интерес в быстром запуске полезно сделать видимым, но он не должен превращаться в скрытое основание решения. Время подключения стоит измерять вместе с долей повторных запросов: быстрое первое письмо мало значит, если потом клиента трижды просят прислать то же самое.
Закройте досье коротким ответом: какое лицо и какую деятельность одобрили, какие источники это подтверждают и какое изменение вернёт заявку на проверку. Остальные страницы должны помогать восстановить этот ответ.
Комментарии · 0
Комментариев пока нет — будьте первым.
Войти · войдите, чтобы оставить комментарий.