В день прихода проверяющего VASP программа комплаенса должна предоставить записи, а не обещания. Регуляторная проверка заставляет по запросу показать, что мониторинг транзакций действительно работает. Проверяющий приходит не читать политику, а проследить конкретное уведомление от обнаружения до решения и подтвердить запись каждого шага. Если решения автоматизированы, ожидайте дополнительного вопроса: законность автоматического закрытия уведомлений зависит от доказуемости автоматизации. Отсутствие такой цепочки у VASP воспринимается как пробел программы независимо от качества механизма проверки. Руководство описывает запросы проверяющих в риск-ориентированном подходе FATF: готовность журналов, объяснение оценок без непрозрачной модели, полноту STR и пробную проверку. Общий процесс мониторинга, создающий записи, представлен в Phalcon Compliance. Эта страница — часть центра знаний о KYT.
Что запрашивают проверяющие в рамках риск-ориентированного подхода FATF
Их рамка — риск-ориентированный подход FATF к VASP, основанный на Рекомендации 1. Она обязывает выявлять, оценивать и понимать риски отмывания и финансирования терроризма и применять соразмерный контроль. Это раскладывается на три проверяемых элемента: постоянный мониторинг, выявление подозрительных транзакций и пригодные для аудита записи. KYT как мониторинг ончейн-риска относится к первым двум: наблюдает за каждым пополнением, выводом и связью с контрагентом, оценивает риск и создаёт уведомления для процесса сообщений о подозрительных транзакциях.
Важна граница того, чем обязанность не является. Рекомендация 16 FATF, Travel Rule, — отдельное обязательство передачи сведений об отправителе и получателе между VASP. KYT его не выполняет. Он выполняет мониторинговую сторону Рекомендаций 10 и 11: наблюдать, выявлять и хранить записи, доказывающие оба действия.
На практике запрашивают оценку риска, обосновавшую охват мониторинга, выборку уведомлений с расследованиями, поданные сообщения и стоящие за ними записи, а также журнал, соединяющий шаги. Он позволяет читать уведомление, расследование, решение и подачу как одну непрерывную запись. Организация, вынужденная восстанавливать что-либо после запроса, уже провалила проверку. Само восстановление доказывает, что записи не велись.
Создайте журнал до запроса проверяющего
Журнал аудита превращает программу проверки в обоснованную программу. Специалисты, проходившие проверки, формулируют стандарт просто: безупречные журналы определяют разницу между чистой проверкой и письмом с замечаниями. Отсутствие журнала читается как отсутствие контроля, поскольку другого способа прочитать его нет. Выполненный контроль без записи с места проверяющего неотличим от невыполненного.
Обоснованный журнал ончейн-мониторинга имеет три слоя, существующих до начала проверки. История уведомления: какая проверка сработала, по какому адресу или транзакции, в какое время и какие индикаторы определили оценку. История расследования: кто взял дело, какие трассировки выполнил, какие показатели связей увидел и к какому выводу пришёл. История решения: кто проверил вывод, утвердил решение, что подано или закрыто, когда и на каком основании.
Phalcon Compliance создаёт все три через Audit Trails, Audit Logs и Risk Engine Details с экспортом каждого в PDF или CSV. Audit Trail фиксирует последовательность действий, Audit Logs — кто и когда их выполнил, делая историю атрибутированной, а не анонимной. Risk Engine Details фиксирует сработавшие индикаторы и расчёт оценки, делая скоринг понятным. Совместный экспорт даёт регулятору непрерывный путь от уведомления до решения. Он сопровождает дело, поэтому пакеты доказательств и аудита не расходятся.
Практическая проверка готовности — может ли второй аналитик или проверяющий восстановить решение только по записям. Если требуется память первого аналитика, журнал неполон.
Как объяснять оценки регулятору без непрозрачной модели
Проверяющие не принимают оценку на веру. Это число, а число без объяснения выглядит непрозрачным механизмом — контролем, который организация не может обосновать. Прошедшие проверки специалисты прямо называют главную проблему: способность объяснить, почему транзакцию отметили и почему обработали именно так, разрешает вопросы проверки. Оценка, не раскладывающаяся на причины, — источник риска на проверке, а не преимущество.
Разница прозрачной и непрозрачной модели становится вопросом проверки, а не только продукта. Механизм, возвращающий лишь оценку, заставляет команду защищать вердикт без возможности показать расчёт. Механизм, возвращающий оценку и конкретные индикаторы, даёт иной путь: провести проверяющего через решение в тех же понятиях, в которых его принял механизм. Первый превращает проверку в спор, второй — в рассмотрение.
Phalcon Compliance использует прозрачную модель на 17 категориях индикаторов риска. Каждая оценка сопровождается конкретными сработавшими индикаторами. Это составной результат, который команда может разобрать, а не спущенный сверху вердикт. На вопрос, почему транзакция высокорисковая, ответ состоит из трёх частей: названные индикаторы, ончейн-доказательства каждого и веса, объединившие их в оценку. Так скоринг становится обоснованным: регулятор видит те же входные данные, что аналитик, приходит к тому же выводу и идёт дальше.
Та же понятность важна в обратную сторону. На вопрос, почему транзакцию разрешили, команда должна показать несработавшие индикаторы и объяснить, почему их отсутствие поддержало низкий риск. Прозрачная модель отвечает прямо. Непрозрачная не отвечает вовсе; именно это молчание становится замечанием.
Сохраняйте полноту записей SAR и STR
Сообщение о подозрительной транзакции — один из первых документов проверки: в нём мониторинг, расследование и решения видны вместе. Но сама подача — половина записи. Вторая — дело: исходное уведомление, ончейн-описание, показатели связей, индикаторы, цепочка проверки и утверждения и соединяющий их журнал. STR или SAR без этого подтверждения организация не может обосновать. Проверяющий не подтвердит, что это реальное расследование, а не рефлекторное заполнение шаблона.
Рекомендация 20 FATF устанавливает обязанность сообщений о подозрительных транзакциях для VASP и связана с требованием записей Рекомендации 11. В США это SAR в FinCEN по правилам сообщений о подозрительной активности (31 CFR 1022.320). Записи должны существовать до проверки, а не собираться в ответ на неё.
Платформа поддерживает формирование STR на Essential и выше. Дело, журнал и экспорт STR создаются в одной среде. Уведомление, расследование, решение, журнал и подача живут в одной записи, экспортируемой пакетом. На запрос подтверждающих документов для выборки подач ответ — один экспорт на дело, а не восстановление по несвязанным инструментам.
Хранение важно не меньше создания. FinCEN ожидает пятилетнего хранения подтверждающих SAR документов; юрисдикции, следующие FATF, задают сопоставимые сроки. Готовая программа хранит всё дело, а не только сообщение, весь срок, с получением и экспортом по запросу.
Типичные замечания проверки и их предотвращение
Замечания криптокомплаенса группируются вокруг нескольких сбоев. Большинство восходит к одной причине: контроль выполнился, но не записался, либо запись нельзя экспортировать.
Первый — пробел мониторинга: периодичность оставила окно между проверками для движения средств. Проверка реального времени каждого пополнения и вывода вместо периодического пакета закрывает окно. Журнал должен показать выполнение на живом потоке.
Второй — необъяснённое решение: уведомление закрыли или эскалировали, но запись не показывает причину. Прозрачная модель с именованными индикаторами предотвращает это. Причины фиксируются в Risk Engine Details в момент решения, а не восстанавливаются по памяти.
Третий — STR или SAR без подтверждающих документов. Сообщение есть, но дело не предоставляется по запросу. Создание STR и журнала в одной среде предотвращает расхождение.
Четвёртый — сбой хранения: записи существовали, но срок хранения истёк, доступ к инструменту утрачен или экспорт в понятном формате невозможен. Экспорт PDF и CSV из одной среды предотвращает это: запись переносима и для её получения не нужна действующая лицензия.
Все четыре предотвращаются одной дисциплиной: создавать запись в момент действия, в переносимом формате, приложенной к делу.
Контрольный список пробной проверки: выполните до регулятора
Пробная проверка — самый дешёвый способ найти пробелы раньше проверяющего. Она заставляет сделать то, что потребует реальная: выбрать уведомления и подачи и предоставить полные записи по запросу. Ниже — артефакты для каждого дела выборки.
Журнал каждого дела. Для каждого уведомления предоставьте совместный экспорт Audit Trail, Audit Logs и Risk Engine Details. Подтвердите тест второго аналитика: не работавший над делом человек восстанавливает решение только из экспорта.
Объяснение оценки каждого дела. Для каждого решения предоставьте названные индикаторы, ончейн-доказательства каждого и объединившие их веса. Подтвердите ответ в обе стороны: почему отмечено и почему разрешено.
Полнота STR или SAR каждой подачи. Предоставьте дело, ончейн-описание, показатели связей, цепочку проверки и утверждения и журнал. Подтвердите, что сообщение и подтверждения идут одним пакетом.
Причина решения каждого дела. Для каждого закрытия или эскалации предоставьте документированную причину, записанную в момент решения. Она не должна восстанавливаться постфактум.
Доказательства охвата мониторинга. Покажите выполнение проверки на живом потоке пополнений и выводов, а не по периодическому расписанию, без окон между проверками. Подтвердите постоянный мониторинг временными метками журнала.
Хранение и получение. Для подач по всему сроку хранения подтвердите получение полного дела и экспорт PDF или CSV. Получение должно быть по запросу и не зависеть от живой сессии или истёкшей лицензии.
Программа, предоставляющая все шесть элементов для каждого дела выборки, готова к проверке. Остальная уже нашла на пробной проверке именно то замечание, которое написала бы реальная. KYT выполняет сторону постоянного мониторинга Рекомендации 10; журнал, объяснение оценки и запись STR — сторону хранения Рекомендации 11. Посмотрите, как Phalcon Compliance объединяет журнал и 17 категорий индикаторов в одну запись для проверки, с которой столкнётся ваша программа.