Main site

Insurance AI agent · Death claims & DMF

Death-Claims, DMF & Unclaimed-Property AI Agent

Compare the in-force file against the DMF, work each match into evidence, run the good-faith beneficiary search on a confirmed death, track the dormancy clock by state, and prepare the escheat report.

Typical delivery
4–6 weeks
Deployment
Your stack
Examiner review
Match-first
After launch
Agent Care

What this agent does

Raises the match, never the finding of death

In

  1. 01

    A comparison runs against the in-force file, on the block's schedule and against DMF update files.

  2. 02

    A match is returned, and the agent pulls the policy, the beneficiary record and the identifiers behind it.

Reason

  1. 03

    Each possible match is worked up into evidence for and against, with a confidence score attached.

  2. 04

    The block's own match-tolerance rules and state dormancy configuration are applied, not a generic default.

  3. 05

    On a confirmed death, the good-faith beneficiary search runs and every contact attempt is logged.

Decide

  1. 06

    Ambiguous matches, a stale beneficiary record and a dormancy clock at risk are flagged for the examiner.

  2. 07

    The match, its evidence and the dormancy status are routed to the examiner named for the block.

Out

  1. 08

    The match, the evidence, the search log and the examiner's decision stay on the policy.

  2. 09

    Execute write actions only inside the approval boundaries agreed during implementation.

Product statement

The agent raises the match and assembles the evidence; the examiner confirms death and decides, and is the one who signs what goes to the state.

Example workflow

One match, comparison to report

  1. 1Comparison runPeriodic in-force comparison against the full DMF and DMF update files
  2. 2Evidence assembledPolicy record, beneficiary record, contact history and identifiers — each against the match
  3. 3Match worked upEvidence for and against, confidence and dormancy status
  4. 4Controls appliedMatch-tolerance checks, LADMF-certification check, dormancy-rule fit and confidence threshold

No human action required

Stages 1 to 4 run unaided, and no death is confirmed at any of them — the agent is assembling evidence, and the examiner's lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the examiner's queue as a match to confirm.

Low confidence

Adds a supplemental-identifier check first.

Examiner review

The match is held with its evidence, its search log and the confidence.

Decide · Request more evidence · Escalate

Decided — released to prepare filing

  1. 6Claims and policy systems updatedOnly where write access and approval policy allow it
  2. 7Outcome evaluatedMatch accuracy, search outcomes, dormancy timing and post-filing corrections

Additional searches

Every additional search is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Confirming that a policyholder has died.
    • Determining eligibility or authorizing a claim payment.
    • Closing a policy or clearing it off the in-force file.
    • Reporting unclaimed property to a state administrator.

  • Automation boundary

    Agent acts unaided

    • ✓Run the periodic comparison against the in-force file and the DMF.
    • ✓Work each possible match up into evidence for and against.
    • ✓Apply the block's own match-tolerance and dormancy rules to the case.
    • ✓Flag ambiguous matches and an at-risk dormancy clock.

    Any write happens inside the boundaries agreed at implementation, never ahead of the examiner.

    • Initiating beneficiary contact — wording, channel and timing are a person's call.
    • Treating public DMF data as equivalent to certified LADMF access.
    • Assuming one dormancy-trigger position across every state.
  • Changes to match-tolerance rules or state dormancy configuration.

Example output

One match in the file, annotated

Everything the agent assembles is attached to the record it was drawn from.

Match-evidence output · single policy

Illustrative example
Policy
In-force whole-life policy, DMF match
Evidence line
Name and date of birth match the DMF record; the SSN field on the policy is incomplete
Match strength
3 of 4 identifiers
Evidence type
DMF comparison result
Confidence
86%
Attribution
Examiner of record and licence ID

As received

Taken from the comparison result and the policy record — nothing on this side is written by the agent.

Evidence used

  • DMF comparison
  • Beneficiary record
  • Policy file history

Why this match

It states what the comparison shows, not a death — the line the examiner weighs.

What the score decides

Below the configured threshold before it reaches the approver.

Action

DecideRequest more evidenceEscalate

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every policy

