Tag Archives: Insurance

No. 144: MIES – Intertemporal Choice

26 July, 2020 10:11 PM / Leave a Comment /

This entry is part of a series dedicated to MIES – a miniature insurance economic simulator. The source code for the project is available on GitHub.

Current Status

This week, I’ve been continuing my work on incorporating risk into the consumer behavior component of MIES. The next step in this process involves the concept of intertemporal choice, an interpretation of the budget constraint problem whereby a consumer can shift consumption from one time period to another by means of savings and loans. The content of this post follows chapter 10 of Varian.

For example, a person can consume more in a future period by saving money. A person can also increase their consumption today by taking out a loan, which comes at a cost of future consumption because they have to pay interest. When making decisions between current and future consumption, we also have to think about time value of money. When I was reading through Varian, I was happy to see that many of the concepts I learned from the financial mathematics actuarial exam were also discussed by Varian – such as bonds, annuities, and perpetuities – albeit in much less detail.

This inspired me to create a new repo to handle time value of money computations, which is not yet ready for its own series of posts, but for which you can see the initial work here. I had intended to make this repo further out in the future, but I got excited and started early.

Also relevant, is the concept of actuarial communication. Now that I’m blogging more about actuarial work, I will need to be able to write the notation here. There are some \LaTeX packages that can render actuarial notation, such as actuarialsymbol. Actuaries are still in the stone age when it comes to sharing technical work over the Internet, not out of ignorance, since many actuaries are familiar with \LaTeX, but out of corporate inertia in getting the right tools at work (which I can suppose be due to failure to persuade the right people) and lack of momentum and willingness as many people simply just try to make do with using ASCII characters to express mathematical notation. I think this is a major impediment to adding rigor to practical actuarial work, which many young analysts complain about when they first start working, as they notice that spreadsheet models tend to be a lot more dull than what they see on the exams.

I was a bit anxious in trying to get the actuarialsymbol package working since, although I knew how to get it working on my desktop, I wasn’t sure if it would work with WordPress or Anki, a study tool that I use. Fortunately, it does work! For example, the famous annuity symbol can be rendered with the command \ax{x:\angln}:

Rendered by QuickLaTeX.com

That was easy. There’s no reason why intraoffice email can’t support this, so I hope that it encourages you to pick it up as well.

The Statics Module

Up until now, testing new features has been cumbersome since many of the previous demos I have written about required existing simulation data. That is, in order to test things like intertemporal choice, I would first need to set up a simulation, run it, and then use the results as inputs into the new functions, classes, or methods.

That really shouldn’t be necessary, especially since many of the concepts I have been making modules for apply to economics in general, and not just to insurance. To solve this problem, I created the statics module, which is named after the process of comparative statics, which examines how behavior changes when an exogenous variable in the model changes (aka all the charts I’ve been making about MIES).

The statics module currently has one class, Consumption, which can return attributes such as the optimal consumption of a person given a budget and utility function:

A lot of the code here is the same as that which can be found in the Person class. However, instead of needing to instantiate a person to do comparative statics, I can just use the Consumption class directly from the statics module. This should make creating and testing examples much easier.

Since much of the code in statics is the same as in the Person class, that gives me a hint that I can make things more maintainable by refactoring the code. I would think the right thing to do is to have the Person class use the Consumption class in the statics module, rather than the other way around.

The Intertemporal Class

The intertemporal budget constraint is:

    \[c_1 + c_2/(1+r) = m_1 + m_2/(1+r)\]

Note that this has the same form as the endowment budget constraint:

    \[p_1 x_1 + p_2 x_2 = p_1 m_1 + p_2 m_2 \]

With the difference being that the two endowment goods are now replaced by consumption in times 1 and 2, represented by the cs and the prices, the ps are now replaced by discounted unit prices. The subscript 1 represents the current time and the subscript 2 represents the future time, with the price of future consumption being discounted to present value via the interest rate, r.

The consumer can shift consumption between periods 1 and 2 via saving and lending, subject to the constraint that the amount saved during the first period cannot exceed their first period income, and the amount borrowed during the first period cannot exceed the present value of the income of the second period.

Since the intertemporal budget constraint is a form of the endowment constraint, we can modify the Endowment class in MIES to accommodate this type of consumption. I have created a subclass called Intertemporal that inherits from the Endowment class:

