Friedland09.BornFerg

From CAS Exam 5
Revision as of 15:52, 10 July 2020 by 66.248.200.4 (talk) (Example C: Benktander Variation on BF)
Jump to navigation Jump to search

Reading: Friedland, J.F., Estimating Unpaid Claims Using Basic Techniques, Casualty Actuarial Society, Third Version, July 2010. The Appendices are excluded.

Chapter 9: Bornhuetter-Ferguson Method

Pop Quiz

Study Tips

BattleTable

Based on past exams, the main things you need to know (in rough order of importance) are:

  • fact A...
  • fact B...
reference part (a) part (b) part (c) part (d)
E (2019.Spring #17) ultimate:
- reported B-F
ultimate:
- reported B-F
combining data:
- argument against
E (2019.Spring #19) ultimate claims:
- rptd devlpt (tort reform)
ultimate:
- reported B-F (tort reform)
E (2018.Spring #17)
E (2018.Spring #19)
E (2017.Spring #18) Friedland08.ExpectedClms unpaid & IBNR:
- reported B-F
E (2016.Fall #21) IBNR:
- B-F method
ECR assumption:
- assess reasonableness
alternate method:
- recommend & justify
E (2016.Spring #16) Friedland08.ExpectedClms Friedland07.Development ultimate:
- paid B-F
E (2015.Fall #18) ultimate:
- reported B-F
CDFs < 1.0:
- does B-F still work?
E (2015.Spring #19) ultimate:
- reported B-F
selected ultimates:
- discuss appropriateness
ultimate:
- Benktander
unpaid:
- explain Benktander iterations
E (2014.Fall #18) IBNR:
- Benktander
credibility weighting:
- explain Benktander
E (2014.Spring #14) ultimate:
- reported B-F
rptd B-F vs rptd dvlpt:
- situations where equal
rptd B-F vs rptd dvlpt:
- where is B-F better
E (2013.Fall #17) unpaid:
- Benktander
unpaid:
- Benktander 1000 iterations
E (2013.Spring #4) ultimate:
- reported B-F
E (2013.Spring #18) key assumption:
- B-F method
credibility-weighting:
- explain for B-F
credibility-weighting:
- violation of assumption
(d) paid vs rptd B-F for rising LRs
(e) B-F vs Cape Cod

In Plain English!

Example A: Intro to BF Method

The following information is as of Dec 31, 2023. Calculate the ultimate for AY 2023 using the reported Bornhuetter-Ferguson method.

EP 1,000
ECR 65%
reported claims12 375
reported CDF12→ult 1.4

First, note how easy it is to calculate the ultimate using the reported development method:

  • Ultr-Dev   =   375 x 1.4   =   525

And the ultimate for the ECR method is equally easy:

  • UltECR   =   65% x 1,000   =   650

The reported BF method is just a weighted average of these where the weight, z, given to the reported development method is:

z   =   %reported   =   1/CDF

So,

  • z   =   1 1/CDF12→ult   =   1/1.4   =   0.714

and therefore,

  • Ultr-BF   =   [ 0.714 x 525 ] + [ (1 – 0.714) x 650 ]   =   561

Actually, there's a simpler but equivalent formula for the BF ultimate:

Ultr-BF   =   (reported claims) + %unreported x UltECR   =   (reported claims) + (1 – 1/CDF) x UltECR

The proof that these formulations of the BF method are equivalent is not likely to be asked on the exam but you can click the link if you'd like to see it. It's easy. And it's helpful to understand the interpretation of the BF method as a weighted average of the development and ECR methods. Anyway, let's verify that this simpler formula gives the same result.

  • Ultr-BF   =   (reported claims) + %unreported x UltECR   =   375 + (1 – 1/CDF) x 650   =   375 + (1 – 1/1.4) x 650   =   561

Observation: The second term on the right side of the formula: %unreported x ECR is the same thing as unreported claims which is actually just the IBNR.

Here's a straightforward exam problem on the ECR and reported BF methods. Note that you have to choose LDFs so you might not get exactly the same answer as in the examiner's report. You just have to make sure you make reasonable selections and write a short phrase to justify your choices. In this problem, the triangle is so small that unless there is an obvious outlier in the LDF triangle is should be ok to select an all period weighted average.

E (2017.Spring #18)

There's also a paid version of the BF method and it works exactly like the reported version. Just substitute paid amounts in place of reported amounts, and the paid CDF in place of the reported CDF. (The ultimate for the ECR method would be the same for both the paid and reported BF methods.)

Ultp-BF   =   (paid claims) + %unpaid x UltECR   =   (paid claims) + (1 – 1/CDF) x UltECR

A few practice problems...

Practice: 4 problems on the basic BF method

And the quiz...

mini BattleQuiz 1 You must be logged in or this will not work.

Example B: Tort Reform with the BF Method

We're going to take a quick look at a BF method problem that requires an extra adjustment fortort reform. The key is precisely understanding the effect of the tort reform and how to properly adjust for it in your calculation. You'll see it's different (easier actually) from how you adjust for tort reform with the ECR method.

Recall that the ultimate loss is the sum of the paid and unpaid loss. Suppose you're given:

  • unpaid = 1,000
  • paid = 400

Then the ultimate loss is 1,000 + 400 = 1,400. Now, if tort reform is introduced and expected to reduce all future paid amounts by 15% then:

  • adjusted unpaid = 1,000 x (1 - 15%) = 850 (remember that unpaid is the same thing as future paid)

So taking into account tort reform, the adjusted ultimate loss is 850 + 400 = 1,250. Here are a couple of practice problems based on this idea:

Practice: 2 problems on BF method with tort reform

Here's a exam problem just like the tort reform practice problems:

E (2019.Spring #19)

Example C: Benktander Variation on BF

The Benktander method is an iterative method and is a very simple extension of the BF method. Recall the formula for the reported BF method:

  • Ultr-BF   =   (reported claims) + (1 – 1/CDF) x UltECR

The Benktander variation looks almost the same except you substitute Ultr-BF for UltECR on the right side.

UltBenk   =   (reported claims) + (1 – 1/CDF) x Ultr-BF

Let's calculate the Benktander estimate of ultimate using our example from Intro to BF Method. The first step is to calculate the "normal" reported BF ultimate:

  • Ultr-BF   =   (reported claims) + %unreported x UltECR   =   375 + (1 – 1/CDF) x 650   =   375 + (1 – 1/1.4) x 650   =   561

Then we take the result, 561, and substitute it into the Benktander formula:

  • UltBenk   =   375 + (1 – 1/CDF) x 561   =   535

The Benktander method is called an iterative method because you can continue indefinitely. Just take the the result on the left side of the equation:

  • next iteration UltBenk   =   375 + (1 – 1/1.4) x 535   =   528
  • next iteration UltBenk   =   375 + (1 – 1/1.4) x 528   =   526
Pop Quiz A!    :-o
  • What answer do you get if you apply the iterative Benktander approach an infinite number of times? Click for Answer 

BF Method Concepts

You've learned how to apply the BF method but you also need to learn when to apply it. Like any reserving method, it works well in certain situations and not so well in others.

BF Method Key Assumption: unreported (or unpaid) claims will emerge in accordance with expected claims

Let's examine what this means. We know the BF method can be thought of as a weighted average of the development method and ECR method, but the formula we generally use when doing a calculation is this:

  • Ultr-BF   =   (reported claims) + %unreported x UltECR      ← for the reported BF method (discussion is similar for paid BF method)

The second term on the right side of the equation is just the unreported claims (or unpaid claims in the paid BF formula) and you can see it's completely determined the ECR. We are implicitly assuming that the reported claims provide no information about the emergence of the unreported claims. That always seemed a little strange to me. Let's look at a simple example:

  • suppose your reported-claims-to-date = 500
  • suppose your UltECR = 1,000 and the reported CDF = 1.5 so that the %unreported = (1 - 1/CDF) = 0.333
  • based on this, you expect 0.333 x 1,000 = 333 to be reported in the future (this is the emergence)

So Ultr-BF = 500 + 333 = 833. But notice that the 333 has nothing to do with the reported-claims-to-date of 500. You could have had 1,000,000 of reported claims but the expected emergence of 333 would be the same because the 333 is based only on the ECR, not any claims activity to date. That's an extreme example but my point is that there are situations where the BF assumption makes sense and some where it doesn't.

Recall our discussions from prior chapters, Chapter 7 - Development Method - Summary & Observations and Chapter 8 - ECR Method Concepts. There we looked at situations where each of those methods works well and situations where they don't. Since the BF method is a weighted average of those methods, the situations where BF works well is going to be a mixture. In other words, it's a bit of a mishmash where BF works and where it doesn't, but here are a few general comments.

Question: in what situations is the key assumption for the BF method more likely to be satisfied [Hint: NxDx]
  • New line or territory (where data is thin or volatile)
  • Development method may not work well for less mature periods (LDFs could be highly leveraged, especially for lines with longer emergence and settlement patterns)
(the HINT is similar to the one for situations where the ECR method works but with the 2nd and 4th items deleted and marked with an x)

where is BF better

E (2014.Spring #14)


covers lots of good concepts

E (2013.Spring #18)

POP QUIZ ANSWERS

Pop Quiz A - ANSWER

→ Continued application of the Benktander method converges to the development method estimate of ultimate. In this case, 525.

  • You can prove this algebraically but it's easier to understand conceptually. Recall the reported BF ultimate is a weighted average between the development method and the ECR method. For our example we had:
Ultr-Dev   <   Ultr-BF <   <   UltECR
  • By the same reasoning, the first iteration of Benktander is a weighted average of the development method and the BF method so we have:
Ultr-Dev   <   UltBenk   <   Ultr-BF   <   UltECR
  • And again, the next iteration of Benktander will be a weigthed average of the development method and the first iteration of Benktander:
Ultr-Dev   <   next iteration UltBenk   <   UltBenk   <   Ultr-BF   <   UltECR

→ You can see what's happening: Each successive iteration of Benktander is squeezed between the previous iteration and the development method. The result is that is must converge to the development method estimate. (If the development method had originally been higher than the ECR method, then the inequalities would be reversed but the reasoning is the same.)