Click Here to Print This Bulletin
Update News for November 2014
Here is a quick run-down on what you will find in this bulletin:
These topics will be dealt with in more detail throughout this bulletin.
During November postal codes renewal invoices will be going out to subscribers who have purchased additional postal codes at www.term4sale.ca.
Postal codes are invoiced on the calendar year which means that everyone's renewals come due at the same time. The reason is simple. We use January as the time when un-renewed postal codes become available. Everyone gets the same opportunity to shuffle their selections and add (or exchange) postal codes that may have come open.
Here is a quick review of the changes for 2015:
First, if you did purchase additional postal code listings at term4sale, and you did not receive any email contacts during 2014, you will be able to renew your paid postal code listings for free. This is NOT an automatic credit, you must request it. Assuming you request it, we will check our archives to confirm that you did not receive any email contacts. If you did get an email request during the year, there is no point claiming the credit. We get a copy of each email generated by the term4sale system and which is sent to a subscriber.
On a side note, we do not get copies of emails if you are using our web quote option on your web site. That question is one that we routinely receive and we want to assure all our subscribers that the email contacts that they receive from the web quote option, which they add to their website, ONLY go to the emails that they have entered into their control panel.
www.term4sale.ca is different because that is our website. Even though we get copies of those emails, nothing else happens to the emails that we receive from www.term4sale.ca. Those consumer contacts are not given or sold to anyone else. They are simply kept in an archive for purposes such as auditing how many contacts a subscriber received.
Second, if you are a personal use subscriber and you only had two free postal codes during 2014, you can select a third free postal code for 2015. You have from November 1st until the end of business on November 14th to make a selection of a postal code which is currently full, and which has other subscribers who paid to be listed in that postal code. If you do not select an additional free postal code by that time, and you have purchased additional postal codes, Compulife will simply assign one of those paid postal codes as your third free postal code. If you only have two free postal codes, and you take no steps to add a third free postal code, one will not be given to you until you ask for it.
To review postal codes and postal code availability, please use this:
Third, if you have more than 20 paid postal codes, you will be required to upgrade to a Standard license if you do not already have one. This upgrade will need to occur at your next regular subsciption renewal. As we have advised in the last two bulletins, you can extend your current personal use subscription by adding additional years. The prices are:
This will delay the price increase for those buying more than 20 postal codes.
Work on the new data entry system continues to march forward. During December we will be entering ROP factors into the new data format.
We will continue to support the old ROP factors for a brief transitional time which means that Compulife Internet Engine Users,who are using our system to quote Critical Illness products on their websites, will not have to do an upgrade until we elect to abandon the old ROPF rate format. We are going to try and bundle that upgrade with a few other items, and so you can anticipate this to occur in or about April 2015. The Windows version of the program will be moved to the new files as soon as we have completed testing and are certain that the new tables are working fine. For subscribers using our Windows program, the new program will come with the new data and so there is nothing to do. If you notice no changes or differences that will be a good thing.
Internet engine users are another story. Much of what follows is for their consumption. If you don't use our internet engine (the one you pay $995 per year for) and are interested in software nuts and bolts, feel free to read on.
The new ROP factors, for different CI categories, will be stored in 3 data files called ROPFT.500, ROPFT.600 and ROPFT.700. Those three files will replace the 21 files currently used for ROP factors. The numbers 5, 6 and 7 represent the CI categories which are represented by:
The ROPFT.500 file will replace the existing ROPF.D5? files, where the ? is the product category. For example, ROPF.D5P is the CI ROP on death factor table for category "P" which is Term to 100 (with ROP on Death). There are 5 ROPF tables for CI with ROP on Death currently in use, and those five will be cut to one.
That change will happen fairly quickly as there are not a great number of ROP CI products in our system that rely upon those factor tables, and so the building of the new ROPFT.000 file will not take long.
The next step in the conversion process will be the implementation of a new renewal premium file called RENEW.000. This has much more significance to our U.S. subscribers than our Canadian subscribers, as virtually all U.S. term products revert to a YRT renewal premium system after their initial level period. If you take a look at Primerica Life, and what happens to the renewals in those products after age 70, you'll have a sense of what I am talking about. For those who can remember them, CNA and Reliable Life used the same YRT renewal system that is found in U.S. products.
Currently YRT renewals are stored with each product that they are used for, and this represents a great deal of redundancy in our U.S. system (and some in Canada) because the same renewal tables are frequently used for many different products. For example, a company may have a 10, 15, 20 and 30 year level term, all of which share the same renewal tables. Currently we store those renewals for each variation of those products. That will not be required once we have the new renewal file, which will be able to contain the renewal files for all the products that use them, and those different products will all be able to point to and share the correct renewal file. The impact will be that term rate files will shrink dramatically, which is always a good thing, because smaller is faster. Hard to imagine our software faster than it already is, but it will be.
No doubt some will go "duh, what took you so long" but we have been saving and sitting on this idea for a very long time. We knew we also needed to upgrade (overhaul) our data format, and so we didn't want to just jump into that one change before the overhaul.
What inevitably delays a big overhaul are the demands for other things along the way. Someone comes up with an idea for a new feature in the software and it makes more sense to build that feature into the GOWIN program that you use, than to upgrade a data structure that is already working. Put another way, what you don't see behind the curtain is of little consequence to you, and we tend to be more concerned with what you do see in front of the curtain.
Further delays come as a result of people who want versions of our software for other devices and operating systems. We need to address that and the overhaul gets delayed. Delays, delays, delays. Pretty soon something you had wanted to do 10 years ago is still on the "to do list".
The impact of the new renewal files will be that we will be able to systematically go through and re-enter individual products into our existing data structure, breaking out the YRT renewals into the new data structure as we go.
In the old product entry we will point to the fact that the renewals have moved to the new renewal table. That pointer will be a previously unused variable in our current data file structure which means that internet engine users will not have to upgrade for that change because the internet engine that we currently provide does not display renewals. So we can literally convert all our term products over to the the new renewals, and you will still be able to run current copies of our existing data files with your current copy of the internet engine.
That is WITH ONE BIG EXCEPTION and one other smaller exception.
The big exception is the Pick 12 option in the Internet engine. If you use that option (and we think few do) and are comparing 10 year versus 20 year term, you will need to upgrade your internet engine or you will end up with the display of the wrong renewals. We'll tell you when that is about to happen. At that point, if you get the internet engine upgrade, your Pick 12 option will work with the new RENEW.000 file and your quotes will be correct. And of course that same upgrade will also use the the new ROPFT.000 file, and so you will be set for a few months.
But most internet engine users do NOT use the Pick 12 option. The upgrade will not be required for that. It will be required when we pull the plug on the old ROP factor files. You can look for that sometime in April. Even that may not hit you immediately, simply as ROPF factor tables do not change very often. But the minute one of those tables does change, and you didn't upgrade to the new engine, you will have wrong ROP quotes.
The small exception for internet engine users are two subscribers who currently have a more enhanced version of our engine which allows them to offer a web based, historical version of Compulife that does show renewal premiums. The minute that we roll out the new RENEW.000 file, a new engine will be needed.
Therefore, those folks will need to upgrade to the new engine because the new engine must be used with the ongoing current data.
However, it will also mean that the new engine will not work properly with the OLD data. We will NOT be supporting or upgrading the old engine, and so it will be up to those users to maintain historical copies of the old engine. If they lose those, and ask for help with an old engine, such assistance will not be available. We are not going to support old programs so people can run old data.
Note for those buying the historical data. Each month/year's edition of Compulife comes with the Windows program that was used at that time, and so this is not an issue. It is only an issue if someone tries to run new data with an old program, or old data with a new program. To some degree that can be done, but there are definite points in time where there are serious incompatitibilities, and that is coming with these changes.
Once we have gotten through upgrades for the exceptions, and have moved most of the renewals into the RENEW.000 file which will be tested along the way with the updated GOWIN.EXE, we will then announce a REQUIRED Internet engine upgrade which ALL internet engine subscribers will need to make. After that, the old ROPF files will be abandoned and no longer updated.
And none of that has anything to do with the data conversion of the main rate/product files which comes after that. It merely means that we are beginning to use and test the new data format for some of our data, and not the main data.
The key, all along the way, is to ensure that you still have software that is able to quote and be updated, at the same time as we are changing that software. It's a lot like doing heart surgery, where you still have to keep blood flowing in the patient, while you make major changes to the pump.