The main difference here is that the Intertemporal class can accept an interest rate and an inflation rate to adjust the present value of future consumption.

Example

As an example, suppose we have a person who makes 5 dollars in each of time periods 1 and 2. The market interest rate is 10% and their utility function takes the Cobb Douglas form of:

    \[u(x_1, x_2) = x_1^{.5} x_2^{.5}\]

which means they will spend half of the present value of the endowment as consumption in period 1:

The main thing that sticks out here is that the slope of the budget constraint has changed to reflect the adjustment of income to present value. The x-axis intercept is slightly less than 10 because the present value of income is slightly less than 10, and the y-axis intercept is slightly more than 10 because if a person saved all of their time 1 income, they would receive interest of 5 * .1 = .5, making maximum consumption in period 2 10.5.

Since the person allocates half of the present value of the endowment to time 1 consumption, this means they will spend (5 + 5/1.1) * .5 = 4.77 in period one, saving 5 – 4.77 = .23, which then grows to .23 * (1 + .1) = .25 in period 2, which allows for a time 2 consumption of 5 + .25 = 5.25. This is verified by calling the optimal_bundle() method of the Consumption class:

Further Improvements

The Varian chapter on intertemporal choice briefly explores present value calculations for various payment streams, such as bonds and perpetuities. I first made a small attempt at creating a tvm module, but quickly realized that the subject of time value of money is much more complex than what is introduced in Varian, since I know that other texts go further in depth, and hence it may be necessary to split a new repo off from MIES so that it can be distributed separately. This repo is called TmVal, the early stages of which I have uploaded here.

Neither of these are ready for demonstration, but you can click on the links if you are interested in seeing what I have done. The next chapter of Varian covers asset markets, which at first glance seems to just be some examples of economic models, so I’m not sure if it has any features I would like to add to MIES. There is still more work to be done on refactoring the code, so I may do that, or move further into risk aversion, or do some more work on TmVal.

Posted in: Actuarial, MIES / Tagged: , , ,

No. 142: The Property Casualty Data Model Specification

12 July, 2020 10:31 PM / 4 Comments /

Introduction

A few weeks ago, I stumbled across something neat – the Property Casualty Data Model (PCDM). PCDM is a relational database specification that covers all major parts of an insurance company’s operations. At first glance, the web page on which it is located seemed mundane to me, so I almost overlooked it, but when I opened the accompanying documentation, I realized I had stumbled upon a goldmine of useful information. This document contains enough information to implement an entire data warehouse and then tweak it to an organization’s specific needs.

Although we actuaries have a reputation for being able to handle data, most of us have not received any kind of formal training in handling relational database systems, and have had little interaction with standards organizations outside of our own governing organizations like the CAS, SOA, and AAA. When I tried searching for PCDM in the CAS library, I was astonished to find just a handful of references to the specification, and flabbergasted that there had been a document floating around on another profession’s website for the last seven years that almost no actuaries had ever heard about, but contained the exact type of information that many actuaries wanted but thought had never existed in the public domain (and in my case, it contains more than what I need for parts of the MIES backend).

One benefit that I’ve had from working several jobs, and also as a consultant, is that I’ve been able to witness widely varying levels of maturity of data warehouse systems at commercial insurance companies of different sizes and functions (specialty, commercial, and reinsurance) as well as those of a major stock exchange to get some perspective of how insurance database implementations compare to those of other industries. I have seen many actuaries at small and midsize carriers struggle with how to create OLAP data warehouses, not knowing what tables, relationships, and fields to define, how to do it in a way that conforms to commonly accepted data management practices (if they even knew what they were), or even where to look or whom to talk to to find out what data are stored at the company, and in what form.

Earlier in my career, at a small insurer, a few years before this document existed, I would sometimes encounter databases with hundreds of undocumented tables, not knowing what any of the tables stored, if they were the right tables I needed, or if they were designed appropriately. I was one of the few actuaries in my department who knew SQL (and even then, I wasn’t good at it). So, with my introductory textbook on database management systems at my side and a landline I used to contact people in the IT deparment, I embarked upon the long journey of understanding insurance information systems.

