Know More About Input Variables

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.


Comments

  1. husnaDecember 9, 2020 at 8:53 PM

    Good post cheebs! We can also control the definition using tables as much as possible.

    ReplyDelete
    Replies
    1. Lim Chee BengDecember 11, 2020 at 12:32 PM

      Thanks Husna for reading this post! Agree that tables will be very helpful in making our master products more generic to be used to setup more same as products. However, this flexibility may bring complexity along and it is important that we find a balance - Of course we don't want come to a situation tables that we have created invite lots of maintenance efforts, which by right are supposed to make our work easier.

      Delete

Post a Comment

Popular posts from this blog

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

Image
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  How...
Read more

How do You Setup Indicators in Your Prophet Model?

Image
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. 
Read more

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

Image
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...
Read more