Why Stat Reporting Shouldn’t Be an Afterthought
- Written By Jason Hudson
Authors: Jason Hudson, Principal Director, Statistical Reporting Services, and Mark Nawrath, Principal Director, Account Management
When insurance companies prepare to implement new software for policy and claims administration, regulatory reporting of the data captured is an afterthought. What appear to be turnkey systems often turn out to require more retrofitting and configuration than initially expected to meet statistical reporting requirements, resulting in an increase in investment and a longer timeline to launch.
Here’s why it’s necessary to consider statistical reporting needs throughout the entire development and implementation process.
Powerful and flexible modern systems…they require more configuration
Legacy technology (early mainframe systems) demanded a ton of programming to account for every possible scenario required for policy and claims administration. Building the complex logic required to encode, transform and format data into compliant statistical plan formats was an assumed part of the implementation process.
However, when client server technology started to take off in the 1990s and 2000s, new client-server-based technology vendors decided not to invest in complex logic to comply with statistical reporting mandates. These new products were like warm Jell-O waiting to be molded: they had the ingredients to perform policy and claims administration processing, but required heavy configuration and customization, not just to write insurance business (that is, all the transaction sets in a business life cycle—endorsement transactions, change renewals, cancellations, etc.), but to conform to the regulatory mandates for statistical reporting. It was up to insurance companies to make sure they were covered.
In plain terms: many of today’s systems are set up for collecting information, but how they store data on the back end is not designed to meet statistical reporting requirements.
Set yourself up for stat reporting success
In the rush to get new products to market, insurance companies often get caught up in launching their new system (or product or policy) as quickly as possible. Today’s client-server-based systems are not less capable than previous systems, they’re just more malleable. In providing insurance companies with more flexibility, the vendors put the onus on the insurance companies to configure their systems to perform and ensure compliance. Unfortunately, companies tend to focus on business functions (product rating, forms, coverages, claims handling, etc.) and overlook the importance of collecting and formatting specific transaction sets and data points needed to meet regulatory standards. This is why it’s so crucial to consider statistical reporting requirements from the very outset of your new technology implementation. Here are some strategies that work:
- Involve the right people from the start
Bringing statistical reporting compliance stakeholders to the table late in the game increases the odds of revealing functionality and data needs previously unaccounted in defining implementation specifications. Therefore, it’s important to have statistical reporting subject matter experts work together with experts in rating, underwriting and claims, early in the process to understand what products, coverages and claim events are contemplated and to define the transaction sets and data elements required.
- Account for configuration in your budget
Because of the heavy amount of programming required for legacy systems, it was very difficult to ascertain exactly how much was invested in programming for statistical reporting. These days, it’s easier to identify and quantify. Avoid sticker shock on the final project by earmarking a section of the budget for statistical reporting requirements definition, configuration and testing.
- Clarify your specifications
Identify the statistical file generation processes you’re currently using to inform your needs for your new system. From there, generate a comprehensive list of specifications and make sure they are reviewed by the teams who will be responsible for statistical reporting. Statistical reporting subject matter experts and third-party reporting consultants can come in handy here, as they can make you aware of current industry best practices and other information “you don’t know that you don’t know.”
- Produce usable test policy data
One part of the transition that is often overlooked is the availability of “production like test data”, essential to ensure completeness in the encoding/transformation process and often required in bureau electronic testing certifications. A number of statistical agents and rating bureaus require you to compare the captured and encoded statistical data (for risks, coverages, policy and claims transactions) to what is being produced on front-end for the insured. That means classifications of business, coverages being offered, rates and premium amounts must be a direct replica on the back end for statistical reporting process. Account for this in your roll-out plan and dedicate appropriate resources for it.
- Don’t rely on your data warehouse for stat reporting
Data warehouse solutions are typically not architected to satisfy statistical reporting mandates (including rating, premium and claims detail at the line/subline/coverage/transaction level, policy and endorsement form data and onset/offset entries for regular and out of sequence endorsements). Rather than making your data warehouse too complex and robust, let your statistical reporting experts and programmers work with native data that comes from policy and claims administration systems.
Create a comprehensive game plan
Develop a proactive strategy to test how your system will issue policies and transactions once policies become enforced. Don’t make the mistake of testing front-end functionality without an end-to-end review of how those policies and claims get formulated in comparison to the statistical data that you will also be collecting on the back end.
Involving an outside insurance reporting and development consultant to guide you through the process can be especially valuable here. At Perr&Knight, we offer workshops as a part of our Statistical Reporting Solution service offering. These workshops involve all relevant stakeholders and cover key topics that will inform the game plan that guides you forward.
In these multi-day workshops, we discuss with your teams the interlacing of statistical reporting file creation and testing processes into your information technology objectives, the risks associated with delivering an improved statistical reporting capability, and the coordination of your team and third-party participants to schedule projects related to the implementation of an enhanced statistical reporting solution. The final deliverable to you is an evaluation of strengths, potential vulnerabilities, and a plan for moving ahead that includes clear roles and responsibilities, cost projections and duration estimates. Whether you decide to partner with us or not, you end up with impartial strategy for implementation that you can use as a roadmap.
Because statistical reporting is not seen as revenue-generating aspect of the business, it’s often overlooked during technology development. However, doing so only short-changes you on the back end of your project implementation, as teams scramble to retrofit new systems to meet statistical reporting mandates. Instead, keep statistical reporting requirements in mind straight from the start and save yourself the headache of having to go back and make costly corrections – or being fined for non-compliance.
