Почему оценка страховых рисков ломается на потоке заявок
Ручной андеррайтинг держится на двух допущениях: заявок немного, а решение по каждой можно принять за минуты. На потоке ломается и то, и другое — очередь растёт быстрее, чем андеррайтеры её разбирают, и оценка страховых рисков превращается в соревнование «кто успел». Часть заявок уходит клиенту без внятного ответа, часть получает шаблонный вердикт по одному-двум признакам, и портфель наполняется рисками, которые никто не измерял.
Правила устарели. Таблицы коэффициентов и опросники собирались под другую статистику убытков и не учитывают, как менялось поведение клиентов. Фиксированный порог не видит ни сезонности, ни связок признаков: заявка проходит как типовая, хотя сочетание маршрута, стажа и характера повреждений уже встречалось в группах с высокой частотой выплат.
Отдельная проблема — телематические данные. Они собираются, лежат в хранилище, но в решении почти не участвуют: агрегаты пересчитываются пакетно, раз в сутки, и попадают в отчёт, а не в момент оценки. Свежие события — резкие торможения, ночные поездки, смена основного водителя — на вердикт не влияют.
Итог одинаков в обоих случаях: решение запаздывает, а его обоснование не воспроизводится. Разбираем, как это закрывается — от пересборки правил на телематике до автоматической проверки заявок в потоке.
Что даёт предиктивная аналитика убыточности портфеля
Предиктивная модель переводит работу с убыточностью из годовой отчётности в непрерывный контроль. На вход идут обезличенные данные договоров, история выплат, телематика и результаты осмотров, на выходе — ожидаемая убыточность по каждому сегменту и сигнал там, где факт расходится с прогнозом. Калибровку сверяем с публичной актуарной статистикой Банк России, чтобы прогноз опирался на рынок, а не только на внутренние данные компании.
Доля автоматических решений растёт за счёт разделения потоков. Заявки без признаков мошенничества, в пределах лимита и с полным комплектом документов закрываются системой — типовой ориентир 60–70% потока; остальное уходит на ручной разбор, но уже с собранным досье и оценкой риска. Время разбора заявки падает с нескольких дней до часов.
Выявление мошеннических схем опирается на граф связей: система подсвечивает повторные заявки по одному событию, завышение ущерба, серийных участников и признаки сговора с посредниками. Каждый класс схем описан правилом и подтверждается моделью, поэтому спорные случаи уходят на проверку с обоснованием, а не по подозрению.
Сегментация договоров — по типу транспорта, каналу продаж, региону и стажу водителя — показывает, где убыточность растёт. Внутри сегмента разброс держится в заданном коридоре: тариф перестаёт выравнивать убыточных и прибыльных клиентов, а отклонение видно до того, как оно накопится в отчётности.
Сравнение подходов: правила, статистика, машинное обучение
Правила и статистика не конкурируют с машинным обучением — они закрывают разные участки воронки. На входе, где данных по клиенту почти нет, работает свод экспертных правил: он ловит явные аномалии и не требует обучающей выборки. Дальше подключаются балльная модель и модель на исторических данных — выбор между ними определяется не «современностью», а зрелостью портфеля, стабильностью признаков и качеством разметки.
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Экспертные правила | Портфель небольшой, история короткая, нужна объяснимость каждого отказа | Не масштабируется: условия конфликтуют, ложные срабатывания растут вместе с числом правил |
| Балльная модель | Признаков немного и они стабильны, нужна прозрачная шкала для андеррайтера | Веса задаются вручную, нелинейные зависимости и взаимодействия признаков теряются |
| Модель на исторических данных | Накоплены десятки тысяч договоров с подтверждёнными убытками и заявками | Требует разметки и контроля дрейфа; на редких классах переобучается и «додумывает» |
| Гибридная схема | Нужен охват по новым клиентам и точность на зрелом сегменте сразу | Дороже в эксплуатации: два контура, версионирование признаков, согласование итогового балла |
Ограничения подходов важнее их точности на демонстрации. Поэтому на зрелом портфеле мы собираем гибридную схему: правила фильтруют вход, модель ранжирует заявки, а итоговый балл калибруется по фактической убыточности когорт.
Этапы внедрения системы андеррайтинга
Внедрение андеррайтинга — не установка модели, а последовательность, где каждый шаг опирается на результат предыдущего. Если пропустить аудит источников или проверку на периоде, которого модель не видела, она покажет красивые цифры на обучении и разойдётся с реальным потоком заявок. Работы идут от разведки данных к регламенту для команды.
- Аудит данных. Разбираем источники: заявления, телематику полиса, историю выплат, внешние проверки. Считаем долю пропусков, задержку поступления и стабильность выгрузок за прошлые периоды — от этого зависит, какие признаки допустимо использовать.
- Схема решения. Определяем состав блоков: оценка риска, правила выявления мошеннических сценариев, очередь ручного разбора. Фиксируем точку встраивания в процесс оформления полиса.
- Настройка признаков и порогов. Задаём границы зон: автоматическое одобрение, ручная проверка, отказ. Порог считаем от стоимости ошибок — пропущенного убытка против потерянного клиента.
- Проверка на отложенной выборке. Прогоняем решение на периоде, который модель не видела, сверяем калибровку и устойчивость при смене сезона, смотрим долю заявок, уходящих на ручной разбор.
- Теневой режим. Решение работает параллельно с текущим, расхождения сверяем по сегментам портфеля — так видно, где новый подход спорит с опытом андеррайтера.
- Мониторинг и передача. Настраиваем контроль смещения входных данных и падения качества, описываем регламент пересмотра порогов. Обучаем команду разбору спорных случаев и работе с обратной связью.
Регламенты, схемы и политики доступа в поставке
Решение без документации живёт ровно до первого ухода инженера, который его собирал. Поэтому в поставку входит не только работающая система оценки страховых рисков, но и комплект, по которому ваша команда сама добавляет признаки, разбирает спорные заявки и замечает просадку качества до того, как её увидит андеррайтер.
- Описание признаков — по каждому источнику: формула, окно агрегации, допустимые пропуски и вклад в итоговый балл. Новый признак вводится правкой конфигурации, без пересборки модели.
- Схема потоков данных — от телематического устройства и заявления до хранилища признаков и очереди на разбор. Отмечено, где обезличиваются персональные данные и какие поля остаются в сыром виде.
- Политики доступа — матрица ролей: андеррайтер видит балл и объяснение к нему, аналитик — признаки и выгрузки, служба безопасности — историю заявок по клиенту и связанным лицам. Каждое действие пишется в неизменяемый журнал.
- Регламент разбора — порядок работы с заявкой на пограничном балле: кто смотрит, за какой срок, как фиксируется решение и как оно возвращается в обучающую выборку.
- Мониторинг качества — метрики (доля пропущенных мошеннических заявок, доля ложных срабатываний, смещение распределения признаков), пороги оповещения и порядок действий дежурного при их выходе.
- Версионирование и переобучение — какая версия обработала конкретную заявку, как воспроизвести её решение, как откатиться назад и по какой периодичности согласуется выпуск новой версии.
Комплект передаём в вашем контуре и разбираем его на ваших заявках — команда выходит на самостоятельные правки без нас.
Кейс: сокращение выплат по мошенническим схемам
Портфель автокаско: где утекали выплаты
До проекта решение по заявлению шло последовательно: проверка документов, экспертиза, и только на этапе выплаты всплывали связи между участниками. Инсценированные ДТП, задвоенный ущерб по одному автомобилю и «дружественные» сервисы ремонта выявлялись уже после согласования — вернуть выплату получалось редко. Повторные обращения одних и тех же связок не сопоставлялись: данные лежали в разных системах и не сходились по ключам.
Что изменили
События по каждому полису собрали в единый слой: заявление, телематика, история ремонтов, заключения экспертов, прошлые выплаты. Поверх построили граф связей между водителем, автомобилем, полисом, сервисом ремонта и экспертом, а также модель, которая считает риск в момент подачи заявления, а не после. Заявления с признаками схемы уходят специалисту с расшифровкой — перечень сработавших признаков и вес каждого, чтобы решение выдерживало разбор со стороны клиента и надзора. Обработка персональных данных выстроена по контуру ISO/IEC 27001.
Метрики до и после
Доля схем, выявленных на этапе заявления, выросла с 14% до 63% — значительная часть выплат просто не уходит. Повторные обращения сократились на 38%: система помнит участника и поднимает его историю до принятия решения. Время принятия решения по чистым заявлениям — с нескольких дней до минут, а подозрительные разбираются в приоритетном порядке с готовым набором признаков. Откат правил и модели на предыдущую версию занимает один рабочий цикл и не останавливает приём заявлений.
Чем отличается скоринг рисков от правил андеррайтинга?
Балльная оценка превращает набор признаков в непрерывную величину: стаж вождения, историю выплат, поведение по телематике, частоту обращений. Каждый признак входит со своим весом, веса калибруются на прошлых договорах, а результат сравнивается с порогами — получается не «да/нет», а место клиента на шкале риска.
Жёсткие правила — бинарные условия на конкретный факт. Если заявленное транспортное средство не совпадает с данными осмотра или по клиенту уже идёт расследование мошенничества, решение принимается независимо от балла. Правил немного, они пишутся вручную, версионируются и проходят юридическую проверку.
Порядок срабатывания строгий. Сначала прогоняются правила-запреты: сработало — отказ, дальше система не идёт. Затем правила-триггеры, которые уводят заявку в ручной разбор или запрашивают дополнительные документы. И только после этого считается балл.
Конфликт решений разрешается в пользу правил. Правило — зафиксированное требование, которое нельзя перевесить суммой баллов, иначе модель начнёт одобрять то, что бизнес запретил. Обратный случай — высокий балл при мягком предупреждении — не блокирует, но помечает заявку для выборочной проверки, чтобы расхождения разбирались, а не копились.
Подходы дополняют друг друга: правила дают объяснимость и след для аудита, скоринг — чувствительность к сложным сочетаниям признаков. Часть правил со временем переходит в признаки модели, а расхождения между слоями становятся материалом для перекалибровки.
Технические сомнения: данные, объяснимость, интеграция
Техническая команда заказчика перед стартом задаёт один и тот же набор вопросов: хватит ли данных, можно ли объяснить отказ по конкретному полису, как решение встроится в текущий контур и что с ним будет через год. Отвечаем по существу.
Спорить о выборе подхода до аудита данных бессмысленно: на оценке страховых рисков редкое событие — норма, а не аномалия. Поэтому сначала проверяем полноту истории по каждому договору и то, как в ней отражены отказы клиентов.
Хватит ли наших данных?
Смотрим не на объём, а на покрытие: как давно ведётся учёт, сколько полисов имеет полную историю, где пропуски в признаках поведения. При сильном дисбалансе классов настраиваем веса и порог срабатывания под цену ошибки пропуска — у страховщика она выше, чем стоимость лишней ручной проверки.
Можно ли объяснить, почему заявка ушла на ручную проверку?
Да. Для каждого решения сохраняем значения признаков и их вклад на момент расчёта, поэтому сотрудник видит не «высокая оценка», а основания: расхождение данных, нехарактерная история, признаки мошеннической схемы. Записи неизменяемы — их можно предъявить при разборе спорного случая.
Как система встроится в наш контур?
Через существующие каналы: поток заявок, справочники, очередь ручной проверки. Наружу отдаём оценку и набор оснований, карточка андеррайтера не ломается. Если сервис оценки недоступен, оформление продолжается по прежним правилам.
Что будет с моделью после запуска?
Данные дрейфуют: меняется портфель, поведение клиентов и схемы мошенничества. Вместе с решением передаём регламент сопровождения — контроль доли срабатываний на свежем срезе, периодическое переобучение и порядок отката на предыдущую версию.
Что уточнить перед стартом работы над системой
Сроки разработки системы оценки страховых рисков определяют не объём кода, а качество и доступность данных: телематика с разных устройств, история убытков, анкеты агентов и внешние реестры почти всегда разнородны. Поэтому до старта нужен короткий набор вводных — по ним мы вернёмся с планом работ по этапам, оценкой сроков и точками приёмки. Собрать их можно за одну встречу с инженерами проекта, без посредников и пересказов.
- Источники данных: какие каналы телематики уже подключены, в каком виде приходит история убытков, за какой период накоплена и где в ней пропуски.
- Целевой сценарий: система ставит оценку при выдаче полиса, при обращении по убытку или при пересмотре тарифа, и что она решает сама, а что отдаёт андеррайтеру.
- Текущий процесс: сколько времени занимает ручная проверка одной заявки, какая доля обращений уходит на дополнительную проверку и где теряются деньги.
- Интеграции: встраиваемся в систему урегулирования, в кабинет агента или в отчётность для перестраховщика.
- Данные и доступы: как обезличиваются сведения о клиентах, где хранятся, кто и на каком основании получает доступ.
- Приёмка: на какой выборке проверяем качество оценок и какие показатели считаем достаточными для запуска в работу.
Опишите задачу в общих чертах — вернёмся с оценкой сроков и планом работ по этапам. На встрече с инженерами уточним детали: вы получите состав команды, последовательность шагов и точки приёмки.
