The short version:
-
Group benefits rating integrations rarely stall on the math. They stall on translating actuarial workbooks into platform code, then keeping two versions of the truth in sync forever.
-
A national voluntary benefits carrier stopped translating. Instead, its Excel rating models became one governed service its underwriting platform calls for every rate.
-
Hospital Indemnity, accident, and critical illness launched without rebuilding a single rating model. Three years on: 80,000+ production rating calls in eight months, 23,000+ test runs, and a 50% expansion of contracted capacity at renewal.
A national voluntary benefits carrier launched Hospital Indemnity, Accident, and Critical Illness rating inside its underwriting platform without rebuilding a single rating model. Six months earlier, that same program was delayed, over budget, and consuming its actuarial team in documentation work.
What changed was not the platform, the team, or the products. It was the decision to stop treating the carrier's Excel rating models as source material to be re-coded, and to start treating them as the production asset itself: governed, version-controlled, and callable by any system that needs a rate.
The walkthrough below covers what stalled, what the carrier did instead, and what three years of production looks like. It ends with the part that matters beyond this one carrier: the motion this generalizes to for any group benefits carrier modernizing its rating operations.
The program that stalled
The carrier sells voluntary group products: Hospital indemnity, accident, critical illness, universal life, worksite health. Its rating logic is the kind that makes group benefits distinctive. Hundreds of rating parameters per product. Block offers with underwriting rules embedded in the rate structure. Plan variants negotiated case by case.
And their transformation program had a sensible goal: bring rating inside the underwriting platform so proposal generation and rate sheets would run through one workflow.
The execution path was the standard one. Actuaries documented requirements, and IT re-coded the math into the rules platform. But for even a single accident product, the requirements document would reach 90 pages.
As a result, six months in, the program was behind schedule and over budget with the most complex products still ahead of it.
Why do rating integrations stall?
Rating integrations stall because the rating logic already exists, in actuarial workbooks, and the integration plan requires translating it into another system. Every translation creates a second version of the logic that has to be tested, reconciled, and maintained in parallel.
The delay lives in that loop, not in the calculation.
The loop this carrier was stuck in ran five steps:
-
Actuaries update the rating workbook
-
Requirements documents get written
-
IT re-codes the math into the rules platform
-
Both versions get tested and reconciled
-
Then a rate changes, and the cycle restarts
Worth being precise about what was happening here.
The carrier was not shopping for a rating engine. It was pressing its rules platform into rating duty, one re-coded model at a time.
Rules platforms like Pega are built to automate decisions and workflow, and they do that well. Asking one to hold a live copy of actuarial math is what created the translation loop.
The cause sits in where the rater estate lives: in workbooks that are correct, current, and owned by the right people, but disconnected from the platforms that need them.
The stalled integration everyone experiences downstream is the symptom.
The decision: govern the logic instead of translating it
Six months into the delay, the carrier changed its plan for the calculation layer. The Excel rating models would stay exactly where they were, owned and maintained by the actuaries who built them. Coherent would govern those models and run them as a production service.
Concretely, each rating workbook is brought under Coherent, which gives it the controls enterprise software takes for granted:
-
Version control with formula-level history
-
Automated regression testing before any release
-
Permissioned promotion so only designated roles can move a model into production
The governed model is then exposed as a service.
The underwriting platform requests rates from it the way it would from any internal system, and feeds the results into proposal generation and downstream workflow.
Nothing was ripped out. The rules platform kept the job it is good at: screens, workflow, case management. It stopped being asked to hold a copy of actuarial math.
Is Coherent a rating engine?
No. Coherent is not a rating engine that carriers migrate their pricing into. It governs and deploys the rating logic carriers already build in Excel, so existing workbooks become a controlled, version-managed service instead of logic that has to be re-coded in another system.
While a traditional rating engine asks a carrier to rebuild its actuarial logic, then maintain a second version of the truth indefinitely, Coherent leaves the logic in Excel, where actuaries and underwriters own it, and exposes it deterministically to the quoting platform, broker portal, benefits administration software (Workday, Benefitfocus, Businessolver), underwriting workbench, and CRM.
A rate change is made once, in the model. Every connected system gets the same answer.
What the results looked like
Hospital Indemnity, Accident, and Critical Illness went live in the underwriting platform without rebuilding a rating model, at significantly lower IT development cost than the original re-coding plan. An earlier project under the same pattern, a universal life quoting tool, ran roughly ten times faster than the Excel-and-VBA process it replaced.
The more telling evidence is what production looks like three years later, measured over an eight-month window ending mid-2026:
-
80,000+ production rating calls, with the governed service now a cornerstone of the carrier's proposal process
-
23,000+ test runs, because every model change is regression-tested against a scenario library before release
-
22 models in the development pipeline behind the products already live
-
A 50% expansion of contracted production capacity at the carrier's most recent renewal
What governed production actually looks like
Three operational details matter more to a practitioner than the headline numbers.
Actuaries run the release process, within controls.
A model update is built and validated in a staging environment, run against a regression test bed (the carrier's actuaries run 50 scenarios in about a second), and promoted to production only by designated roles. The carrier reports no bad deployments under this process. This is governance working as a growth enabler: the actuarial team ships changes quickly because the control structure makes every change provable.
The service absorbed seasonality without architecture work.
Group benefits volume concentrates in proposal season. Call volume scaled with the business cycle inside contracted capacity headroom. No re-platforming, no emergency capacity work.
The pattern is shaping the carrier's next platform decision.
The carrier is now selecting a new policy administration system, and its stated direction is to keep rating centralized in the governed service and connect the new platform through the same interface rather than recreate rating logic system by system.
That is the endgame of the approach: rating as a single governed asset, consumed everywhere and rebuilt nowhere.
"We already have a rules engine."
You are not wrong to have one, and the same goes for a rating module inside the policy administration system or a homegrown quoting platform.
The question is the same in every case: where does your actuarial logic actually live today?
If the answer is Excel, then whatever platform sits downstream is holding a translated copy, and someone is paying to keep that copy current.
In this case, the carrier kept its platform. What it removed was the step where a developer re-keys an actuarial model every time a rate changes. Launches got faster because governance replaced translation, and there was nothing left to reconcile.
The motion, generalized
For a group benefits carrier modernizing its rating operations, the walkthrough above reduces to a sequence you can start this quarter:
-
Locate where rating actually lives. Not where the architecture diagram says it lives. The rate manuals, experience-rating workbooks, block-offer logic, and proposal models that actuaries maintain today make up the rater estate, and they are the real system of record for pricing.
-
Govern the estate in place. Version control, regression test beds, permissioned release, and audit history around the models actuaries already own. This step comes before any integration work, because it is what makes the logic safe to connect.
-
Run the governed models as one production service. Quoting, the underwriting platform, benefits administration, and proposal generation all call the same service and get the same answer. Rating is maintained once.
-
Make connection the default for every platform decision that follows. New policy admin system, new enrollment stack, new distribution channel: each one integrates with the rating service instead of receiving its own re-implementation of the logic.
Governance leads this sequence. Speed is what it pays out: launch velocity, rate-change turnaround, and audit readiness stop competing with each other once the logic is governed at the source.
-
For actuarial and pricing leaders, the motion means model ownership survives production, with testing rigour that stands up in an audit.
-
For IT leaders, it means the platform roadmap stops carrying a rating re-implementation inside every project.
-
For distribution and underwriting, it means new products reach the field inside the market window.
If your rating estate lives in Excel and your transformation program assumes it has to move, pressure-test this motion before anything gets re-coded.
