Tag Archives: Mies

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. 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. 132: Exploring Serverless Architectures for MIES

21 April, 2019 9:44 PM / Leave a Comment /

A few months ago, I introduced MIES, an insurance simulation engine. Although I wanted to work on this for the last few years, I had been sidetracked with exams, and more recently, a research project for the Society of Actuaries (SOA) that involved co-authoring a predictive modeling paper with other actuaries and data scientists at Milliman. That effort took an entire year from the initial proposal to its final publication, of which the copy-edit stage is still ongoing. Once it has been published, I’ll provide another update on my thoughts over the whole process.

Meanwhile, I’ve had some time to get back to MIES. As far as technology goes, a lot has changed over the years, including the introduction of serverless computing – implemented in AWS Lambda in 2014. In short, serverless computing is a cloud service that allows you to execute code without having to provision or configure servers or virtual machines. Furthermore, you only need to pay for what you execute, and there is no need to terminate clusters or machines in order to save on costs. Ideally, this should be more cost (and time) effective than other development options that involve allocating hardware.

Since MIES is cloud-based, I thought going serverless would be worth a try, and was further motivated to do so upon the recommendation of a friend. The following image comes from one of the AWS tutorials on serverless web apps. What I have envisioned is similar, with the exception of using Postgres instead of DynamoDB.

Following the tutorial was easy enough, and took about two hours to complete. My overall assessment is that although I was able to get the web app up and running quickly, many of the pieces of the tutorial, such as the files used to construct the web page, and the configuration options for the various AWS services involved (S3, Cognito, DynamoDB, Lambda, API Gateway) were preset without explanation, which made it hard to really understand how the architecture worked, or what all the configuration options did, or why they were necessary. Furthermore, I think a developer would need to have more experience in the component AWS services to be able to build their own application from scratch. Nevertheless, I was impressed enough to want to continue experimenting with serverless architectures for MIES, so I purchased two books to get better at both AWS itself and AWS Lambda:

  1. Amazon Web Services in Action
  2. AWS Lambda in Action

One downside to this approach is that while informative, these types of books tend to go out of date quickly – especially in the case of cloud technologies. For example, I have read some books on Spark that became obsolete less than a year after publication. On the other hand, books offer a structured approach to learning that can be more organized and approachable than reading the online documentation or going to Stack Overflow for every problem that I encounter. This is however, cutting edge technology, and no one approach will cover everything I’ll need to learn. I’ll have to take information wherever I can get it, and active involvement in the community is a must when trying to learn these things.

Going back to the original MIES diagram, we can see that serverless computing is ideal:

I ought to be able to program the modules in AWS Lambda and store the data in Postgres instances. Having multiple firms will complicate things, as will focusing on the final display of information, along with the user interface. For now, I’ll focus on generating losses for one firm, and then reaching an equilibrium with 2 firms. I already have a schema mocked up in Postgres, and will work on connecting to it with Python over the course of the week.

Posted in: 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: , ,