Подозрительная операция: признаки и порядок действий СФМ
Как субъекту финансового мониторинга выявить подозрительную операцию, провести эскалацию, зафиксировать решение и не смешать её с пороговой.
Операция на 900 тысяч тенге может оказаться подозрительной, а операция на 50 миллионов — только подпасть под формальный порог финансового мониторинга. В Казахстане сумма не заменяет оценку: пункт 3 статьи 4 Закона о ПОД/ФТ прямо распространяет финансовый мониторинг на подозрительные операции независимо от формы и суммы.
Для СФМ отсюда следует архитектурная проблема. Порог, основание для изучения, совпадение со списком, техническая ошибка и окончательная квалификация — это пять разных событий. Если свести их к одному красному статусу, система либо автоматически обвиняет клиента по слабому сигналу, либо теряет обязательный маршрут сообщения внутри общей очереди ошибок.
Ниже — воспроизводимая модель решения: что считать наблюдением, кто проверяет гипотезу, когда возникает юридическое событие, какой срок запускается и какие данные должны остаться в журнале. Она не заменяет ПВК конкретного СФМ, а показывает, как перевести нормы в отдельные состояния процесса.
Коротко
Пороговая операция и подозрительная операция имеют разные основания.
Сигнал должен называть наблюдение и вопрос для проверки.
Итог принимает уполномоченный работник по действующей версии ПВК.
Журнал сохраняет правило, источники, действия участников и мотивированное решение.
Клиенту нельзя раскрывать внутреннюю AML-квалификацию; допустимый ответ фронт-офиса проектируют отдельно.
Пять событий нельзя объединять в один статус
Закон Казахстана о ПОД/ФТ задаёт разные правовые основания. В интерфейсе и журнале им нужны разные типы события.
Событие | Что запускает | Следующий шаг | Чего оно не доказывает |
|---|---|---|---|
Пороговая операция | Одновременно выполнены сумма и вид операции из пункта 1 статьи 4 | Обработать сведения по установленному маршруту | Преступное происхождение средств |
Основание для изучения | Необычная или лишённая видимой цели операция, уклонение от проверки и другие основания пункта 4 статьи 4 | Изучить операцию и зафиксировать результат | Что операция уже признана подозрительной |
Подозрительная операция | Возникли подозрения из определения статьи 1 либо сделан вывод по ПВК и результатам изучения | Запустить сообщение и применимый процесс статьи 13 | Виновность клиента |
Совпадение со списком | Данные похожи на запись в используемом перечне | Проверить идентификаторы и применить правило конкретного перечня | Что найдено именно это лицо |
Техническая ошибка | Не получены данные или не отработал модуль | Повторить, восстановить либо обработать исключение | Наличие AML-риска |
Последние два события нельзя смешивать. Спорное совпадение требует содержательной проверки, а ошибка API — технического восстановления. Один статус verification failed скрывает причину и не позволяет назначить правильного владельца.
Закон называет четыре обязательных основания для изучения
Пункт 4 статьи 4 требует изучать и фиксировать результат, если клиент:
совершает сложную, необычно крупную операцию либо операцию без очевидного экономического смысла или видимой законной цели;
пытается уклониться от надлежащей проверки или финансового мониторинга;
совершает операцию, которая предположительно направлена на обналичивание преступных доходов;
проводит операцию с участником из государства или территории, недостаточно выполняющих рекомендации ФАТФ, либо с использованием счёта в таком государстве.
Это основания открыть анализ, а не готовые ответы. Например, отсутствие видимой цели означает, что аналитику нужно установить контекст и проверить объяснение; закон не превращает первоначальную непонятность в автоматическую подозрительность.
Сигнал должен вести к проверяемой гипотезе
Полезное правило называет наблюдение и вопрос. Например: операция не соответствует обычному обороту клиента; средства быстро проходят через несколько связанных получателей; клиент избегает объяснения цели; реквизиты или устройство связаны с ранее выявленным риском.
Сигнал запускает сбор контекста, но не выносит приговор. Аналитик проверяет данные клиента и бенефициара, историю, экономический смысл, документы и связи. Результатом становится одно из решений: оснований недостаточно; нужен дополнительный запрос; требуется действие по отдельной норме; операция признана подозрительной.
Полезная формула сигнала выглядит так:
наблюдение → отличие от ожидаемого поведения → вопрос → необходимые данные → срок анализа.
Фраза «подозрительный перевод» не задаёт работу. Запись «в течение десяти минут средства поступили и ушли новому получателю; проверить экономический смысл, связь участников и объяснение клиента» создаёт проверяемую гипотезу. Числа и интервалы в реальном правиле СФМ определяет по собственной риск-модели и ПВК, а не копирует из этого примера.
Рабочий маршрут состоит из шести событий
Система или сотрудник создаёт сигнал с конкретным признаком в рамках процедур ПОД/ФТ.
Карточка подтягивает профиль риска и связанные операции.
Аналитик фиксирует проверенные источники и объяснение клиента.
Уполномоченный работник принимает решение по ПВК.
При наличии основания формируется сообщение в установленном формате.
Система сохраняет версию правила, данные и действия участников.
Правила представления сведений определяют прикладной формат, а основные события и сроки закреплены в законе. Их нельзя хранить одной настройкой AML deadline, потому что отсчёт начинается от разных событий.
Юридическое событие | Срок по действующей редакции закона | Что должно запускать таймер |
|---|---|---|
Операция признана подозрительной до проведения | Сообщить незамедлительно до проведения | Зафиксированное решение о признании операции подозрительной |
Уже совершённая операция признана подозрительной | Не позднее 24 часов после признания | Время утверждения решения, а не первоначального сигнала |
Отказ, прекращение отношений или замораживание в предусмотренных статьёй 13 случаях | Не позднее следующего рабочего дня | Конкретное решение или действие СФМ |
Таблица служит навигацией, а не заменяет проверку нормы для конкретного события. СФМ должен сверять действующую редакцию закона, правил и собственный регламент перед настройкой срока.
Карточка решения должна воспроизводить путь от сигнала до сообщения
Для проверки недостаточно сохранить итог reported=true. Минимальная аналитическая карточка связывает:
Поле | Что фиксировать | Зачем |
|---|---|---|
Событие | Порог, основание для изучения, совпадение, подозрительная операция или техническая ошибка | Не смешивать правовые и технические маршруты |
Наблюдение | Конкретные факты без обвинительной формулировки | Повторно проверить срабатывание |
Контекст | Профиль клиента, связанные операции, документы и объяснение | Показать полноту анализа |
Норма и ПВК | Статья, версия правила и признак | Воспроизвести основание решения |
Решение | Закрыть, запросить данные, эскалировать, сообщить или применить отдельную процедуру | Зафиксировать результат и владельца |
Время | Создание сигнала, признание, сообщение и последующее действие | Правильно рассчитать применимый срок |
Это авторская модель журнала, а не установленная законом форма. Её ценность в том, что момент первоначального сигнала отделён от момента признания операции подозрительной: для уже совершённой операции именно после признания запускается установленный законом срок сообщения.
Запрет разглашения требует отдельного сценария фронт-офиса
Пункт 5 статьи 11 запрещает СФМ и их работникам информировать клиентов и иных лиц о принимаемых в отношении них мерах ПОД/ФТ. Закон отдельно допускает информирование о замораживании операций, отказе в установлении деловых отношений и отказе от проведения операции. Это не разрешение раскрыть внутреннее правило, содержание сообщения или аналитическую гипотезу.
Поэтому фронт-офису нужен утверждённый нейтральный ответ для каждого состояния. Доступ к аналитической карточке ограничивают по роли, а обращение к ней фиксируют. Формулировку ответа согласуют с юристом: слишком подробное объяснение создаёт риск разглашения, а произвольное молчание может противоречить обязанности сообщить клиенту о самом отказе или замораживании.
AML-скрининг — один источник сигнала
AML Screening Biometric.Vision заявляет проверку физических и юридических лиц по санкционным, PEP и другим указанным на странице перечням, ранжирование совпадений, ручную проверку спорных случаев и повторный мониторинг. Такой результат можно связать с подтверждённой личностью клиента.
Скрининг не анализирует весь экономический смысл операции и не заменяет решение СФМ. В архитектуре его результат остаётся одним из входов рядом с профилем клиента, транзакционными признаками, связанными лицами и документами.
Начните с десяти действующих правил и для каждого проверьте пять вещей: какое событие создаётся, кто его владелец, какие данные нужны для решения, какой срок запускается и что увидит фронт-офис. Такой тест быстрее обнаружит смешение сигналов, чем общее требование «автоматизировать AML».
Материал носит информационный характер и не заменяет ПВК или юридическое заключение для конкретного СФМ.
Готовы усилить проверку клиентов?
500 проверок бесплатно каждый месяц · без карты · без контракта · без звонка от менеджера.
