As well, if you haven't yet noticed, after 15 years GGY has traded the old logo for a new one. We've put this new logo into our business cards, letterhead and the AXIS icon within AXIS itself. We've also begun to redesign our website which will be friendlier and easier to navigate than the current one.

In October of 2004, we initiated our first web-based training module with the Overview session. Its introduction was quite successful as you can now go through the training on your own time and then really focus on more advanced topics when you come to train at our offices or over the internet.

To further this initiative, we now introduce the web-based training for General Liability. Once you finish the Overview session, this is a great way to get an even deeper understanding of the actual calculations that take place in AXIS. Through a case-study approach, you will gain some key skills that are useful in figuring out how AXIS handles assumptions and results.

This session is a pre-requisite for all advanced AXIS training, and users are expected to have completed this session as well as the Overview training before progressing. Follow the link above to check out this new session.

Here are some statistics on the respondents.

Actuarial work experience: 

• Less than 5 years - 33% 

• Between 5 and 10 years - 24% 

• More than 10 years - 43%

AXIS experience:

• Less than 2 years - 36%

• Between 2 and 5 years - 32%

• Between 5 and 10 years - 21%

• More than 10 years - 11%

How does AXIS compare to other actuarial projection systems: 

• 90% of the respondents that have used another actuarial system indicated that AXIS was at least as comprehensive as the other system; in fact, 70% indicated that AXIS was more comprehensive than the other system.

• 75% of the respondents feel that AXIS is easier to use than other systems. 

• 85% of the respondents feel that AXIS is as fast or faster than other systems.

Respondents experience with GGY Client Support: 

• 99% of the respondents feel that overall, GGY has met or exceeded their expectations with respect to Client Support.

• 97% of the respondents feel that their questions were addressed in a reasonable timeframe.

• 98% of the respondents had their questions dealt with in less than 8 hours.

Respondents experience with AXIS:

• 98% of the respondents feel that the number of bugs encountered in AXIS is at an acceptable level.

• 95% of the respondents feel that AXIS processes calculations at an acceptable level; in fact, 68% consider AXIS fast with respect to calculation speed.

• 93% of the respondents find it is easy to input assumptions and table data in to AXIS. 

• Only 1 respondent feels that AXIS does not give the output they require.

• 95% of the respondents feel that AXIS is fast when it comes to a total productivity perspective. Total productivity relates to model building from start to finish - data input, testing, model evaluation, processing speed.

And speaking of surveys, we were also included in the SOA survey on cashflow testing software earlier this year. There is a link above to the survey. We were quite pleased with the responses from our users and look forward to continuing to improve our product and to develop happy users--so the next SOA survey, we'll be sure to knock your socks off again!

New Mortality Risk Components

New calculation options have been introduced in the Regular Life, Universal Life and Par Products modules of AXIS to support proposed changes in the Canadian MCCSR calculations related to mortality risk. As these proposals have not yet been adopted in final form by OSFI, they are currently only available in AXIS under a feature code. 

At the cell level AXIS now calculates both the expected net claims for the coming year and the corresponding variance. Both of these are based on valuation assumptions. In addition, AXIS also calculates both the numerator and the denominator of the Macaulay Duration of the future net claims. These four components are calculated for each model point and the results are stored in four new supplementary calendar year rows. In addition, both volatility and catastrophe components are calculated on a model point basis for use in pricing. However, there is no aggregation of volatility at the cell level and such aggregation takes place at higher levels.

AXIS normally treats each subfund as a “group of products”. At the subfund level the total variance of all of the cells is used to produce one overall standard deviation. Similarly the total numerator and total denominator are used to calculate an overall duration. The overall volatility is then calculated. Two additional supplementary calendar year rows contain the volatility and the catastrophe components. These are also displayed in a new vendor defined report that also displays some of the intermediate results such as the standard deviation and the Macaulay duration.

At the fund level AXIS provides two options for calculating the fund’s volatility. By default each subfund is assumed to constitute a “group of products” so the total fund volatility is calculated as the square root of the sum of the squares of the volatilities of each subfund. Optionally the fund can be treated as one “group of products” in a manner similar to a subfund.

New Seg Fund Capital Requirements

In April 2005, OSFI announced a new factor based method for determining the Required Capital impact (and reserve provision) for guarantees related to segregated funds or other similar products. The revised approach is expected to be effective for the 2005 MCCSR filing. If companies have not developed an approved internal model for determining the value of these guarantees then they are expected to use the prescribed method and factors announced by OSFI.

The 2005 method involves a revised formula for applying the prescribed factors which OSFI has made available in database tables. OSFI have also provided lookup routines which will extract the appropriate factors from the database tables, according to a set of parameters.

