Обзор методов оценки требований для не связанной с жизнью страховки

Способность точно оценить неоплаченные требования важна для страховщиков. В отличие от компаний в других секторах, страховщики не могут знать точный доход в период финансовой отчетности до много лет спустя. Страховые компании берут в страховых взносах регулярно и выплачивают требования, когда события имеют место. Для того, чтобы максимизировать прибыль, страховая компания должна точно оценить, сколько будет выплачено на существующих требованиях в будущем. Если оценка для неоплаченных требований будет слишком низкой, страховая компания станет неплатежеспособной. С другой стороны, если оценка слишком высока, то требования резервируют капитал страховой компании, возможно, был инвестирован в другом месте или повторно инвестирован в бизнес [1].

Risk Management Toolbox™ поддерживает четыре метода оценки требований для актуариев использовать для оценки неоплаченных требований:

Рабочий процесс, чтобы оценить неоплаченные требования

Для различных методов оценки требований следует основной рабочий процесс.

  1. Создайте треугольник разработки с данными о страховых исках с помощью developmentTriangle. Данные о требованиях могут быть или для требований, о которых сообщают, или для заплаченных требований. Можно построить использование требований, о котором сообщают, claimsPlot.

  2. Используйте треугольник разработки, чтобы вычислить использование отношений ссылки linkRatios. Можно построить использование отношений ссылки linkRatiosPlot.

  3. Используйте отношение ссылки треугольника разработки для требований, о которых сообщают, или заплаченных требований вычислить средние значения отношения ссылки с linkRatioAverages.

  4. Использование ultimateClaims вычислить спроектированные окончательные требования на основе средних значений отношения ссылки или для требований, о которых сообщают, или для неоплаченных требований.

  5. Используя спроектированные окончательные требования к обоим о которых сообщают и заплаченные треугольники разработки, используйте любое из следующих, чтобы вычислить значения понесенного, но не сообщил (IBNR) и общие невыплаченные оценки требований:

    • Цепочечный лестничный метод — Создает chainLadder объект с треугольниками разработки для о которых сообщают и заплаченных требований, сгенерируйте использование значений IBNR ibnr, и вычислите неоплаченную оценку требований с unpaidClaims.

    • Ожидаемый метод требований — Создает expectedClaims объект с треугольниками разработки для о которых сообщают и заплаченных требований, а также заработанной премии. По умолчанию первоначальные требования вычисляются как среднее значение окончательных требований, о которых сообщают, и заплаченных окончательных требований. Однако можно задать пользовательские значения для первоначальных требований. Подобно цепочечному лестничному методу можно вычислить использование значений IBNR ibnr и неоплаченные требования оценивают с unpaidClaims.

    • Метод Борнхуеттер-Фергюсона — Создает bornhuetterFerguson объект с треугольниками разработки для о которых сообщают и заплаченных требований, а также начальной буквы ожидал значения требований, сгенерируйте использование IBNR ibnr, и вычислите неоплаченную оценку требований с unpaidClaims.

    • Метод Кейп-Кода — Создает capeCod объект с треугольниками разработки для о которых сообщают и заплаченных требований, а также начальной буквы ожидал значения требований, сгенерируйте использование IBNR ibnr, и вычислите неоплаченную оценку требований с unpaidClaims.

Оценка окончательных требований Используя треугольники разработки

Одна характеристика Треугольников Разработки - то, что окончательные требования оцениваются от записанных значений, принимающих, что разработка будущих требований напоминает это в предшествующих годах — прошлое показательно из будущего.

