Как определить минимальный состав контура по 115-ФЗ
Финтех-компания, которая принимает платежи, выдает займы или проводит операции с цифровыми активами, обязана выполнять требования Федерального закона № 115-ФЗ «О противодействии легализации (отмыванию) доходов, полученных преступным путем, и финансированию терроризма». Закон распространяется на кредитные и некредитные финансовые организации, платежных агрегаторов, микрофинансовые компании, операторов цифровых платформ и ряд других субъектов, перечисленных в статьях 5 и 7.1.
Прежде чем подключать конкретные сервисы, нужно зафиксировать границы контура: какие проверки закон требует проводить, из каких источников брать данные и какие события документировать. Без этого каркаса автоматизация превращается в набор разрозненных интеграций — дорогих в поддержке и уязвимых при проверке Росфинмониторинга или ЦБ.
Контур по 115-ФЗ — совокупность процедур, правил, источников данных и точек фиксации решений, которая позволяет организации идентифицировать клиентов, оценивать риски, выявлять подозрительные операции и передавать сведения регулятору. Минимальный состав определяется тремя вопросами: что проверять, откуда получать данные и что фиксировать.
Какие проверки и решения закрепить в правилах внутреннего контроля
Основой контура служат правила внутреннего контроля (ПВК). Закон обязывает каждого субъекта 115-ФЗ разработать и утвердить ПВК, а затем регулярно актуализировать их при изменениях в законодательстве. С 2025 года требования к составу ПВК существенно расширились: помимо противодействия отмыванию доходов и финансированию терроризма, в документ включают разделы о противодействии финансированию экстремистской деятельности (ФЭД) и финансированию распространения оружия массового уничтожения (ФРОМУ). Постановление Правительства РФ от 02.08.2025 № 1157 определяет актуальные требования к структуре ПВК для организаций, не поднадзорных ЦБ; для поднадзорных действуют нормативные акты Банка России.
Минимальный набор программ внутри ПВК включает несколько обязательных блоков.
Программа идентификации описывает порядок установления личности клиента, его представителя, выгодоприобретателя и бенефициарного владельца. Для физического лица фиксируются ФИО, дата рождения, реквизиты документа, удостоверяющего личность, ИНН (при наличии), адрес регистрации или пребывания. Для юридического лица — наименование, ОГРН, ИНН, адрес, сведения об учредителях и конечных бенефициарах с долей владения свыше 25 %. Программа определяет, в каких случаях применяется упрощенная, стандартная или углубленная идентификация в зависимости от уровня риска клиента.
Программа оценки риска задает критерии присвоения клиенту степени риска: низкой, средней или высокой. Критерии опираются на тип клиента, страну регистрации или проживания, характер деятельности, источник средств, публичный статус (PEP — политически значимое лицо) и историю взаимоотношений. Риск-ориентированный подход позволяет направить ресурсы команды на клиентов с повышенным профилем риска, а для низкорисковых — сократить объем проверок до минимума, допустимого законом.
Программа выявления операций, подлежащих обязательному контролю, и операций с признаками связи с отмыванием доходов или финансированию терроризма фиксирует пороги, типы операций и признаки необычных сделок. Перечень операций обязательного контроля задан статьей 6 закона 115-ФЗ и дополняется приказами Росфинмониторинга. Базовый порог для большинства операций из перечня статьи 6 составляет 1 млн рублей, однако по отдельным категориям (операции по лизингу — 600 тыс. рублей, гособоронзаказ — 10 млн рублей, операции с драгоценными металлами и камнями — 1 млн рублей с августа 2025 года) пороги отличаются. Признаки необычных сделок утверждены приказом Росфинмониторинга от 08.05.2009 № 103 и периодически обновляются.
Программа действий при отказе от выполнения распоряжения клиента описывает порядок принятия решения об отказе в проведении операции и уведомления клиента.
Программа подготовки и обучения кадров определяет периодичность и формат обучения сотрудников, включая вводный и дополнительный инструктаж при изменениях в законодательстве. Организации обязаны назначить специальное должностное лицо (СДЛ), отвечающее за реализацию ПВК и соответствующее квалификационным требованиям.
При проектировании KYC/AML-контура каждая из этих программ переводится в набор автоматизированных проверок: какие данные собирать при онбординге, по каким правилам присваивать риск-профиль, при каких условиях блокировать операцию или отправлять кейс на ручную проверку.
Чем точнее ПВК описывают логику решений, тем проще эту логику реализовать в коде и тем меньше серых зон остается для комплаенс-офицера.
Какие данные и внешние источники нужны контуру
Контур работает с двумя потоками информации: данные, которые предоставляет сам клиент, и данные, которые система получает из внешних источников для верификации и обогащения.
От клиента поступают анкетные сведения и документы. Для физического лица — скан или фото паспорта (страницы с фотографией и регистрацией), селфи для биометрической верификации, контактные данные. Для юридического лица — учредительные документы, выписка из ЕГРЮЛ, сведения о бенефициарных владельцах, документы, подтверждающие полномочия представителя. Закон допускает получение части данных в электронном виде, если организация обеспечивает их подлинность и целостность.
Внешние источники делятся на обязательные и дополнительные. К обязательным относятся перечни, сверка с которыми прямо предусмотрена законом: перечень лиц, причастных к экстремистской деятельности или терроризму (ведет Росфинмониторинг), перечень лиц, причастных к распространению ОМУ (Совет Безопасности ООН), а также перечни в рамках решений Межведомственной комиссии по противодействию финансированию терроризма. Сверка с этими перечнями проводится при идентификации и на постоянной основе — при каждом обновлении списков.
К источникам, необходимым для полноценной идентификации и оценки риска, относятся: база недействительных паспортов МВД, реестры ФНС (для проверки ИНН, статуса юрлица, массовых адресов и директоров), ФССП (для выявления задолженностей и взысканий), реестр банкротов, санкционные списки — как российские, так и международные (ООН, OFAC, ЕС, HMT/OFSI и другие в зависимости от юрисдикции клиентов). Для финтех-компаний, работающих с трансграничными переводами или криптовалютой, набор международных источников расширяется.
Дополнительные источники зависят от риск-аппетита и бизнес-модели: проверка связок ФИО — телефон, ФИО — email, данные кредитных бюро, арбитражные и судебные дела, проверка на статус PEP, скрининг по негативным упоминаниям в СМИ и открытых источниках (adverse media). Чем больше источников подключено к контуру, тем выше точность оценки риска и меньше ложных срабатываний, но каждый источник увеличивает стоимость проверки и время отклика. Оптимальная стратегия — подключать источники каскадно: обязательные сверки для всех клиентов, расширенные — только при повышенном риске или при обнаружении отклонений на предыдущих этапах.
Техническая реализация предполагает API-интеграцию с каждым источником. На практике финтех-компании используют одного или нескольких провайдеров, агрегирующих доступ к десяткам реестров через единый интерфейс. Это сокращает количество интеграций и упрощает обновление при изменении источников.
Какие события и решения контур обязан фиксировать
Закон 115-ФЗ устанавливает обязанность документального фиксирования сведений и их хранения не менее пяти лет с момента прекращения отношений с клиентом. Фиксации подлежат не только итоговые решения, но и промежуточные шаги, которые к ним привели.
| Категория | Описание |
|---|---|
| Первая категория | Результаты идентификации: все собранные данные клиента, копии документов, дата и способ идентификации, присвоенный уровень риска и его обоснование. Эти сведения фиксируются в анкете клиента — ее форму организация определяет самостоятельно в ПВК (за исключением случаев, когда обязательная форма установлена нормативным актом). |
| Вторая категория | Операции, подлежащие обязательному контролю. По каждой такой операции система фиксирует вид операции, дату, сумму, данные участников и основания совершения. Эти сведения передаются в Росфинмониторинг через личный кабинет не позднее трех рабочих дней после совершения операции в формате формализованного электронного сообщения (ФЭС). |
| Третья категория | Подозрительные операции. Если сотрудник или система выявляет операцию с признаками связи с отмыванием доходов или финансированием терроризма, необходимо зафиксировать основания подозрения, принятые меры (дополнительное изучение, отказ от выполнения, заморозка) и направить сведения в Росфинмониторинг в течение трех рабочих дней с момента выявления. |
| Четвертая категория | Решения об отказе. Если организация отказывает клиенту в проведении операции или в заключении договора на основании подозрений, факт отказа, его причины и контекст фиксируются в журнале. Эта информация также передается в Росфинмониторинг. |
| Пятая категория | Результаты пересмотра риск-профиля и обновления данных. При изменении уровня риска клиента, при повторной идентификации или при получении новой информации из внешних источников (например, при попадании клиента в санкционный список) контур фиксирует дату, причину пересмотра, предыдущий и текущий статус. |
С точки зрения архитектуры эти требования транслируются в несколько компонентов: полный аудит-лог всех действий системы и оператора, версионирование правил и моделей принятия решений (чтобы можно было воспроизвести логику решения на дату его принятия), хранилище документов и анкет с контролем целостности, модуль формирования и отправки ФЭС.
Фиксация должна происходить автоматически в момент события, а не постфактум. Разрыв между совершением действия и его документированием — одна из типичных претензий регулятора при проверке. Контур, в котором каждый шаг порождает запись в журнале, снижает этот риск и позволяет комплаенс-команде сосредоточиться на содержательном анализе, а не на заполнении отчетов вручную.
Как собрать KYC-контур на онбординге
KYC-контур на онбординге — цепочка автоматических шагов от момента, когда клиент открывает форму регистрации, до решения: верифицирован, отклонен или направлен на ручную проверку. Задача контура — собрать минимально необходимые данные, проверить их подлинность и оценить риск, уложившись в рамки 115-ФЗ и не потеряв пользователя на полпути.
По закону идентификация должна быть завершена до начала обслуживания клиента — даже для разовой операции. С 11 июля 2025 года действует приказ Росфинмониторинга от 23.04.2025 № 74, который заменил прежние приказы № 100 и № 355 и уточнил требования к составу идентификационных данных, проверке по перечням и фиксации результатов в анкете. Для финтеха это означает: контур должен собрать полный набор сведений, проверить их по обязательным спискам, присвоить группу риска и сохранить аудит-трейл каждого шага — все это предпочтительно без участия оператора.
KYC-контур для финтеха состоит из трех слоев: сбор данных (документы и анкета), проверка подлинности (документ, лицо, признаки подмены) и принятие решения (автоматическое или маршрут на комплаенс-офицера).
Сбор анкеты и документов без ручного ввода
Классический подход — попросить клиента заполнить анкету и загрузить скан паспорта — приводит к ошибкам ввода, низкой конверсии и дополнительной нагрузке на операторов, которые сверяют данные вручную. Автоматизация начинается с замены ручного ввода на AI-OCR и встроенные SDK для захвата документов.
AI-OCR-движок принимает фотографию или видеопоток с камеры устройства, определяет тип документа (паспорт РФ, загранпаспорт, водительское удостоверение, вид на жительство и другие), извлекает текстовые поля (ФИО, дата рождения, серия и номер, адрес регистрации, MRZ) и нормализует их в структурированный JSON. Анкета клиента формируется автоматически: поля заполняются на основе распознанных данных. Клиент видит предзаполненную форму и подтверждает корректность — это быстрее и точнее, чем заполнение с нуля.
Для финтех-компании критично время этого этапа. Современные OCR-платформы распознают документ менее чем за секунду с точностью извлечения полей на уровне 99 % и выше для печатного текста. Для рукописных полей (например, адрес прописки в российском паспорте) точность обычно ниже — порядка 97–98 %, и здесь важно выбирать решение, специализирующееся на конкретных типах документов и языков.
На что обратить внимание при выборе OCR-слоя:
— Покрытие по типам документов и странам: если финтех работает с нерезидентами, нужна поддержка широкого набора ID-документов;
— Наличие SDK для мобильных платформ (iOS, Android) и веб-виджета, чтобы захват изображения происходил внутри приложения, а не через загрузку файла из галереи;
— Контроль качества изображения до отправки на сервер: SDK должен подсказывать пользователю, что фото размыто, обрезано или снято при плохом освещении, иначе процент отказов на этом шаге вырастет;
— Возможность развертывания в защищенном контуре (on-premises или private cloud), если регуляторные требования или политика безопасности не допускают передачу сканов документов на внешний сервер.
Собранные данные дополняются проверками по внешним источникам — следующий обязательный шаг идентификации по 115-ФЗ. Контур автоматически запрашивает подтверждение связки ФИО — паспорт, получает ИНН по ФИО и реквизитам документа, проверяет действительность паспорта, статус самозанятого и другие параметры в зависимости от бизнес-логики. Результаты этих проверок фиксируются в анкете и становятся частью аудит-трейла.
Точность извлечения полей и скорость обработки определяют, какая доля заявок пройдет без ручного вмешательства оператора. AI-OCR-модуль NeuroVision распознает более 10 000 типов документов из 200+ стран на 90+ языках, возвращая структурированный JSON менее чем за секунду с точностью 99,85% для печатного текста. SDK для iOS, Android и веб контролирует качество снимка на устройстве клиента до отправки на сервер, что снижает процент отказов из-за размытых или обрезанных фотографий.
Мы настроим пайплайн распознавания под ваши типы документов, подключим автоматическую сверку с внешними реестрами и обеспечим фиксацию каждого шага в аудит-трейле. Вы получите предзаполненную анкету клиента и скоринг доверия к документу, готовые к передаче в ваш backend. Для оценки покрытия и подбора конфигурации потребуются примеры документов и описание текущего процесса онбординга.
Проверка документа, лица и признаков подмены
Извлечение данных — необходимый, но недостаточный шаг. Контур обязан убедиться, что документ подлинный, лицо клиента совпадает с фотографией в документе, а перед камерой находится живой человек, а не фотография, видеозапись, маска или дипфейк.
Проверка подлинности документа включает несколько уровней. Первый — валидация структуры: корректность расположения полей, наличие обязательных зон, соответствие шрифтов и размеров эталонным шаблонам. Второй — проверка целостности: поиск следов редактирования, несоответствий в цветовой модели, артефактов вклейки или ретуши. Третий — кросс-валидация: MRZ сверяется с данными из визуальной зоны документа, контрольные суммы проверяются алгоритмически. Платформы с широким покрытием используют для этого десятки специализированных алгоритмов, формирующих скоринг доверия к документу.
Биометрическая верификация — сравнение селфи клиента с фотографией из документа (режим 1:1, face matching). Современные алгоритмы верификации лиц достигают точности выше 99,7 % при частоте ложных совпадений на уровне одного на миллион сравнений. Метрика зависит от датасета и условий съемки: качество камеры, освещение и угол наклона головы влияют на результат. SDK на стороне клиента должен контролировать условия захвата и направлять пользователя (повернуть голову ровно, убрать тень, снять очки).
Отдельный слой — liveness-проверка (Presentation Attack Detection, PAD). Она определяет, находится ли перед камерой живой человек или используется подмена. Типы атак, от которых должен защищать контур:
— Предъявление распечатанной фотографии или экрана другого устройства с изображением;
— Воспроизведение заранее записанного видео;
— Использование силиконовых или 3D-масок;
— Дипфейки в реальном времени (face swap через инструменты вроде DeepFaceLive), когда генеративная модель накладывает синтетическое лицо поверх видеопотока атакующего;
— Инъекционные атаки (injection attacks), при которых поддельное изображение или видео подается в систему верификации в обход камеры устройства, напрямую в программный канал.
Пассивный liveness анализирует микросигналы в одном кадре или короткой серии: текстуру кожи, блики, глубину, микродвижения. Активный liveness просит пользователя выполнить случайное действие — повернуть голову, моргнуть, улыбнуться — и оценивает естественность отклика.
Наиболее устойчивые решения комбинируют оба метода и дополняют их проверкой целостности устройства: контролируют, что видеопоток поступает с реальной камеры, а не с виртуального источника.
Для финтех-компаний, выстраивающих KYC-контур по 115-ФЗ, liveness — обязательный элемент защиты от мошеннических регистраций. Без него контур пропускает синтетические личности и учетные записи, открытые по украденным документам с подменой лица. Стоимость пропущенного мошенника для финтеха — прямые потери, риск санкций регулятора, потеря банковского партнера и репутационный ущерб.
Синтетические личности и подмена лица при регистрации — нарастающий вектор атак, от которого не защищает ни стандартная проверка паспорта, ни простое сопоставление селфи с фотографией. KYC-контур NeuroVision объединяет проверку подлинности документа, биометрическое сравнение через алгоритм Enface с точностью верификации 99,74% и пассивный liveness с показателем 99,9%, дополняя их более чем 40 антифрод-алгоритмами — от анализа целостности изображения до обнаружения инъекционных атак.
Мы соберем сценарий проверки, включающий захват документа и селфи через SDK, валидацию подлинности, биометрию и агрегированный скоринг с причинами решения. Платформа развертывается в облаке или в вашем защищенном контуре (on-premises, Docker/VM), что позволяет обрабатывать биометрию без передачи данных за периметр инфраструктуры.
Правила автоматического решения и маршрут на ручную проверку
Собранные данные и результаты проверок должны привести к решению. В выстроенном KYC-контуре оно принимается автоматически для подавляющего большинства заявок и только в спорных случаях передается на ручную проверку.
Автоматическое решение формируется на основе агрегированного скоринга, который учитывает результаты каждого шага: распознавание документа (качество, подлинность, полнота данных), биометрическое сравнение (score совпадения лица), liveness (pass/fail и уровень уверенности), проверки по перечням (санкционные списки, перечень террористов и экстремистов Росфинмониторинга, списки СБ ООН, PEP), а также результаты внешних запросов (действительность паспорта, ИНН, ФССП и другие). Каждому параметру задается пороговое значение, а правила комбинации настраиваются в конфигурации контура.
Типовая логика маршрутизации устроена так. Если все проверки пройдены, скоринги выше пороговых значений и совпадений по перечням не обнаружено — клиент верифицируется автоматически (Straight-Through Processing, STP). Если один или несколько скорингов попали в «серую зону» (например, score лица между 75 и 90 % при пороге автоматического одобрения в 90 %) — заявка направляется на ручную проверку комплаенс-офицеру. Если обнаружены критические признаки (подделка документа, совпадение по санкционному списку, провал liveness) — заявка отклоняется автоматически.
Доля автоматических решений (STP-rate) — ключевая метрика эффективности контура. Для зрелых KYC-систем целевой ориентир — 85–95 % заявок, обработанных без участия оператора. Остальные 5–15 % попадают в очередь ручной проверки. Если доля ручных кейсов устойчиво превышает 20 %, это сигнал: пороги настроены слишком жестко, OCR или liveness-модуль генерируют избыточное количество неопределенных результатов либо в потоке присутствуют систематические проблемы — например, плохое качество фотографий у определенного сегмента клиентов.
Настройка порогов — итерационный процесс. На старте их калибруют по результатам пилота на ограниченной выборке, затем пересматривают по мере накопления статистики. Ключевые метрики для калибровки: доля ложных отказов (FRR — False Rejection Rate, легитимные клиенты, которым отказано ошибочно), доля ложных допусков (FAR — False Acceptance Rate, мошенники, прошедшие проверку) и среднее время до решения. Баланс между FRR и FAR определяет, насколько контур приемлем с точки зрения и бизнеса, и регулятора.
Для ручной проверки контур должен предоставлять оператору полный контекст: исходные изображения документа и селфи, извлеченные данные, результаты каждой проверки с указанием причин попадания в ручной маршрут, историю предыдущих попыток клиента (если они были) и связанные записи в базе. Оператор подтверждает или отклоняет заявку, а его решение и обоснование фиксируются в журнале действий. Эта запись становится частью аудит-трейла, который контур обязан хранить и предъявлять по запросу регулятора.
Весь сценарий — от загрузки фотографии документа до финального решения — должен занимать для клиента не более одной-двух минут при автоматическом прохождении. Увеличение этого времени напрямую влияет на конверсию онбординга: по отраслевым данным, каждый дополнительный шаг или экран в процессе верификации снижает долю завершивших регистрацию на 5–15 %. Для финтеха, где стоимость привлечения клиента может составлять сотни рублей, оптимизация KYC-воронки — вопрос не только комплаенса, но и экономики продукта.
Каждый шаг верификации, не приводящий к решению, увеличивает стоимость привлечения клиента и снижает конверсию. Полный цикл проверки в NeuroVision — документ, биометрия, liveness и AML-скрининг — укладывается в ориентир 35–50 рублей за проверку в зависимости от набора модулей и объема. Интеграция через REST API и готовые SDK занимает от 3 до 7 дней, а до 90% заявок обрабатываются без участия оператора благодаря настраиваемым порогам и правилам маршрутизации в бэк-офисе платформы.
Мы рассчитаем стоимость контура под ваш объем заявок, подберем оптимальный набор модулей и согласуем пороги, чтобы STP-rate соответствовал вашему балансу между конверсией и допустимым уровнем риска. Для расчета потребуются ориентировочный объем проверок в месяц и перечень шагов идентификации, предусмотренных вашими ПВК.
Как собрать AML-контур
KYC-проверка при онбординге фиксирует, кто перед вами. AML-контур отвечает за другое: не попадает ли клиент под ограничения, каков его реальный риск-профиль и что происходит с его операциями после открытия счета. KYC — входной фильтр; AML — постоянно работающая система наблюдения на протяжении всего жизненного цикла клиентских отношений.
По логике 115-ФЗ AML-контур решает три связанных задачи: первичный скрининг клиента по перечням и присвоение уровня риска, непрерывный мониторинг операций с пересмотром статуса при изменении обстоятельств, а также закрытие инцидентов и передача сведений в Росфинмониторинг в установленные сроки.
Проверка по перечням и риск-профиль клиента
Первый шаг AML-контура — автоматическая сверка данных клиента с обязательными и дополнительными перечнями. Обязательный минимум по 115-ФЗ включает три списка: перечень лиц, причастных к экстремизму и терроризму (формирует Росфинмониторинг), перечень Межведомственной комиссии по ПОД/ФТ/ФРОМУ и перечень лиц, причастных к распространению оружия массового уничтожения. Сверка проводится не разово — при каждом обновлении перечня организация обязана проверить всю клиентскую базу и при совпадении незамедлительно применить меры по замораживанию средств.
На практике ограничиваться тремя обязательными списками рискованно. Финтех-компания, работающая с международными платежами или клиентами из разных юрисдикций, нуждается в скрининге по санкционным спискам ООН, OFAC (включая SDN, SSI, NS-CMIC), ЕС, Великобритании (HMT/OFSI), а также по национальным перечням стран присутствия. Отдельного внимания заслуживает проверка на статус PEP и анализ негативного медиафона (adverse media) — эти категории не запрещают обслуживание, но существенно повышают уровень риска и требуют усиленной проверки.
Ключевая техническая проблема — ложные совпадения. При сверке по сотням источников система неизбежно генерирует массу срабатываний из-за частичного совпадения имен, транслитерации, распространенных фамилий. Без механизма оценки значимости совпадений (fuzzy matching с настраиваемыми порогами, учет дополнительных идентификаторов — даты рождения, страны, ИНН) очередь на ручную проверку переполнится в первый же день. Качественный AML-модуль должен ранжировать совпадения по степени достоверности и автоматически отклонять нерелевантные — это позволяет сократить ручную нагрузку на скрининг на 70–80 %.
На основании результатов скрининга и анкетных данных контур присваивает клиенту уровень риска. 115-ФЗ обязывает организации распределять клиентов по группам риска совершения подозрительных операций и применять к каждой группе соответствующий набор мер. Типовая модель предполагает три уровня: низкий (стандартные процедуры, обновление данных не реже раза в год), средний (расширенная проверка документов, источников средств, более частый пересмотр) и высокий (углубленная проверка, одобрение руководством, усиленный мониторинг операций). Критерии отнесения к группам определяет сама организация в ПВК, но ориентиры задают рекомендации Банка России и типологии Росфинмониторинга.
Риск-профиль — не статичная метка. Он пересчитывается при поступлении новых данных: смена юрисдикции, появление в санкционных списках, нетипичная активность, негативные публикации. Контур, который присваивает риск один раз и не пересматривает его, не соответствует требованиям закона и создает уязвимость для компании.
Присвоение уровня риска при онбординге — только первый шаг; без постоянной сверки с обновляемыми перечнями и отслеживания изменений в статусе клиента контур теряет актуальность в течение недель. AML-модуль NeuroVision подключается к более чем 1 700 источникам — от перечней Росфинмониторинга и списков ООН/OFAC/ЕС до баз PEP и adverse media-с ежедневным обновлением ключевых списков. При изменении статуса клиента система автоматически инициирует пересмотр риск-профиля и направляет уведомление ответственному специалисту.
Мы подключим AML-контур к вашим источникам данных и настроим правила скрининга, пересмотра и эскалации под требования вашего ПВК. Ориентировочный срок интеграции — 1–2 дня; кейс-менеджмент с полным аудит-логом и историей действий по каждому клиенту доступен в операторском интерфейсе платформы.
Мониторинг операций и пересмотр статуса клиента
После онбординга AML-контур переходит в режим непрерывного мониторинга. Его задача — выявлять операции, подлежащие обязательному контролю (статья 6 115-ФЗ), и операции с признаками подозрительности (статья 7).
Обязательному контролю подлежат операции, сумма которых равна или превышает установленный порог и которые относятся к определенным типам: снятие или зачисление наличных на счет юрлица, переводы в пользу нерезидентов, сделки с недвижимостью и ряд других. Базовый порог для большинства категорий — 1 млн рублей; для операций по лизингу — 600 тыс. рублей; для сделок с недвижимостью порог устанавливается отдельным приказом Росфинмониторинга и не может быть ниже 5 млн рублей. Перечень регулярно расширяется — с 2025 года под контроль попали операции с цифровыми активами, ужесточены требования к ювелирной отрасли. Для операций обязательного контроля закон требует документальной фиксации и передачи сведений в Росфинмониторинг не позднее трех рабочих дней после совершения.
Подозрительные операции — более сложная категория. Фиксированного порога суммы здесь нет. Контур должен выявлять отклонения от обычного поведения клиента, признаки структурирования платежей (дробление крупных сумм), транзакции с высокорисковыми юрисдикциями, нетипичные схемы движения средств. Для этого используются правила (rule-based логика) и, на более зрелом уровне, поведенческие модели, анализирующие совокупность признаков каждой транзакции: сумму, частоту, контрагентов, географию, время, отклонение от профиля клиента.
Практический минимум для финтех-компании — набор настраиваемых правил мониторинга, покрывающих типологии Росфинмониторинга (они публикуются в информационных письмах и на сайте ведомства). Каждое правило задает условие срабатывания, порог и действие: автоматическая блокировка, маршрутизация в очередь комплаенс-офицера или фиксация для дальнейшего анализа. Чем точнее настроены правила, тем меньше ложных срабатываний и тем быстрее команда обрабатывает реальные инциденты.
Пересмотр статуса клиента — обязательная часть ongoing-мониторинга. Если клиент попадает в обновленный перечень, его операции систематически вызывают алерты или выявлены новые обстоятельства (смена бенефициара, негативные публикации), контур обязан инициировать пересмотр риск-профиля. При переходе в группу высокого риска применяются усиленные меры: запрос дополнительных документов, ограничение отдельных операций, эскалация на уровень руководства. В отдельных случаях организация вправе отказать в проведении операции или расторгнуть договор, уведомив Росфинмониторинг.
Для клиентов, не отнесенных к группе низкого риска, закон требует обновления сведений не реже одного раза в год, а при возникновении сомнений в достоверности данных — в течение семи рабочих дней. Контур должен автоматически отслеживать сроки обновления и генерировать задачи для ответственного специалиста.
Как закрывать инцидент и передавать сведения в Росфинмониторинг
Выявленный алерт — еще не инцидент. Прежде чем передать сведения в Росфинмониторинг, комплаенс-офицер должен провести внутреннее расследование: собрать контекст операции, проверить документы, оценить экономический смысл, зафиксировать основания для принятого решения. Контур обеспечивает этот процесс через механизм кейс-менеджмента: карточка инцидента, прикрепленные документы, история действий, комментарии, статусы и аудит-лог каждого шага.
Сроки передачи сведений жестко регламентированы. Для операций обязательного контроля — не позднее трех рабочих дней после совершения операции. Для подозрительных операций — не позднее трех рабочих дней после выявления. Для приостановленных операций — незамедлительно. Нарушение сроков влечет административную ответственность по статье 15.27 КоАП РФ: для должностных лиц — штраф до 50 тыс. рублей, для юридических лиц — до 500 тыс. рублей либо административное приостановление деятельности на срок до шестидесяти суток; при повторных и грубых нарушениях возможна дисквалификация руководителя.
Технически передача осуществляется через личный кабинет на сайте Росфинмониторинга в формате формализованных электронных сообщений (ФЭС). Каждое сообщение подписывается усиленной квалифицированной электронной подписью и содержит структурированные данные: сведения об участниках операции (включая бенефициарного владельца), характеристики операции, основания для направления сообщения. Существует несколько типов ФЭС в зависимости от вида события — для обязательного контроля, для подозрительных операций, для информирования о схемах подозрительной деятельности и других случаев.
Зрелый AML-контур формирует черновик ФЭС автоматически на основе данных из карточки инцидента. Комплаенс-офицер проверяет полноту, при необходимости дополняет и отправляет. Это критически важно для соблюдения сроков: при большом потоке алертов ручное заполнение каждого сообщения с нуля съедает часы рабочего времени и увеличивает риск ошибки.
Все материалы по операциям, сведения о которых передавались в Росфинмониторинг, а также документы идентификации клиентов должны храниться не менее пяти лет с момента прекращения отношений с клиентом. Контур обеспечивает доступ к этим данным для внутреннего аудита и проверок регулятора-с полным аудит-логом действий, позволяющим восстановить хронологию каждого решения.
При проектировании AML-контура стоит сразу заложить возможность адаптации к изменениям. 115-ФЗ — один из наиболее часто обновляемых федеральных законов: только с середины 2025-го по март 2026 года вступили в силу более десяти редакций, расширивших перечень субъектов контроля, изменивших пороговые значения для отдельных категорий операций и обновивших требования к ПВК. Росфинмониторинг регулярно выпускает новые приказы, информационные письма и типологии. Контур, в котором обновление правил и источников требует привлечения разработчиков, будет систематически отставать от регуляторики — а значит, создавать для компании юридический и финансовый риск.
Регуляторика в сфере ПОД/ФТ обновляется чаще, чем большинство внутренних IT-систем: новые пороги, расширение перечней контролируемых операций, актуализированные типологии Росфинмониторинга требуют оперативной реакции. Бэк-офис платформы NeuroVision позволяет комплаенс-команде самостоятельно менять правила мониторинга, пороги скоринга и сценарии маршрутизации без обращения к разработчикам. Каждое изменение фиксируется в журнале действий с указанием автора, даты и причины, что закрывает требования регулятора к документированию и версионированию правил.
Мы проведем аудит вашего текущего набора правил, предложим конфигурацию контура с учетом актуальной редакции 115-ФЗ и настроим операторский интерфейс под роли вашей команды. Тестовый период платформы составляет до одного месяца — этого достаточно, чтобы оценить эффект на реальном потоке заявок и операций.
Как не перегрузить команду
Комплаенс-контур по 115-ФЗ генерирует поток алертов, каждый из которых требует внимания оператора. Чем больше клиентов и операций проходит через систему, тем быстрее растет этот поток — и тем выше риск, что команда начнет пропускать реальные угрозы, погруженная в разбор ложных совпадений. Задача не в том, чтобы нанять больше людей, а в том, чтобы до оператора доходили только те кейсы, которые действительно нуждаются в человеческом суждении.
Три направления позволяют удержать нагрузку в управляемых рамках: снижение объема ложных срабатываний, прозрачный учет очереди кейсов и регулярная калибровка правил.
Как подавлять ложные и повторные срабатывания
Основной источник перегрузки — ложноположительные алерты (false positives). В классических rule-based системах мониторинга их доля достигает 95–99 %: система находит совпадение по имени с санкционным списком, хотя речь идет о другом человеке со схожим написанием. Комплаенс-офицер вынужден открывать карточку, проверять контекст, фиксировать решение — и так сотни раз в день.
Снизить долю ложных срабатываний можно на нескольких уровнях.
Точная настройка порогов fuzzy matching. Алгоритмы нечеткого сопоставления неизбежны: данные приходят с опечатками, в разных транслитерациях, с сокращениями. Порог чувствительности нужно калибровать отдельно для каждого типа списка и категории клиентов, а затем пересматривать по мере накопления статистики разборов. Слишком мягкий порог дает шквал совпадений, слишком жесткий — пропускает реальные хиты.
Обогащение контекста при скрининге. Совпадение по одному полю (имя) — слабый сигнал. Если система одновременно сверяет дату рождения, гражданство, ИНН или другой уникальный идентификатор, большинство ложных хитов отсеиваются автоматически. Чем больше атрибутов участвует в оценке значимости совпадения, тем меньше кейсов уходит на ручную проверку. В AML-модуле NeuroVision оценка значимости совпадений реализована как штатная функция: система сопоставляет набор признаков и выдает оператору взвешенный скоринг с причинами, что позволяет сократить ручную нагрузку до 80 %.
Подавление повторных срабатываний. Если оператор уже разобрал кейс и зафиксировал решение «false positive» — повторный алерт по тому же клиенту и тому же списку не должен снова попадать в очередь. Для этого в кейс-менеджменте фиксируется идентификатор решения: при следующем скрининге система проверяет, не было ли аналогичного разбора, и подавляет дублирующий алерт. Подавление должно автоматически сниматься при изменении данных клиента или обновлении источника — иначе возникает комплаенс-риск.
ML-модели для приоритизации. Машинное обучение на исторических данных разборов позволяет ранжировать алерты по вероятности реального совпадения. Модель учитывает паттерн: какие комбинации признаков чаще оказывались ложными, а какие — подтверждались. Это не заменяет оператора, но меняет порядок разбора: наиболее вероятные true positive поднимаются в начало очереди, а типовые false positive уходят вниз или закрываются автоматически с фиксацией в журнале.
Как считать очередь кейсов и нагрузку на комплаенс
Управлять нагрузкой невозможно, если она не измерена. Комплаенс-подразделение в финтехе нуждается в тех же операционных метриках, что и любой сервис с очередью задач, — но с поправкой на регуляторные сроки.
Ключевые показатели, которые стоит отслеживать на дашборде.
Размер очереди (backlog) — количество открытых кейсов, ожидающих разбора. Если очередь стабильно растет, текущая емкость команды не справляется с потоком. Полезно отслеживать не только абсолютное число, но и возраст самого старого кейса: если он приближается к регуляторному дедлайну, это критическая ситуация.
Среднее время закрытия кейса показывает, сколько длится разбор от момента появления алерта до фиксации решения. Разброс нормален: скрининговый false positive закрывается за минуты, а расследование подозрительной операции может занимать дни. Метрику лучше сегментировать по типу кейса — скрининг, мониторинг транзакций, пересмотр риск-профиля.
Доля автоматических закрытий — процент кейсов, которые система закрывает без участия оператора (автоматический false positive, подавление дубликата, автоматическое одобрение по риск-правилу). Показатель напрямую отражает эффективность настройки контура. Для зрелых систем ориентир — 80–90 % кейсов без ручного вмешательства.
Пропускная способность оператора — количество кейсов, закрытых одним оператором за смену, с разбивкой по типу и сложности. Метрика помогает прогнозировать, при каком росте клиентской базы текущий штат перестанет справляться, и планировать либо найм, либо дополнительную автоматизацию.
Все перечисленные показатели доступны через бэк-офис платформы, если он предусматривает журнал действий и аналитику по операциям. В NeuroVision операторский интерфейс фиксирует историю действий по каждому кейсу и агрегирует данные на дашбордах — это дает основу для принятия решений о нагрузке без дополнительных инструментов.
Отдельно стоит учитывать регуляторные дедлайны. 115-ФЗ и подзаконные акты устанавливают конкретные сроки: на фиксирование операции обязательного контроля, на направление сведений в Росфинмониторинг. Если средний возраст кейса приближается к этим срокам, это не просто операционная проблема — это комплаенс-риск с потенциальными санкциями.
Как пересматривать правила без расширения штата
Правила мониторинга устаревают. Схемы отмывания эволюционируют, регуляторные требования обновляются (с середины 2025-го по март 2026 года 115-ФЗ претерпел более десяти редакций, каждая из которых требует актуализации ПВК), профиль клиентской базы меняется по мере роста бизнеса. Если правила не пересматривать, одни начинают генерировать бесполезный шум, другие перестают обнаруживать реальные риски.
Пересмотр правил — не разовый проект, а регулярный цикл: анализ, гипотеза, изменение, замер эффекта.
Анализ эффективности существующих правил. Раз в квартал (или чаще, если объемы растут) полезно выгружать статистику по каждому правилу: сколько алертов оно сгенерировало, какая доля оказалась true positive, какое среднее время разбора. Правила с нулевой или околонулевой конверсией в реальные кейсы — кандидаты на пересмотр порогов или отключение. Правила с высокой конверсией, но избыточным потоком — кандидаты на уточнение условий.
Итеративная калибровка. Изменение правила не вводится сразу в боевом режиме. Безопаснее запустить новую версию параллельно: система считает алерты по старому и новому правилу, но в очередь оператора попадают только по старому. Через период наблюдения сравниваются результаты: снизился ли шум, не пропущены ли реальные инциденты. После подтверждения гипотезы правило переключается.
Учет регуляторных изменений. Каждая новая редакция 115-ФЗ и подзаконных актов может менять перечень контролируемых операций, пороги сумм, состав списков и сроки реагирования. Эти обновления должны отражаться не только в документах, но и в логике автоматизированного контура: какие сценарии мониторинга активированы, какие пороги применяются, какие списки подключены. Без связки между регуляторным документом и настройками системы возникает разрыв, который фиксируется при проверке.
Документирование изменений. Каждое изменение правила — новый порог, новое условие, деактивация сценария — фиксируется в журнале с указанием причины, автора и даты. При проверке регулятором или внутреннем аудите потребуется объяснить, почему правило было изменено и на основании каких данных принято решение. Кейс-менеджмент и журнал действий в бэк-офисе платформы закрывают эту задачу, если настроены на фиксацию не только операторских решений, но и административных действий над правилами.
Три направления в совокупности — подавление шума, измерение нагрузки и регулярная калибровка — позволяют масштабировать комплаенс-контур вместе с бизнесом. Рост клиентской базы в два-три раза не должен автоматически означать пропорциональное увеличение штата: если контур настроен корректно, основная нагрузка ложится на автоматику, а операторы работают с кейсами, которые действительно требуют экспертного суждения.
Комплаенс по 115-ФЗ перестает быть источником операционного давления, когда KYC и AML-контур спроектирован как единая архитектура с четкими правилами маршрутизации, каскадными проверками и автоматической фиксацией каждого решения. Идентификация на онбординге, скрининг по перечням, мониторинг операций и передача сведений в Росфинмониторинг укладываются в управляемый процесс, если пороги откалиброваны по реальной статистике, ложные срабатывания подавляются на уровне системы, а нагрузка на команду измеряется так же строго, как регуляторные дедлайны.
Финтех-компания, которая выстраивает контур от ПВК до дашборда очереди кейсов, получает не просто соответствие закону, а масштабируемый механизм, способный расти вместе с клиентской базой без пропорционального расширения штата. Практический следующий шаг — провести аудит текущих процедур, определить долю ручных операций на каждом этапе и запустить пилот автоматизации на ограниченном сегменте, чтобы замерить эффект до полного развертывания.
Переход от ручных проверок к автоматизированному контуру начинается с измерения: какой объем операций обрабатывается вручную, где возникают задержки и какие этапы генерируют наибольшую долю ложных срабатываний. Мы проведем аудит ваших текущих процедур идентификации и мониторинга, подберем конфигурацию модулей — от AI-OCR и биометрической верификации до AML-скрининга по 1 700+ источникам — и запустим пилот на ограниченном сегменте клиентской базы. В ходе пилота соберем ключевые метрики: STP-rate, долю ложных срабатываний, среднее время обработки заявки и нагрузку на операторов.
По итогам вы получите обоснованную оценку эффекта автоматизации и согласованный план масштабирования на весь контур. Платформа разворачивается в облаке или в вашей инфраструктуре (on-premises, Docker/VM), а тестовый период составляет до одного месяца.