My Actuarial Working Life

After completing the debugging on Prophet model yesterday, I still think that building a #Prophet model that aims to fit-for-all (e.g., business units) is NOT A GOOD IDEA . Yesterday my team member, Cang Zheng, and I were assisting one of our Prophet users in debugging her reserve figure generated from their existing Prophet production model (which was developed earlier by other modelers). When we went through the Prophet model, although it was not modified from the standard Conventional library, we still found traces that it is modified from a library that aims to achieve fit-for-all purposes.

In several discussions with Prophet users, the topic of sub-product codes, commonly known as SPCODE , often comes up. I thought it would be helpful to share some of my views on how SPCODE should be used—especially in terms of maintaining model flexibility and supporting various actuarial analyses.

In my previous post about using enumerations in Prophet, I referenced "calculation looping" in one of the illustrations. That got me thinking—not all Prophet users may be familiar with this concept. After all, not every Prophet model uses the calculation looping technique. Let’s take a closer look at what calculation looping is, how it works, and why it’s useful—especially when you're dealing with different sets of assumptions in a single run.

From my experience working with Prophet users (Valuation Team), most are quite familiar with running in-force projections, such as monthly valuation and embedded value calculations. However, when it comes to new business ("NB") processing , many users find themselves uncertain or confused on how it works. It’s not uncommon for me to receive questions like,  "Why can’t I just use the cross multiplication method?" "Why does the project method take so much longer to run?" (Prefer video? View the  video  for this post!)

If you’ve upgraded your Prophet version to Release 2024 Q4, you might have noticed a new and helpful feature: you can now define a variable as an enumeration type—in addition to the usual number and text types. (Prefer video? View the video for this post!)

In one of the discussions with my team about medical insurance, I emphasized that claim data is one of the most valuable assets  for insurance companies. Even if insurers engage third-party administrators ("TPAs") to handle claim processing, it’s crucial for them to retain access to detailed claim data – and at a granular level.  

In its recent announcement on medical insurance , Bank Negara Malaysia highlighted Malaysia’s medical inflation rate of 15%, which surpasses the average across global and Asia Pacific region. However, when I consider the rate of increase in medical insurance premiums, I question whether this 15% figure is truly a suitable benchmark – are we really comparing apples to apples?   Before diving into my thoughts on this, I believe it’s helpful to explain the concept of " insured lives " experience.  

Bank Negara Malaysia has announced interim measures to address rising medical insurance premiums. While I can’t foresee how some of these measures will resolve the underlying issues, I am particularly curious to see how the Diagnosis Related Group ("DRG") payment model might help tackle the root cause.   Reflecting on my experience with my first actuarial employer, I recall being responsible for preparing claim analyses for individual medical insurance. One of the more interesting aspects of this work was constructing claim distributions based on actual experience. While the results were typically presented in tables, I often created histograms to better illustrate the distribution – in my opinion, the visual representation provided deeper insights into the claim patterns.  

Medical insurance has become one of the hottest topics in Malaysia’s insurance and Takaful industry lately. Some members of parliament (MPs) have urged Bank Negara Malaysia to impose a cap on rising medical insurance premiums. In the process, certain MPs have portrayed insurance and Takaful companies as profit-driven entities operating at the expense of public interest – with social media posts framing the debate as a "Rakyat Win."   I’d like to share a few general thoughts on this issue, steering away from technical details for now (perhaps I’ll dive into those another time). Here are a few perspectives we can take away from the recent developments:  

In my last post , we discussed the importance of avoiding “black box” Prophet models—models so complex and opaque that users struggle to understand the underlying calculations and dependencies. Without clarity, these models can lead to errors, inefficiencies, and unwelcome surprises when something goes wrong. Today, let’s shift our focus to another characteristic of a "good" Prophet model: keeping redundancy low . Let's make the idea simple, redundancy in a Prophet model refers to variables in the model’s library that aren’t actually used in any products within the workspace. If a Prophet model has high redundancy, this means it has thousands of variables available but only a fraction actively contributing to the calculations. 

If you're working in the valuation team of a life insurance company, chances are you've spent a lot of time with Prophet. It’s that powerful tool we use for things like cash flow projections and calculating reserves. But here's the thing—how often do you really stop to think about whether the Prophet model you're using is a 'GOOD' Prophet model ?

In my last post and debut podcast, I talked about why strong foundations matter for coming up with smart, workable solutions in business. But, there's a twist when we hit a problem that's completely new to us: just having that solid base isn't always enough. This brings me to a story I love to share with my team and my training participants, about how Henry Ford had a lightbulb moment that changed cars forever. Did you know he got the idea to build cars faster and cheaper by watching how meatpacking plants worked? They had this assembly line where everyone did one job, moving the product along quickly. Ford thought, "Why not do this with cars?" And just like that, in 1913, he changed the game by setting up an assembly line at his car plant in Michigan.

