My Actuarial Working Life

Fit-for-All Prophet Model - Not a Good Idea

2026-05-25T13:50:53.281+08:00

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.

How did we find the traces? In fact, it is not something difficult - such Prophet library usually contains substantial redundancy, as well as longer route to trace the calculations - also many rules to control the calculations. In addition, the formatting used in coding is inconsistent, which is clearly not from a standard library.

Having a fit-for-all Prophet model is indeed ambitious, but in my view, it is less practical. As I also share with my team members, FLEXIBILITY always come with COMPLEXITY - more flexibility, more complexity. When we want to build a fit-for-all Prophet model (i.e., FLEXIBLE for many business units), we can't avoid of making the Prophet model more COMPLEX. This also increases the hurdles in using the Prophet model - i.e., the users need to have more technical knowledge in understanding the Prophet model. But in reality, we definitely can't expect all actuarial valuation users to have good technical knowledge in Prophet.

It is IMPORTANT to note that the persons who going to USE Prophet models are valuation users, and NOT Prophet modelers.

That's the reason when we assist our clients in setting up Prophet models, we will usually first understand their level of Prophet knowledge.

(Source of Image: Gemini AI)

Prophet Modelling Technique (4): SPCODE

2025-05-16T21:52:00.002+08:00

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.

Understanding the Role of SPCODE

When Prophet performs calculations, it can produce results either on a total basis—which is labeled as SPCODE = 0—or on a grouping basis, where model points are grouped by SPCODE. Grouping by SPCODE is by far the most common approach. There is another grouping method, such as grouping by maturity year, but that’s rarely used these days, particularly in jurisdictions where regulators don’t require results to be broken down that way. (You can also use "Flexible Results" functionality for result grouping, but it is subject to additional subscription fee)

Here’s a quick illustration of how SPCODE works in practice:

Suppose you have three SPCODEs in your model point file: 1, 11, and 21.
Each SPCODE contains 1,000 model points.

When Prophet runs, it will generate four sets of results—one for each SPCODE, and one combined result where SPCODE = 0. For any variable defined as a cumulative variable, Prophet will automatically sum the values across all model points with the same SPCODE. So, when you extract results for SPCODE = 1, you’ll get the total results for those 1,000 model points.

Also, I summarize some SPCODE basics you should know:

SPCODE is a mandatory field in all model point files and must be placed in the first column.
You do not need to create a variable to read SPCODE—it is automatically read by Prophet.
Any positive integer up to 9999 can be used. For model point files used for in force run (i.e., not new business processing), the SPCODE less than or equal to the “Last Sub-product Code for Existing Business” specified in the Run Structure.

My Recommendation on How to Use SPCODE

In all Prophet models I’ve developed, I emphasize one principle to the users: "SPCODE should be used purely as a grouping criterion, and NOT as a specific driver for reporting."

This is especially important when working with frameworks like IFRS17. I do not recommend using SPCODE to manage groupings such as ICG (Insurance Contract Groups). Once we assign calculation-based meanings to SPCODEs, we limit its flexibility and reduce our ability to use it for other important analysis.

Here’s why this matters:

Let’s say you later want to analyze profitability by distribution channel.
If SPCODEs have already been hardcoded to represent something else, you lose the ability to use them to group policies by channel.
Similarly, if you need to run model testing and want to trace the impact of changes by assigning different SPCODEs to test groups, you’ll face unnecessary constraints.

Don’t Lose Flexibility

It’s important to remember that our Prophet models aren’t built for just one purpose, such as IFRS17 valuation. These models support a range of actuarial analyses—from profitability studies and sensitivity tests to stress scenario reporting.

That’s why it’s essential to preserve the flexibility of SPCODE as a grouping mechanism—one that can be easily re-assigned based on the analysis you’re running, without being tied to a specific set of rules or business logic.

Related Posts:

Prophet Modelling Technique (1): Enumerations
Prophet Modelling Technique (2): New Business Processing
Prophet Modelling Technique (3): Calculation Looping
Prophet Modelling Technique (4): SPCODE

Prophet Modelling Technique (3): Calculation Looping

2025-05-15T16:21:00.002+08:00

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.

What Is “Looping” in Prophet?

Broadly speaking, looping is one of several calculation techniques available in Prophet. Some of the most commonly used techniques include:

Calculation Looping
Rebasing
Dynamic Run

Among these, calculation looping is generally the simplest form. In plain terms, if a model uses calculation looping, Prophet repeats its calculations multiple times within the same run.

Here's how it works:

The number of loops is defined by the variable NUM_CLCLOOPS. Prophet will repeat calculations that many times.

During each loop, the variable CALC_LOOP (i.e., the counter) automatically updates—starting from 1 and increasing with each iteration.
If you want to preserve the result of a variable from a specific loop and avoid it being overwritten in the next loop, you can use the NO_CALC function.

Why Use Calculation Looping?

The biggest advantage of calculation looping is that it allows you to reuse the same set of variables for different purposes—like applying different assumption sets—all within a single run.

Let’s say you’re calculating reserves using the Gross Premium Valuation ("GPV") method. With calculation looping, you can reuse the same variables—for premiums, expenses, claims, surrenders, and so on—to calculate:

Best Estimate Reserves
Statutory Reserves
Capital Reserves for RBC

This means you don’t need to duplicate variables for each scenario, and you don’t have to convert everything into array variables just to handle different reserve bases.

Reducing Errors and File Size

This approach also helps improve consistency. Under GPV, your valuation and projection scenarios should use the same variable logic. By running all scenarios in one place, you minimize the chance of discrepancies between them.

There’s a bonus, too: Prophet models that use calculation looping often produce smaller result files, because only the results from the last loop are stored—unless you specifically set up variables with CALC_LOOP and NO_CALC to retain intermediate results.

A Tip for Prophet Users in Malaysia

If you’re a Prophet user working with RBC2 requirements, calculation looping can be especially powerful. Instead of setting up multiple separate runs for each RBC2 stress scenario, you can perform them all in a single run, using different loops to handle the different stress cases.

And let’s be honest—there are a lot of runs to deal with under RBC2. So anything that helps streamline the process is worth considering.

Related Posts:

Prophet Modelling Technique (1): Enumerations
Prophet Modelling Technique (2): New Business Processing
Prophet Modelling Technique (3): Calculation Looping
Prophet Modelling Technique (4): SPCODE

Prophet Modelling Technique (2): New Business Processing

2025-05-09T21:57:00.003+08:00

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!)

In this blog post, I’ll walk through how NB processing works in Prophet, highlight the differences between the two most common methods — cross multiplication and project method — and explain why I often recommend the project method for Prophet users from family takaful operators.

What is NB Processing?

NB processing in Prophet is a technique used to project results for future sales, based on sales volume specified in the Sales File. Prophet offers three methods for new business projection, but in practice, cross multiplication and project method are most commonly used.

To understand how these methods work, it’s important to first break down the two key components involved in NB projection, i.e. NB profile and Sales File.

A. Overall Concept

NB Profile / NB Premium × Sales File = Projected Cash Flows

In essence, Prophet projects new business cash flows by multiplying the NB profile with the monthly sales volumes from the Sales File. To be more specific, the "NB Profile" in the above formula refers to per dollar NB profile.

Let me use an illustration to better explain the above formula:

From the NB profile, the expected premium incomes for policy month 1 and 2 are $100,000 and 95,000 respectively.
The NB profile is generated using a model point file, with annualized premium $1,200,000. The annualized premium is captured under a mandatory variable PREM_AMOUNT. We need to ensure this variable is spelled correctly, as it is Prophet a specified variable.
If expected sales for Jan '25 is $600,000, the expected premium income for Feb '25 is 100,000 / 1,200,000 × 600,000 = $50,000.
Using similar approach, the expected premium income for Feb '25 is $47,500.

Similarly, if expected sales for Feb '25 is $900,000, the expected premium incomes for Feb '25 (policy month 1) and Mar '25 (policy month 2) are $75,000 and $71,250.

To get the expected premium income for Feb '25 on totality basis, we need to add up the results from both Jan '25 block and Feb '25 block of new business, i.e., 47,500 + 75,000 = $122,500.

B. NB Profile

The NB profile is generated from NB model points. Prophet distinguishes these model points by looking at the SPCODE, where values exceeding the "Last Sub-product Code for Existing Business" (as defined in the Structures) are treated as NB model points. In addition, it is important to ensure DUR_M for NB model point is set to 0.

For example, if the "Last Sub-product Code for Existing Business" is set to 50, all model point files with SPCODE = 51, 52, ..., 9999 are treated as NB model points.

You may have another question in mind: "Will my results be better if I use more NB points in the calculations?" In fact, NB model points represent the distribution of the target new business stated in the Sales File.

The most common approach is to use the actual new business acquired by the company. This approach assumes the distribution is the same as the actual new business.
You can also construct the expected distribution using fewer model points.
In simple words, 1 model point and 100,000 homogenous model points produce the same NB profile.

C. Sales File

The Sales File contains monthly sales volumes, organized by Prophet product and SPCODE. For example, if your new business model point file includes SPCODEs 51 and 52, then your sales file should contain columns labeled “PRODUCT#51” and “PRODUCT#52,” representing the expected monthly sales for each SPCODE.

