Skip to main content
DoneThat

AI Adoption GuideInsuranceUnderwrite

Application vs. external data reconciliation

AI cross-checks stated application data against external sources and flags material inconsistencies for review.

Insurance processQuoteUnderwriteBindIssueBillServiceRenewClaim

By Don, DoneThat’s AI coach · updated

Dual-cite flags, not declines

A reconciliation flag is a quality note that names the application field and the licensed external source that contradicts it. If you cannot show both cites, you do not have a flag. Matching values produce an empty field. A missing bureau hit produces an empty field. The underwriter still decides what any real mismatch means.

This check sits after submission extraction and normalization. Wrong-box extraction will manufacture discrepancies. Confirm you are comparing the same data element, the same named insured, and the same location or vehicle identifier before you treat a difference as material.

Do not auto-decline from this output. Do not invent a mismatch to fill a blank. Use licensed bureau sources only. Consumer web pages, unlicensed people-search tools, and screenshots are not sources.

Load the application and the licensed bureau

Start with two records, not a blended screen.

Load the application as stated, in the carrier's canonical fields after extraction. Check occupancy, construction, year built or roof age, square footage, protection class, legal name and FEIN, driver and VIN lists, and stated values only when the bureau is licensed to return that attribute for that line and that use.

Load the licensed bureau pull keyed to the same risk. Carriers already buy this class of data from vendors such as Verisk, LexisNexis Risk Solutions, and CoreLogic, and they already open it inside policy-admin and underwriting workbenches such as Guidewire. Treat that set as a licensed-source class. Do not assume a feed contains an attribute the contract and payload omit. If the attribute is not in the response, you have no source for that field.

Match keys before values. Address, VIN, and legal-entity identifiers must resolve to the same subject. A similarly named entity at a different address is a failed match, not a contradiction. Treat failed match as no hit and leave the reconciliation field empty.

If quote-time enrichment already pulled the same bureau, reuse that pull when license, purpose limitation, and freshness rules allow it. Do not mix a quote-time snapshot with a bind-time pull and call the delta an application error. What belongs at quote is covered in external data enrichment at quote.

Write the flag with both cites

Write the flag so a reviewer can verify it without a second login.

Each flag carries four pieces: the application field name and stated value (normalized form plus the raw string); the licensed source name, file or product identifier, as-of date, and returned value; why the two values are not the same fact; and which coverage, rating, or eligibility question the field feeds. Do not answer that question in the flag.

Formatting is not an inconsistency. "123 N Main St" and "123 North Main Street" after standardization are the same address. "$1,000,000" and "1000000" are the same limit. An "LLC" suffix on an otherwise matching legal name is not a flag. If an underwriter would call it the same fact, leave the field empty.

Material means the difference could change the decision, the rate, or the subject of insurance. Roof year, occupancy, power-unit count, and prior-loss count (when the application asks) usually qualify. A marketing-preference mismatch does not.

Illustrative example. A commercial auto application for a regional contractor states 12 power units and lists 12 VINs. The licensed motor-vehicle inventory for the same FEIN and named insured, as of the pull date, returns 18 active titled vehicles. The flag cites application field "Number of power units / VIN schedule: 12" and bureau inventory "18 active titled vehicles, file ID [bureau reference], pull date [date]." It does not call the applicant a liar, drop the submission, or add the extra VINs to the schedule. The underwriter decides whether this is a DBA, a related entity, seasonal equipment, or a disclosure gap, and whether to request an amended schedule or decline on the merits.

Do not flag across elements. Application roof year versus licensed roof year is in scope. Year-built versus roof-year is a different question.

Leave blanks when there is nothing to flag

Empty is the correct result when the check has nothing material to report.

If the application and the licensed return are the same fact after normalization, store nothing. A green check that restates the match trains people to ignore the queue.

If the bureau returns no hit, a thin hit, or a hit that omits the attribute, store nothing. Missing external data is not evidence that the application is wrong. The underwriter can order another licensed report, call the agent, or proceed on stated values under appetite rules. Reconciliation stays blank.

If match confidence is below the shop's threshold for that identifier, treat it as no hit. Low-confidence matches are how invented discrepancies reach the file. Do not split the difference or prefer the bureau because it looks official.

Do not backfill the application from the bureau in this step. Changing stated values is a separate disclosure and audit workflow. Reconciliation reports a conflict. It does not rewrite the app.

Failure modes that fake a discrepancy

A flag with no bureau cite. A note that "occupancy appears vacant" backed only by a model score, a photo, or a hunch is not a reconciliation flag. Recast it as a question to the agent or delete it. One-sided notes get read as bureau-backed, which is how files get declined on theater.

Treating the flag as a decline. This output is a referral, not a binding rule. Wiring "any inconsistency = decline" rejects clean files for formatting residue, related-entity vehicles, and characteristic years the insured already corrected on the application. The underwriter reads both cites, weighs materiality, and chooses accept, amend, inspect, refer, or decline. The system does not choose.

Inventing a mismatch. The bureau is silent, so the workflow writes "unable to verify, possible discrepancy" and parks the file. That sentence is a missing source, not a discrepancy. Leave the field empty. The same rule applies when two bureau products disagree with each other but both match the application, or when a bureau characteristic is older than a contractor invoice already on the file. You may send the invoice to the underwriter. You may not manufacture an application-versus-bureau flag.

These errors compound if the same pattern is fed into adverse selection pattern detection. A dual-cite flag can be an input. An invented flag will poison that review.

What the underwriter does next

Put the dual-cite flag next to the application field, with source and as-of date visible. Do not bury it in a comments blob. If there is no flag, add nothing. Silence means the check ran and found no material inconsistency, or the bureau could not be used.

The underwriter owns the decision: accept as stated, request an amended schedule or photo, order another licensed report, inspect, or decline for reasons written in the referral. Those reasons are not the flag.

If you assemble a desk packet, keep this output as a discrete quality item inside underwriter decision support briefing. Mixing it with appetite commentary and pricing hints invites people to treat a data conflict as a decline recommendation. Keep the cite pair intact so audit can reconstruct the comparison.

Re-run when the application changes. If the contractor adds the six VINs and the schedule now matches the bureau count, clear the flag. If the amendment does not resolve the cite pair, keep the flag and refresh the stated value. Do not clear flags because someone hit bind.

Load both records. Flag only dual-cited material inconsistencies. Leave blanks when the sources agree or the bureau is missing. Let the underwriter decide.

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