BACKGROUND
AXIS is an exceptionally flexible vendor maintained software system built to accommodate the needs of a large number of clients across the world in multiple actuarial functions. This robust and flexible framework allows Moody’s to quickly and efficiently perform changes or upgrades which benefit all users. Such flexibility offers a significant advantage because a necessary change is made once, with the full benefit of different company interpretations. It is then tested by the vendor and its many users and is implemented by a professional software team. In addition to its flexibility, AXIS offers speed, functionality, integrity, consistency, and value. Being an end-to-end solution, AXIS has the potential of meeting all the actuarial software needs of a company.
HOW LONG DOES A CONVERSION TO THE AXIS SYSTEM TAKE?
The answer to this question depends on many company-specific factors, including:
- Number and types of plans
- Complexity of the business
- Ease of getting information from the current system
- Expertise of the internal staff regarding the products and the current system
- Availability of internal staff to work on the conversion
- Expertise and experience of the external partner to help lead the AXIS conversion
Valani Global staff have facilitated 100+ conversions to AXIS. Implementations vary from 3 to 4 months for a simple conversion to 18 to 24 months for more complex conversions. It is essential to carry out conversions in micro pieces to gain early wins, keeping the team motivated and senior management supportive of their progress and ultimate goals. In that regard, setting up a steering committee with key stakeholders is indispensable.
For some of our larger projects, we have used the Agile methodology with daily Scrums conducted by a Scrum Master. Two to three week Sprints tend to work best. In general, we prefer to use a hybrid approach that incorporates the best of Agile and traditional project management methods. Agile is a great way to manage large projects; however, we must adapt the approach to account for instances when we need to meet strict deadlines. It helps to recognize that some tasks need to move to a day 2 implementation list to complete the critical work and meet key deadlines.
INFORMATION GATHERING
A fundamental step in performing a conversion to AXIS is gathering high-level and detailed information about the business that is to be converted. Information may include:
- Number of policies, number of plans, issue years, etc.
- Plan descriptions, marketing material, sample contracts, data tables (premiums, cash surrender values, etc.).
- Description of riders and benefits and how the current valuation software models them.
- Description of any complex features and any deficiencies in the current valuation system
Documentation of any enhancements that are needed to model the business.
- Number and information on the type of treaties.
- Reinsurance fields in the seriatim source file(s) will be needed.
- Use of the model, including valuation (e.g., IFRS 17, local statutory, tax, local GAAP), pricing, projections, business planning, embedded values, economic capital, capital & surplus projections, budgeting, forecasting, regulatory requirements, experience studies, etc.
- Model outputs required, reports required, required reporting deadlines during each reporting cycle.
- Details of assumptions being used.
- What resources will be dedicated to help with the project?
- Internal resources allocated to this project must have an adequate level of knowledge about both the product details and the current internal systems that are in place.
- Timely responses are critical to meeting deadlines.
Internal resources should not have competing priorities that would prevent them
- from responding quickly and efficiently.
- Statutory and GAAP assumptions, deferred acquisition costs, best estimate assumptions, and margins, etc.
- Capital market and asset assumptions if applicable.
- Administration systems, downstream systems, reporting tools, etc
- The existing seriatim extract source files and documentation on these files’ layout will be needed, including liabilities and assets, if applicable.
- Will the model need to incorporate future new business or future conversions? If so, provide the relevant details.
- Perform a static validation at one point in time (e.g., reserves, inforce policy counts, policy amounts, fund values, surrender values, etc.), benchmark numbers are required on a seriatim basis (broken down to present value components) from the current software.
- Provide a detailed description of the assumptions being used by the current software.
- A dynamic validation of future cash flows (such as premiums, expenses, claims, surrenders, taxes, etc.) match within a tolerance.
- Tests that the Pricing/Projection section of AXIS is setup correctly for best estimate cash flows.
- These cash flows will be needed from the current system.
- Measurements (e.g., GAAP reserves, statutory reserves, etc.) and the tolerance in conversion to AXIS.
MODEL DESIGN & CONSTRUCTION
Without the expertise to build an efficient AXIS model, the process can take much longer than expected and potentially result in frustrations, errors, and an inferior model design.
Considering the end-to-end valuation landscape when designing an AXIS solution is vital. The flow of data from the administration system to the reporting system is just as imperative as the actuarial calculations within the AXIS dataset(s). The model design should be forward-looking and efficiently work with all the connected systems.
Within AXIS, there are often multiple approaches to solving the same problem. The choice of approach may differ based on your needs. For example, the modelling approach for a large company is often different from that of a small company, requiring additional focus on the model’s efficiency, size, and scalability. Our experts always consider the big picture and follow best practices when making key decisions.
Other areas to look at are deciding how many AXIS datasets will be needed and which AXIS modules to use. It is also important to determine the best strategy around the order in which to perform the conversion. Common strategies are to choose whether to start modeling easy products to get quick wins or begin with the most complex products to ensure that AXIS can properly handle these products and, if not, identifying early the enhancements that you would need in AXIS. It can work well to start both of these work streams simultaneously.
When designing an AXIS dataset, you will want a model developer who considers your specific needs during each step of the process. Careful consideration must be taken for each aspect of the business to decide which objects or modelling approaches to utilize.
The most efficient way to construct an AXIS model is to use an automated basis using dynamic model construction. A handful of Base Cells are constructed using the dynamic build and act as templates for major design feature options. These Base Cells do not contain seriatim records. Rules are setup to populate the Cells with the appropriate assumptions automatically. Cells are only created if business exists that need these Cells. This ensures that the model is clean and is not populated with unnecessary Cell data.
One of the critical design features is the naming convention used for objects, Batches, and tables within AXIS. The naming convention tells the user how the model works, what assumptions have been assigned, and has an impact on reporting. In particular, the Cell naming convention is very important. Currently, AXIS has a limit of 40 characters for the Cell name. Cell Tags have been introduced to give more flexibility in labelling Cells and clarifying their reference to actual plans.
Cells also have advanced functional purposes so is important to determine the most efficient way to name them. The Cell naming convention will depend on the granularity of characteristics, assumptions, and your reporting needs. It is easy to modify Cell names with a dynamic build. However, it is still good practice to determine the optimal Cell naming convention.
Ultimately, you want to develop your model objects and Batches with proper model governance in mind. We find that creating a Master dataset that is a clean copy of the model containing only the Base Cells and fully automated Batch jobs that populate your model works best. As a result, you can end up with a lot of Batch jobs, often having some Batch jobs calling other Batch jobs. Adopting a disciplined Batch jobs naming convention will be essential to avoid confusion.
Protecting objects that should not change, such as cash values of a particular product, is paramount; thereby, consideration must be given to the appropriate use of the protection features. For example, Protection at the AXIS object level could be considered for important objects that should not be modified or deleted (these objects can only be changed or removed by a user after unprotecting the object).
The final AXIS dataset should be robust and have proper controls and error checking. The model should be built to identify potential errors and prevent incorrect calculations. There are many features within AXIS that can be used to ensure low operational risk. Controls should be a fundamental aspect of the model design and implementation.
It is best to have a Model Steward responsible for the enhancement and maintenance Master dataset(s). Installing an Enterprise AXIS version, with the proper controls and security permissions will allow suitable control over the management of models. Devel- opment and Production environments with the appropriate controls will also be essential for proper governance.
The granularity and types of output you require has a significant impact on the design of the model. We design models that efficiently output the required results, which is why it is important to consider scalability, upcoming regulation changes, and future state environments, such as SQL, when designing reports. AXIS offers several vendor designed reports to output commonly required fields. However, custom reports can be designed as needed. AXIS has flexible and powerful reporting capabilities to address varying needs for the different regulation requirements worldwide.
RECONCILIATION
It is important to have a plan for reconciliation between the current system and AXIS before performing this task. The strategy should include both static and dynamic validations as well as appropriate tolerance levels.
Static validation refers to the process of reconciling values at the conversion inforce date:
- Inventory items
- Number of coverages/policies, total face amounts, cash surrender values, etc.
- Calculated items
- Liability/reserves, risk adjustments/margins, deferred profit/CSM, deferred acquisition costs, etc.
Dynamic validation refers to the process of reconciling values in the future, after the con- version inforce date:
- Future cash flows such as policy premiums, expenses, benefits, reserves/li- abilities in the future, etc.
- Both the timing and the value of each of the items is important.
Setting tolerance levels in advance of performing your reconciliation is also a priority. These do not have to be set in stone; they will need to be reviewed during the project and adjusted accordingly based on what makes sense as the work progresses.
- Are generally expected to match exactly. Typically set to a zero acceptable tolerance level.
- Need some thought in setting acceptable tolerance levels.
- Items calculated at the conversion inforce date may be set at a lower acceptable tolerance level than items calculated in the future.
- Thought should be given as to the acceptable tolerance level at a coverage/policy level versus a block of business level.
- Tolerance levels should be set at a component level rather than at a final calculation level. Since some components may offset other components in the final calculation.
- Examples of setting a tolerance at a component of the liability/re- serve calculation level are present value of gross policy premiums, present value of expenses, present value of death benefits, etc. rather than at a total liability/reserve calculation level.
Reconciliation can be a very time-consuming process. Thus, it is important to set up an efficient process rather than figure things out as you go. Reconciliation should be performed, both on a macro (block/plan of business) and on a micro (coverage/policy) basis, at the same time. Taking the poorest matching 10 policies on a block of business and drilling down to the detailed component calculations may reveal significant issues. Once we have addressed these issues, we analyze the macro-level again and a new list of the poorest matching ten policies.
It is ideal to have a resource who is familiar with the current system and can easily produce numbers by component that can be compared to AXIS. This collaboration works best when the two resources (one looking at the existing system) and the other (looking at AXIS) can spend dedicated time together.
There can be reasonable calculation differences in the two systems, including the precision of the calculations. Usually, these are small but need to be quantified, investi- gated, and accepted if reasonable. There may be known differences in approach (e.g., the current system uses an approximation, whereas AXIS performs a more accurate calculation). Without the help of an expert, how do you adjust for these differences?
If there were errors in the current system, how would this be quantified? You will have to ask yourself if it makes sense to spend the time to fix the current system and how material is the error? It usually does not make sense to bend over backwards to reproduce the error in AXIS. AXIS does not want to have wrong calculations in the code. Let’s say you used the wrong lapse table; sometimes, it can be easier to reproduce the mistake in AXIS than to correct the old system. In this case, it is vital to document and rectify the calculation after the reconciliation is complete. How will you adjust these errors from the current system to compare to the values from the AXIS system?
Optimally, you want to run your current system and your new AXIS system in parallel for two to three quarters, including a yearend, to confirm that the differences from one quarter to the next are consistent and make sense.
Back-end reporting is often overlooked but can be requisite to the insurance company. It is distinct to each client and must be considered throughout the design and implementation phases of the project. It could include many reports such as:
- Source of Earnings
Reserve Movement Analysis
Liability Summaries
Output feeds top other external summaries Required Capital
Financial Condition Testing
Own Risk and Solvency Assessment (ORSA)
Some of these back-end reports can take a significant amount of effort and time to implement, which is why we encourage our clients to test, validate, and signoff on the back-end reporting.
The implementation should consist of the following deliverables:
- Automated dynamic build of the AXIS Master dataset(s).
- Model documentation, extensive use of Notepads and appropriately commented code within the AXIS dataset(s).
- Procedures manual with documentation on the end-to-end process, including governance and maintenance of the Master dataset(s). The Master must stay clean and pristine at all times. Copies of the Master are to be used to perform work. The Master should only contain a hand full of Base Cells to be used as templates and do not contain seriatim records.
- A few years after we have delivered AXIS Master dataset(s), some of our clients have made comments similar to: “When Valani delivered the AXIS dataset, it was shiny and new, like a new car. Once we took it over, it is all dented and is now like an old car. How do we keep the car like new?” We say the objective is to keep the car looking new over time.
- Conversion report which documents what the conversion entailed, problems and issues that were encountered, reconciliation of the business, improvements that were made, future tasks or improvements that were put aside to address in the future.
- Assistance with setting up the production environment.
- Staff training should occur on an ongoing basis throughout the implementation. Before completion, we make an additional focused effort to ensure that they can operate the dataset(s) independently without needing further assistance in the future.
WHY PARTNER WITH VALANI GLOBAL ON YOUR CONVERSION TO AXIS?
Valani Global is a niche consulting firm that solely focuses on Moody’s risk management software solutions. We are also part of the Moody’s Global PartnerAlliance program, which is an expert network that offers delivery and support options for Moody’s Analytics clients.
Using our expertise, we have performed 100+ transformations from different data sources to Moody’s software solutions, including AXIS and RiskIntegrityTM.
100% of our consultants are fully certified in RiskIntegrityTM for IFRS 17. We do not hire juniors who learn on the job at your expense.
Once a resource is allocated to a client, they will remain dedicated to the project until completion.
The success and satisfaction of our clients are paramount to us. We will work hard to ensure that our work meets or exceeds your standards.