My Actuarial Working Life

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

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

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

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

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

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