After completing the actuarial modelling class on Tuesday, I had a short but fruitful conversation with my team member, Koh Ying, at the lift lobby. As this was a developer course, Koh Ying came over to support the training and provided guidance to the participants when they encountered challenges in the class exercise. Well, the topic we discussed might seem a bit dry, but it is important to our work - yes, we discussed why we should learn the fundamentals/concepts, or which I usually call "theory".

One of my favorite functionalities in Prophet is "parameterized extended formula". Although this technical term sounds a bit complex, the concept is in fact pretty straight forward - we can just relate to something we learned in the secondary school, i.e. "f(x)" (functions). How parameterized extended formulas work is similar to self-defined function in Excel VBA. Say we have a function with multiple elements, e.g. f(x, y, z). When we input x = 2, y = 3 and z = 4 to this function, we may get a value of 10 directly. The same function can be used for different combinations of x, y and z - i.e. we can REUSE the function and make our calculation models more efficient. We can use parameterized extended formulas for various areas, such as converting annual decrement rates to monthly rates. Instead of replicating similar formulas for death, TPD and CI separately, we can create a parameterized extended formula that can be used for death, TPD and CI at the same time: Create ...

Sharing is always a good thing. By sharing the knowledge I have, apart from providing others some ideas on how to improve their daily work or resolve the problems they encounter, I can still benefit from the sharing. Through writing posts in LinkedIn, I strengthen my knowledge and concepts, as well as gaining some inputs and view from other connections in my network. For better records, I also put down my sharing under this blog, so that it is easier to be referred if needed.   Thought (1): Debugger License - Get it if you have the budget If you have additional budgets on Prophet licensing, I would suggest to get the Debugger license (yes, it needs a separate licensing). When you encounter errors in your Prophet runs, AND Prophet cannot display its run log (i.e. errors in both doing runs and displaying run logs at the same time) , Debugger will save your life (otherwise it may very tough to find out what the issue is). If I can suggest enhancements on Prophet, I think it will ...

In my previous post, I have discussed areas that you may consider in setting up input variables . Before I proceed my discussion on core variables, I would think that it is good for use to take a look on indicators - as indicators play an important role in setting core variables with various formulas (known as "variable definitions" in a Prophet model).  The funny thing about indicators is: it DOES NOT carry any formulas that you need to use in calculating a variable! Basically, they are just some texts that you can combine using different logical operators (AND, OR, NOT), such as "ORD_PAR AND SING_PREM" for a single premium ordinary participating product. 

If you a Prophet user, you must have heard about input variables  and core variables . In simple words, input variables that you need to define individually when you setup a product (of course you can accept the default definitions), whereas core variables are those will be automatically called from libraries when you perform a run.  However, do you ever think how we should assign a variable as input variable or core variable? What are the characteristics that make a variable to be better assigned as input variable? There is no a single right or wrong answer for the above questions. In this article, I am going to share my views (actually the treatment I adopted in the Prophet models I developed before) on how you can handle input variables in the Prophet models.

When I worked on Prophet projects that involved setting up Prophet model from scratch or streamlining existing Prophet models, one of the common requests I came across was relating to no. of master products. Many Prophet users have such a perception, i.e. the lesser no. of master products in a Prophet workspace, the better it is. Let's think about it, is this perception correct? When we are talking about of having a better Prophet model, what does the word "better" mean? Define a BETTER Prophet Model It is important for us to define what we expect from a "better" Prophet model, instead of focusing on the no. of master products in the model. Let me share some views if I am a Prophet user:

Among the materials & books related to learning effectiveness that I have studied recently, “ PEAK: How all of us can achieve extraordinary things ” written by Anders Ericsson& Robert Pool (I read the Chinese translation, e-book format) is the one giving me the most inputs. How does an EXPERT do? Instead of going to the deliberate practice straightaway, I decide to take another approach in carrying out this discussion, in the same manner as doing a business planning - let's start with the targets / goals we would like to achieve, work backward and find out what the best way to follow. Say I would like to excel in a particular subject, such as in mastering a programming language, so that I will be more competitive in the job market. Apart from attending programming classes without a clear target of how far I should go (although certification may be a good reference), perhaps it will be good for me to take a look on how an EXPERT should be. Ideally, an expert should ...

When involving in system implementation (policy administration system) related work, I always encounter queries raised in administrating claim processes related to waiver of premium ("WOP") benefit. When WOP feature is triggered by a covered event (either death, TPD or critical illness), the benefit will be paid over long period (which may stretch for many years). This makes a systematic WOP claim process more important so that the inflow and outgo related to WOP benefit can be managed properly. What is WOP benefit? Briefly, when WOP feature is triggered by a covered event (either payor or insured), all future payments for premium after event date are "waived" - this doesn't mean the affected policy no longer receiving premiums. More accurately, although no payment is required for this policy, this policy still receives premiums - just the premiums come from different sources. This policy is expected to work as normal without any hiccup, for example, an inves...