Cross Multiplication vs. Project Method

The key difference between the cross multiplication method and the project method lies in how the NB profile is produced and used over time.

Cross multiplication method - Prophet generates the NB profile once, based on a single starting date. This same NB profile is then multiplied by the sales volumes for each month in the projection period.
Project method - Prophet regenerates the NB profile for every single month. Each month’s projection begins with a new starting date, and a new NB profile is created to match that start date before being multiplied by that month’s sales volume.

In simple terms, you can think of the project method as a series of cross multiplications—each tied to a different starting month.

Why Does This Matter?

You might wonder whether it’s really necessary to regenerate the NB profile each month. The answer depends on whether your model includes calendar date-specific cash flows.

If your projection assumptions are NOT dependent on the calendar—say, if policy events like benefits occur exactly one year from issue regardless of start month—then the cross multiplication method may be sufficient.
However, in Family Takaful, the timing of certain events—particularly profit and surplus sharing—is often tied to the financial year-end. For example, surplus distribution may be performed annually as of 31 December, regardless of when a policy was issued during the year. Unless this has been simplified to a monthly declaration (which is less common), the model needs to reflect this calendar-based timing accurately.

If a user applies the cross multiplication method in this context, Prophet will apply the same NB profile to all sales months. As a result, every new business policy—regardless of its actual issue date—will appear to participate in surplus sharing on the same schedule. This leads to inaccurate results, where surplus sharing seems to happen monthly, simply because the NB profile does not reflect different policy start dates.

To model this behavior correctly, the project method should be used, as it regenerates the NB profile for each month’s batch of new business. This ensures that each policy reflects the correct projection period and aligns with the actual financial calendar.

But What About Performance?

It’s true that the project method is significantly SLOWER than the cross multiplication method. Because Prophet regenerates the NB profile for each month in the sales file, a 3-year projection (i.e., 36 monthly sales points) means Prophet must generate and project 36 separate sets of NB profiles.

As a rule of thumb, you can expect the project method to take roughly 36 times longer than the cross multiplication method for a 3-year horizon. Naturally, this extended run time becomes a key consideration for modelers.

To manage performance while maintaining accuracy, I recommend using grouped model points when applying the project method. By grouping similar model points before generating the NB profile, you can significantly reduce the volume of data while still capturing the essential patterns of new business.

Wrap Up

Choosing between the cross multiplication method and the project method isn’t just a matter of run time—it’s about choosing the right method to reflect your business reality.

For Family Takaful products, where profit and surplus sharing often follow a fixed calendar cycle, the project method is the more accurate approach. While it does come with a performance trade-off, this can be managed with proper grouping techniques.

Ultimately, using the right NB processing method ensures your projections are not only technically correct but also aligned with the true business mechanics of your products.

Related Posts:

Prophet Modelling Technique (1): Enumerations
Prophet Modelling Technique (2): New Business Processing
Prophet Modelling Technique (3): Calculation Looping
Prophet Modelling Technique (4): SPCODE

Prophet Modelling Technique (1): Enumerations

2025-05-05T12:15:00.007+08:00

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!)

If you’re not familiar with enumerations, let me briefly explain. In simple terms, an enumeration works like a two-dimensional array. The first dimension is a sequence of integers starting from 0, and the second is the corresponding text value. You can easily move between the two within the same pairing—get the text from an integer, or the integer from a text value.

Let’s say we set up an enumeration for IFRS17 discount rates and call it IFRS_DISC:

The first pairing is 1 (integer) and “LIR” (text), for locked-in rates.
The second pairing is 2 (integer) and “VIR” (text), for current rates.
We can refer to them using object-like notation: IFRS_DISC.LIR and IFRS_DISC.VIR—similar to how it works in object-oriented programming (“OPP”) in VBA.

Prophet provides functions to handle these conversions. For example, you can use ENUM_TO_INT and ENUM_TO_TEXT to get 1 and "LIR" from IFRS_DISC.LIR. You can also convert an integer or a text value to an enumeration using INT_TO_ENUM and TEXT_TO_ENUM.

So when should we use enumerations in our Prophet coding? In my view, enumerations make variable definitions much more readable. Instead of using raw values like 0, 1, or 2, you can make your conditions clearer. For example:

Without enumeration: IF CALC_LOOP = 1 THEN
With enumeration: IF CALC_LOOP = ENUM_TO_INT(DISC_TYP.LIR) THEN

Using enumeration makes the logic more transparent—you don’t have to remember what the numbers stand for. Plus, since enumerations must be defined under Workspace Objects, it also helps reduce manual errors.

With enumeration now supported as a variable type, we can streamline our logic even further. Going back to the earlier example:

You could create a new variable that automatically converts CALC_LOOP into an enumeration, say CALC_DISC.
Then, your condition becomes as simple as: IF CALC_DISC = DISC_TYP.LIR THEN, with no need for conversion functions.

There’s another useful application—enumeration variables can help with table suffixes that need to vary by t or CALC_LOOP. As many of you know, text variables in Prophet can't directly depend on t or CALC_LOOP. But with the new CALC_DISC variable, you can derive a suffix like this: "ifrs_disc_" + ENUM_TO_TEXT(CALC_DISC) + "_pc".

Wrap Up

The addition of enumeration as a variable type in Prophet is a small but meaningful improvement. The use of enumerations makes our code cleaner, easier to understand, and less prone to errors. If you haven’t used it yet, give it a try—you might find it a simple way to bring more structure and clarity into your Prophet coding.

Related Posts:

Prophet Modelling Technique (1): Enumerations
Prophet Modelling Technique (2): New Business Processing
Prophet Modelling Technique (3): Calculation Looping
Prophet Modelling Technique (4): SPCODE

Rising Medical Insurance Premiums (4) – Additional Metrics in Claim Analysis

2025-01-03T12:29:00.002+08:00

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.

Loss Ratio Alone Isn’t Enough

When it comes to claim analysis for medical insurance, many of us tend to focus solely on loss ratio. While useful, loss ratio analysis primarily evaluates product profitability – offering a high-level view of whether a product is making or losing money. Of course, we can refine this by analyzing profitability across different plans or age groups.

But here’s the catch – loss ratio alone isn’t enough for medical insurance products that reimburse hospitalization and surgical expenses. Why? Because loss ratio reflects the end result. It doesn’t shed light on the underlying claim experience or the drivers behind those results.

So, how should we approach claim analysis for medical insurance? I recommend incorporating at least four key metrics – and examining them across different dimensions (e.g., plans, age groups, gender):

Loss ratio
Incidence rate
Average claim paid
Average length of stay (for hospitalization)

If you studied actuarial science before, you might recall the formula for expected aggregate loss:

E(S) = E(N) × E(X)

In simple terms, the above formula explains the total claims depends on frequency of claims (how often claims occur) and the severity (how large each claim is). Incidence rate and average claim paid correspond directly to these two components – frequency and severity.

Understanding the Drivers of Claims

When aggregate claims rise – leading to an increased loss ratio (assuming premium rates remain unchanged) – analyzing these additional metrics helps identify the root cause. Is the rise driven by higher incidence rates, larger average claim amounts, or both?

By breaking down the drivers behind rising claims, we gain deeper insight into the underlying claim experience. And with that understanding, we can make more informed decisions – beyond simply reacting to loss ratios.

As many of us know, increasing premiums alone won’t solve the problem.

Further reading:

Rising Medical Insurance Premiums (1) – Is Emotion Clouding the Discussion?
Rising Medical Insurance Premiums (2) – Why Small Claims and Big Tails Matter?
Rising Medical Insurance Premiums (3) – Is Medical Inflation in General a Fair Benchmark?
Rising Medical Insurance Premiums (4) – Additional Metrics in Claim Analysis

Note: The image is generated using Grok AI.

Rising Medical Insurance Premiums (3) – Is Medical Inflation in General a Fair Benchmark?

2024-12-30T18:07:00.003+08:00

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.

If you work in life insurance or family takaful, you may be familiar with terms like "M8388" or "M1115". These abbreviations represent mortality tables derived from claim experiences of insured lives in Malaysia’s life insurance industry. The numbers in these abbreviations aren’t secret codes – they simply refer to the years in which the mortality studies were conducted. For example, "M8388" reflects mortality experience observed between 1983 and 1988 (a 5-year period).

Why Conduct Studies on Insured Lives?

Why does the life insurance industry conduct these studies? Couldn’t we just rely on mortality data from the general population? The answer, by common sense and theory, is "NO". Insured lives typically experience better mortality rates because life insurance companies conduct underwriting assessments before approving coverage. If someone applying for insurance has a poor medical history or engages in a high-risk occupation, their application may be declined.

This makes sense, right? Now let’s circle back to medical insurance. Just like life insurance, underwriting assessments are conducted before someone is accepted for medical coverage. Logically, we might expect similar results – that insured individuals should experience lower healthcare costs.

The Reality: A Mixed Answer

The answer to whether this applies to medical insurance is "YES"... and "NO".

While underwriting helps filter out applicants with pre-existing conditions or high-risk occupations, there’s an element unique to medical insurance that’s harder to control – HUMAN behavior and decision-making.

For products like term insurance, which covers death or total permanent disability ("TPD"), the insured events are generally random and independent. In most cases, people don’t actively seek to experience death or TPD to claim insurance.