Шаги для треугольников разработки продемонстрированы с помощью симулированных данных:

  1. Используйте developmentTriangle чтобы сгенерировать требования, о которых сообщают, в том, что называется треугольником разработки, где существует одна строка в течение каждого года источника и столбцов, изображают, как требования разрабатывают в зависимости от времени.

    Reported claims report

  2. Использование linkRatios вычислить факторы от возраста к возрасту. Эти факторы также известны как факторы от отчета к отчету или отношения ссылки. Отношения ссылки измеряют изменение в записанных требованиях от одной даты оценки до следующего. Стандартное соглашение о присвоении имен запускает заканчивающий месяц месяц. Например, фактор от возраста к возрасту в течение 12-месячного периода к 24-месячному периоду часто упоминается как фактор 12-24.

    Чтобы вычислить факторы от возраста к возрасту в течение периода 12-24, разделите требования по состоянию на 24 месяца требованиями по состоянию на 12 месяцев. Таким образом треугольник факторов от возраста к возрасту имеет тот меньше строки и один меньше столбца, чем исходный треугольник данных.

    Age-to-age factors report

  3. После вычисления факторов от возраста к возрасту использовать linkRatioAverages вычислить средние значения факторов от возраста к возрасту. Актуарии используют большое разнообразие средних значений для факторов от возраста к возрасту. Некоторые из общих единиц являются простым средним, средним средним значением, средним геометрическим и взвешенным средним объема.

    Link ratio averages report

  4. Использование cdfSummary получить совокупные факторы разработки требования (CDF), которые вычисляются последовательным умножением, начинающимся с фактора хвоста и самого старого фактора от возраста к возрасту. Совокупный фактор разработки требования проектирует общий рост по остающимся оценкам.

    CDF report

  5. Все предыдущие шаги применяются к требованиям, о которых сообщают. Для того, чтобы вычислить невыплаченные оценки требований, вам нужны заплаченные требования, а также требования, о которых сообщают. Используйте developmentTriangle сгенерировать треугольник разработки для заплаченных требований.

    Paid claims report

    Подобно треугольнику разработки требований, о котором сообщают вы используете заплаченные требования, разрабатывают треугольник, чтобы вычислить отношения ссылки, средние отношения ссылки, и затем можно выбрать одно отношение ссылки и вычислить совокупные факторы разработки.

  6. Использование ultimateClaims спроектировать окончательные требования. Окончательные требования равны продукту последней оценки требований и соответствующих совокупных факторов разработки требования. Спроектированные окончательные требования отображены и для требований, о которых сообщают, и для заплаченных требований.

    Projected ultimate claims report

  7. После вычисления спроектированных окончательных требований используйте chainLadder, expectedClaims, или bornhuetterFerguson метод для оценки неоплаченных требований.

Оценка неоплаченных требований Используя цепочечный лестничный метод

Цепочечный лестничный метод требует Треугольников Разработки для о которых сообщают и заплаченных требований. Цепочечный лестничный метод принимает, что можно предсказать будущее действие требований в течение данного года источника (год несчастного случая, год политики, год отчета, и так далее) на основе исторического действия требований до настоящего времени в течение того года источника. Первичное предположение об этом методе - то, что создание отчетов и оплата будущих требований напоминают шаблоны, наблюдаемые в прошлом.

Кроме того, цепочечный лестничный метод требует большого объема исторического опыта требований. Это работает лучше всего, когда присутствие или отсутствие больших претензий не значительно искажают данные. Если объем данных не достаточен, большие претензии могут значительно исказить факторы от возраста к возрасту, проекции окончательных требований и оценку неоплаченных требований.

  1. После вычисления спроектированных окончательных требований с помощью Треугольников Разработки создайте chainLadder основанный на объектах на о которых сообщают и заплаченных Треугольниках Разработки для того, чтобы вычислить невыплаченные оценки требования с unpaidClaims.

  2. Актуарии вычисляют невыплаченную оценку требований как различие между спроектированными окончательными требованиями и фактическими заплаченными требованиями. Это значение невыплаченной оценки требования представляет общие неоплаченные требования, и включая выдающиеся случаи требований и включая требования IBNR. Чтобы определить оцененные значения IBNR на основе цепочечного лестничного метода, вычтите требования, о которых сообщают, из спроектированных окончательных требований. В качестве альтернативы можно использовать ibnr вычислить IBNR, который равен оценке общих неоплаченных требований меньше выдающиеся случаи.

    Unpaid claims estimate report

Оценка неоплаченных требований Используя ожидаемый метод требований

