Inforce Data Management: Analysis and Tool Considerations
By David Eckrich
Product Matters!, August 2024
Managing an inforce block requires actuaries to have access to numerous tools, some less tangible than others, for example: an understanding of products, their risks, and company strategy through time. A more tangible tool needed is data and software. Data is required to tie everything together and turn a foundational level of company knowledge into a state of active inforce management. It is the inforce management actuary’s responsibility to understand the data and know how it can be used advantageously so business decisions can be made for an organization. Insurance companies have seemingly endless amounts of data—each with its own set of strengths and weaknesses. An obstacle that many inforce management actuaries will encounter is how to effectively use data from a growing inforce block. As an inforce block grows, so does the accompanying data. Ever growing datasets create challenges, and occasionally impossibilities, as users struggle to know the limitations and encounter system resource constraints while using the data. Finding the solution to an inforce management problem buried in data can be like looking for a needle in a haystack. This is where an actuary’s skillset and the right software can be leveraged to determine how the data can be best used for inforce decision making. From here, actuaries must succinctly communicate findings to stakeholders to turn the insight from the data into actionable items to manage an inforce block.
Numerous tools and software exist to manage data for inforce business. Deciding which software to use can often be overwhelming. This can be even more challenging for large inforce blocks. Often multiple tools are leveraged for inforce data analysis. The actuary must consider the entire process, starting from the flow of data for his or her entity to the final delivery for the project. For example, if a life actuary is tasked with reviewing partial withdrawals for an inforce block, they must consider where policy level transaction data is stored, what limitations exist in the data, how it can be extracted, where the transaction data will be loaded in to, what analysis must be performed, how the results will be shared with and communicated to stakeholders, and finally how appropriate reactions can be taken. The end-to-end process requires a depth of knowledge and decision making fortitude.
Figure 1 illustrates an example process for obtaining the data used for inforce management purposes, conducting the analysis, and sharing the results. Different tools may be required along different steps in the process. For example, the tool used to extract data may not be the same tool used to conduct an experience study. Furthermore, tools used in one inforce analysis may not carry over to other analyses. For example, a valuation model likely won’t be the best tool to show how policyholder behavior has trended historically in recent quarters. A loop is shown to demonstrate that inforce management may be a cyclical process.
Figure 1
Illustrative Inforce Management Data Cycle
The process to analyze inforce data usually starts with a database or some other tool to access company data. The database may be internally maintained or may even be managed by a third-party. An internal database may link straight to a policy administration system used throughout the entity. For internal databases, the actuary may need to partner with admin teams and IT to understand how data is being populated to know the most applicable data to use. A third-party database could be sponsored by a professional organization or an entity that is contracted specifically for administration purposes by the firm. Some third-party software has a specific use case, like sharing policyholder data with reinsurers. Regardless of who manages the data, the actuary must be mindful of data limitations along with any other considerations that will influence the analysis.
Especially important for growing inforce blocks, it is imperative that the actuary understands the data required to perform inforce analysis. This may be easier said than done, and the actuary might need to work cross-functionally to locate the data required for a project. The initial dataset may have millions of records that must be parsed through and the actuary must narrow data down to the specific need. Small sets of data or data for less mature inforce blocks can be easily brought into most software for analysis, but this is not always the case for more mature inforce blocks with lots of data. Some databases will allow for some analysis, but data frequently must be loaded elsewhere to perform analysis before sharing insights to a broader audience.
After identifying the data, it is the actuary’s responsibility to determine what tool will complete the project. For example, tools capable of financial projections or valuations may be required to understand the value in an inforce block. Third-party or in-house software could be used here, or even a combination of the two. Another example could be if the actuary is compiling a trending view of liquidity needs and liability risk for an inforce block. The actuary would need to bring qualitative and quantitative policy level information into a tool capable of analyzing the data. It would be helpful to also have visualization capabilities to illustrate trends and communicate findings cross-functionally. At this step, colleagues can share insight into why the inforce block is trending the way it is and action items can be established if applicable.
If there is a large amount of data, the actuary may be challenged when bringing data into a tool for analysis. Some commercial tools have limitations to the numbers of rows or columns in a dataset or there may be file size limitations. Likewise, there may be organizational storage limitations that must be considered. With growing inforce blocks, tools may also take longer to load and process data. Keeping all of this in mind, the actuary must be mindful of which tools to use when analyzing inforce data. Depending on the situation, in-house or third-party software can be used.
Third-party software can be invaluable when analyzing a large inforce block. Numerous tools exist on the market with different purposes, strengths, and weaknesses. If a third-party tool is used to analyze inforce data, the entity may have a contract with a provider or licenses for users. A consideration here is that using this software may come with a substantial price tag. If an entity wants to work with an external vendor, internal discussions must determine if the benefit of the software justifies the cost. Senior management may be consulted to opine on how a software will fit into the organization’s budget plans. If a tool is deemed helpful for an organization when analyzing and managing inforce data, teams must be prepared when explaining their needs to utilize the software.
Inforce management must work closely with the third-party to make sure that business needs are satisfied. For example, will the software accomplish the analysis needs that the company has so business decisions can be made for the block? If not, other external tools should be reviewed or there should be a partnership with the third-party to satisfy needs. There may be legal and practical challenges in bringing data into third-party tools. Teams must consider how data used in the third-party tool is delivered and stored. Specifically, if data is on a cloud platform, how much risk will the organization be exposed to if there is a data breach at the vendor? IT, risk, and administration teams should be consulted when determining what makes the most sense for an entity when working with third parties. Third-party tools must be used with a level of scrutiny. It is necessary that tool users understand limitations in the analysis tool and how it works. If regulators or auditors question results, users will be responsible for satisfying these requests. This may be difficult depending on the auditability of a tool developed by a third-party.
If an inforce management team uses a third-party tool, there may be numerous benefits. Third parties may offer consultative services on how to best use the tool and gain the most insight from data. These providers are experts in how to become masters in their applications and the team at the insurer should make the most of this expertise. The developer may also be able to offer insights for what they have seen at other organizations that are using their tools. Furthermore, third parties may have responsibilities for managing and maintaining the tool. This is necessary in an insurance context as business needs, regulatory frameworks and accounting standards are always evolving. Emerging regulations that the inforce block may be subject to are often difficult to fully understand. Devoting internal resources to incorporating these into tools from scratch can be difficult. Third-party developers may be able to bear some of that burden. If errors are in the tool, they may also have some responsibility for corrections. Some third-party tools may also have full end-to-end needs incorporated: aside from assisting with the inforce data analysis and computations, some tools may have visualizations that can help communicate results to other teams and management to help drive the business decisions.
Analysis tools developed in-house are an alternative to third-party tools. These can have numerous advantages and disadvantages compared to third-party tools. In-house tools can be more cost effective than third-party tools. By not having to deal with licensing fees required by third-party vendors, the overall budget requirements for in-house tools may be less. Similarly, third-party tools may require a pay per user, or bulk number of users, fee structure that may increase with the number of users. This may not be the case for in-house software since the development team and users are all within in the same organization. Another advantage is that tools developed in-house are created to meet the exact needs of the organization. Third-party software may not be robust if the vendor must generalize the software for multiple clients. Management could be perplexed if a large fee is paid for third-party software but only parts of the tool satisfy business needs. If even possible, it could be costly having a third-party vendor change the tool to meet all niche requirements. It’s the responsibility of the in-house development team to ensure that business needs are continuously satisfied. Finally, in-house developed tools may be better for satisfying auditor and regulator demands. Third-party tools can be a black box where the inner workings are less known. It may be easier to understand exactly what an in-house application is doing. This will all help in satisfying the requests of these stakeholders.
A disadvantage of software and analysis tools developed in-house is that development will require a larger commitment from the organization. Business units throughout the company will bear the development responsibilities. Especially for large or growing inforce blocks, development must consider many different policy level aspects that will require rigorous testing. There is an opportunity cost by devoting time to tool development over other commitments. Doing this will require resource commitments that are often difficult to obtain consistently as other projects take priority. Consequently, this could ultimately lead to delays in tool development. On the other hand, third-party tools may already be available to launch. There could be a situation where so much time has passed between ideation and final rollout of an internal tool that the business needs are now different. Relying on a third-party to quickly develop software for a use case could help avoid this.
Managing an inforce block presents numerous challenges. Inforce management problems themselves are unique and keep actuaries agile as policyholder actions and organizational needs evolve. To solve the problems at hand, inforce management actuaries must be mindful when selecting data for the inforce analysis. When the data is chosen, the right tools must be used to provide the most effective analysis that will lead to the conclusions that management is hoping for. With the right data, analysis, tools, and conclusions, the actuary can help guide the organization down the path that is best suited for the company’s inforce block.
Statements of fact and opinions expressed herein are those of the individual authors and are not necessarily those of the Society of Actuaries, the editors, or the respective authors’ employers.
David Eckrich, FSA CERA, is a manager and actuary at Sammons Financial Group. He can be reached at deckrich@sfgmembers.com.