Чек-лист проверки компании: что проверяет KYB

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

Чем проверка компании отличается от проверки человека

Проверка личности удостоверяет конкретного человека: его имя, документ, иногда адрес. Проверка компании удостоверяет организацию — запись в реестре, её реквизиты и её связи.

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

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

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

Что обычно запрашивают при проверке компании

Перечень зависит от отрасли и от страны, но ядро устойчиво.

• Свидетельство о регистрации или выписка из реестра.
• Налоговый номер или номер VAT.
• Подтверждение юридического адреса.
• Сведения о владельцах и о конечных выгодоприобретателях.
• Лицензии и разрешения, если деятельность их требует.
• Банковские реквизиты для расчётов.

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

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

Почему у компании несколько уровней владения?

Потому что владеть организацией может другая организация, а той — третья.

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

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

Именно эта многослойность делает проверку компании тяжелее проверки личности по объёму работы.

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

Какие статусы проходит заявка

Путь заявки удобно описать как набор состояний.

Состояния не должны исчезать из интерфейса. Пользователь, чья заявка отклонена, обязан видеть причину, иначе он будет отправлять те же документы снова и снова.

Отдельно нужен статус «требуется повторная проверка». Он наступает не из-за ошибки, а из-за времени: документы устаревают, состав владельцев меняется, лицензия истекает.

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

Что делать с отказами, которые можно исправить?

Отказы делятся на две группы, и смешивать их нельзя.

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

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

В обоих случаях сообщение должно быть конкретным. Формулировка вида «документы не подошли» не даёт ничего ни пользователю, ни поддержке.

Какие поля документа нужны и почему у них есть срок

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

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

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

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

Для разработчиков: песочница, изоляция и запрет на отключение контроля

Тестируйте проверку в песочнице. Отдельное окружение, отдельные ключи, отдельные документы — так вы не смешаете учебные заявки с рабочими.

Состояния должны меняться по явным переходам. Не давайте возможности перепрыгнуть с «не отправлена» сразу на «одобрена»; каждый переход — отдельная операция со своей проверкой прав.

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

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

Храните след решений. Кто, когда и на основании каких документов одобрил заявку — эти сведения нужны и при разборе спора, и при проверке со стороны регулятора.

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

Что делать дальше

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

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

О смежных темах рассказано в статьях о регистрационном номере компании и о проверке налогового номера, а о том, какие данные допустимо использовать в таких прогонах, — в материале о границах применения вымышленных данных.

Этот чек-лист носит общий характер, не является юридической консультацией и не заменяет требования вашего регулятора.