Перейти к основному содержимому

Инженерия в InsurTech: скорость под регуляторами, риск под контролем

· 10 мин. чтения
Artur Pan
Artur Pan
CTO & Co-Founder at PanDev

CTO одной insurtech-компании как-то сказал мне: «Мы не SaaS. Мы SaaS, который продаёт финансовый дериватив». Разница важна, потому что страховое ПО не просто релизит фичи — оно релизит модели риска, которые регулятор будет проверять на горизонте пяти лет. Баг в claims-сервисе — это тикет в поддержку. Баг в модели ценообразования — это жалоба регулятору, потенциально неверно оценённый портфель контрактов и разгребание в квартальных, а не спринтовых единицах.

Deloitte в Global Insurance Outlook 2024 сообщил, что 47% страховщиков называют модернизацию legacy-систем инженерным ограничением №1. Команды, которые её ведут, ходят по канату: регуляторы (EIOPA в ЕС, NAIC в США, Банк России и казахстанский AFSA в СНГ) не интересуются, что вы внедрили continuous deployment. Они интересуются, можете ли вы доказать, какая версия актуарной модели оценивала полис в конкретный день.

{/* truncate */}

Почему insurtech-инженерия отличается от fintech​

Fintech и insurtech часто складывают в одну корзину «регулируемого финансового ПО», но инженерные ограничения сильно расходятся.

Fintech живёт во времени транзакции. Платёж прошёл или не прошёл за секунды. Регулятор (FCA, OCC, ЦБ РФ) аудирует через транзакционные логи и reconciliation-отчёты. Инженерные метрики крутятся вокруг DORA-скорости с дисциплиной audit trail.

Insurtech живёт во времени контракта. Полис, проданный сегодня, может оплатить убыток в 2041. Регулятор аудирует через документацию модели, обоснование цены и историческую реконструкцию каждого изменения параметра. Инженерные метрики крутятся вокруг воспроизводимости — не «можем ли мы быстро деплоить», а «можем ли мы восстановить состояние модели на 17 февраля в 14:30:12?».

Этот сдвиг временного горизонта перестраивает инструментарий:

Регуляция / СтандартЧто требуетГде бьёт по инженерам
Solvency II (ЕС)Документированный governance внутренних моделей, качество данныхКаждый деплой актуарной модели требует криптографической фиксации входов/кода/выходов
NAIC Model Law (США)Оценка кибер-рисков, model governanceДоступ разработчиков к актуарным моделям — least-privilege и логируется
GDPR / CCPAПраво на удаление данных полисодержателяПрослеживаемость данных от подачи убытка до дообучения ML-модели
Model Risk Management (MRM, OCC SR 11-7)Независимая валидация всех моделей в принятии решенийОтдельный code review / test lineage — от разработчика модели к валидатору
ICS (IAIS, глобально)Групповая согласованность платёжеспособностиКоординация деплоев между дочерними структурами — изменение в одной влияет на групповой отчёт

Ни одно из этих правил не говорит «следите за lead time for changes». Все они неявно предполагают, что вы это можете, — и наказывают, если не умеете ответить на базовые вопросы о проде.

Референсная архитектура (и где что измеряем)​

Архитектурная диаграмма: четыре вышестоящих сервиса (claims, policy, actuarial model, underwriting API) сливаются в regulatory audit log и change management ledger. Типичная insurtech-платформа. Audit log и change ledger — место, где живёт compliance. Ваши инженерные метрики должны питать оба.

«Change management ledger» — артефакт, специфичный для insurtech. Любое продовое изменение — от UI-твика до константы дисконтирования — должно маппиться на:

  • тикет, авторизовавший работу,
  • инженера(ов), написавшего код,
  • ревьюера(ов), апрувнувшего,
  • событие деплоя в прод,
  • путь отката (если применимо),
  • полисы/убытки, на которые это повлияло.

Если ваш инструмент метрик не умеет кормить этот ledger — это не тот инструмент для этой индустрии.

5 метрик, которые имеют значение в insurtech​

1. Model change lead time (а не только code lead time)​

В SaaS «lead time for changes» — это DORA-стандартная длительность commit-to-deploy. В insurtech полезнее model change lead time: время от подписи актуариев под новой ценовой гипотезой до её выхода в прод.

Сюда входят интервалы, важные регулятору:

  • Актуарный peer-review (MRM требует независимой валидации до продового использования)
  • Интеграционное тестирование на исторических полисах
  • Parallel-run период (новая модель работает рядом со старой; выходы сравниваются)