In those days, the game kind of went like this. I would ask my boss if they knew anyone in IT, then I’d pick up the phone and call them to ask if they maintained the database I was looking at or knew of anyone who did or anyone who might know anyone who did. That chain of phone calls typically went 5 people deep until I finally reached someone who actually worked on the relevant database, and if I was lucky, they’d have some documentation, and I’d slowly figure out what kind of data I was working with.

It might have looked like this. What the hell? Boss, this is gonna take me a while to understand. (Actually this is PCDM, but the good news about PCDM is that it’s documented – but imagine what it would be like if it weren’t and the last person who touched it left 3 years ago).

When I moved to a larger organization, I came to realize how large of a knowledge/talent gap there was between companies when I actually got to use a well-documented data warehouse that had all the entities, relationships, and fields defined as well a data dictionary detailing what all the values were – a rare practice that even many established insurers don’t follow. Unfortunately, when I left that organization, I also lost access to that documentation, and with it, a wealth of knowledge on what a proper data warehouse should look like.

I had thought to myself if only the CAS had a standard that actuaries and students could access, we’d have something that would actually resemble what a database at a real insurer actually looked like, instead of just having just theoretical papers from which to learn that might have some code copy-pasted in. If we had a standard, knowledge of proper database design and implementation would then not be employer dependent, and new research papers could reference the standard rather than just imagining what a data warehouse would look like or omitting proprietary parts of a company’s database.

When I came across PCDM, I realized the significance of a document I randomly found while eating breakfast on holiday. Therefore, I immediately got to work in writing an implementation of it in Python so that other actuaries could finally have what I wish I had when I was younger. I completed the first release at the end of the July 4th weekend, and made it available on GitHub. My hope is that somebody out there finds this post and clones my repository – and understands how important it is to spread word of this specification.

Subject Area Models

PCDM details 13 subject area models (SAMs), each of which comes with an entity-relationship (ER) diagram. Each subject area model represents a major portion of an insurance company’s operations:

  1. Party
  2. Account and Agreement
  3. Policy
  4. Claim
  5. Assessment
  6. Agreement Role
  7. Claim Role
  8. Staffing Role
  9. Party Subtype
  10. Insurable
  11. Money
  12. Event
  13. Product Coverage

For example, the Party SAM contains information on all parties that are involved in insurance transactions, such as households, employees, vendors, etc. Other SAMs contain information on underwriting, claims, and accounting operations. The rest of this post will show you what those SAMs look like – the images are crowded and contain quite a bit of information, so it’s best to click on them to see them in full resolution. If you want more details, the PCDM document is available on the object management group website.

Party

As stated before, the Party SAM contains information about households, firms, and staff:

Account and Agreement

The Account and Agreement SAM contains information on legal agreements, such as policies, reinsurance contracts, etc.

Policy

The Policy SAM contains information on…policies. Policy number, effective date, expiration date, limits, deductibles, coverage, etc.

Claim

The Claim SAM contains information on claims, relevant dates, adjusters, lawyers, damage amounts, etc.

Assessment

The Assessment SAM contains information on how the insurer goes about gathering information, such as credit scores, appraisals, and investigations carried out during the claim adjustment and underwriting processes.

Agreement

The Agreement Role SAM contains information on the different types of parties that might be involved in insurance – mostly an expansion of the Party Role superclass found in the Party SAM.

Claim Role

The Claim Role SAM contains information on the parties involved in the adjustment process, such as adjusters, claimants, lawyers, etc.

Staffing Role

The Staffing Role SAM contains information on insurance company staff and contractors.

Party Subtype

The Party Subtype SAM contains information on company subdivisions.

Insurable Object

The Insurable Object SAM contains information on things that can be insured, like cars and buildings.

Money

The Money SAM contains information on transactions, like premium, loss payments, and case reserves.

Event

The Event SAM contains information on policy and claim events, like policy inception, cancelation, and claim occurrence.

Product Coverage

The Product Coverage SAM contains inforamtion on product types and coverages.

Python/SQLAlchemy Implementation

I figured if I want to claim credit for anything besides just copying and pasting the diagrams above from the specification, I should actually make some kind of contribution. The good news is I haven’t found any kind of implementation on GitHub – what I mean by that is the PDF is nice to have and all, but you can’t deploy a datawarehouse with the PDF, it needs to be translated into code which people can then use to deploy the warehouse. Therefore, I’ve written my own implemntation of PCDM in Python using the SQLAlchemy ORM.

