The $0.03 Problem
Rate the same policy twice. Get two different premiums. It happens more than you think.
IEEE 754 floating-point arithmetic (the kind every programming language uses by default) cannot represent $12,450.23 exactly. It stores something like 12450.22999999999956. Apply fourteen modifying factors to that number, and rounding errors compound at every step. By the end of the chain, you're off by pennies. Sometimes dollars.
Pennies don't sound like much until a state regulator asks why the same class code in the same territory produces a premium variance across quotes. Or until a broker runs your API twice and gets different numbers. Or until your ledger doesn't balance at month-end because you booked 12,450.23 but billed 12,450.20.
Integer Cents: The Foundation
We made a decision early: no floating-point math touches financial calculations. Ever. Every dollar amount is stored as integer cents. $12,450.23 is 1245023. Multiplication is integer multiplication. Division uses banker's rounding at every step: not at the end, at every intermediate result.
This single decision eliminated an entire class of bugs. The same input to the same rating plan produces the same premium, always. Not "usually." Not "within tolerance." Exactly the same, to the cent, every time.
Factor Ordering Is a Contract
A rating engine applies modifying factors to a base premium: territory, class code, experience mod, fleet size, cargo type, operating radius, schedule credits. Fourteen factors for commercial auto alone.
The order matters. Multiplying by 1.15 then rounding, then multiplying by 0.92, produces a different result than multiplying by 0.92 first. With floating-point math, the difference is noise. With integer cents and rounding at each step, the difference is deterministic and auditable, but it must be the same order every time.
Our factor chain has a fixed, versioned ordering. The engine version is stamped on every rating result. When we change the chain (add a factor, reorder, remove), the version bumps. Tests pin exact expected premiums against exact inputs. Any deviation is a test failure, not a "close enough."
The Specialized Module Problem
Commercial auto presents a unique challenge. The engine applies fourteen factors to a base premium. But physical damage (APD) and cargo coverages have their own internal rating logic: deductible factors, vehicle age, garaging territory, loss history specific to that coverage.
If the engine applies radius-of-operation factors to the base premium, and the cargo module also applies radius factors internally, the premium is double-factored. The policy is overpriced by 5-15%.
We solved this with a simple flag: specialized. When a coverage module marks its result as specialized, the engine knows to skip overlapping factors. The premium stream splits: flat-rate coverages get the full chain, specialized coverages get only the non-overlapping factors. No double-dipping. Testable. Auditable.
Temporal Premium: Time Is the Last Variable
A policy isn't a single premium. It's a function of time. Every endorsement creates a new segment with a new annual premium, effective on a specific date. The earned premium for any point in time is the sum of all segments, each pro-rated to the number of days they were in effect.
Endorsements can arrive out of order. A backdated endorsement at Day 45 of a 365-day policy means every downstream segment must be re-derived. The past-period adjustment is the difference between what was earned under the old timeline and what should have been earned under the new one.
We handle this with a timeline engine that rebuilds the entire segment chain on every endorsement, computes the delta split into past and future periods, and allocates rounding errors to the last segment. The result: the sum of all segment premiums equals the total policy premium, to the cent.
Penny-Perfect or It Doesn't Ship
The rating engine is a pure function. Same input, same plan, same result. Every premium output is verified to the exact cent before it reaches production. Not "within 1%." Not "close to expected." Exact.
When a state files new territory factors, or a carrier adjusts their class code relativities, or we add a new LOB, any unintended premium drift is caught automatically before it ever reaches a quote.
That's not a QA achievement. That's a regulatory requirement we chose to enforce in code instead of in spreadsheets.
Want to see the engine in action?