Целевой бенчмарк: 4-8 недель для изменений pricing-модели в крупных страховщиках, 1-3 недели в API-native insurtech. Меньше недели на ценовое изменение без явного преодобрения регулятора — это красный флаг, а не повод хвастаться.

Почему self-report не работает: инженер пишет изменение за часы, потом оно неделями сидит в очередях валидации. Таймшит цикл не поймает; IDE-телеметрия + Git + состояние тикета — поймают.

2. Change failure rate, сегментированный по blast radius​

Глобальный DORA change failure rate усредняется по всем деплоям. Insurtech нужны сегментированные частоты отказов, потому что бизнес-эффект различается на 4-5 порядков:

Тип деплояДопустимый CFRBlast radius при ошибке
Маркетинговый сайт20-30%Падение bounce rate на час
UI поиска полиса10-15%Брошенные котировки
Underwriting API3-5%Неверно оценённые полисы, выписанные часами
Актуарная модельМеньше 1%Неверная цена портфеля, видная на конце квартала
Логика урегулирования убытковМеньше 0.5%Необоснованные отказы → жалобы регулятору

Один CFR по всему этому бессмыслен. Сегментация — это проектное решение первого порядка, а не украшение дашборда.

3. Полнота audit trail​

Можете ли вы для любого продового деплоя за последние 7 лет (стандартное требование хранения в большинстве страховых юрисдикций) восстановить полную цепочку:

  • Тикет → ветка → коммиты → PR → апрувы ревьюеров → CI/CD-run → событие деплоя → первый затронутый полис/убыток?

Команды обычно считают, что у них 90%+, и меряют 60-75%. Разрыв берётся из веток без task ID, прямых merge в main, хотфиксов мимо тикет-системы и деплоев, у которых CI/CD-метаданные затёрты retry.

Что трекать: доля продовых деплоев, где полная цепочка восстанавливается без ручной работы. Меньше 95% — будущий аудит будет болезненным.

Единственное Git-правило, которое здесь окупается первым: имена веток должны содержать task ID (feature/POL-1480, fix/CLM-2117). Insurtech — индустрия, где это правило окупается первым, — якорь, делающий всю цепочку реконструируемой.

4. Разделение обязанностей (тест MRM)​

Guidance по Model Risk Management (OCC SR 11-7 в США, аналогичный PRA SS1/23 в Великобритании) требует независимой валидации моделей, используемых в принятии решений. На практике: люди, которые пишут pricing-модель, не могут быть людьми, которые валидируют её для прода.

Инженерная метрика: для каждого продового деплоя, трогающего актуарную или ценовую логику, был ли апрувер отличен от каждого коммиттера? В legacy-командах с маленьким штатом это ломается постоянно — моделлер сам пишет и ревью-комментарий, потому что больше никто не понимает код. Это findings в любом MRM-аудите.

Цель: 100% разделения для всего, помеченного actuarial/, pricing/, underwriting/. Если 100% недостижимы, документируйте исключения и компенсирующие контроли, потому что регулятор спросит.

5. Parallel-run divergence time​

Когда новая pricing-модель выходит в прод, она работает в shadow-режиме рядом со старой — обе оценивают каждую входящую заявку, но клиенту уходит выход старой. Инженерная метрика — сколько времени требуется shadow-run, чтобы отклонение между старой и новой стабилизировалось до объяснимой дельты.

Цель: стабильное отклонение за 2-4 недели для большинства ценовых изменений. Дольше — новая модель дрейфует непонятным образом; короче — новая модель функционально идентична старой, и вы сожгли бюджет валидации впустую.

Эта метрика почти невидима в типичных инженерных дашбордах. И при этом — лучший предсказатель того, пройдёт ли ценовое изменение регуляторный review без перерегистрации.

Как compliance меняет измерение​

Три практических следствия работы под страховой регуляцией:

Retention данных важнее их свежести. SaaS-команда думает про 90-дневные тренды. Insurtech-команда — про 7-летнюю реконструкцию. Это значит, что платформа инженерных метрик должна хранить сырые события, а не только агрегаты, на протяжении всего нормативного окна. Большинство SaaS-инструментов сворачивают данные после 180 дней. Это compliance-мина.

On-prem или суверенное облако побеждает multi-tenant SaaS. GDPR, CCPA и юрисдикционные правила резидентности данных (казахстанский закон о персональных данных, ФЗ-152 в РФ) означают, что инженерная телеметрия часто не может покинуть страну операции. Multi-tenant SaaS проигрывает этот бой по умолчанию. В PanDev Metrics мы регулярно видим это: регулируемые финансовые клиенты просят именно on-prem Docker или Kubernetes, чтобы инженерная телеметрия осталась внутри регулируемого периметра.