Below is an example of how I translated the Party SAM into code. I did this for the 12 other SAMs as well, and then wrote another module to combine them all together into a single deployable data warehouse:

I have taken a few liberties in my own implementation, such as creating surrogate keys whenever I came across a composite identifier, which should make joining easier. I’ve also chosen my own data types for ambiguous fields (such as integers for identifiers and strings for descriptions) based on my own interpretation, and chose to represent superclass/subclass relationships by making one table for each superclass and subclass, which can be joined with primary/foreign key relationships.

Installation and Deployment

To use PCDM, you need to install SQLAlchemy if you don’t already have it:

You can install and deploy PCDM by cloning the repo from my GitHub. The deployment script is displayed below:

You can either run this script, or use the terminal to clone and then deploy:

If the deployment succeeds, you should see a SQLite database appear with 256 tables in it:

Although SQLite is the default, you can use this repo to make your own deployments for other RDBMSs (Postgres, SQL Sever, etc.). I have not made these ports yet, but I’m assumming if you have read this far, you’re a technically savvy person who can help me out by writing your own.

Documentation

I am working on making my own documentation, which is not yet available. But for now you can refer to the official OMG PCDM document.

Bugs

Warning – this repo is open source, and hence contains no warranty and may contain bugs. You can help contribute to the effort by making an issue or pull request should you encounter a bug.

Posted in: Actuarial / Tagged: , , , ,

No. 140: MIES – Rate Changes – Slutsky and Hicks Decomposition

28 June, 2020 6:24 PM / Leave a Comment /

This entry is part of a series dedicated to MIES – a miniature insurance economic simulator. The source code for the project is available on GitHub.

Current Status

Last week, I revisited the MIES backend to split what was a single database into multiple databases – one per entity in the simulation. This enhances the level of realism and should make it easier to program transactions between the entities. This week, I’ll revisit consumer behavior by implementing the Slutsky and Hicks decomposition methods for analyzing price changes.

In the context of insurance, consumers frequently experience changes in price, typically during renewals when insurers apply updated rating algorithms against new information known about the insureds. For example, If you’ve made a claim or two during your policy period, and miss a rent payment, causing your credit score to go down, your premium is likely to increase upon renewal. This is because past claims and credit are frequently used as the underlying variables in a rating algorithm.

What happens when consumers face an increase in rates? Oftentimes, they reduce coverage, may try to shop around, or may do nothing at all and simply pay the new price. Today’s post discusses the first phenomenon, whereby an increase in rates causes a reduction in the amount of insurance that a consumer purchases. We can use the Slutsky and Hicks decomposition methods to break down this behavior into two components:

  1. The substitution effect
  2. The income effect

The substitution effect concerns the change in relative prices between two goods. Here, when a consumer faces a premium increase, the price of insurance increases relative to the price of all other goods, altering the rate at which the consumer would be willing to exchange a unit of insurance for a unit of all other goods.

The income effect concerns the change in the price of a good relative to consumer income. When a consumer faces a premium increase without a corresponding increase in income, their income affords them fewer units of insurance.

The content of this post roughly follows the content of chapter 8 in Varian. As usual, I focus on how this applies to my own project and will skip over much of the theoretical derivations that can be found in the text.

Slutsky Identity

The Slutsky identity has the following form:

    \[\frac{\Delta x_1}{\Delta p_1} = \frac{\Delta x_1^s}{\Delta p_1} - \frac{\Delta x_1^m}{\Delta m}x_1\]

Where the x_1 represents the quantity of good 1 (in this case insurance), p_1 represents the price of insurance (that is, the premium) and m represents the consumer’s income. The deltas are used to describe how the quantity of insurance purchased changes with premium, expressed on the left side of the identity. The first term after the equals sign represents the substitution effect, and the second term after the equals sign represents the income effect.

The Slutsky identity can also be expressed in terms of units instead of rates of change (\Delta x_1^m = -\Delta x_1^n):

    \[\Delta x_1 = \Delta x_1^s + \Delta x_1^n\]

While MIES can handle both forms, we’ll focus on the first form for the rest of the chapter.

Substitution Effect

Let’s examine the substitution effect. First, we’ll conduct all the steps manually, and then I’ll show how they are integrated into MIES. If we have some data already stored in a past simulation, we can extract a person from it:

