AI Adoption GuideInsuranceRenew
Automated re-underwriting at renewal
Agent pulls current external risk data and re-scores risk before renewal terms are issued.
Insurance processQuoteUnderwriteBindIssueBillServiceRenewClaim
By Don, DoneThat’s AI coach · updated
Re-score before terms go out, not after
A renewal re-score exists so the person who issues terms can see current licensed risk next to the in-force policy, with the bureau vintage named. It is a pre-issuance check, not a substitute for underwriting. If the licensed feed does not return, the score field stays empty. An underwriter still writes the terms. Nothing in this flow auto-non-renews, and nothing invents a number to fill a gap.
Treat this as distinct from continuous real-time risk scoring, which watches a live book between anniversaries. Here the clock is the renewal cycle: pull, attach vintage, present, decide. The in-force record is the baseline. External licensed data is the update. The re-score is the comparison, dated. Any later use of that comparison in rate belongs with dynamic renewal pricing.
What counts as a valid re-score
A re-score is valid only when it cites the licensed bureau vintage and the in-force policy it was run against. Vintage is the extract date, file version, or licensed snapshot identifier from the bureau, not "today" and not the agent's run timestamp. The in-force cite is policy number, term dates, and the rating snapshot on the book, not a reconstructed application.
If either cite is missing, you do not have a re-score. You have an untraceable number. A score with no vintage cannot be defended in file review, cannot be compared to the prior pull, and cannot be distinguished from a stale cache. Do not display it as a score. Leave it blank and record the reason: vintage unavailable.
The same cite rule applies at new business, where external data enrichment at quote should name the licensed source and vintage. Renewal is stricter because a bound contract already exists. You are updating a known risk, not filling an application.
Licensed sources only. Hazard, credit-based insurance scores where permitted, property characteristics, and similar bureau products come through contracted feeds from vendors such as Verisk, LexisNexis Risk Solutions, and CoreLogic, and through the policy systems that hold the in-force record, including Guidewire. Do not scrape public pages. Do not blend an unlicensed web pull into the score. Do not average a licensed value with an inferred one.
Load the in-force file, then the licensed feed
Run the job in a fixed order so the score always knows what it was compared to.
Load the in-force policy first: term dates, location and exposure as currently rated, deductibles and forms, and the last accepted risk view. Freeze that snapshot for the run. Do not silently refresh it mid-job from a later endorsement batch unless you re-cite the snapshot.
Call the licensed feed for that same risk. Match on the identifiers your contract allows. Record the vintage the vendor returns with the payload. If the vendor returns data and no vintage, treat vintage as missing. Do not stamp your own date in its place.
Score only when both sides are present. The rules, model, or bureau-provided score must take the in-force snapshot and the licensed extract as inputs and emit a result that still carries both cites. If the scoring service drops vintage, the result is not usable.
Write blanks as blanks. A timeout, a no-hit, a permission error, or a vintage-less payload is not a zero, not a prior-term carry-forward, and not a hold of the last score. Empty stays empty.
Queue the file for an underwriter. That person issues terms: renew as is, amend, refer, or non-renew under existing authority and notice rules. The scoring job does not issue and does not non-renew.
A typical pass looks like this. A commercial property is in the renewal diary. The job loads the in-force location, construction, and occupancy as rated on the current term. It requests a licensed property and hazard extract for that address. The extract returns with a bureau vintage identifier. The re-score compares that extract to the in-force snapshot and writes a result that names both. The underwriter sees the comparison, the vintage, and the in-force term dates, then issues renewal terms. If the same extract had returned characteristics with no vintage, the score field would stay empty and the underwriter would still issue, using the in-force file and the authority guide.
Where the licensed extract disagrees with what was bound, treat it as a data conflict, with the same discipline as application vs external data reconciliation. Do not let the scorer overwrite the in-force record to make the score look clean.
Empty stays empty when the feed is missing
Missing is normal: no-hit on address, bureau outage, license scope that does not cover the class, or a payload that cannot be tied to a vintage. Store empty, with a reason code the underwriter can read.
Do not invent a risk score to keep a dashboard complete. A filled number that did not come from a licensed extract with vintage is a fabricated score. File reviewers will treat it as if you scored the risk. You did not.
Do not substitute the prior term's bureau pull and call it current. That is a prior vintage. If you show it, label it as prior vintage and do not present it as this cycle's re-score. The current score field remains empty until this cycle's licensed feed returns with a vintage.
Do not let a downstream system default empty to "no material change." Absence of a feed is not evidence that risk is unchanged.
A score is not a non-renewal
The failure that does the most damage is treating the re-score as if the policy were already non-renewed.
A worse score is a referral, a load, a deductible change, or a decline path that an underwriter executes under the authority guide and state notice rules. It is not a system status of non-renewed. Do not flip a cancellation or non-renewal flag from the score alone. Do not suppress the renewal offer because a model output crossed a threshold. Do not send insured-facing non-renewal language from the scoring job.
A score with no vintage is the failure that looks like success on a queue. It shows a number, so people work it. Without vintage you cannot say which bureau file produced it, so you cannot reproduce it, and you cannot tell whether you scored a fresh extract or a cached copy. Hide the number. Show that the file was not scored because vintage is missing.
Inventing a score is the third failure. It shows up as a midpoint, a class average, a similar-occupancy proxy, or a copied neighbor. None of those are licensed for this policy on this vintage. Leave the field empty.
Mid-term monitoring after terms are out is a different control, covered in continuous real-time risk scoring. Do not collapse that watch and this renewal re-underwriting into one automated outcome.
Who issues, and what they need on screen
The underwriter issues terms. The screen should make that unavoidable: in-force snapshot, licensed extract with vintage, re-score or a clear empty state, and an action only an authorized underwriter can complete, or your existing automated-issue path for files that already qualify under the authority guide.
Automated issue of unchanged terms is a separate authority decision. It is not implied by having a re-score. If the score is empty, any automated path must follow the same empty-feed rules as manual files: do not treat empty as clean.
Bureau and property-data vendors such as Verisk, LexisNexis Risk Solutions, and CoreLogic supply licensed extracts and vintages. Policy administration, including Guidewire, supplies the in-force record and is where terms are issued. Do not ask a scoring job to post a policy-admin transaction.
On a sample of files, confirm every displayed score has vintage and policy cites, empty files have reason codes rather than zeros, no non-renewal or cancellation originated from the scoring job, and no file shows a score that cannot be traced to a licensed payload. If any of those fail, stop issuing from that queue until the cites are restored.
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. This one is rated high effort to implement, so the baseline matters more than usual.
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