In the October 2005 release of AXIS, the existing Seg Fund factor functionality in the Annuity module has been extended to support the new 2005 method and factors. It is currently available only under Feature Code control, since OSFI has not released the final regulations effective for 2005, and changes are possible.

The approach is different from previous approaches to Seg Fund guarantee factors in AXIS because of the complexity of the approach and the size of the database tables in which the factors are found. The database tables have been incorporated into a separate installation file, and a new Formula table in AXIS performs the full process of:

a) defining the appropriate look-up parameters relevant to the cell in which the table is selected, or a seriatim record being processed in the cell;

b) executing a set of lookup functions to retrieve prescribed factors from the built-in OSFI database tables, interpolating them where appropriate (AXIS does not use the routines available from OSFI); and

c) triggering the automatic calculation of the reserve or required surplus component calculation, using the factors and relevant fund balances, as prescribed by the formula.

The Stochastic Processing Module, introduced in version 11.2, is the newest member of the AXIS family of modules. Users of the module have been using a new AXIS object, titled the “Block”, to model and analyse their variable annuity and segregated fund portfolios under a large number of scenarios in a timely basis.

Numerous new features and improvements have been added to the module since its introduction, including the ability to process non-Annuity products through a Block.

The biggest news is that the October 2005 release of AXIS (11402001) adds the functionality required to calculate “C-3 Phase 2” capital requirements for US-based RBC on Variable Annuity products. “C-3 Phase 2” requires the modeling of policies under thousands of scenarios, and calculating a CTE of the Required Initial Assets under each. Users can use the ScenarioTools module to generate their stochastic scenarios, or can use the 10,000 illustrative scenarios provided by the American Academy of Actuaries (which we have converted into AXIS format). The module also provides support for the calculation of the “C-3 Phase 2 Standard Scenario”.

The Stochastic Processing Module is designed specifically for this kind of calculation, not only allowing you to calculate the capital requirement on a timely basis, but giving you the reporting and audit tools required to understand the underlying numbers.

The functionality can also be used to calculate stochastic reserves. We expect to make the calculation fully compliant with “VA-CARVM” when the details are finalized in 2006.

The traditional approach to modelling a single product in AXIS has involved multiple cells, allocating each underwriting risk class, and premium rate category to a single cell. In part this was necessary because many product parameters (premiums, cash values, dividends, etc.) and assumptions (mortality, lapse rates) are risk or rate class specific. AXIS did not require you to identify the risk class, but left it up to you to name the cell clearly, and then select the appropriate assumptions within the cell. This, however, has resulted in increasingly large models covering entire portfolios spanning many years of products.

AXIS now allows you to simplify your large models. You can now define your own Risk Class structure for each product, and associate a specific Risk Class with each Cell. Or, if you wish, use just one cell for a product, and define the Risk Class on a seriatim basis for each inforce record processed by the cell. The Risk Class structure can deal with multiple attributes (sex, smoking class, rate band, etc.) at your discretion, and the naming of each possible choice for each attribute is also up to you. For example, one Risk Class choice might be Male preferred non-smoker band 1, or you could shorten it to M PNS B1.

The other half of the solution is a new type of Table called a Rules Table. You can still use all the previously created tables to define the premium rates, mortality assumptions that are Risk Class specific, but now you can collect a family of them in a single Rules Table, and select it in the usual assumption field slot in the cell. The Rules Table then examines the Risk Class for the Cell or for each seriatim record when it is processing, and extracts rates and values from the correct risk class specific table, as required. The Rules Table is in fact a Formula Table, which provides a great deal of flexibility in associating assumption tables and any required Flat and Multiple table modifiers with Risk Classes and their attribute values.

Risk Classes and Rules Tables are brand new and currently under Feature Code control. GGY would be grateful for any feedback on this feature and on any additional assumptions which need to react to Risk Classes in order to make this approach practical and attractive for your modeling. Follow the link for further details or contact Trevor Howes.

• Local Caching improves the performance of batch jobs by bringing the data closer to the processor.
• Fault Tolerance allows a job to finish successfully even if one or more helper fails.
• Dynamic Load Balancing means you don’t have to worry about the distribution of seriatim records between cells, since AXIS can split cells on the fly for the very best performance.
• Winsock Messaging improves the performance of all distributed processing jobs by eliminating file based messaging overhead.
• The Stochastic Processing Module achieves virtually perfect scalability under distributed processing by caching both assumptions and results in memory.
• The Enhanced Distributed Processing Module provides remote control, job queuing and enhanced support for large distributed processing farms.
• The Grid Processing Module is for automated management of very large distributed processing farms, and is a joint initiative of GGY and Platform Computing, the leaders in the Grid Computing arena.