Here, we have a person who makes 89k per year, with Cobb Douglas parameters c = 0.1 and d = 0.9. This means this person will spend 10% of their income on premium. For the sake of making the graphs in this post less cluttered and easier to read, let’s change c = d = .5 so the person spends 50% of their income on insurance:

From the above figure, we can see that the person consumes about 45k worth of insurance. That’s about 11 units of exposure at a 4k premium per exposure, which is unrealistic in real life, but makes life easy for me because I haven’t bothered to update the margins of my website to accommodate wider figures. We’ll denote this bundle as ‘Old Bundle’ because we’ll compare it to the new consumption bundle after a rate change (note – if you are trying to replicate this in MIES, your figures may look a bit different, in reality I manually adjust the style of the plots so they can fit on my blog).

Now, let’s suppose the person faces a 100% increase in their rate so that their premium is 8k per unit of exposure, and construct a budget to reflect this:

Plotting this new budget, we see that the line tilts inward, since the person can only afford half as much insurance as before:

The first stage in Slutsky decomposition involves calculating the substitution effect. This is done by tilting the budget line to the slope of the new prices, but with income adjusted so that the person can still afford their old bundle. We then determine the new optimal bundle at this budget (denoted ‘substitution budget’) and call it the substitution bundle:

    \[\Delta m = x_1 \Delta p_1\]

You can see that if the person were given enough money to purchase the same amount of insurance even after the rate increase, they would still reduce their consumption from 11.1 to 8.3 units of insurance. 8.3 – 11.1 = -2.8 is the substitution effect.

Income Effect

Now, to calculate the income effect, we then shift the substitution budget to the position of the new budget:

The person purchases 5.5 units of insurance at the new budget, so the income effect is 5.5 – 8.3 = -2.8 for the substitution effect. The total effect is -2.8 -2.8 = -5.6 units of insurance, the sum of the substitution and income effect. This is the same as the new consumption minus the old consumption 5.5 – 11.1 = -5.6

MIES Integration

The Slutsky decomposition process has been integrated into MIES as a class in econtools/slutsky.py:

This has been added to the Person class, so we can use its methods to get the substitution and income effects. This conveniently packages all the manual steps we took above together:

Which returns -2.8 for each effect, the same as above.

Hicks Decomposition

A similar decomposition method is called Hicks decomposition. Instead of pivoting the budget constraint so that the person can afford the same bundle as before, the budget constraint is shifted so that they have the same utility as before. Using algebra, we can solve this by fixing utility:

    \[m^\prime = \frac{\bar{u}}{\left(\frac{c}{c +d}\frac{1}{p_1^\prime}\right)^c\left(\frac{d}{c+d}\frac{1}{p_2}\right)^d}\]

where m^\prime is the adjusted income, and p_1^\prime is the new premium, and \bar{u} is the utility fixed at the original level.

You’ll notice there’s a subtle difference, the new bundle is the same as in the Slutsky case, but the substitution bundle in this case is on the original utility curve. This gives different answers for the substitution and income effects, which are -3.3 and -2.3, which add up to a total effect of -5.6, as before.

The code for the Hicks class is much the same as that for the Slutsky class, so I won’t post most of it here, the relevant change is in calculating the substitution budget:

Further Improvements

Since Hicks substitution is mostly similar to Slutsky in terms of code, it makes sense for the Hicks class to inherit from the Slutsky class or for both of them to inherit from a superclass.

I’m currently working on implementing wealth into MIES, since as of today, none of the transactions actually impact wealth.

Posted in: Actuarial, Mathematics, MIES / Tagged: , , ,

No. 130: Introducing MIES – A Miniature Insurance Economic Simulator

26 November, 2018 12:31 AM / Leave a Comment /

MIES, standing for Miniature Insurance Economic Simulator, is a side project of mine that was originally conceived in 2013. The goal of MIES is to create a realistic, but simplified representation of an insurance company ERP, populate it with simulated data, and from there use it to test economic and actuarial theories found in academic literature. From this template, multiple firms can then be created, which can then be used to test inter-firm competition, the effects of which will be manifested via the simulated population of insureds.