However, the opposite may apply to medical insurance. Individuals with coverage might incur higher medical costs simply because they are insured.

The Insured Lives, Hospitals, and Insurers Dynamic

There’s an imbalance between insured individuals, hospitals, and insurers. When insurers lack the authority to adequately control claimable costs, the following scenarios often occur:

Unnecessary medical exams, treatments, or hospitalizations – sometimes driven by a desire to qualify for claims.
Dual pricing – different rates are applied to medical services covered by insurance versus those paid out-of-pocket.

These factors can drive medical insurance inflation at a higher rate than the medical inflation in general. Additionally, I wonder if the 15% medical inflation rate cited by Bank Negara includes areas like general practitioners ("GP") and dental services – areas typically not covered by individual medical insurance policies.

I’m genuinely curious to learn more about how this 15% medical inflation rate was derived.

Further reading:

Rising Medical Insurance Premiums (1) – Is Emotion Clouding the Discussion?
Rising Medical Insurance Premiums (2) – Why Small Claims and Big Tails Matter?
Rising Medical Insurance Premiums (3) – Is Medical Inflation in General a Fair Benchmark?
Rising Medical Insurance Premiums (4) – Additional Metrics in Claim Analysis

Note: The image is generated using Grok AI.

Rising Medical Insurance Premiums (2) – Why Small Claims and Big Tails Matter?

2024-12-26T23:00:00.004+08:00

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.

A Right-Skewed Reality

So, what did the histogram reveal?

It consistently showed a right-skewed distribution. In simpler terms, most claims were for relatively small amounts, often tied to minor ailments. Picture this – the bulk of claims fell into categories like “below 1,000” or “1,000 to 2,000.” (Of course, these thresholds have likely shifted over the past 20 years.)

At first glance, having lower average claims might seem like good news. But don’t celebrate too quickly. This pattern can sometimes indicate potential abuse of medical insurance – which is precisely why sufficiently high deductibles are essential. For instance, patients might opt for hospitalization solely to qualify for claims. When this type of abuse becomes prevalent (reflected in higher skewness), the cumulative claim amount that needs to be spread across all policyholders increases significantly.

The Tail That Stings

Another challenge in medical insurance lies in the "TAIL" of the claim distribution – those large, infrequent claims that can disrupt the entire portfolio. Unlike other insurance products, where catastrophic claims are rare (perhaps once or never in our entire career), large medical claims are far more common.

I vividly remember encountering a claim that instantly maxed out the annual limit of the highest plan at the time. Back then, the limit stood at 80,000, but this particular claim exceeded 100,000.

Was it a one-off case? Unfortunately not. I encountered such claims more than once.

In theory, annual limits should help control these tail-end risks. However, the current trend in Malaysia’s medical insurance market tells a different story. Today, annual limits of 1,000,000 are fairly standard – a direct result of market competition. While this high limit doesn’t affect most claims (since the average claim amount is far below 1,000,000), it significantly increases exposure to large claims.

Consider this example:

The average premium per policy is RM1,000.
A single large claim of RM500,000 could deplete premiums from 500 policyholders.

At this point, you might wonder – shouldn’t larger portfolios benefit from economies of scale?

Logically, yes. But based on past observations, I’m not convinced this holds true for medical insurance. In fact, I found out that the number of policies in the portfolio grew, I noticed an odd trend – the loss ratio increased.

Strange, isn’t it? Unfortunately, I didn’t get the chance to fully investigate the root cause at the time.

Further reading:

Rising Medical Insurance Premiums (1) – Is Emotion Clouding the Discussion?
Rising Medical Insurance Premiums (2) – Why Small Claims and Big Tails Matter?
Rising Medical Insurance Premiums (3) – Is Medical Inflation in General a Fair Benchmark?
Rising Medical Insurance Premiums (4) – Additional Metrics in Claim Analysis

Note: The first image is generated using Grok AI.

Rising Medical Insurance Premiums (1) – Is Emotion Clouding the Discussion?

2024-12-26T22:45:00.004+08:00

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:

1. Informed Decisions

For those of us working in corporate environments, the term "informed decisions" is second nature. When making strategic decisions, we gather sufficient information to ensure we’re on solid ground. The same logic applies here – I wonder if the MPs involved consulted with insurance or actuarial associations to fully understand the situation? Decisions made without the full picture may lead to unintended consequences.

2. Emotional Bias

Bringing emotion into discussions introduces bias, which rarely leads to productive outcomes. When discussions shift into arguments driven by emotion, the goal becomes winning rather than seeking truth or solutions. Arguments centered around slogans like "Rakyat Win" can narrow the focus, making it difficult to explore alternative solutions that could benefit all parties involved.

3. Blind Spots

Some issues are inherently technical – and medical insurance is no exception. Unlike simpler products such as term or endowment life insurance, medical insurance involves complex arrangements requiring specialized knowledge. Without addressing the root causes of rising premiums, proposed solutions risk exacerbating the problem rather than solving it.

Frankly, I’m a little concerned about potential measures. If insurers or Takaful operators are eventually forced to withdraw from medical insurance portfolios due to unsustainable losses, the public may face fewer options. It’s basic business sense to withdraw unprofitable products – and it seems unreasonable to expect companies to continuously subsidize loss-making products with profits from other lines of business.

Further reading:

Rising Medical Insurance Premiums (1) – Is Emotion Clouding the Discussion?
Rising Medical Insurance Premiums (2) – Why Small Claims and Big Tails Matter?
Rising Medical Insurance Premiums (3) – Is Medical Inflation in General a Fair Benchmark?
Rising Medical Insurance Premiums (4) – Additional Metrics in Claim Analysis

Note: The above image is generated using Grok AI.

What Makes a "Good" Prophet Model? (2) - Reduce Redundancy

2024-10-28T09:15:00.006+08:00

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.

How to Measure Level of Redundancy?

To measure redundancy, theoretically we can look at the ratio of variables used by products to the total number of variables in the library. A lower percentage suggests higher redundancy. Fortunately, getting no. of variables used of variables used by products in the workspace isn’t just guesswork; we can use Prophet’s diagnostic files to find the exact numbers. Of course, if we can consider indicators and variable definitions that aren’t used by any products, the metric can provide a fuller picture.

Although we can get the no. of variables used by all products from the diagnostic files, some variables may be set to zero or used as bypassing results from other variables, obscuring whether they’re truly in use. This makes it harder to understand the "REAL" level of redundancy in the Prophet model.

From my experience building Prophet models from scratch—particularly before the implementation of IFRS 17—most models needed only around 1,200 to 1,500 variables to cover the full range of ordinary and investment-linked products (same goes to family takaful products, which are more complex that conventional life insurance). This benchmark gives us a rough idea of how many variables are genuinely necessary, and it highlights just how much room for optimization there may be in models that exceed this range.

For example, I’ve seen many Prophet models with variable counts as high as 4,000 to 5,000 or more, but to keep things simple, let’s use a 4,500-variable model for illustration. If we find that only 1,500 of those variables are active in calculations, then just 33.33% are being used, while 66.67% of variables serve no functional purpose in the model. While this is an estimate, it shows how widespread redundancy can be in many models.

Does It Really Matters? Yes, It Does.

At this point, you might be wondering, “What’s the problem with redundancy? I'm not using those variables anyway.” A fair question! If it’s harmless, why should we care?

Unfortunately, redundancy DOES bring issues to our Prophet models. Here’s something to consider: By referring to the above example, that means you’re only utilizing about 33% of what’s in the model. This raises a few important questions:

Do you understand what the other 3,000 variables are for?
If you make a modification to the library, how confident are you that it won’t impact any of those 3,000 unused variables?
Are you certain those 3,000 variables don’t have hidden dependencies on the 1,500 active ones?

One of the challenges with redundancy is that unused variables today won’t necessarily stay unused forever. When we set up a new product, we may need to include an indicator or a variable that hasn’t been used previously, pulling new variables and variable definitions into the active calculation mix. This often happens when a new product design calls for something unique or tailored that wasn’t part of our prior product setups.

Here’s where the real risk kicks in: those newly introduced variables might interact with existing ones that are already in use by other products. This can lead to unforeseen interactions or even conflicts in the calculations, especially if those pre-existing variables have underlying definitions that shift as new elements come into play.

This is why we can’t simply ignore variables that are currently inactive in our model. As our product lineup evolves, those seemingly dormant variables could enter the calculation stream.

Does Your Prophet Model Have Excessive Patching?

For Prophet models with high level of redundancy, excessive patching has become a common practice. This often leading to layers of replicated variable definitions and added indicators used solely to bypass existing settings. For example, an expression might end with an “AND BYPASS_INDICATOR” to sidestep a variable definition rather than addressing the core setup. How about the existing variable definitions without the bypassing Indicators? Well, I think most Prophet modeler will tend to leave those variable definitions in the library - no choice, we DO NOT KNOW what will happen if we delete the existing variable definitions.

These temporary fixes may seem harmless, but they may create serious risks in the future. When Indicators that weren’t previously used suddenly come into play for a new product or new calculation requirements, they can trigger unexpected outcomes and calculation issues.