Ключевое предположение об ожидаемом методе требований - то, что актуарий может лучше оценить неоплаченные требования на основе первоначальной оценки, а не существующие требования, наблюдаемые до настоящего времени.

Ожидаемый метод требований требует Треугольников Разработки для о которых сообщают и заплаченных требований, а также заработанной премии. По умолчанию первоначальные требования вычисляются как среднее значение окончательных требований, о которых сообщают, и заплаченных окончательных требований. Однако можно задать пользовательские значения для первоначальных требований. Используя первоначальные требования, актуарий применяет метод отношения требования, где окончательные требования к периоду разработки равны выбранному ожидаемому отношению требования, умноженному на заработанную премию. Используя эти расчетные окончательные требования, актуарий может затем вычислить невыплаченные оценки требований.

  1. Создайте expectedClaims объект вычислить ultimateClaims.

    Projected ultimate claims report

  2. Используйте expectedClaims объект вычислить unpaidClaims.

    Unpaid claims report

Оценка неоплаченных требований Используя метод Борнхуеттер-Фергюсона

Метод Борнхуеттер-Фергюсона комбинирует цепочечный лестничный метод, и ожидаемый метод требований путем разделения окончательных требований на два компонента, фактические, сообщил (или заплатил), требования, и ожидал несообщаемый (или неоплаченный) требования. Когда требование назревает за периоды разработки, больше веса дано фактическим требованиям, и ожидаемые требования постепенно становятся менее важными.

Метод Борнхуеттер-Фергюсона требует Треугольников Разработки для о которых сообщают и заплаченных требований, а также начальная буква ожидала значения требований. Метод Борнхуеттер-Фергюсона вычисляет свои собственные спроектированные окончательные требования, отличающиеся от вычисленных в объекте Development Triangle. Используя эти новые спроектированные окончательные требования, вычисляются невыплаченные оценки требований.

  1. Создайте bornhuetterFerguson объект вычислить ultimateClaims.

    Projected ultimate claims report

  2. Используйте bornhuetterFerguson объект вычислить unpaidClaims.

    Unpaid claims estimate report

Оценка неоплаченных требований Используя метод Кейп-Кода

Как в методе Борнхуеттер-Фергюсона, метод Кейп-Кода разделяет окончательные требования на два компонента: фактический сообщил (или заплатил), и ожидал несообщаемый (или неоплаченный). Когда год несчастного случая (или другой временной интервал) назревает, фактические требования, о которых сообщают, заменяют ожидаемые требования, о которых не сообщают, и начальная буква ожидала, что предположение требований постепенно становится менее важным. Главной разницей между этими двумя методами является деривация ожидаемого отношения требования. В методе Кейп-Кода ожидаемое отношение требования получено из опыта требований, о котором сообщают, вместо независимого и часто поверхностного выбора как в методе Борнхуеттер-Фергюсона.

Метод Кейп-Кода требует Треугольников Разработки для о которых сообщают и заплаченных требований, а также заработанной премии. Ключевое предположение о методе Кейп-Кода - то, что требования, о которых не сообщают, разработают на основе ожидаемых требований, которые выведены с помощью, сообщил (или заплатил), требования, и заработал премию. И методы Кейп-Кода и Борнхуеттер-Фергюсона отличаются от метода разработки, где первичное предположение - то, что требования, о которых не сообщают, разработают на основе требований, о которых сообщают, до настоящего времени (не ожидаемые требования).

  1. Создайте capeCod объект вычислить ultimateClaims.

    Projected ultimate claims report

  2. Используйте capeCod объект вычислить unpaidClaims.

    Unpaid claims estimate report

Ссылки

[1] Фридланд, Жаклин. "Оценивая Неоплаченные Требования с помощью Основных Методов". Арлингтон, ВА: Несчастный случай Страховое Общество, 2010. (https://www.casact.org/library/studynotes/Friedland_estimating.pdf).

[2] Wüthrich, Марио и Майкл Мерц. Стохастические методы резервирования требований в страховке. Хобокен, NJ: Вайли, 2008.

Смотрите также

| | | |

Документация Risk Management Toolbox

Поддержка

Для просмотра документации необходимо авторизоваться на сайте