Сценарии мошенничества
Сначала описываю сценарии мошенничества, характерные для компании: подмена реквизитов, фиктивный поставщик, возврат на иной счёт, дробление платежей, обход лимита согласования, аномальный доступ сотрудника. Каждый сценарий привязываю к карте бизнес-процессов: на каком шаге возникает риск, кто принимает решение и какие данные видит. Внедрение антифрод-системы без такой карты превращается в набор разрозненных запретов, которые не объясняют, почему операция остановлена. Итог этапа — перечень сценариев, согласованный с владельцами процессов.
Красные индикаторы
Для каждого сценария формулирую красные индикаторы — признаки, при которых операция требует проверки: новые реквизиты получателя, срочность без деловой причины, сумма чуть ниже лимита, серия однотипных платежей. Индикаторы фиксирую в описании контрольных правил с порогами и источниками данных. Из них собираются набор антифрод-правил и скоринг операций, поэтому каждый индикатор должен быть измеримым и проверяемым по журналу операций, а не оценочным. Пороги согласую с финансовой службой: слишком низкий порог перегружает проверяющих, слишком высокий пропускает значимые операции. Каждое изменение порога фиксирую с датой и основанием.
Разделение полномочий
Проверяю, кто в компании заводит контрагента, меняет реквизиты, согласует и проводит платёж. Разделение полномочий фиксирую в матрице ролей: одно лицо не должно одновременно создавать поставщика и подтверждать оплату ему. Разделение критических ролей сверяю с фактическими правами в учётной и банковской системах, а не только с приказами. Расхождения между матрицей ролей и реальным доступом выношу в отдельный перечень с ответственными и сроками устранения. Отдельно проверяю временные права, выданные на период отпуска или аврала, и учётные записи уволенных работников: именно через них чаще всего происходит аномальный доступ.
Правила остановки операции
Правила остановки операции отвечают на три вопроса: при каком сигнале платёж задерживается, кто вправе его остановить и в какой срок принимается решение. Закрепляю их локальным актом, чтобы остановка имела основание и не нарушала договорные сроки перед добросовестными контрагентами. Для каждой остановки предусматриваю протокол остановки платежа с указанием сигнала, проверяющего сотрудника и результата проверки. Отдельно описываю, кто и в какой срок сообщает контрагенту о задержке платежа и как операция возобновляется после проверки. Без такого порядка остановка сама становится источником претензий и убытков компании.
Проверка сигнала
Сигнал системы — ещё не вывод о мошенничестве. Устанавливаю сценарий ручной проверки: какие документы запрашиваются, как подтверждаются реквизиты, кто связывается с контрагентом по независимому каналу. Результаты проверки сигнала заношу в реестр инцидентов. По нему считаю метрики ложных срабатываний и корректирую пороги, чтобы модель не останавливала обычную работу компании и при этом не пропускала опасные операции. Для каждого типа сигнала определяю срок ручной проверки и сотрудника, который её проводит. Если проверка не завершена в срок, вопрос автоматически передаётся на следующий уровень, а не остаётся без решения.
Фиксация решения
Каждое решение по сигналу фиксирую так, чтобы его можно было предъявить в споре с контрагентом, банком или работником: кто принял решение, на основании каких данных и когда. Порядок эскалации определяет, когда вопрос передаётся руководителю или службе безопасности. Доказательственная связь между журналом операций, реестром инцидентов и решением ответственного лица позволяет обосновать остановку платежа, претензию или заявление в правоохранительные органы. Записи храню в неизменяемом виде в течение срока, достаточного для претензионной работы и судебного спора. Это же требование закладываю в договор с поставщиком антифрод-решения.