When we use the bypassing Indicator in our Prophet models, we don't really solve the problems as a whole. We are only addressing only the symptoms of a problem, just like what is explained in a common Chinese idiom: "treating a headache by curing the head, treating foot pain by curing the foot". When we incorporate such bypassing Indicator in the Prophet models, we are unable to add the Indictor into all required variables as there are too many variables to go through for a library with high level of redundancy.

To make mater worse, for Prophet models that cannot fully pass the technical validation using Prophet’s “Validate” function, it is hard to detect these issues in advance as patches may mask underlying errors that only surface later.

Conclusion

Redundancy in Prophet models may seem benign at first glance, but as we've explored, it brings risks and complexities that can hinder both model accuracy and maintainability. With too many unused variables, patching shortcuts, and bypass indicators, a model quickly becomes unwieldy and prone to errors—especially when new products enter the mix or new calculation requirements arise. By reducing redundancy, we’re not just keeping our Prophet models lean; we’re ensuring they remain effective, adaptable, and much easier to validate.

That's one of the reasons I recommend creating Prophet models from scratch, as well as avoiding centralization of Prophet models across different business units.

Related Posts:

What Makes a “Good” Prophet Model? (1) - Avoid Black Box
What Makes a "Good" Prophet Model? (2) - Reduce Redundancy

Podcast Version:

What Makes a “Good” Prophet Model? (1) - Avoid Black Box

2024-10-19T14:05:00.004+08:00

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?

I'll be honest, in my first 10 years of working with Prophet, I was just like many of you—more of a "user" than a modeler. I’d input the data, run the numbers, and trust the results without really digging into the mechanics of how the model worked. Sound familiar?

At that time, the Prophet model I was using had thousands of variables—so many that it was impossible to study every single one in detail. Plus, there were tons of customized workarounds and coding tweaks added over time. And then it happened—I came face-to-face with the risk of using a "black box" model when I discovered a simple error buried within those thousands of variables.

The issue? A simple division mistake: the denominator should have been the number of policies, but instead, it was set to 1. The result? A multi-million-dollar error that could have easily been avoided. That’s when I realized how crucial it is to really understand the models we rely on, and not just take them at face value.

In this first post of my "What Made a 'Good' Prophet Model?" series, I’ll dive into how you can identify a BLACK BOX Prophet models, as well as the risks associated to such Prophet models.

Most Importantly, Avoid Black Box

So, how can you tell if your Prophet model has turned into a black box? One way to find out is by asking yourself a couple of key questions:

Do you really know how your Prophet model is set up?
Do you have any documentation that explains how it’s designed?

Setting up a Prophet model isn't just about plugging variables into the libraries. In actuarial models, variables are deeply interconnected. For instance, premium income depends on the number of in-force policies, which in turn depends on mortality rates. Mortality rates are influenced by attained age and gender, while attained age is based on entry age and policy duration. It’s like a chain reaction—everything is linked.

If you don’t understand the core modeling philosophy and infrastructure (I refer as the model "backbone") behind your Prophet model, maintaining it effectively becomes almost impossible. Without this understanding, even small changes can become risky.

To make matters worse, if there’s no documentation laying out the design and philosophy behind the model, you’re left making wild guesses whenever you need to modify something. It’s like crossing your fingers and hoping for the best. You make changes, and then... well, you pray that everything will work out fine. But that’s a dangerous game when millions of dollars are potentially at stake.

So, What May Happen?

When your Prophet model becomes a black box, it introduces several significant risks that can impact the accuracy, reliability, and maintainability of your actuarial work. Let’s break down some of the biggest risks:

Risk 1: Difficulty Understanding How Calculations Are Made

One of the most obvious risks is that you may not fully understand how your calculations are being done. When the model is too complex or poorly documented, it becomes almost challenging to follow the logic behind key outputs. This lack of transparency can leave you relying on results you don’t fully grasp, which is never a good position to be in.

In this situation, we must conduct more rigorous model testing to uncover issues that may be hidden in the dark, beyond our line of sight. We also need to ensure that the libraries we use can pass basic technical checks (the validation function) with 100% accuracy — I sometimes refer to this as ensuring that at the very least, the "grammar" of all variables in the library is correct.

Risk 2: Hidden Errors Are Hard to Spot

As I mentioned earlier in the introduction, I learned this risk the hard way. When models are too convoluted, even simple errors can go unnoticed. In my case, a basic division mistake resulted in a multi-million-dollar error, buried within thousands of variables. Identifying such mistakes is much harder when you don’t have a clear understanding of the model's structure.

Risk 3: Guesswork Leads to Unintentional Errors

When we don’t have a solid understanding of how a Prophet model is set up, every change becomes a guessing game. You may need to make adjustments, but without clear documentation or insight into the model’s backbone, these changes can unintentionally create new errors. It’s a bit like tinkering with a car engine when you don’t fully understand how the parts fit together—things can go wrong fast.

Risk 4: Models Become More Complex and Eventually Unmanageable

The more changes you make without understanding the model, the more complex it becomes. Especially when you’re forced to add a lot of workaround coding, the model can quickly spiral into something that’s beyond repair. I’ve seen this happen firsthand from my Prophet modelling projects —Prophet models that have become so tangled with customizations and tweaks that fixing or upgrading them was no longer feasible.

Risk 5: Unpredictable Model Behavior

When a model becomes a black box, you lose the ability to predict how it will behave. In one of my Prophet training sessions, a participant asked me, “What will happen if I select Indicator XYZ for a product in my Prophet model?” I had to answer with no choice, “I was not the one who created the library, how am I able to know what will happens?” That’s a major red flag—if you don’t know what changes will do to your model, you’re working in dangerous territory.

It's Important to Understand Our Prophet Models

A good Prophet model should never feel like a black box. As we've explored, the risks of working with a model that you don’t fully understand are far too great. From hidden errors to unintentional mistakes, or even models becoming unmanageable over time, the lack of transparency can cause significant problems. That’s why it’s so important to understand the structure, design, and philosophy behind the models you rely on.

In my next post, I’ll be diving into another key aspect of a GOOD Prophet model—redundancy.

Podcast Version:

Related Posts:

What Makes a “Good” Prophet Model? (1) - Avoid Black Box
What Makes a "Good" Prophet Model? (2) - Reduce Redundancy

Get Inspiration for New Problems

2024-04-21T22:49:00.000+08:00

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.

Now, jumping from cars to my world of actuarial modeling in Prophet. Under the new demands and requirements like IFRS17 implementation, the old ways of doing things just weren't enough anymore. I needed models that could twist, turn, and adapt fast. Where did I look for inspiration? Believe it or not, WordPress, the website platform, especially the way it uses plug-ins to add new features easily.

Inspired by this system, I developed a similar mechanism for Prophet models. This innovation allows users to easily attach or detach selected riders to basic insurance plans through a table-driven approach, significantly increasing the models' flexibility. This approach not only streamlined the modeling process but also introduced a level of customization and efficiency previously unattainable.

Both these stories, mine and Ford's, show that sometimes, the best way to tackle new challenges is to look outside your usual toolbox. You never know where the next great idea will come from, making work not just smarter but also a lot more fun.

Theory & Practical

2024-04-21T22:41:00.000+08:00

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".

From our past experience, we came across many course participants with good skills, but... Well, poor fundamentals/concepts. Some of them may seem to know a lot, or do a lot of so-called advanced work, but when I threw out some simpler but new problems, they were stunned without having a good idea of how to resolve them. They built their skills and understanding on the "surface".

I explained further to Koh Ying why we need to master the "theory" well. For most of our projects, we deal with NEW problems. We need to find out new ways to resolve the problems arising, by using our creativity. However, creativity will only make sense if it is built on the solid ground of fundamentals / concepts. This is how we ensure the solutions we develop are practical.

I hope this short conversation will let Koh Ying the importance of learning the fundamentals / concepts. Perhaps she is too young to understand this well (just the 1st year of her actuarial job!), I believe she definitely can comprehend why I emphasized on "theory".

Some Thoughts on Prophet (Part 2)

2022-05-28T18:31:00.006+08:00

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 an extended formula that contain (say) 3 elements, say I call it as EXT_FORMULA.
Create different extended formula for death, TPD and CI. Just one line code, #EXT_FORMULA(x, y, z) (it's hash-E-X-T-underscore-F-O-R-M-U-L-A). Say the extended formula for death is DTH_INPUT.
To get the value from EXT_FORMULA, we need to specify the variable that carries values of elements, such as DTH_INPUT.QX (QX is a public variable under EXT_FORMULA).

Another reason I love using parameterized extended formula is it allows multiple outputs from the same extended formulas. For example, in case we have two separate public variables for male and female, we can define two public variables within the same parameterized extended formula, i.e. we can directly get the values from the variable by specifying (say) DTH_INPUT.QX_M and DTH_INPUT.QX_F.

You can also have numeric and text public variables at the same time. Both numeric and text public variables may appear as array variables if needed.

Further reading:

Some Thoughts on Prophet (Part 2) (This post)
Some Thoughts on Prophet (Part 1)

Some Thoughts on Prophet (Part 1)

2022-05-28T18:24:00.003+08:00

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 be great if we can allow t-dependent calculation for TEXT variable as well. At the moment, Prophet doesn't allow t-dependent text variables - which create some hassles especially when we want to change the text values for different calculation loopings (CALC_LOOP).

