Проверяют всех одинаково
Регламент требует одинаковой проверки для сделки на 50 тысяч и на 5 миллионов. Время уходит на мелочи, а крупные риски разбираются в конце очереди.
Управление рисками
Смотрим туда, где риск выше, а не туда, где очередь длиннее
Модель оценивает контрагента, сделку или операцию по сотням признаков и выстраивает их в порядке риска. Служба риска получает короткий список того, что требует внимания, и объяснение по каждому случаю.
Или сразу: +7 (962) 368-39-51 Telegram
AUC
измеряем качество ранжирования
precision
цена ложной тревоги под контролем
drift
контроль дрейфа входных данных
explain
вклад признаков в каждую оценку
Почему риск-контроль пробуксовывает
Проблемы, знакомые любой службе риска, которая пытается перейти от ручных проверок к системной оценке.
Алертов больше, чем людей
Система мониторинга генерирует сотни срабатываний в день, 95% из них — ложные. Аналитики привыкают закрывать алерты не глядя, и настоящий сигнал теряется в шуме.
Признаки живут в разных системах
Юридические данные в одном сервисе, платежная история в ERP, поведение на сайте в веб-аналитике. Собрать из этого единый профиль контрагента вручную невозможно.
Решение нельзя обосновать
Отказ в сделке нужно объяснить клиенту и внутреннему контролю. Формулировка «не прошло автоматическую проверку» не является основанием ни для клиента, ни для аудита.
Мошенники меняют схему быстрее модели
Модель, обученная на прошлогодних случаях, не видит новую схему. Без мониторинга дрейфа и регулярного дообучения качество уходит вниз незаметно для бизнеса.
Ручной пересмотр ломает экономику процесса
Когда доля отправленных на ручную проверку заявок вырастает до 30%, автоматизация перестаёт экономить время: проверяющих нужно столько же, сколько было до внедрения.
Что мы строим
Четыре блока, которые вместе дают управляемый процесс оценки риска.
Профиль контрагента и признаки
Собираем данные о компании или клиенте в единый профиль: регистрационные сведения, историю платежей, судебные события, поведение в продукте.
- Интеграции с внешними источниками и внутренними системами
- Расчёт производных признаков: динамика выручки, частота смены реквизитов
- История взаимодействий и нарушений сроков
- Регулярное обновление профиля по расписанию
Модель скоринга
Модель выдаёт вероятность нежелательного события и место в очереди на проверку. Порог настраивается под допустимый уровень потерь.
- Градиентный бустинг на исторических исходах сделок
- Кросс-валидация по времени, а не случайным образом
- Подбор порога под баланс потерь и нагрузки аналитиков
- Проверка стабильности на данных другого периода
Мониторинг и ранжирование алертов
Поток событий оценивается в реальном времени, а срабатывания объединяются в инциденты и сортируются по потенциальному ущербу.
- Потоковая обработка операций и активностей
- Дедупликация и группировка связанных срабатываний
- Приоритет по ожидаемому ущербу, а не по времени события
- Автоматические действия для однозначных случаев
Объяснение и контроль качества
Каждая оценка сопровождается набором признаков с весами и понятной формулировкой основания для решения.
- SHAP-значения и вклад признаков по конкретному случаю
- Сравнение распределений признаков с обучающей выборкой
- Отчёты по precision и recall на размеченной выборке
- Журнал решений для внутреннего контроля и регулятора
Как проходит внедрение
Начинаем с офлайн-оценки на истории: модель должна доказать качество до того, как попадёт в живой процесс.
-
01 2–4 недели
Постановка задачи и разметка
Определяем, что считается нежелательным событием, собираем историю исходов и размечаем данные. Этот этап определяет всё остальное.
-
02 3–4 недели
Модель и офлайн-оценка
Обучаем модель, проверяем её на отложенном периоде, подбираем порог и считаем, сколько случаев уйдёт на ручную проверку.
-
03 4–6 недель
Пилот в теневом режиме
Модель работает параллельно с текущим процессом и не влияет на решения. Сравниваем её ранжирование с тем, что находили аналитики.
-
04 4 недели
Внедрение и мониторинг
Подключаем модель к процессу, настраиваем алерты на деградацию и регламент дообучения, передаём систему службе риска.
Почему ROC AUC не единственная метрика риск-модели
ROC AUC показывает, насколько хорошо модель упорядочивает объекты по риску, но ничего не говорит о том, сколько работы она создаст. Две модели с одинаковым AUC могут дать совершенно разную нагрузку на службу риска: одна отправит на проверку 3% заявок, другая — 20%.
Поэтому мы всегда показываем матрицу ошибок при выбранном пороге: precision (доля реальных нарушений среди отобранных), recall (доля найденных нарушений от всех имевшихся) и абсолютное количество случаев в каждой ячейке. Порог вы выбираете не по метрике, а по деньгам: сколько ложных срабатываний готовы оплачивать проверками и какой ущерб от пропуска считаете недопустимым.
Дрейф модели: как заметить деградацию до того, как она станет проблемой
Модель обучается на прошлом, а работает в будущем. Со временем меняется и поведение клиентов, и схемы мошенников, и качество входных данных. Если не следить за этим, качество падает постепенно, и обычно это замечают по росту потерь, а не по метрикам.
Мы мониторим дрейф на двух уровнях. Data drift — сравнение распределений входных признаков с обучающей выборкой: если доля заявок с новым типом документа выросла втрое, это сигнал. Concept drift — контроль качества на размеченных данных, которые поступают после завершения разбора: если precision упала ниже согласованного порога, запускается дообучение. Алерты приходят в Telegram или почтой, а не остаются в дашборде.
Как работать с сильным дисбалансом классов
В задачах мошенничества и дефолтов доля нежелательных событий обычно составляет доли процента. При таком дисбалансе бесполезны accuracy и обычная кросс-валидация: модель, которая всегда отвечает «всё хорошо», даёт точность 99,5% и нулевой практический смысл.
Мы используем стратифицированное разбиение по времени, метрики precision-recall вместо ROC, и обязательно проверяем модель на периоде, где зафиксирован известный всплеск нарушений. Отдельно разбираем редкие признаки: иногда один признак с покрытием 0,1% оказывается решающим, и его нельзя терять при отборе переменных.
Частые вопросы
Для устойчивой модели нужно не менее 300–500 наблюдений нежелательного события — именно событий, а не строк в таблице. При доле нарушений 1% это означает десятки тысяч размеченных случаев. Если такой истории нет, начинаем с правил и экспертной оценки: они дают результат быстрее, а модель подключается позже, когда накопится достаточно примеров для обучения и проверки.
Число ложных срабатываний регулируется порогом, а его выбор — вопрос экономики, а не технологии. Мы считаем стоимость ручной проверки одного случая и ожидаемый ущерб от пропуска, после чего подбираем порог, при котором суммарные издержки минимальны. Дополнительно снижаем шум группировкой связанных срабатываний в один инцидент и отсечением повторяющихся событий по одному контрагенту.
Да, и это обязательное требование к системе. Для каждой оценки мы формируем перечень признаков, повлиявших на результат, с их вкладом и человекочитаемой формулировкой: например, «резкое увеличение запрашиваемого лимита при сокращении истории платежей». Такая формулировка пригодна и для разговора с клиентом, и для внутреннего контроля, и для проверки регулятором.
Разбираем случай и добавляем его в набор для оценки: если ошибка показывает новую схему, дообучаем модель, если единичный случай — уточняем правила. Каждое такое событие фиксируется с признаками и решением аналитика, поэтому со временем набор сложных случаев становится ценнее исходной обучающей выборки. Именно он, а не объём исторических данных, определяет, насколько хорошо модель работает на новых схемах.
AI для бизнес-процессов: другие направления
Смежные задачи, которые обычно решаются в одном проекте с этой.
Сколько времени уходит на проверку каждой сделки?
Опишите, какие риски вы контролируете и какие данные уже собираете, — предложим схему оценки и покажем, как будет выглядеть очередь на проверку.