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