Правила внутреннего контроля ПОД/ФТ в Казахстане

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

Поэтому правила внутреннего контроля (ПВК) нельзя проверять только чтением документа. Рабочий контроль прослеживается от нормы до системного события, роли, решения и доказательства исполнения. Если хотя бы одно звено отсутствует, новая редакция ПВК может не изменить реальный процесс.

Ниже — метод трассировки ПВК на одном клиентском пути. Он отделяет общий каркас статьи 11 Закона о ПОД/ФТ от отраслевых требований и показывает, как найти расхождение между политикой, конфигурацией системы и журналом.

Коротко

• ПВК зависят от категории СФМ и профильного акта; универсального текста для всех нет.

• Каждая программа должна быть связана с владельцем, системным правилом и доказательством исполнения.

• Совпадение или технический отказ требуют заранее определённого маршрута исключения.

• Изменение продукта, поставщика или модели риска проверяют одновременно в ПВК и конфигурации системы.

• Отчёт проверка пройдена недостаточен: должна восстанавливаться версия правила и причина итогового решения.

Единого текста ПВК для всех организаций нет

Статья 11 Закона Казахстана о ПОД/ФТ задаёт обязанность субъектов финансового мониторинга принять правила внутреннего контроля и программы, предусмотренные законом. Детальные требования различаются по видам СФМ и утверждаются соответствующими государственными органами и регуляторами.

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

Общая норма задаёт пять программ, отраслевой акт — детали

Статья 11 Закона о ПОД/ФТ закрепляет общий каркас программ:

• организация контроля и полномочия ответственного лица;

• управление риском ОД/ФТ/ФРОМУ, включая риск использования технологических достижений;

• идентификация клиентов;

• мониторинг и изучение операций;

• подготовка и обучение работников.

Это не готовое оглавление для любой организации. Детали устанавливают органы, указанные в статье 11 Закона о ПОД/ФТ, для соответствующих категорий СФМ. Поэтому банк, платёжная организация и участник нефинансового сектора не должны копировать один комплект требований.

Например, действующие Требования к ПВК для платёжных организаций распространяются именно на платёжные организации. В них описаны их роли, агенты, оценка рисков и автоматизированные системы. Эти положения полезны как иллюстрация глубины контроля, но их нельзя объявлять универсальной нормой для всех СФМ.

Для платёжной организации система сама становится частью ПВК

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

Практическое следствие шире наличия AML-модуля. Контроль нужно проектировать так, чтобы система отвечала на четыре вопроса:

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

У каждого правила должны быть вход, решение и след

Фраза «клиент проходит проверку» не определяет контроль. Рабочая запись отвечает на вопросы: при каком событии запускается проверка, какие данные нужны, кто рассматривает исключение, какой результат блокирует операцию и сколько хранится доказательство.

Например, для совпадения с PEP нужны источник списка, дата, параметры совпадения, решение аналитика, согласование и режим дальнейшего мониторинга. Для некачественного документа — причина отказа, число повторов и маршрут ручной проверки. Такая детализация переводит ПВК из текста в исполнимый процесс.

Рабочую норму удобно переводить в карточку контроля:

Карточка не заменяет текст ПВК. Она связывает его с настройкой и тестом. Перед выпуском новой версии команда проходит положительный сценарий, пограничное совпадение, технический отказ и повторную попытку; для каждого случая ожидаемый маршрут должен совпасть с утверждённым документом.

Один сквозной тест выявляет четыре типа разрыва

Возьмём дистанционное установление отношений с клиентом, по которому найдено неоднозначное PEP-совпадение. Это тестовый сценарий, а не предписание конкретному СФМ.

• Норма и ПВК. Определено, какой источник используется, кто рассматривает совпадение и какое последующее действие допускается.

• Конфигурация. Система запускает нужную версию проверки для нужной категории клиента и не превращает спорное совпадение в автоматический отказ.

• Решение. Назначенный сотрудник получает исходные идентификаторы, фиксирует сравнение и выбирает мотивированный результат.

• Доказательство. Журнал связывает клиента, источник списка, версию правила, автоматический результат и решение человека.

Такой тест создаёт information gain: вместо вывода «ПВК есть» организация получает точное место разрыва и владельца исправления.

Изменение системы требует совместного релиза ПВК и конфигурации

Новый продукт, канал, поставщик данных или модель риска может изменить порядок проверки. Общая программа управления риском по статье 11 Закона о ПОД/ФТ прямо учитывает риск использования технологических достижений. В отраслевых требованиях для платёжных организаций отдельно предусмотрена оценка рисков до запуска новых продуктов, практик и механизмов передачи.

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

Минимальная карточка изменения содержит:

• описание старого и нового маршрута;

• затронутые пункты ПВК и системные правила;

• владельца юридического и технического согласования;

• тесты обычного, пограничного и аварийного сценария;

• дату включения и план отката;

• первое наблюдение после релиза и критерий пересмотра.

Эта карточка не установлена законом как форма. Она предотвращает ситуацию, когда текст, код и рабочая инструкция обновляются в разные дни.

Оркестратор Biometric.Vision заявляет настройку последовательности проверок документа, лица, живости и AML с условиями выполнения. Он не формирует ПВК и не определяет правовую обязанность. Конфигурация должна следовать утверждённой матрице контроля, а версия сценария и результаты модулей — попадать в доказательную цепочку заказчика.

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

Материал носит информационный характер. Состав и требования к ПВК нужно проверять по актуальному отраслевому акту для категории конкретного СФМ.