From the in-force file

03Comparison

Compare against the DMF

Draw on the in-force file, the beneficiary records on file and the block's configured match rules.

01Approved path

A match is a question

Every match carries the evidence for and against it, not a bare name-match flag.

02Human review

Point the examiner at what needs

Low-identifier matches and stale beneficiary records are flagged, so review starts where confirmation is hardest.

04

Build an evidence trail

The match, the evidence weighed against it and the examiner who confirmed stay on the policy.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • DMF & identity data

    • NTIS LADMF
    • public DMF
    • SSA verification services

  • Policy admin & claims

    • In-force file
    • claims system
    • Guidewire
    • Duck Creek

  • Unclaimed-property reporting

    • NAUPA reporting formats
    • State UP administrator portals

Agent

Death-claims, DMF & unclaimed property

  • Reads the file
  • Runs the comparison
  • Holds for the examiner

  • Case & correspondence

    • Bereavement-contact templates
    • Examiner workbench tools

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the policy

The layers wrap one another. What gets past them all is set out in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeHold every match at unconfirmed when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, match-rule and dormancy-configuration changes.Track
L4TraceabilityRecord the match, its evidence, the search log and the examiner's decision.Record
L3Examiner reviewHold the match for the examiner; it governs release, not whether the match is right.Gate
L2Policy guardrailsTest the match against the block's match-tolerance and dormancy rules; a failure returns it.Restrict
L1Confidence thresholdsRoute low-confidence matches to a supplemental check before the examiner sees them.Require review
Model coreMatch assembled — evidence, search log, dormancy status and confidence
L1 – L2
Test whether the match may proceed
L3
Puts the confirmation in the examiner's hands
L4 – L5
Keep the match and the evidence behind it
L6
Holds the match at unconfirmed when signals degrade

How Nestack evaluates it

Evaluate the comparison workflow — not only the final match.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the match the examiner opens

  1. E1Final-output evaluationDid every piece of evidence in the match tie back to its source?
  2. E2Step-level evaluationDid the agent apply the right match-tolerance and dormancy configuration?
  3. E3Tool evaluationDid it read the correct policy and the correct beneficiary record?
  4. E4Confidence calibrationDo low-confidence matches actually turn out to be false positives?
  5. E5Slice evaluationHow does performance change across specific block types?
  6. E6Business outcomeHow many matches needed a supplemental check or were later reversed?

Floor — the outcome the carrier answers for

Failure modes

Where each failure originates in the agent

Seven failure modes, placed at the stage each one originates.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • DF-03

      Stale in-force extract

      The comparison runs against an in-force file superseded by a more recent extract.

    Stage gathers

    In-force file, DMF extract, beneficiary record and history

  2. 02 · Reasoning

    2 modes

    • DF-04

      Match read as death

      A data match is written up as though death were confirmed, not still a question.

    • DF-06

      Dormancy clock preset

      One state's date-of-death trigger is applied to a policy governed by a different rule.

    Stage proposes

    Evidence lines, dormancy status and confidence

  3. 03 · Tool / write

    2 modes

    • DF-02

      Search exceeds good faith

      Beneficiary search widens into open-ended data aggregation beyond a documented effort.

    • DF-05

      Certification lapsed, unnoticed

      The comparison runs on LADMF data after the carrier's NTIS certification has expired.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • DF-01

      Both sides not checked

      The life side is never confirmed to have run the same comparison as the annuity side.

    Stage returns

    The match the examiner confirms

  5. 05 · Change / Version

    1 mode

    • DF-07

      Silent tolerance drift

      A match-tolerance or dormancy-configuration change widens what the agent will flag unreviewed.

    Stage tracks

    Model, prompt, match rules and dormancy configuration

  • Sev-1 · a report files outside the boundary
  • Sev-2 · an unconfirmed match reaches contact
  • Sev-3 · evidence degrades, routes to review
See the complete Insurance & Financial Services failure-mode catalogue

Affected slices

A clean match rate can hide where the risk sits