Inspiration for the project came from the early days of my career, when I was first learning how to program computers. While I found ample general-purpose material online for popular languages such as Python, R, and SQL, little existed as far as insurance-specific applications. Likewise, from an insurance perspective, plenty of papers were available from the CAS, but they were mostly theoretical in nature and lacked the practical aspects of using numerical programming to conduct actuarial work – i.e., using SQL to pull from databases, what a typical insurance data warehouse looks like, how to build a pricing model with R, etc.

I had hoped to bridge that gap by creating a mock-up of an insurance data warehouse that could be used to practice SQL queries against, thus bridging the gap between theory and practice, and creating a resource that other actuaries and students could use to further their own education. I then realized that not only would I be able to simulate a single company’s operations, but I’d also be able to simulate firm interactions by cloning the database template and deploying competing firm strategies against each other. And furthermore, should I succeed in creating a robust simulation engine, I would be able to incorporate and test open source actuarial libraries written by others.

I would have liked to introduce this project later, but I figured if I were to reveal pieces of the project (like I did with the last post) without an overarching framework, readers wouldn’t really get the point of what I was trying to achieve. Back in 2013, the project stalled due to exams, and my lack of technical knowledge and insurance experience. Now that I’ve worked for a bit and finished my exams, I can continue work on this more regularly. Below, I present a high-level schematic of the MIES engine:

The image above displays two of the three layers of the engine – an environment layer that is used to simulate the world in which firms and the individuals they hope to insure interact, and a firm layer that stores each firm’s ERP and corporate strategy.

  • Environment Layer

    • The environment layer simulates the population of potential insureds who are subject to everyday perils that insurance companies hope to insure. The environment module will be a program (or collection of programs) that provides the macroeconomic (GDP, unemployment, inflation), microeconomic (individual wealth, utility curves, births and deaths), sociodemographic (race, religion, household income, commute time), and other environmental parameters such as weather, to represent everyday people and the challenges they face. The simulated data are stored in a database (or a portion of a very large database) called the environmental database.

    A module called the information filter then reads the environmental data and filters out information that can’t be seen by individual firms. Firms try to get as much data as they can about their potential customers, but they won’t be able to know everything about them. Therefore, firms act on incomplete information, and the information filter is designed to remove information that companies can’t access.

  • Firm Layer

    • The firm layer is a collection of firm strategies – each of which is a program that represents the firm’s corporate strategy (pricing, reserving, marketing, claims, human resources, etc.), along with a set of firm ERPs which store the information resulting from each firm’s operations (premiums, claims, financial statements, employees).

The environment layer then simulates policies written and claims incurred, which are then stored in their respective firm’s ERPs. The result of all this is a set of economic equilibria – that is, insurance market prices, adequacy, availability, etc. Information generated from both the environment and firm layers are then fed back into the environment module as a form of feedback that influences the next iteration’s simulation.

The image below represents a simple breakdown of an individual firm ERP:

Here, we have the third layer of MIES – the user interface layer.

  • Underwriting System

    • An underwriting system is a platform that an insurer uses to write policies. I’ll try my best to use an available open-source engine for this (possibly openunderwriter). The frontend will be visible if a human actor is involved, otherwise, it will be driven behind the scenes programmatically.

  • Claims System

    • A claims system is a platform that an insurer uses to manage and settle insurance claims. On top of the claims system is the actuarial reserving interface (triangles).

  • General Ledger

    • The general ledger stores accounting information that is used to produce financial statements. Current candidates for this system include ledger-cli and LedgerSMB.

Below, is a rudimentary claims database schema, containing primary-foreign key relationships, but no other attributes (to be added later):

I’m using PostgreSQL for the database system, and MIES itself will be hosted on my AWS cloud account as a web-based application. I’m currently exploring Apache and serverless options as a host. The MIES engine itself was originally being scripted in Scala (I was really into Spark at the time) but will now be done in Python to reach a wider audience (I may revisit Scala if the data becomes big – hopefully I’ll be able to get some kind of funding for hosting fees if that happens).

With this ecosystem, I aim to reconcile micro- and macroeconomic theory, and study the effects of firm competition, oligopoly, and bankruptcy on the well-being of insureds. The engine will serve as the basis for other actuarial libraries and will incorporate pricing, reserving, and ERP systems that could eventually become standalone open-source applications for the insurance industry. Stay tuned for updates, and check the github repo regularly to see the project progress.

Posted in: Uncategorized / Tagged: , ,