Skip to main content
DoneThat

AI Adoption GuideInsuranceBind

Stale-quote repricing lock

Agent detects when risk data changed since quote and requires re-rating before bind to prevent premium leakage.

Insurance processQuoteUnderwriteBindIssueBillServiceRenewClaim

By Don, DoneThat’s AI coach · updated

Bind holds until the quoted rate still matches the file

A stale-quote lock is a bind-stage quality control, not a rating engine. If the risk file at bind disagrees with the file that produced the quote, bind must not proceed on the quoted premium. The control stops bind, names what changed, and leaves re-rating to bind operations.

The quoted premium is a number computed against a vintage of the risk. Between quote and bind, occupancy, construction, TIV, location attributes, prior-loss data, or other rating inputs can change. Updates arrive from the broker, the insured, an underwriter edit, or later enrichment. Binding on the old number prices a different risk than the one on the file. That is leakage in one direction and an unsupportable price in the other. The lock exists so neither outcome is silent.

The outcome is a lock object, or an empty result. When something material changed, the lock cites the quote vintage (rating time, plus file version or snapshot id) and the changed field or fields. When nothing material changed, the result stays empty. Empty is a pass: bind may continue under the existing quoted terms, subject to every other bind check.

Bind ops still holds the work. The agent does not compute a new premium, push a revised rate into the policy admin, call a rating service to reprice, or invent a leakage amount. Guidewire, Duck Creek, Earnix, and Verisk-class rating or bureau tools remain the rating path. This control only answers whether the quote is still valid for this file, and if not, what ops must re-rate against.

This sits downstream of quote-time work such as ml-augmented indicative rating and external data enrichment at quote. Those steps produce or refresh the file the quote was rated on. The stale-quote lock does not redo them. It asks whether the bind-time file still matches that vintage.

Compare the quote snapshot to the current risk file

Compare two artifacts that already exist. The quote carries premium, rating date or vintage id, and the risk snapshot (hash, version, or stored extract) used to rate. The current risk file at bind carries the same rating-relevant fields as they stand now, including post-quote updates.

Compare the rating-relevant set, not every free-text note. Occupancy, construction class, protection class, TIV and its breakdown, location identifiers, deductibles that affect rate, applied credits and surcharges, and bureau-derived attributes that were stored as rating inputs belong in the set. If the rating plan treats a field as an input, include it. If it does not, leave it out. Narrative-only differences create noise locks that ops will learn to ignore.

Treat missing current values as missing, not as unchanged. Populated at quote and blank now is a change. Blank at quote and still blank is not. Blank at quote and populated now is a change: the quote was rated without an input the file now has. Do not treat blanks as nothing to compare.

Do not lock because timestamps differ. A file can be touched without a rating input changing. A quote can be old on the calendar and still match the current file. Vintage is the rating snapshot, not days since quote. Calendar age can be a separate SLA. It is not this control.

When the compare finds no rating-relevant difference, emit nothing. Do not write "no changes found" into a record that downstream systems treat as a hold. Empty stays empty.

When the compare finds differences, do not reprice and do not write a leakage dollar. Record vintage and changed fields, then stop. A lock with no changed-field cite is not a conservative default. If you cannot show the field, the prior value, and the current value, you do not have a lock. You have an incomplete compare.

Write a lock that cites vintage and the changed field

A usable lock is something bind ops can act on without a second investigation. Include quote vintage (rating timestamp and snapshot, version, or extract id), the changed field name as it exists on the file, prior value at quote, current value at bind, and a hold: bind is blocked until ops re-rates against the current file. The quoted premium is not authorized for bind.

If several fields changed, list them. Do not collapse them into "risk changed." Ops needs to know whether they are re-rating for occupancy, TIV, or both. Cite sources you actually have. If you cannot show the prior value, you cannot claim the field changed.

Illustrative path: a property quote was rated on warehouse occupancy and a stated TIV. Before bind, the broker updates occupancy to manufacturing. The lock cites the quote vintage (rating date and snapshot id), names occupancy as the changed field, shows warehouse at quote and manufacturing now, and holds bind. TIV is unchanged, so it does not appear. The quoted premium may appear as reference only, not as a proposed new price. No leakage dollar is written, because no one has re-rated yet.

The lock is a quality signal, not a bind instruction to issue the policy. Population of bind instructions is a different control: bind instruction extraction and system population. Completeness of conditions before issue is another: bind condition completeness validation. This lock only says the quoted rate is stale relative to the file.

Do not auto-issue a re-rate as if the lock were a rate call. Bind ops decides whether to re-rate, who re-rates, and whether the new indication still meets referral and authority. Do not treat the lock as a new premium. Mapping the lock object into the premium field uses an unofficial rate. The lock is a hold, not a price.

Keep premium and leakage fields empty until ops re-rates

The control may show the original quoted premium as context. It must not overwrite bind premium with a guessed number, and it must not fill required premium, indicated premium, or leakage.

Empty is correct for any field that would imply a new price. Bind ops holds the submission, re-rates in the carrier's existing path (policy admin rater, rating service, or pricing platform in the Guidewire, Duck Creek, Earnix, Verisk class of systems), then records the new authorized premium. Until that happens, those fields stay blank.

Inventing a leakage amount is worse than leaving it blank. Leakage is the difference between quoted premium and a correctly re-rated premium, after the rater has run. Without a re-rate, a leakage figure is fiction that reporting will treat as fact. Do not produce it.

After ops re-rates, this control is done unless the file changes again before issue. Compare again in that case. Match the new vintage: stay empty. Drift again: lock with the new vintage and the newly changed fields.

Failure modes that look like control and are not

A lock with no changed-field cite cannot be cleared. If you cannot name the field and both values, escalate as an incomplete compare, not as a bind hold.

Do not treat the lock as a new premium, and do not auto-reprice from it. Calling the rater from stale-quote detection couples a quality hold to a production rate change. Authority and broker communication sit with bind ops.

Do not invent leakage. A dollar, a percent, or a magnitude flag is a made-up statistic unless a re-rate produced it.

Two related misses: comparing bind to an indicative that was never the authorized quote, and locking on enrichment jitter for display-only bureau attributes. The vintage is the quote that would otherwise bind. Rating inputs belong in the compare; display-only values do not.

Ops should see vintage, see the field, re-rate, and bind or decline. Nothing in the lock pretends to be the new premium.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first