A file-level match rate can look clean while a handful of match types carry most of the false positives. Nestack reports the false-match rate by type, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Common names with partial identifiers7.6%3.9×Review
Policies with stale beneficiary records5.7%3.0×Review
Matches on retained-asset accounts3.3%1.7×Watch
Exact matches on full identifiers1.9%0.8×Normal

Bar: false-match rate lift vs. the exact-match baseline · scale 0–4.0× · tick at 2.0×

2 of 4 slices over threshold

Evidence-linked improvement

Every cycle earns the file its next case

A cycle shuts when the false match is a case the next release has to catch. That suite is what the next comparison run is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    False-match rate rises in a block slice.

  2. 02

    Diagnose

    The name that matched and belonged to someone alive is traced back through the comparison until the cause narrows to one field.

  3. 03

    Improve

    The change ships against a version, with the matches that exposed it attached.

  4. 04

    Verify

    A failing match case holds the release until it clears.

  5. 05

    Learn

    The case joins the standing suite and the search rules move with it.

  6. Learn → Detect

    The return edge. Detection next time runs against a suite one match longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, DMF sources, comparison workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Comparison workflow discovery and scope and boundary definition.Week 1
  2. 02DMF and beneficiary-source assessment.Week 1, Week 2
  3. 03Match-tolerance and dormancy-rule mapping and rule mapping.Week 1, Week 2
  4. 04In-force file ingestion and normalisation.Week 2
  5. 05Evidence logic and source binding.Week 2, Week 3
  6. 06Confidence scoring and flag routing.Week 3
  7. 07Examiner review workflow.Week 3, Week 4
  8. 08DMF and policy-system integration.Week 5
  9. 09Match and dormancy cases.Week 4, Week 5
  10. 10Guardrails and confirmation controls.Week 4
  11. 11Policy-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne block, one stateProductionProduction claims systemsAdvancedMultiple blocks / states
Introduced at Pilot
Comparison to your file and rules✓✓✓
Examiner review✓✓✓
Match-accuracy baseline✓✓✓
Introduced at Production
Reporting by state—✓✓
Examiner workflow in your systems—✓✓
Approved write-back—✓✓
Policy-file integration—✓✓
Introduced at Advanced
Multi-state escheat rules——✓
Multi-stage examiner review——✓
High in-force volume——✓
Multi-state escheat controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, block volume, review controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your in-force file structure and beneficiary records

    In-force file ingestion and beneficiary-record mapping

    Week 1

  2. 02Representative past matches, including false positives

    Match-evidence baseline and confidence-scoring baseline

    Week 2

  3. 03Your match-tolerance rules and state dormancy positions

    Match-tolerance and dormancy-rule mapping

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    DMF and policy-system assessment, then integration setup

    Week 2

  5. 05Matches you would not want acted on

    False-positive cases and the evaluation suite

    Week 4

  6. 06What no match may be treated as

    Confidence scoring, flag routing, guardrails and confirmation controls

    Week 3

  7. 07Named examiners to confirm matches

    Examiner review workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Each band sits on the weeks the work occupies, so week 5 runs evaluation and pilot together.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Comparison workflow discovery, rule mapping and the automation boundary

W2DMF-source integration and the match-evidence baseline

W3Match workflow, confidence logic and examiner-review controls

W4Evaluation suite, confirmation checks and failure-mode testing

W5DMF-vendor integration, pilot blocks and targeted corrections

W6One comparison cycle run under the claims examiner, then Agent Care handover

Reading the band
A bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
At the end of W6
The final checks clear on live matches and monitoring moves to Agent Care.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Insurance AI agent

Build a death-claims agent around your DMF and escheat obligations.

Show us your in-force file, your DMF certification status and your state list. You get matches raised as evidence, a documented search log, and every confirmation and filing left with a named examiner.

Typical delivery
4–6 weeks
Deployment
Your in-force file
Examiner review
Match-first
After launch
Agent Care available

Nestack Agents · Death claims, DMF & unclaimed property

AGT-INS-21 · Agent Care available after launch

Build a death-claims agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your policies

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.