Воспроизводимость важнее real-time. Дашборд, говорящий «сегодня ваши DORA зелёные», менее ценен, чем тот, что говорит «3 ноября 2024 года latency от деплоя до обновления котировки был 87 минут, вот цепочка коммитов». Insurtech-инструменты оцениваются по исторической реконструкции, а не по блеску дашборда.

Типичный профиль insurtech-команды​

ПараметрТипичный диапазон (2026)
Размер команды40-250 инженеров
СтекJava (legacy Spring), Scala или Kotlin (новое), Python для актуарного ML, React/Angular для агентских порталов
Каденс деплоевЕжедневно для маркетинга/UI, еженедельно для API, ежемесячно для pricing engines
Основное давлениеРегуляторная воспроизводимость + мультиюрисдикционная локализация
Model governanceОтдельная актуарная организация, обычно 10-40 человек
ToolchainGitLab или GitHub Enterprise, Jira + ServiceNow, Jenkins или GitLab CI, Vault, PagerDuty
Retention данных7 лет минимум (варьируется по юрисдикции)

Что трекать иначе, чем в стандартной SaaS-команде​

  • Audit trail важнее velocity. Не публикуйте улучшения lead time руководству, если в audit-цепочке пробелы. Быстрый сломанный процесс хуже медленного трассируемого.
  • Деплои, сегментированные по классу риска. Один показатель «deploy frequency» скрывает, что маркетинг деплоится ежедневно, а pricing — ежемесячно, и это правильно, а не проблема.
  • Метрики дрейфа модели. За пределами инженерии: parallel-run divergence, стабильность калибровки, fairness по защищённым атрибутам. Этим место в инженерном дашборде актуарных и ML-команд, а не только в data-science ноутбуках.
  • Координация между дочерними структурами. Группы, работающие в нескольких юрисдикциях, деплоят одну и ту же фичу с разным каденсом, потому что регуляторы разные. Трекайте deploy gap между entity — он показывает, где ломается групповая координация.

Частые ловушки​

  • «У нас DORA, всё ок». DORA необходима, но недостаточна. Команда с отличными DORA-показателями и сломанным separation-of-duties провалит следующий MRM-аудит независимо от зелёных дашбордов.
  • Трактовка актуарных моделей как «просто кода». Это не просто код. Им нужна отдельная линия ревью, отдельные записи валидации, отдельные процедуры отката. Ваш CI/CD-пайплайн для pricing-репозиториев не должен выглядеть как CI/CD для маркетингового сайта.
  • Попытки догнать fintech-каденс на pricing-engine. Команда, перешедшая с месячного на ежедневный каденс pricing-деплоев в 2023, в 2024 на аудите потратила квартал, восстанавливая пропущенные audit-цепочки. Скорость — неверный таргет для pricing-пути.
  • Хранение инженерной телеметрии в multi-tenant SaaS. Не универсальная ловушка, но та, которую регулятор может использовать на экзамене. Знайте свою юрисдикцию.

Контрарная точка: большинство insurtech-лидеров считают, что главный их риск — скорость. Данные аудитов говорят, что главный риск — трассируемость. Санкции получают не медленные; санкции получают те, кто не смог восстановить, как возникло конкретное продовое состояние.

Честное ограничение​

Наш датасет силён по B2B SaaS и приемлем по fintech. Insurtech-специфичный сигнал тоньше — у нас видимость по примерно дюжине insurance-смежных клиентов, в основном в ЕС и СНГ. Бенчмарки выше опираются больше на разбор регуляторных документов и интервью с инженерными лидерами insurtech, чем на одну телеметрию. Команды в US P&C или перестраховании могут видеть материально другие числа; относитесь к бенчмаркам как к точке отсчёта для собственных измерений.

Где находится PanDev Metrics​

PanDev Metrics работает как on-prem Docker или Kubernetes — конфигурация, которую запрашивает большинство страховых клиентов для compliance по резидентности. IDE heartbeat-телеметрия плюс интеграции Git + трекер дают трассируемую цепочку commit-to-deploy, требуемую MRM-аудитами. Чего мы не делаем: workflow по model governance (это задача Domino или Dataiku) или актуарная валидация. Мы — слой инженерной intelligence под этими workflow, а не их замена.

Похожие материалы​

Готовы увидеть метрики своей команды?

30-минутная персональная демонстрация. Покажем как PanDev Metrics решает задачи именно вашей команды.

Забронировать демо