Rate revision used to be an annual exercise. A carrier reviewed its experience, filed a change, and implemented it according to a schedule everyone could plan around. Vendor release cycles fit comfortably into that model.
That model has changed. Carriers now adjust rates more often in response to loss trends, competitor activity, reinsurance costs, and segment performance. The pressure to respond quickly is also growing.
In this environment, sending a rating factor change through a vendor queue can add weeks to the process. Those delays can affect how long a carrier continues writing business at a rate that may no longer be adequate or competitive. This brings up a more useful question about P&C policy administration systems. It is not simply whether the system is configurable. The real questions are where configuration is needed, how much control the carrier should have, and what safeguards need to be in place.
Vendors will usually say their platforms are configurable. Buyers often accept that answer because there is no single definition of configurability. Once the concept is broken down, however, the differences become much easier to see.
A platform may give a carrier considerable control over rating while limiting what it can do with the data model. That may not matter until the carrier needs to rate on a variable the system does not currently capture. This is why each category needs to be assessed separately. A general claim that a platform is configurable can hide the limitation that matters most to a particular carrier.
The easiest way to set priorities is to look at how often each type of change occurs and what a delay costs the business.
Rating changes usually come first. A carrier operating across 40 states and reviewing several segments each quarter may need to make dozens of rating adjustments in a year. If each change takes six additional weeks to reach production, the carrier spends those six weeks writing business at a rate that may be inadequate or uncompetitive. Over time, those delays can cost more than the difference between software licenses.
Forms are another important area because regulatory requirements can drive changes as much as product strategy does. State mandates come with effective dates. If a carrier cannot attach a required form without waiting for a vendor release, it has to choose between delaying compliance and creating a manual workaround.
Underwriting rules come next. As loss experience changes, so can the carrier's appetite for a particular class of business. Being able to tighten eligibility within days instead of months gives the carrier more control over that exposure.
The remaining areas tend to change less often, but they can have a deeper impact when they do. Data model changes are a good example. They may be rare, but they can block a new product, rating factor, or reporting requirement because they often arise when the business wants to do something the existing platform was not designed to support.
For this reason, property & casualty policy administration systems should receive the closest scrutiny in rating, forms, and underwriting rules. Structural changes may reasonably require vendor involvement, but that should be understood upfront rather than discovered during implementation.
There is another issue to consider during the sales process. Asking whether a platform supports configurable rating will usually produce a yes. A better test is to ask who actually performs a rating change in production, how long the change took at a named reference carrier, and how the carrier would roll it back if something went wrong. Those questions often reveal meaningful differences between P&C policy administration systems that appear similar on a feature matrix.
Fast configuration only helps if the change can also move through the filing process. For P&C carriers, that means dealing with regulatory requirements.
A rate change may require a filing, supporting exhibits, and approval in each state. The timelines can vary. A platform that lets the carrier configure a change quickly but cannot produce useful filing material has not removed the bottleneck. It has simply moved it somewhere else.
There are several capabilities worth testing:
The fifth point is particularly important. A configuration model built for regulated insurance products needs to account for historical reconstruction from the start. Otherwise, a carrier may discover a limitation during an examination, when there is little room to fix it.
Configurability creates its own problems when there are no controls around it.
A carrier with a highly configurable platform can end up with rating algorithms containing layers of factors that few people understand. Rules can begin to conflict in situations that were never tested. Product variants can be created by copying existing products, and those copies can gradually drift apart. Eventually, a simple change may require updates to several different definitions.
Configuration created by someone who has since left the organization can make the problem worse when there is no documentation explaining why a particular rule or factor exists.
At that point, the platform may still be technically open, but the carrier becomes reluctant to change anything because no one is confident about the consequences. The result is similar to vendor dependency, even though it came from a different source.
The controls needed to prevent this do not have to be complicated:
These controls should not materially slow down a capable team. They help prevent a more serious problem: having a configurable platform that the carrier is ultimately afraid to change.
Legacy migration adds another layer to the problem. When carriers replace an older platform, they often bring rating logic that was originally written as code. Moving that logic into a configuration model can expose years of undocumented factors, state-specific exceptions, and adjustments that were made for reasons no one recorded.
Property & casualty policy administration systems vary in how much of this legacy logic they can absorb through configuration instead of sending it back into custom development. That difference can have a direct impact on the implementation estimate. Vendors should be asked how they handle legacy rating logic that does not map cleanly to their configuration model, because most carriers will have some of it.
The right level of configurability depends on how often a carrier changes its products and processes. That requirement can be measured rather than debated.
Start with the previous year's changes. Group them into rating adjustments, form changes, rule modifications, product launches, and data model changes. For each change, record who performed the work and how long it took from the business decision to production. This gives the carrier a clearer picture of where the current platform creates delays.
A carrier making four rating changes a year has different needs from one making forty. A carrier operating in three states has a different filing burden from one operating in forty. A carrier focused on one line of business also needs less structural flexibility than one that regularly enters new lines.
The platform should match that reality. Deep configurability makes sense for a carrier with frequent changes and an internal team capable of managing them. A vendor-managed model with strong defaults may be a better fit for a carrier with stable products and limited configuration resources.
The staffing question is easy to overlook. Configurable P&C insurance software still requires people who understand both insurance products and structured configuration. That expertise needs to be built, maintained, and retained. A carrier can buy a highly configurable platform, but if no one is equipped to use it, the carrier takes on the cost without getting the benefit.
A product demonstration is not enough to determine how configurable a platform really is. A practical exercise using a change the carrier has already made will provide a much better answer.
Take a real rating change from the previous year and give it to the carrier's own analyst in a vendor sandbox. Measure how long it takes to configure, test, and reach a production-ready state. Then repeat the exercise with a state-specific form requirement.
The vendor should also provide a written list of changes that require vendor involvement. Every platform has some, but they are not always highlighted during a sales demonstration.
Ask how rating changes are tested before release, what regression testing is available, and how an incorrect change can be rolled back. It is also worth asking how many configuration specialists exist outside the vendor. If most of the expertise remains with the supplier, the platform may have simply recreated vendor dependency in another form.
Analyst work identifies data capability as a constraint on returns from insurer technology investments, alongside the broader push toward modernization. Data capability named as a key constraint also highlights why configuration and data need to be considered together.
When the carrier controls how a product is defined, it has greater control over the data produced by that product. That can make the data easier to use for analysis. When product logic remains inside vendor-managed structures, the carrier may have less control over the resulting data.
The right level of configurability is not the maximum level a platform can offer. It is the level that covers the changes the business makes, can be managed by accountable people, and can still be understood years later.
For most P&C carriers, that means deep configurability for rating, forms, and underwriting rules. Workflow and product structure may need a moderate level of configurability, while data model and integration changes may reasonably involve the vendor. Governance should be part of the configuration model from the beginning, rather than added after complexity has built up.
Experienced vendors build property and casualty policy administration with business-user configuration for the areas that change most, along with the versioning and effective dating needed for regulated products.
A useful starting point is the carrier's own change log from the previous year. Add two dates to every change: when the business made the decision and when the change went live. Add those delays together across the year. That total shows what the current arrangement is costing the business. Only then does it make sense to compare that cost with differences in software licensing and decide which platform is actually more expensive.
Sign up for free local newsletters and alerts for the
California City Patch
Patch.com is the nationwide leader in hyperlocal news.
Visit Patch.com to find your town today.