This combination of features sets AXIS far apart from other software, and clients have told us that AXIS on 32 processors can exceed the performance of rival systems using several hundred computers.  AXIS achieves the highest levels of reliability and is  much easier to set up and run.

But there is a problem. All is not well in paradise! Some of our users have batch jobs that just don’t scale very well. How can this be? Is there no truth in advertising?

First, let’s take a quick look at what AXIS does, and why this might not be enough. AXIS divides each batch job into two parts: Cell level recalculation, and what we call high-level code, meaning the Subfund, Fund, Office and Reinvestment Strategy parts. Normally, the time consuming part of any long batch job is the first part, the cell recalculation. Typically the cells may take 1000 times longer to process than the entire high-level code. So we have concentrated all of our efforts in the past at speeding up the cell calculations. These are the calculations that are split out among all the available processors to speed up the job. Once the cell calculations are complete, the Master then performs the high level calculations in a flash, and then moves on to the next scenario if there is one, inviting the helpers to join in once again.

For most jobs, this works very well, but there are some jobs where this balance between cell calculation and high-level code is upset. Consider the case where the reinvestment strategy is particularly complex, and where the reinvestment frequency is monthly for many years. This would stretch the amount of time spent in the high level code. Now suppose the liabilities, or a large chunk of them at least, are considered independent of scenario. The user may also include an initial asset position generate at the fund level, which iterates around the high level code until a solution is found. Another shift in the balance. The user may be reading in liability cashflow from another system, or may pre-calculate them in AXIS and instruct AXIS not to recalculate them with every scenario. This will greatly reduce the amount of time spent recalculating cells. The balance is shifted again.

You may end up with a batch job in which the cell recalculations take say 10 minutes and the high level code takes 2 minutes, and you want to run 1000 scenarios. Without distributed processing, this would take 200 hours, 166.67 hours on the cells, and 33.33 hours on the high level code. Run this on a 16 processor farm, and the theoretical best performance would reduce the cell run time to 10.42 hrs, while the high level code would still take 33.33 hrs, for a total of 43.75 hrs. Now this is much better than 200 hours, but nowhere near the 16-fold improvement we are aiming for. Using 32 processors reduces the run time to 38.54 hours.

The October release of AXIS introduces a new alternative method of distributed processing called Distributed Batch Testing. If you select this option in your batch testing jobs (and other related jobs Portfolio Rate Capture, OAD Analyzer and Results Analyzer) AXIS will distribute the work in an entirely different way. Instead of splitting up the work by cell, the Master will now split it by scenario. Each helper will run both cell level and high-level code for a given scenario, and this will greatly improve the speed of these jobs. Our theoretical maximum performance on 16 processors is now 200 hours divided by 16, or 12.5 hours, nearly four times faster than the standard method. With 32 processors we are down to 6.25 hours. Now you’re cooking with gas!

Now I hear a question. If this new approach is so smart, why don’t we use it all the time? After all, it can speed up both types of calculation. Well the answer is Dynamic Load Balancing. The cell distribution method is extremely sophisticated now in squeezing out the best performance from your processors. If one processor has finished processing its last cell while another is in the middle of its last cell, the system will divide the cell that is still being processed up so that the idle helper can run some of the remaining records. This mechanism keeps all helpers busy until all cells are finished, leading to superb scaling of cell calculations. But if I distribute by scenarios, then each processor must complete an integral number of scenarios – one cannot be split in the middle. So the load balancing is not so efficient. You may also have 16 processors but only 10 scenarios. Then you can use at most 10 processors if you distribute by scenario. So by default, we set the distribution method to work by cell, but if you have a particular batch job that doesn’t scale well under this method, you should try the alternative at that point.

Distributed Batch Testing is activated by setting the switch Distribution Mode to “Distribute testing targets” in your batch testing jobs. Your old jobs will continue to run by distributing cells unless you change the switch yourself, since this option is only appropriate for a limited number of jobs.

We are committed to help each of you obtain the very best results from your distributed runs, and we invite you to call Victor, Jeffrey or myself to help you configure your environment or set up the AXIS options optimally. We also have special training for IT support which focuses on production environments and distributed processing. Please contact Nadia to set up training.

For further reading: www.ggy.com/faq/techinfo.asp

(All these numbers are illustrative only. Scaling is never quite perfect, although we strive daily to achieve that. There are some overheads, there may be some time near the end when one processor has finished its work but another is still processing, and there are some limitations in the memory subsystems of multi-processor machines, particularly in Intel based machines. But our tests on high-bandwidth hardware show results quite close to these theoretical maximums.)