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?
- 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.
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.
Good post cheebs! We can also control the definition using tables as much as possible.
ReplyDeleteThanks 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