Rating Belongs in the Core

The single fastest test of whether a core platform is actually configurable is to ask how a filed rate change ships.

It is a question carriers, MGAs, and TPAs have been answering with a sigh for two decades. The state approves a rate filing. The product team turns the filing into a specification. The specification turns into a ticket. The ticket waits for an IT release window. The release window arrives, eventually. By the time the new factor is live, the underlying market signal that justified the filing is months old. The platform did not slow the change down on purpose -- it slowed the change down because rating logic lived in code instead of configuration.

The Mercury Policy and Claims Administration System was designed to remove that gap. Rate factors, tier definitions, surcharges, discounts, minimum premiums, and territory definitions are configuration data, edited and versioned through the same administrative UI a product owner uses every day. A new filing is implemented as a new rate version, not a new branch of source code. There is no compile step, no QA cycle pretending to be a release, no deploy window to defend.

Three properties fall out of this design that are easy to overlook on a feature checklist but matter enormously in operations.

First, every change is versioned. The rate set effective on April first is a different object than the rate set effective on July first. Both exist in the system simultaneously. A renewal quoting against an October effective date pulls the version that applies on October first. A reinstatement going back to April pulls the version that was in force then. There is no question of which factor was used because the version is part of the record.

Second, every change is auditable. The product owner who edited the table is captured. The timestamp is captured. The before-and-after is captured. When a regulator asks how a quote at midnight on a particular night came to use a particular factor, the answer is in the platform, not in someone's email archive.

Third, every change is reversible. If a filing turns out to need a correction, rolling forward to a new version is mechanical. The legacy version stays attached to the policies it priced. Nothing is rewritten in place.

The strategic consequence of those three properties is that rate becomes a real lever instead of a quarterly artifact. A carrier that sees a loss trend developing can adjust. An MGA that wants to support a new program partner can stand up a rate plan in days. A TPA running off a legacy book can keep that book on its original rate while testing a successor in parallel. None of that is dramatic. All of it is the difference between a market participant who can react and a market participant who cannot.

I am, as always, careful to separate what we ship from what the industry talks about. Mercury's configurable rating engine is a feature in production with our clients. AI-driven dynamic pricing that learns from every quote, or generative copilots that draft filings on their own, are real research directions in the broader market -- they are not features I am claiming for Mercury today. The configurable foundation, however, is exactly the surface those future capabilities have to plug into. Without it, the rating engine is a black box that swallows priorities and emits release notes.

If you are evaluating core platforms right now, the rating question to ask is not whether the engine supports the algorithms you need today. It is whether the engine treats your filings as data you control. Everything else flows from that answer.

-- Sean Pitcher, CEO, Quick Silver Systems, Inc.