All You Need to Know About a Successful Model Conversion
By Syed Raza
The Modeling Platform, September 2021
You must have heard the terms actuarial transformations, innovations, or actuarial modernization recently. One of the reasons why you have been hearing these terms is because executives, senior leadership and shareholders are facing the complex challenge of transforming their organizations to deliver higher quality yet cost-effective services. There are many innovations in data, technology, and managed services, and all of them drive the need for further operational efficiency. Actuarial model conversion and transformations are often complex projects that benefit from standard methods and approaches to work cohesively across workstreams.
Actuarial model conversions and transformations require a standardized approach to work effectively with cross-functional teams. This approach can apply to models, data feeds, data warehouses, general/subledger, experience studies, hedging, and risk systems: all systems that involve coordination with actuarial.
For this article, we will use an example of a model conversion project that involves the conversion of a projection or valuation model from a legacy actuarial platform to a future state actuarial system.
Key Stakeholders
Below are some of the key stakeholders that have a vested interest in the end-to-end model conversion process:
- Actuarial teams (valuation, projections, pricing, ALM, risk, etc.);
- vendors (model platform, finance, and risk systems, etc.) and other system integrators;
- information technology (data, architecture, etc.);
- Modeling Center of Excellence, Project Management Office (PMO), Change Management Office (CMO), and Testing Center of Excellence; and
- accounting, finance, treasury, corporate, reinsurance, and model risk management.
Planning
Like any project, planning should be the first stage of every model conversion or transformation. In this phase, the project manager needs to work with all the stakeholders and perform a key set of activities. These activities include aligning the resources, setting key milestones and timelines, creating workstreams, and outlining the use cases. Depending on the nature of the project, the workstreams can either be by product types or use cases. The better the planning, the more effective and efficient the remaining stages of the model conversion cycle will be. At this stage, it is recommended to gather all the key stakeholders that will be involved in the end-to-end process and make sure everyone is on the same page. Some other planning activities include:
- Assessment of the current state,
- selection of the actuarial software or system,
- defining the implementation roadmap, and
- specifying the team structure.
Requirements Gathering
Requirements will form the basis of the model conversion and the importance of adequate gathering of the requirements cannot be stressed enough. For a projection or valuation model conversion, this could involve gathering the list of products and plan codes, the methodology and approach used by each of the plan codes, the assumptions, in-force files, any mapping of the in-force data fields, tools, current state models, results, information about the admin systems, accounting and finance systems, reinsurance information, and output repositories. Testing strategies can also be defined at this stage together with defining the model and process governance.
Design
Adequate thought process will need to go into the design process. Working sessions will need to be held with the end users and parties who have a vested interest in the process. The design could be as simple as putting together a few PowerPoint slides and outlining a high-level design of the future state model whereas a more sophisticated design process would involve writing a lengthy design document that details each of the design aspects. Going back to our example of the projection or valuation model conversion, the design would include things like at what level the master product templates should be set, the naming conventions of the products and assumption tables, setting coding standards, and setting up the naming conventions for the output or result fields as well as defining linkages with the policy admin, reinsurance, accounting, and financial systems. Some key activities in this phase include:
- Defining the structure of the model;
- creating technical design documentation;
- creating the data, model, and reporting design; and
- creating process and automation design.
Development
Development is at the heart of any model conversion or transformation. This is where most of the labor, time and resources are used. The development team takes the requirements, as well as any design documents and outlines, and starts converting or transforming the model based off of those. A suggested approach is to perform parallel testing along with the development. This not only takes some of the load off the developers, but also makes things easier for the testers at the time of User Acceptance Testing (UAT) and other testing stages. At this stage, it is important to not get lost in the details and focus on high-level model builds. For instance, a suggested approach for the team would be to make sure results match at a certain threshold (say 95 percent on aggregate) and focus on the model development from a holistic and overall perspective. Spending too much time matching that last 1 percent of the results could mean several days of running policy level audits, diving deep into the testing, etc. Developers should leave those things for the testers. A strong communication and collaboration between the developers and testers is also important here.
Testing
It is useful to know the different kinds of testing typically employed by IT and software developers. These could be system testing, system integration testing, user acceptance testing, parallel testing, etc. In a typical actuarial model conversion, the user acceptance, components, and model governance testing are usually employed. A test plan is created either at this stage or at the time of initial planning. The plan identifies what threshold levels the results should be within to pass testing. I’ve seen some companies follow simple thresholds such as results being within 1 percent on aggregate basis, while more comprehensive approaches could be at the plan code level or even policy levels. It is worth noting that these differences belong to the “unknowns” category. Any known differences that are identified separately should be quantified and documented accordingly. For instance, there could be an error in the legacy system and an improvement being made in the future that could result in much larger differences both at the policy level and/or at the aggregate basis. There is a tradeoff between accuracy and timeliness here. If you want to match policies to the nearest dollar, that will take the most amount of time. Having a little lenient tolerance level in the testing allows more products and items to be covered in a comparatively shorter amount of time, especially if there are time constraints.
Deployment and Post-implementation Monitoring
Training for the end users should be conducted by the core model development and/or testing team. Any necessary deployment plans should be set, such as version controls, model documentations, assignments of any model stewards, locations of the model, assumption repositories, and any other supporting documentation.
Program Management Office & Change Management Office
Project management and change management will run throughout the model conversion project. The project management office (PMO) defines the program charter and governance. They also monitor and report on the program health to the senior management and stakeholders. The PMO also facilitates and addresses risks, assumptions, issues & dependencies (RAID).
The change management office (CMO) establishes the communication strategy among the stakeholders. They also develop training plans and identify and support people and process impacts.
Conclusion
The tools, processes and activities discussed above can not only apply to model conversions, but also to several other actuarial transformations and implementations such as finance/accounting transformations (LDTI, IFRS, etc.), data analytics and experience studies, hedging/risk management projects, etc. The alignment and coordination of all key stakeholders throughout the model conversion is an important part of the process. A successful actuarial model conversion or implementation requires an integrated (unified/combined) approach across workstreams and components. An integrated conversion or transformation approach across people, process and technology should drive the planning and implementation. The insurance industry, like many other industries, is changing fast. Appropriate planning and execution of the ideas when it comes to model conversions, transformations and implementations can save companies a lot in terms of time, effort, and resources. God is in the details!
Statements of fact and opinions expressed herein are those of the individual authors and are not necessarily those of the Society of Actuaries, the newsletter editors, or the respective authors’ employers.
Syed Raza, FSA, MAAA, is founder & president for Actuarial 360 Solutions Inc. He can be contacted at SyedRaza@actuarial360.com. LinkedIn: https://www.linkedin.com/in/syed-raza-a2589722