James Christie | Be Aware or Beware – Part 1
In my previous article titled “Flip the Script-Solve for the Rate” I discussed a different way to go about illustrating and selling a non-guaranteed insurance product, specifically Indexed universal life for cash accumulation and income purposes. The steps to follow are listed below:
- Find 2-3 products you feel comfortable selling – stick with those products, don’t chase the spreadsheet. Product, process, and people matter when selling life insurance
- Find out the income that they need or want and how much they are willing and able to pay consistently
- Determine the rate/rates needed to achieve the desired outcome – solve in the software
- Research the probability of success with those rates – be careful, lots of fake news on this in the marketplace
- Run variations to show the impact of more/less premium, higher/lower rate, bigger/smaller outcome
- Settle on the right product and the agreed upon approach
- Write a policy purpose statement (click here for an example)
- Meet annually to discuss and react – choose a carrier with a good post issue policy management platform
Now I know not everyone is willing or able to follow this path and you just may not be in a position to make this type of change in your business. I get it. So, I wanted to discuss how to at least protect yourself if you are selling IUL using the defaults in the software. By “protect”, I mean put yourself in a position to have a positive sales experience and under promise and over deliver. Also, most importantly, be able to have a good post sale experience servicing these policies moving forward.
There are a number of default assumption embedded in every IUL sale including, but not limited to:
- Minimum Non-Mec DB Solve
- Solve for DB option 2/1 switch in optimal year
- DB reduction solve in optimal year (may or may not be a default)
- Index account – typically a more aggressive account or the one that “illustrates” the best
- Distribution Solve – typically participating loans for a certain duration – usually monthly loans
All of this gives us a number, we then go sell based off of money in versus money out. It makes sense on the surface, but there are a number of dangers embedded in these default assumptions. Never mind the fact that you need to actually make sure all of these things happen in the future. Meaning, you need to make these changes when and how they were illustrated.
It is important to be aware of what these default assumptions mean in the real world. If you are not, then beware, because you are going to be the one judged for any suboptimal outcomes.
Over the next few articles we will explore each of these defaults and discuss them using the same framework. What it is, why we do it, potential issues, and what to do about it.
Let’s start by assuming that you have entered the client age. You then enter their underwriting class. I cringe when I see illustrations that haven’t gone through any UW process yet and they have the client listed as Preferred or Preferred Plus. Start with standard, it can make your life so much easier. Plus, with many carriers you can be a cigar smoking, tobacco chewing diabetic and at the very least still get standard. (Ken W. that line is for you!)
Next you enter a premium amount and a duration. Keep in mind these are vitally important and play a huge role in potential outcomes. Any change in premium amount, duration, or timing as you know could have a big impact and it is paramount to make sure that the client is aware of this synapse. This may seem basic, but how many people really go over this with a client? In the days of GUL we didn’t even discuss it, so I would tend to think it isn’t a point of emphasis now either.
First Solve Input – Minimum Non-Mec DB Solve:
What it is – This solve generates the least amount of death benefit given the premium amount and duration without creating a MEC.
Why we do it – Keep costs low. The solve enables you to reduce the drag associated with the DB since this sale is really about the cash value growth and income potential. You end up with the lowest possible net amount at risk while still qualifying as life insurance for tax purposes, resulting in better tax-free cash value growth and tax-free income potential.
Potential Issues – Believe it or not, there a lot, even though this solve is widely used and considered just standard operating procedure. First off, you are limiting the amount of premium a client can put into their policy moving forward. This can become an issue if the client needs to put more money in the policy. They could have to do this for several reasons:
- Policy is underperforming and is running the risk of lapsing
- Policy is underperforming and the client wants to get back on track with their goals
- Client loves the policy and wants to contribute more money
- Client receives some sort of windfall and in order to take advantage of the benefits of life insurance they now must go through UW again and try to buy another policy or increase current coverage
The biggest thing that doesn’t make sense to me with this, is why would we want to limit the premium a client can put into a policy? Just seems counter-intuitive, especially given the fact that a small increase in DB to allow for future premiums doesn’t have a drastic impact on policy performance.
Another issue with this approach is that at a time where they could most likely qualify for more insurance, we are solving for the minimum they could take. Life insurance is one of the only things where when you need it the most, you can’t get it.
So why minimize the DB? Well it is because we are all selling off of a spreadsheet and need to make the income stream as competitive as possible. When in reality, we should be selling the value of the life insurance as a whole, not just the income stream. If we included the DB as part of the value proposition, we wouldn’t need to minimize the DB. When you do this, you minimize the value of what you are selling in my opinion and commoditize yourself unnecessarily. Never mind the fact that you blur the lines of the true intention of the tax code written around life insurance, but that’s a conversation for another day.
One last thing to pay attention to with this is GPT and CVAT. There are many reasons to use either one, but a crucial aspect to pay attention to is that some carriers do NOT offer overloan protection riders when using CVAT. There are usually ways around having to use CVAT, don’t just choose it because it is easy and lose the value of something like an overloan protection rider.
What to do about it – First off, I am not saying you shouldn’t use this solve. It can be very effective to achieve certain results and I have used it before and will use it in the future. BUT it is really important to know the constraints that it puts on that policy and be prepared to deal with them. If you are going to use this solve, make sure you discuss this with the client. Let them know why you are using it and what it could potentially mean for them and at the same time discuss an alternate approach where you purchase more DB and show the difference. Here are some of my best practices:
- If the client has a DB need in addition to the cash value story, use that amount. You can do this either with pure DB in the policy or by using the supplemental term insurance riders available. Most of these are convertible as well. So, you can either let it fall off of the policy in the future or convert it to permanent DB. Either way, you lock in more DB for the client when they are typically younger and healthier.
- Even if it isn’t a specific need, use a higher DB amount than the minimum. Not only does this make financial sense for you, it can be a real value for the client. It allows for additional flexibility in the future and makes sure that if they want to or have to contribute more, they can.
- If the client has a temporary death benefit need, use that amount. Remember you can reduce the death benefit in the future as that need changes or goes away. At the very least, again you have locked in more insurance which can provide better long-term flexibility.
Using a known DB amount can be a very valuable strategy for IUL, listed below is a case study showing how powerful this method can be.
Sample Scenario: John Hancock Accumulation IUL 18
Male, Age 45, Standard Non-Tobacco, State of NC, GPT, no blending, vitality turned off, 2/1 switch in optimal year, capped account, 21 years of income, indexed loans.
Listed below we have 4 Scenarios to choose from for this client.
Scenario 1 (Typical Sale) – Typical inputs using the Minimum Non-Mec DB solve with $15K of premium for 10 years and solving for income in years 20-40. Inputting higher premiums creates a MEC.
Scenario 2 (Premium Flexibility) – Same $15K of premium for 10 years, but the DB is set at $500K instead of choosing the Minimum Non-MEC DB solve. Income solve for years 20-40. Inputting higher premiums does not create a MEC.
Scenario 3 (Increase Results) – $500K of DB, now with a $20K premium for 10 years. This scenario assumes the client decides to pay more and shows the potential impact on income and short & long-term DB.
Scenario 4 (Drive Value) – $500K of DB, $20K of premium for 10 years. Assumes the client wants to match the income from Scenario 1 of $28,241 for years 20-40.
Using the parameters in Scenario 4, the client can illustrate the same income of $28,241 per year with the $20K of premiums using a rate of only 5.37% compared to the 6.12% needed when run at premiums of $15K per year.
So, what does this mean?
- 60% higher target for you, 30% – 237% higher value for the client.
- More flexibility throughout the life of the policy
- Ability to lower the rate needed to achieve your outcome
- Potential to increase the net death benefit and total value to the client
- Avoid a MEC when needs and wants change in the future and additional premium is needed
- Buy more insurance when the client is healthier, can always reduce if needed
*John Hancock was chosen at random for this exercise. There are other products that will perform just as well and frankly, many that would perform better using this methodology due to a lower cost structure.
I have used this process many times on cases over the last decade, it works. Using this methodology introduces a very unique circumstance in the marketplace. The ability to do what is right for the client and get paid more. Typically, these two things do not align, but in this case they most certainly do.
The flexibility that this provides is the most critical part of the approach. You can now have a broader discussion around the real value of IUL as a dynamic financial tool instead of just an income stream. Consider using a known DB amount instead of the minimum non-MEC. Just because something is the default doesn’t mean it is what we should use. Candidly it doesn’t take much time to go thru the exercise above and for the improved flexibility and value for the client and 60% higher targets, I think it would be time very well spent.
This example was oversimplified to show how this can work and I would recommend looking at different age bands such as life expectancy and not just Age 100 value. I did this for simplicity sake, but there are number of other valuable pieces of this conversation. Using IRR on DB and CCV or Income can also be something worth looking into especially when talking about the value of the DB throughout the life span of the policy.
Next in this series we will discuss the default solve for the DB option 2/1 switch along with the optimal DB reduction solve. We will use the same format for that discussion as we did for this article.