AI Adoption GuideInsuranceUnderwrite
Adverse selection pattern detection
ML identifies submission patterns historically predictive of adverse future loss before bind.
Insurance processQuoteUnderwriteBindIssueBillServiceRenewClaim
By Don, DoneThat’s AI coach · updated
The flag cites pattern, vintage, and grouping
Adverse selection pattern detection helps only when a flagged submission can be reconstructed. The model output is a flag that names three things: the submission pattern that matched, the loss-file vintage used to score that pattern, and the grouping rule that placed this risk in the same cell as the historical peers. If any of those three is missing, the flag is not ready for an underwriter.
The question is not whether this account will lose money. The question is whether this submission looks like a cluster that, in a named book of already-developed losses, ran worse than the rest of the cell. That is a historical association, not a quoted loss ratio and not a bind or decline instruction.
Keep this work after appetite and complexity triage. If the risk is outside appetite or too complex for the desk, a pattern flag wastes time. Keep it after application vs external data reconciliation as well. A pattern built on unreconciled occupancy, class, or exposure will cite the wrong peers.
Policy administration, rating, and analytics stacks such as Guidewire, Duck Creek, Verisk, and Earnix typically hold pieces of the submission and the historical loss file. Treat them as a class of sources. Pull a consistent extract. Do not assume any one of them already stores a cited adverse-selection flag.
Load the submission file against a named loss vintage
Start with the quoted or in-force submissions you intend to score: class, occupancy, territory, producer, limit structure, and the other fields your grouping rule actually uses. Then load a loss vintage that has had time to develop. Name it in the output. The latest month of reported losses is not a vintage. A vintage is a closed evaluation date plus the accident years or report years included.
Join on the same keys the grouping rule will use. If the rule groups by class, territory, and producer channel, those three fields must exist, with the same coding, on both the submission extract and the loss extract. If a field was recoded after the vintage closed, document the map. Do not silently recode.
Score only cells that meet your minimum history rule. That rule is a count of historical policies or claims in the cell, not a feeling that the pattern looks familiar. When the cell is below the minimum, the model writes nothing for that dimension. Empty stays empty.
Do not compute a loss ratio to fill a thin cell. A ratio built on a handful of claims and an immature year is not a cite. If you need a diagnostic for the analytics team, keep it off the underwriter's screen.
Refresh the vintage on a schedule you can defend, tied to a calendar close rather than a nightly overwrite that changes yesterday's cite. When the vintage rolls, the flag text must show the new evaluation date so last month's review is not silently restated.
Write the cite so the cell can be empty
Every flag that reaches the desk should read like a footnote, not a score. The cite names the pattern (producer channel plus occupancy cluster, for example), the vintage (accident years and the evaluation date), and the grouping (class by territory by channel, plus the minimum historical policy count). Then it states the match: this submission sits in that cell.
If the cell is thin, leave the pattern field blank. Do not substitute a broader grouping on the fly unless that broader rule is itself named and historically tested. Silent roll-up applies a signal from one territory-occupancy mix to a file that never appeared in the vintage.
The cite belongs in the same packet as the rest of underwriter decision support briefing. The underwriter should not hunt a separate analytics portal to learn why a badge appeared. If the briefing already lists exceptions and data breaks, the adverse-selection flag is one more exception with a vintage, not a second scoring system.
Do not pipe this flag into continuous real-time risk scoring as if it were a live hazard. Adverse selection here is a book-versus-submission pattern on a lagged loss file. Mixing it with telemetry or mid-term sensor scores blurs which evidence is current and which is historical.
One pass through a mid-market casualty desk
A casualty underwriter opens a manufacturing account: same class as last year, same territory, a new producer of record who has been feeding similar occupancies into the office for several quarters. Reconciliation has already confirmed class and exposure. Appetite triage has already kept the account on the desk.
The detector loads the submission fields the grouping rule uses and the named loss vintage: a closed evaluation of the commercial casualty book for a stated set of accident years. It groups historical policies by class, territory, and producer channel. In that cell, historical submissions from this channel, in this occupancy band, concentrated later-developing frequency relative to the rest of the class-territory bucket.
The model writes a flag that names the pattern (channel plus occupancy band), the vintage (accident years and evaluation date), and the grouping rule (class by territory by channel, cell above the minimum history count).
The underwriter still prices, terms, or walks. They might tighten a deductible, change a limit, or ask for more loss runs. They might decide the producer mix is already in the rate. They might decline on other grounds. They do not accept an auto-decline because a badge lit up. The model does not print a loss ratio for the cell and call it the expected result of this account.
If the same occupancy in the same territory arrives from a different channel with too few historical policies in that cell, the pattern field stays blank. The underwriter works the file from appetite, reconciliation, and the rest of the briefing. Blank is the correct output.
The underwriter decides; the model does not bind or decline
Bind, refer, and decline remain underwriting actions. The detector surfaces a reconstructable historical association before bind, while there is still time to change terms or walk. Routing a flag into a straight-through decline path trains the office to ignore cites. It also hides files where the pattern is real but the account is still acceptable on different terms.
Record the decision against the flag: proceeded as quoted, terms changed, referred, or declined, and whether the cite was used. That record is for later vintage review, not for punishing disagreement. If the next vintage no longer supports the pattern, the flag should disappear rather than linger as folklore.
Authority stays where it already sits. A junior underwriter who sees a cited flag still follows referral rules. A senior underwriter who dismisses a cited flag should leave a one-line reason. Neither path is the model deciding.
Three ways this work goes wrong
A flag with no vintage. If the screen shows an adverse-selection badge and no evaluation date, no accident years, and no grouping rule, the underwriter cannot tell whether they are looking at last year's book, a sandbox extract, or a cell rolled up overnight. Treat an uncited flag as a defect. Do not show it.
Treating the flag as a decline. The pattern is a historical concentration of worse experience in a cell, not a prohibition. Auto-decline, or a workflow that converts the flag into a hard stop, skips the only person who can weigh terms, relationship, and the rest of the file. Producers then learn to route around an unpriced shadow appetite.
Inventing a loss ratio. Thin cells tempt analytics teams to publish a ratio so the desk has a number. A ratio without the vintage, the grouping, and a credible volume of developed losses is not a cite. If history is thin, leave the cell empty. If history is adequate, cite the pattern and let the underwriter decide. Do not fill the gap with a fabricated expected loss ratio for this account.
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