P/S: We can also use PRINT_TO_FILE to output variables that we want to check into run logs.

Thought (2): No t dependent for text value?

To overcome this limitation, of course there is more than one way to handle it. For example, if the text value is a table name, we can vary the table names within READ_GENERIC_TABLE, under the numeric variable that we want to store the value read from the table.

Another approach I use quite a lot is using an extended formula to read the text value (it's OK to make the public variable within the extended formula to vary by calculation looping). Usually I will use ONE extended formula to read many text variables at the same time (so that can reduce no. of variables).

Of course, if you don't have debugger license, it is not easy to check text the value as it cannot be exported to normal text variable.

Further reading:

Some Thoughts on Prophet (Part 2)
Some Thoughts on Prophet (Part 1) (This post)

How do You Setup Indicators in Your Prophet Model?

2020-12-18T12:15:00.001+08:00

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.

How do Indicators Work?

We can define multiple formulas, or variable definitions, for a variable. There are many ways we can setup a variable definition, which the common ones are:

Formula
Constant
Global
Parameter
Extended formula
t-dependent extended formula

Variable definitions setup in a variable are not necessary come from the same type, e.g. the most common mixture of variable definitions are formula and constant. Let's take fund management charge ("FMC") variable as an example, which is applicable to investment-linked products.

Say FMC variable is as a mandatory variable required for all products.
For an investment-linked product, we need to define formulas that calculates FMC from unit funds. Normally, the respective variable definition is setup as Formula type.
For an ordinary participating product, we can right away set the variable to 0. In this case, we can use Constant type of variable definition.

In case the FMC variable is not a mandatory variable, we can totally exclude this variable from the ordinary participating product - FMC is not applicable to this product anyway. The question is: how do we setup the variable definitions, so that Prophet selects the correct action as per our condition?

Yes, that's right, by using a combination of indicators, together with logical operators to define indicator expression. To cater for the calculations required for the FMC variable, we shall have INVST_LINK (investment-linked) created in the library.

For variable definition used by investment-linked products, we should insert INVST_LINK in the indicator expression.
Although another product in our context is an ordinary participating product, FMC variable should be set to 0 for all non investment-linked products. Hence, we should insert NOT INVST_LINK in the indicator expression.

If the FMC variable is not a mandatory variable, what are the indicators we should use? The answer is simple, we don't need to setup the second variable definition at all. If Prophet cannot find any variable that meet the indicators selected by a product, the variable will not be called in.

How do We Setup Indicators?

Again, there is no single correct answer on how we should setup indicators. Based on my explanations above, we can easily see that indicators allow a variable to be defined in a different way. We should then drill down what make a variable having different variable definitions.

Some common types of indicators that you may consider setting up in your library are:

General: Such as ALWAYS. Please remember that ALWAYS is a lone wolf - it doesn't make sense to use ALWAYS with other indicators.
Product type: Such as ordinary participating, ordinary non-participating, investment-linked.
Benefit type: Such as death benefit, TPD benefit and CI benefit.
Reserving method: Such as gross premium valuation method ("GPV") method, sterling reserve method.

"Must not be selected if" under Selection Criteria group

When we create a indicator, we have to consider the possible conflict that may arise from other indicators. For example, when we select INVST_LINK for a product, we should not select ORD_PAR (ordinary participating) for the same product - a product cannot be investment-linked and ordinary participating product at the same time! Hence, it is important to include adequate conditions for indicators, under "Must not be selected if" section. By using INVST_LINK as an example, we should insert "ORD_PAR OR ORD_NONPAR" in "Must not be selected if" section, under Selection Criteria group (assuming the company only has three product types).

By having this condition, when you select INVST_LINK, ORD_PAR and ORD_NONPAR will be automatically disabled. Hence, you will not have any chance to make a mistake in selecting 2 or more of these indicators.

Know More About Input Variables

2020-12-08T20:54:00.000+08:00

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.

Input Variable Concept

When I explain on the idea of input variables to my clients or team members, I usually regard input variables as product-specific variables for simplicity. In the context of my explanations, product-specific variables are those relating to the features of a product, namely premium and benefit (e.g. sum assured, surrender value and maturity benefit), which calculations for respective variables vary by products.

When you create a new variable in a Prophet library and you are unsure how to classify the variable, you can ask yourself the following questions:

Question 1: Is this variable related to product features?
Question 2: Can another product under the same product classifications (e.g. participating, non-participating, universal life and investment-linked) use a different way in doing calculation specified by the variable?

If the answers for these two questions are "YES", you may consider assign the variable as an input variable. Otherwise, you may ask yourself further additional questions below:

Question 3: Is the variable used to define specific variations in product related rates (e.g. commission rates and cost of insurance ("COI") rates) or assumptions?

Another common use of input variables is to define variations in the product related rates or assumptions - especially when we want to handle rates or assumptions that are unique to a small specific group of products. For example, we may introduce COMM_GRP ("commission group") variable with default value 0:

Most product should use the default value of the input variable, as normally all policies under the same product should use the same commission rates.
For specific products which pay different levels of commissions by distribution channel, you can use COMM_GRP to define different sets of commission rates under the same commission rule / flag.

Types of Input Variables

Most of variables in a Prophet model are core variables. Primary input variables should be more than secondary input variables.

Generally, there are two types of input variables that you can setup in Prophet, i.e. primary input variables and secondary input variables. What are the differences between these two types of input variables?

A secondary input variable has the following characteristics:

Do not have any indicator expression.
Cater for specific calculations that are only applicable to specific products.

Secondary input variables will only be "called" into a product when it is specified in the formula of another input variable. For example, we have one or two legacy products that use annual commutation functions in calculating surrender values. Instead of creating a specific indicator for the use of commutation functions, we can make the variables of annual commutation functions as secondary input variables - when you use the variables in a primary input variable, respective secondary variables will be included in the list of input variables after you save the primary input variable.

Conclusion

For a Prophet model that is properly setup, we should not have too many input variables, say only 10 to 20 variables, to define in a Prophet product. If a Prophet workspace needs you to define more than 100 input variables whenever you create a new product, it is high time to overhaul this actuarial model.

Similar to master products, it is unnecessary to over emphasize on no. of input variables until causing maintenance issues.

Master Products in Prophet Workspace - Many or Few?

2020-11-25T18:52:00.001+08:00

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:

It is easier for me to setup a new product in my Prophet model. I don't want to define 50 - 100 input variables when I setup a new product, especially those input variables that I could not really understand what they are for.
When I need to amend coding of an input variable or a core product in the library, the coding is not lengthy and it is easier for me to go through, especially in the diagram view.
It is always a good thing if I can use a Same As product for my new product. But... I don't want to such convenience comes with updating 20 - 30 tables. I may need to study the coding again in order to update those tables.

It goes back to the efforts required in the model maintenance. One of the rules I have learnt from my actuarial models and solutions development projects, flexibility always comes with complexity - i.e. when we want to introduce more flexibility in a model or solution, we need to always take note that we may be going to introduce more complexity at the same time. Furthermore, it will also invite a lot of redundancy if we want to have a generic model / solution.

Let me give some examples for better clarifications. Try to imagine if we need to setup only ONE master product for all investment-linked products. To do so, we need to include all unit deducting riders with various product features in the master products, so that it be used for all investment-linked policies, either with and without riders.

If you are familiar with Prophet models, every rider needs to have a set of designated variables in defining the product features, including cost of insurance ("COI"), benefit amount, incidence rates, reinsurance premiums etc. - it may require a few hundreds of variables for (say) 5 riders. Yes, the master product is now flexible, but do you think it is a suitable master product for a single premium investment-linked product that is without rider (which is mainly for investment purpose)?

Maintenance in Master Products?

I think it is clear enough that the above-mentioned master product is not suitable for single premium product without riders. A better approach that I would recommend is to create a separate master product for this single premium product - so that we can reduce redundancy in the product and shorten the run time.

Some users may object this idea: "This will increase our maintenance work!" Well, it may sound correct when you first hear such comment. However, the truth is most of the time the master products are not even opened by the users after they are setup and tested. In other words, most master products normally do not require maintenance after they are finalized and promoted to production.

In conclusion, we should not be over concerns on the no. of master products - instead, we should create a separate master product if there are significant different product features (I should discuss the concept of input variables in a separate post).

If you have two master products which you have only minor differences in one or two input variables (such as different ways of calculating current sum assured), it is correct that you should have only one master product for these two variables.

Focus on Skills, and NOT Knowledge Itself

2018-05-31T17:36:00.001+08:00

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 be:

1. Familiar with the programming languages (definitely!)
2. Able to analyze a problem and find out the root causes quickly
3. Able to design an effective solution to resolve the problem

For (1), an expert programmer and an average programmer may know the same amount of commands & functions - what make an former as an EXPERT is how he can apply the programming languages in the problem solving - i.e. how he can analyze & understand the problem and design & implement an effective solutions by connecting the programming language he learned before.

What makes an expert? It's MENTAL REPRESENTATION!

The ability of connecting the skills to the problems, as defined by the authors, depends on how extensive relevant "mental representations" are built up in his mind (technically, in the long term memory). Well, this "mental representations" term may look too abstract to many of us. From I understand from book, let me explain this concept in another context, which may be easier for you to relate to. Try to imagine the "mental representations" as a model / program (e.g. Prophet model) that you use to perform calculations (e.g. reserve calculations):

By using the model / program, you can easily feed in the input data and get the results you want after the calculations are complete. Without the model / program, you would need to carry out the calculations manually on the spreadsheets, which will take a lot of time (and prone to human errors!) .
Obviously, using the model / program in calculations is a more effective solutions. Do you realize that when you run the model / program, you don't really need to figure out how the calculations are done?
For manual calculations, you need to be conscious on how you need to construct the correct formulas in order to calculate required results correctly. Such manual work definitely consume more efforts and time (please also spare some time for detecting errors and corrections…).

Another example is calculating simple arithmetic, such as "5 + 4", which we can instantly get "9" as the correct answer without counting manually. This is because we have already built a model / program in our mind so that we can perform such simple calculations instantly without needing to manually count one-by-one. Similarly, a chess master (the authors' favorite example in the book) has built out many thousands of chess models in his mind so that he can easily retrieve the most relevant chess model in order to apply the correct strategy. The more mental presentations built up in our mind, the more efficient we can understand a particular problem and come out with the correct solutions - our brain will search for the correct model / program to be used, feed in necessary inputs for the problems and return the results we would like to have.

Apart from being able to solve problems effectively, having large amount of mental representations equips us with the ability to self-learn for more in-depth areas, i.e. less dependent on guidance from teacher / coach.

How to build mental representations EFFECTIVELY? It's the DELIBERATE PRACTICE!

Here comes the most important question of this article: "How do we build up mental representations EFFECTIVELY?" When we learn a particular new skill, we are actually establishing mental representations in our mind. Does repeating a learning process help to build up more mental representations? The answer is YES and NO, depending on the learning process we carry out - the authors have pointed out that the "10,000 hours of practice" rule suggested by Malcolm Gladwell is actually incorrect, i.e. repeating the same practice for 10,000 hours will not help to make us an expert. More appropriately, the authors suggest us to adopt a more effective way of learning (which may not be necessary to take 10,000 hours), which is called DELIBERATE PRACTICE.

Highlights of deliberate practice are:

Practice repeatedly, which is the key way to build up & strengthen mental representations. Repetition is a MUST - higher IQ may speed up learning for the beginning stage, but in order to an expert, repetition in practices is unavoidable.
Practice with purposes, i.e. having clear objectives for the practices, such as aiming to tackle a particular weakness.
Incorporate some challenges in the practices, which should be out of our comfort zone. The practices should not be too far from the comfort zone until it becomes too difficult to achieve. Learn to walk first before attempting to run.

Obtain guidance from teacher / coach, especially who can provide feedbacks promptly so that we know our weakness and how to overcome. Please note that a person with strong skills may not be a good teacher / coach.

ISBN: 9781473513143

ISBN: 9787111551287

About the Book

Title: PEAK: How all of us can achieve extraordinary things

Author: Anders Ericsson & Robert Pool

ISBN: (English) 9781473513143 (Chinese) 9787111551287

Publisher: (English) Vintage Publishing (Chinese) China Machine Press

Cover Photo Credit: Igor Ovsyannykov on Unsplash

Waiver of Premium: How Do You Manage It?

2016-01-09T13:59:00.002+08:00

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 investment-linked policy will continue to have allocated premiums to be invested in the unit funds as usual.

Yup, you have raised a very good question: "What do 'different sources' refer to?" Basically, when the WOP feature is triggered, risk fund shall "pay out" WOP claim. Different from other types of claims, the claim is not directly paid to the beneficiary - instead, the claim amount shall be used to: (depending on the company's preferred practice)

Method 1: Set aside as provision (no change in reserves calculation)
Method 2: Support huge increase in reserves (i.e. during reserve calculations, no future premium is assumed for policies with waiver status. When a policy changes from "normal paying" to "waiver", there is a huge increase in reserves due to zerorization of future premiums)

Method 1(a): Set aside as provision (no discounting)
There are variations for Method 1, i.e. "no discounting" & "with discounting" - method selection depends on product designs. Let's take a closer look on how the first one works using the following illustration:

Say a WOP rider (covers payor's death, TPD & critical illness) is attached to Policy A. It only covers for basic plan's premium, i.e. quarterly modal premium = 500. On a particular event date, let's say he policy still requires 22 quarterly premium payments after the event date.

When WOP claim is approved, risk fund provides a claim provision amounted 11,000 (= 22 x 500) (e.g. provision for outstanding claims).
When the quarterly premium is due, 500 is taken from the provision (as settled claim) and serves a premium payment.
If Policy A is terminated before its maturity date (e.g. surrender), the provision that is not utilized is released back to risk fund.

It is possible that there are outstanding premium payments between last premium payment and event date, however there is no specific way to handle such situation. The company may require customers to settle the outstanding premiums before approving WOP claims (however sometimes this option is not feasible, especially if the outstanding amount is large), utilize the accumulated cash values or portion of provisions to settle the outstanding claims (the customers need to continue to pay premiums when the provision is exhausted).

In case some premium payments after the event date are already paid by the customer, an amount equal to total payments should be considered as "excess" that would need to be refunded to the customer.

Method 1(b): Set aside as provision (with discounting)
Basically, both variations of Method 1 work in the same way, with a few exceptions. Under this variation, instead of providing full future premium amount, a discounted amount (i.e. a present value, calculated using a specific discount rate) is set up as claim provision.

The tricky part of using Method 1(b) is the claim provision needs to be adjusted from time to time to reflect investment element - by using the same discounting rate. This investment element may introduce additional risk to the company, i.e. the actual investment yield may be lower than the discount rate - as the provision needs to be adjusted at fixed rates (otherwise it will be insufficient), in the event of shortfall, it needs to be supported by other sources. Additional capital may be required for uncertainty in investment element.

Method 2: Support huge increase in reserves
Method 2 is similar to Method 1(b) - instead of setting up separate claim provision for waiver policies, all future premiums are zerorized when calculating actuarial reserves, which yields a huge increase in reserves. The company may want to quantify portion of increase in reserves attributable to zerorization of future premiums as WOP claim.

When a premium is due, a portion of reserves will be released for premium payment:

For a large portfolio, the release in reserves should be more than amount to be utilized as premium payments, due to prudent assumptions in reserve calculations.
However, mismatch may occur for small portfolio, i.e. the release in reserve is insufficient to support premium payments (as variance is larger for small portfolio).

In practical, this method is more complex to implement, due to various "imperfect"condition. For example, the claim approval date is always later than the event date, which premiums due from event date to approval date should be immediately paid to the policy, instead of taken from release in reserves. To get a correct picture of claim, the company would need to include these immediate payment of WOP claim.

Furthermore, the company may require additional capitals due to larger reserves - Method 2 involves more uncertainty comparing to Method 1(b) because reserve calculation uses assumptions in decrements (e.g. death, TPD, critical illness & surrender).

Last but Not Least: COI / tabarru' for WOP Rider
I always face headache when working on WOP rider, as it involves very large tables - too large until it is impossible for me to examine the rates carefully. Large tables are acceptable for premium rates (as level premiums are charged for WOP rider), however it is unacceptable for COI (Cost of Insurance) for conventional investment-linked products or tabarru' for family takaful products (both ordinary family with participant account & investment-linked). Why?

As discussed earlier, when a WOP claim is approved (under Method 1), a specific claim amount is paid out from risk fund. Consistently, the COI / tabarru' should be calculated on the benefit amount expected to be paid out from risk fund upon claim.

By using the example discussed earlier, the COI / tabarru' should be calculated as:

Benefit amount: 500 x 22 = 11,000.00
COI / tabarru' rate (qx): 0.5 per 1,000 (varying by gender & attained age)
Monthly COI / tabarru' = 11,000 / 1,000 x 0.5 x 12 = 0.46

The COI / tabarru' should have the same structure as other tables which are used to calculate COI / tabarru' for death benefit - which normally varying by gender & attained age only. You can even use the same COI / tabarru' tables as the basic plans.

Replacement for VFP… Is Access a Good Choice for Actuarial?

2014-08-24T08:26:00.002+08:00

I started looking for a replacement Visual FoxPro ("VFP") since 2013, especially I noticed that Microsoft is going to cease its support on VFP 9.0 (released in 2004 and updated in 2007) after 13 January 2015. Although such technical support is not a concern to me (I never requested any support from Microsoft during my more than 10 years of experience using VFP for my actuarial work), I noticed that it would be more and more difficult for me to convince my clients (those who are not existing VFP users) to consider VFP in designing solutions for them.

When I did my research on the website, I came across many names that I was totally not familiar… Is "Lightswitch" mentioned in the official VFP website suitable? After studying its features, I concluded that it is perhaps a good application for an IT programmer, but it is too much for me in handling actuarial work. Basically, what I need in my work is to manipulate and analyze data, ideally using common programming languages like VBA and SQL. How about other applications like Lianja or Xbase++? They are "alien" to many clients (and myself as well!) and I am totally unsure whether they are vendors in Malaysia supplying these applications - furthermore, most clients will not consider these applications that are difficult to be maintained by their own users (as the solutions I designed mainly use End User Computing applications) or getting supports.

Look like I don't have other choice except MS Access. Cheap & easily available.

Frankly speaking, initially I did not have a good perception on MS Access - I used to be a "debugger" for my team member, Mr. S, when I was the Valuation Manager in Company I. When Mr. S encountered errors in using his Access programs (developed by my genius ex-colleague Mr. F), he sometimes had no idea how to resolve those errors as Access did not give him enough "clue" on what was going on and what caused those errors. Differently, when we encountered an error in running VFP programs, VFP would indicate which line of SQL code causing that error and the error message did provide a good hint on how to resolve it. Recently I also found another actuary also has the same perception on Access.

In my recent project with one of my clients, I ended up using Access to design my solutions. Well, I have no other choice because their IT Security officer rejected VFP due to their IT policy - it was not allowed to acquire VFP as Microsoft is going to cease their supports. Well, I had to cracked my head how to make my Access programs more user-friendly, as well as having a similar efficient design structure as the VFP programs (which I have spent many years to establish). After doing some researches and referring to the two Access thick reference books I got from Kinokuniya, I have decided to use only the followings to develop my Access programs:

Visual Basic Application ("VBA")
Forms
Tables

It is a bit challenging writing VBA codes in Access, as it doesn't have a function to record "macros" as available in Excel - that means NO SHORTCUT, i.e. I have to enter ALL VBA codes by my own. Furthermore, the VBA language used in Access is not exactly the same as in Excel. Luckily, Access still allows me to write & execute SQL codes, in order to carry out processes like creating tables, selecting records, updating values, adding / removing columns, etc. After going through several times of "enhancements", I have established an initial design structure for Access, as well as leveraging the visual features (i.e. forms) available in Access that I didn't use in VFP - as shown in the screen captures below (modified from one of my actual solution to a non-actuarial user, to remove company specific info).

Users are required to key in username & password in order to use the functions setup in the Access program.

Users key in the run parameters (Start Date, End Date & Master Folder) and select required program procedures

Now I'm getting more and more comfortable with Access and I think Access is a good choice to replace VFP for actuarial work - as well as non-actuarial users. I shall share in more details in my subsequent articles.

Other Ways to Prepare Prophet Model Point Files? Try FoxPro!

2014-02-10T15:09:00.000+08:00

If you are a frequent Prophet user, you must be definitely familiar with "Model Point Files" ("MPF"), i.e. the policy data that you compile in a specific format that Prophet can recognize as inputs for Prophet runs. If my guess is right, most probably you use Data Conversion System ("DCS") to convert the source data you download from your policy administration system (may be in various format, e.g. fixed ASCII / fixed width, comma delimited, tab delimited, etc.) into the required MPF, based on the definitions you specified in your DCS programs. In case your source data are divided into various files, you may need to carry out more steps to prepare MPF, for example:

Open different source files in Excel
Combine required fields from different source files by using commands (such as) VLOOKUP, SUMIF & MATCH. You may have automated this process by using VBA.
Convert the required files into text files
Use DCS to convert those text files into MPF

However, as Excel is not an ideal data manipulation tool (Unfortunately MS Access doesn't seem to be a good choice too!), you may find out the run time becomes longer & longer once the policy data are getting bigger - furthermore you would need to pray hard that the Excel won't hangup!

Understand MPF Structure
If you open a MPF using Notepad, you can easily find out that a MPF consists of 3 parts, namely header, contents & footer - as shown in the following sample MPF below:

Consist of field names (variable names) and policy data.
Delimited with comma (","), similar to CSV format you are familiar with.
1st field should always start with "MPF identifier" field, which the field name is defined as "!" (or "!1" as shown in the above figure) and the values are defined as "*".

"Contents" is the most important part of your MPF, which consists of the policy data that you would like to input into Prophet run (the "header" is the MPF description and "footer" consists of some codes that only Prophet understand). In case you would like to use other tools to create MPF (such as Excel or FoxPro), basically you only need to create the "contents" part.

How to Create MPF Using FoxPro?
Before you start creating MPF using FoxPro, I would suggest you perform all necessary matching and consolidated all/most required policy data fields in ONE master table (file format: DBF) - so that FoxPro only needs to refer to 1 table when generating MPF, as well as making your checking process easier when you need to find out how a particular value is produced.

To better manage your FoxPro program, you may setup a separate PROCEDURE in the FoxPro program for generating MPF.

STEP 1: Generate MPF Using FoxPro
In the MPF generation procedure of your FoxPro program, I would suggest you split the procedure into 2 parts: (1) define values for all necessary variables first, and followed by (2) writing policy data.

Define values for Prophet variables that you need to include in MPF, especially those fields containing values deriving from multiple fields.

By using TEXTMERGE method, write the required field names to a text file. Please remember to include a comma (",") between 2 fields.

Similarly, write the values into the target text file using TEXTMERGE method. In case you would like to convert a numerical value to text value, please remember to set the length & no. of decimal places for the value and remove redundant spaces, such as ALLTRIM(STR(ANN_PREM,15,2)). You need to ensure the string length should cater for all numerical fields that require conversion - use ONE max length will do, otherwise you will be confused by having many different max length.

If you open the file generated by Foxpro, it will look like the following screen capture - without header & footer:

STEP 2: Open & Update MPF in Prophet
Open every MPF in Prophet - click "Import" button for "Open" dialog. If your MPF consists of any text fields (i.e. non-numeric except "!" field), you would need to select all records in a particular field and add "Quote" to the values (right-click, select "Quote" in the menu). Otherwise, no modification is necessary unless you would like to include a description in the MPF (Correct, basically you only need to open & save the MPF if you do not have any text fields).

STEP 3: Save MPF
Save MPF after you have made the necessary modifications in STEP 2. By saving the MPF, Prophet will automatically add the missing "header" & "footer" in the MPF and now the MPF are ready to be used for Prophet runs.

A Reminder...
Apart from FoxPro, you may use Excel to prepare MPF for Prophet runs as well. However, please always note that the policy data should be sorted by SPCODE (Sub Product Code), in ascending order - otherwise, your Prophet run will fail. I would suggest you sort the policy data: (1) first by SPCODE in ascending order; (2) followed by policy number in ascending order.

I would recommend that you always include policy number in your MPF and Individual model point result files (i.e. RPT files) - in case you require Prophet results by policy level in your analysis.

How Should I Do My UAT? (1): Program / Spreadsheet / Model

2013-07-03T19:06:00.001+08:00

If you are working in the actuarial department of an insurance company, it may not be uncommon to you involving in various testing exercises, which are known as User Acceptance Testing ("UAT") in general. Some of us may think that UAT is only applicable to the policy administration system implementation project (Oops... Do I remind on the non-stop follow-ups from your Project Manager?), but in fact UAT is also needed for the programs, spreadsheet templates or actuarial model we use to perform various actuarial studies - whether they are developed internally or by external consultant. It is particularly important for those tools which we are going to use to perform regular studies.

In my view, there is no one right answer for the approach to be used in performing UAT on program / spreadsheet / model - most importantly, the approach that you adopt should allow the required testing to be carried out in a structured manner, and it should not create too much "processes" that doesn't help to improve quality of testing (e.g. filling in too many forms or having too many sign-offs). In case you are struggling in finding a suitable approach for your UAT exercises, perhaps the following proposed method can provide some ideas to you.

STEP 1: Prepare Test Script
To ensure your UAT to carried out in a systematic manner, the first thing you need to do is preparing a test script. A test script consists of (1) test scenario; (2) expected results; (3) actual results (which you will fill in after carrying the required testing). Below is a sample format of a test script for a FoxPro program:

A test script serves as a structured guide to the testers, so that they have a clear idea what areas to be tested and how they should carry out the required testing, in proper order. Without any test script, the testers will only test on what they manage to think of at they are doing the testing (it will be worse if they do the testing after office hour with tired minds), like a kid running helter skelter in the street. Apart from overlooking important areas to be tested, the errors / required modifications reported to the developer will not be in a proper order - which will increase time & efforts to modify the tested tools as well as redo the required testing.

STEP 2: Prepare Test Data
Although it is good to use the actual policy data to perform UAT, sometimes the available data are unsuitable for testing, especially at the initial stage where you would like to detect any errors in formulas. Alternatively, you can use a simulated set of data with a specific pattern to do your testing, such as illustrated in the following diagram (a spreadsheet template for loss ratio study):

As shown in the above diagram, you can easily detect the formula error for Plan D, which by right the claim incurred should be 1,300 and the calculated loss ratio should be 10.00%. If you use the actual data directly, you may not be able to detect such formula error and may lead to incorrect conclusion for Plan D.

Of course, before you sign-off the program / spreadsheet / model, it is recommended to do at least one testing using actual data for reasonableness checking.

STEP 3: Perform Testing
Before you start doing testing, you may want to sort the test scenarios in an order that will allow you to carry out testing in a more efficient way. In case you find out some test scenarios left out when preparing the test scripts, you may add the test scenarios into your test script. Same for additional testing you carry out - especially the findings are meaningful.

Similarly, in case you find out any test scenarios are no longer applicable, you may want to cancel the test scenarios. We should be flexible enough in handling various conditions arising during testing.

STEP 4: Observe Outcomes
After completing each testing, you need to update the "Actual Results" column based on the outcomes you observe and decide the testing is "passed" or "failed". If the UAT exercise is complex, you may consider using an issue log in managing errors you report to the developer (IMPORTANT: Developer and Tester should NOT be the same person) or modifications you request the developer to do.

Some Remarks...
The above proposed approach is not new to actuarial people, since it uses the concept of "actual vs. expected" - which we are always doing in "monitoring the results" stage of the actuarial control cycle. However, in term of how comprehensive a test script should be, it is important to note that we should avoid having million dollar solutions to ten dollar problems - we cannot test everything or check everything, if it is a simple program, some simple testing will do (which justifies the time & effort spent).

Also, we need to take note that a program / spreadsheet / model will not be perfect after doing ONE session of UAT. Please allow the tools to improve over time, but enhancements should not be done frequently (unless there are errors to be fixed) - otherwise, you will end up being busy all the time by doing testing.

Multiple Prophet Workspaces? Combine into ONE!

2013-06-23T18:03:00.001+08:00

SCENARIO:
Mr. A, the head of valuation team of Company X, was struggling on how to manage his Prophet workspaces. Due to various constraints (time constraints, resource constraints, ...) in the past, his team ended up using multiple Prophet workspaces in performing valuation exercises - which incurred extra time & efforts in completing required studies. To make the matter worse, some workspaces were actually having the same products (well, the oldest workspace was used to calculate statutory reserves and the latest workspace was used to calculate IFRS reserves...) - his team needed to prepare different sets of model point files for these workspaces because the variables used to read model model point files having different names!

The Chief Actuary was unhappy with this inefficiency in managing workspaces. He requested Mr. A to work out a way to consolidate the workspaces into one workspace, or at least lesser workspaces. The problem is, the Prophet Manager couldn't allocate much time for this unplanned exercise and he didn't have much time in performing UAT...

(Note: Each workspace used only 1 library)

MY PROPOSED SOLUTIONS
If we don't have time & resources in doing proper consolidation exercise on the multiple existing workspaces, perhaps the fastest way in consolidating multiple workspaces is to import libraries into a selected workspace:

Select a workspace as the base workspace. There is no fixed rule in selecting a base workspace - basically we can select the workspace having most products or most complicated. For example, if we have a workspace for individual products ("Individual Workspace") and another one for group products ("Group Workspace"), we may want to make Individual Workspace as the base workspace as it is more complicated than the Group Workspace.
Import libraries into the base workspace. A workspace can have more than 1 library, as long as the first character of the library name is different. To do so, we can select Tools > Import > Libraries. In case the existing library name in the source workspace is the same as the base workspace (e.g. "Conventional" or "Unit Linked", we need to duplicate the library in the source workspace and rename into different name before we import the library into the base workspace.

For the options to be selected in the "Import of ???? Library" dialog, I would suggest to retain all existing workspace level properties of the base workspace (hopefully we are using the same definitions for these properties in both workspaces...). It is OK to replace all existing definitions because the library you would like to import has different name.

Re-create products in the base workspace. If the library name of the source workspace is originally different from the base workspace, we can import the products (Tools > Import > Products) from the source workspace. Otherwise, we need to re-create the products available in the source workspace - we should select the workspace having the least input variables as the base workspace! This is because we cannot duplicate a product for different library (even though both libraries are in the same workspace).
Add fields in model point files. If the variables from different libraries that used to read the same values have different names, I would suggest to include additional fields in the source workspace's model point fields - i.e. there are 2 or more fields having the same values in the model point files. When Prophet performs calculations for a particular product, it will ignore those fields which the field names are unavailable in the library that the product belongs to. By including these additional fields, we no longer need to prepare multiple sets of model point files.

Of course, we still need to perform necessary checking on the run results before we finalize the workspace for production - we may need to do additional modifications especially if the source workspace uses different definitions for the workspace level properties.

However, please note that the above proposal serves as short term solution only - we still need to do proper workspace consolidation in long run, otherwise it will require more efforts when we want to add new product into the workspace.

How Can We Manage Valuation Prophet Workspaces?

2013-01-21T15:17:00.001+08:00

Finally it comes the time to prepare for actuarial valuation work for new financial year 2013. I think it is the correct time for me to share my proposal to one of my clients, Actuarial Department of Company A, in order to improve how they can manage their valuation Prophet workspaces.

Existing Approach

Apart from monthly valuation (i.e. computing statutory reserves), Company A performed various valuation exercises, such as market-consistent embedded value ("MCEV"), on regular basis. Currently, they use a centralized Prophet valuation workspaces for all sorts of valuation exercises, which designated run numbers are assigned to different types of exercises.

In order to segregate runs for different valuation months, the Prophet workspace is duplicated every month (including the relevant tables) into a new folder. Of course, all workspaces are saved in a designated drive in the server.

Although there are some advantages using this approach, I do share with Company A its shortcomings:

Under utilization of run numbers - Each Prophet workspace allows for up to 99 runs in a single workspace. By using this approach, many run numbers in a particular may not be utilized - in simple words, many run numbers are "wasted". On the other hand, the December workspace (i.e. financial year end) may not have enough run numbers to cater for all sorts of analysis - especially those only done annually.
Housekeeping difficulties - No one likes to do housekeeping, but this is the task we need to do regularly ("Yes we hate it but we have to do it..."). Apart from increasing the housekeeping workloads (due to too many workspaces), it will also cause dispute on who should "zip" up the result files and backup accordingly - it is not efficient to have many teams doing housekeeping on a single workspace, and definitely it is not fair to appoint an UNFORTUNATE staff (normally junior staffs will be prospective "candidates") to "zip" files & do backups.
Different needs in different valuation exercises - There are different requirements for different actuarial exercises. For example, for a annual budget workspace, we may need to create hypothetical products to project the new business for planned new products (which may require coding modifications in the library); however, for monthly valuation workspaces, it may be inappropriate to create such hypothetical products in the workspaces - especially if the required coding modifications impact reserves. Furthermore, monthly valuation workspaces may want to different timing of coding updates - the monthly valuation team may want to do several coding changes at once (say) quarterly, especially those have minor impacts to reserves (your appointed actuary may question you if you need to update your coding every month but minor impacts... Furthermore, you (as well as your boss) need to do testing-checking-review-documentation exercise every month until you don't have time to date your BF / GF...).

Proposed Approach

Hence, in order to overcome the above-mentioned shortcomings, I have made the following proposal to my client. In my view, a Prophet workspace, which consists of actuarial models used to produce various calculations, should be properly controlled. Apart from differentiating developer / user access rights, by right Prophet Manager should be the ONLY ONE to create a new PRODUCTION workspace, which the respective users should submit a request (ensure the process is simple - no multiple forms & sign-off, please) when a new workspace is needed.

My proposal is:

Designated workspaces for each valuation team - Setup separate workspaces for different valuation team, or even by actuarial exercise if needed. For example, a particular valuation team responsible for both embedded value and budget exercises may want to have separate workspaces for each exercise (as the requirements are different).
Continuous use of workspaces - Utilize as many run number as possible in a workspace, until a new workspace is created to replace the workspace.

For example, we create a monthly valuation workspace and name it as "p_mv13a". If there is no revision needed for Jan '13-Jun '13, we can continue to use p_mv13a to perform monthly valuation runs for Jan '13-Jun '13. In case a coding revision is needed during Jul '13, we can create the revised workspace and name it as "p_mv13b". Apart from managing less workspaces, I think you can easily see that your housekeeping work is lesser.
When to create a new workspace? - In order to control number of production workspaces, I would suggest the following approach when we want to introduce a new product to a workspace:

- If the new product doesn't involve any coding modifications in the library (i.e. only modify the definitions in input variables) and doesn't require change of structure in any table, I would think that it is OK to create the new product in the existing workspace - instead of creating a new workspace for this purpose - as this addition of new product doesn't affect existing products / run structure / run settings. Of course, we need to properly define the workspace version (such as updating the workspace version from 1.0 to 1.1).

- If the new product created to replace an existing product (e.g. split an existing product into 2 products), I would think it is necessary to create a new workspace. The existing run structure / run setting containing the replaced product are no longer workable without modification.
Use run control form - Use a run control form to document the run activities, so that we have a proper reference in the future in case we need to use / check a specific run. Of course, such documentation is not a pleasant thing to do - since we already have run log for each run, the run control form should be simple and with SOFTCOPY (so that we can duplicate and existing run control form and update the form easily).

The above-mentioned "run activities" include tables updated, product selected and error/warnings handling (especially those we have ignored).
Try to make Prophet run error free - I would recommend that we should try to make a Prophet run error free - in case there is no longer any in force policy for an old product, please remove from the run structure. If we keep ignoring errors arising from Prophet run (which most of them are missing model point files), it would be possible that we will overlook the REAL run error - which we may only discover when we analyze results or NOT discover it at all! Furthermore, having many errors in a Prophet run will require additional efforts to check the run log.
Housekeeping & backup regularly, please - Although disk space is quite cheap nowadays, it is still a good practice to do housekeeping & backup regularly. If we "zip" up previous result files regularly, it will not only help to reduce the time required for backup - it also help us to ensure enough disk spaces for future Prophet runs (of course you don't want to find out that you have to "zip" files when you are running out of time...).

If you store your workspaces and run results in a server, please ensure that your IT colleagues do necessary backup regularly.