Duplicate Detection and Broker Conflicts: Catching What Manual Clearance Misses

How InsightUW's Corporate Clearance engine uses fuzzy name matching at 92% similarity to catch that "Bluefin Dining" and "Bluefin Dining Group" are the same insured — submitted by two different brokers — before either submission reaches underwriting review, preventing dual quoting, broker conflicts, and the reputational damage that follows.

The Problem

Corporate clearance requires that every new submission is checked for duplicates before underwriting begins. In practice, this check is performed manually — and it fails regularly.

The failure modes are predictable:

• Exact name matching misses variations. "Bluefin Dining" and "Bluefin Dining Group" are the same insured. "J&R Construction LLC" and "J & R Construction" are the same insured. Exact string matching catches neither.
• Multiple brokers submit the same risk. Broker A submits a GL application for Bluefin Dining on Monday. Broker B submits the same risk — under a slightly different name — on Wednesday. Without duplicate detection, both submissions enter the queue, both get quoted, and the carrier has a broker conflict.
• Manual clearance is slow and inconsistent. The clearance analyst searches the submission database, the policy system, and sometimes a spreadsheet. They search by insured name, sometimes by address or FEIN. Different analysts use different search strategies. Some are thorough; others are not.
• Broker conflicts damage relationships. When a broker learns that the carrier quoted the same risk through a competing broker, trust is broken. The broker may pull the submission entirely, and future submissions with it.

The result: carriers discover duplicates after quotes are issued, after underwriting time is invested, and after broker relationships are strained.

The InsightUW Approach

InsightUW's Corporate Clearance engine runs two automated rules — DUP-001 (Duplicate Insured Detection) and BRK-001 (Broker Conflict Detection) — on every submission at intake. DUP-001 uses Python's SequenceMatcher algorithm to perform fuzzy name matching against all active submissions and in-force policies, flagging matches above an 85% similarity threshold. BRK-001 extends this by checking whether matched submissions were submitted by different brokers, escalating to a broker conflict workflow.

How Fuzzy Matching Works: SequenceMatcher in Practice

The DUP-001 rule uses Python's difflib.SequenceMatcher to compute a similarity ratio between the incoming insured name and every active name in the system. The algorithm finds the longest contiguous matching subsequence, then recursively matches the remaining fragments on both sides, producing a ratio between 0.0 (no similarity) and 1.0 (identical).

Name Normalization

Before comparison, both names are normalized:

1. Convert to lowercase
2. Strip legal suffixes (LLC, Inc, Corp, Ltd, Group, Co)
3. Remove punctuation and extra whitespace
4. Collapse "and" / "&" to a canonical form

Threshold Configuration

The 85% threshold is configurable per rule in the Clearance Rules admin panel. Carriers can adjust based on their risk tolerance:

Match Examples

The Duplicate Check Record

When a match is found, InsightUW creates a Duplicate Check record that captures the complete evidence:

Broker Conflict Detection: BRK-001

BRK-001 is triggered whenever DUP-001 finds a match. It compares the broker on the incoming submission against the broker on the matched record. If the brokers differ, the submission is escalated to a broker conflict — a higher severity than a simple duplicate.

Broker Conflict Severity Levels

Resolution Workflow

When a broker conflict is detected, the clearance workflow requires explicit resolution before the submission can proceed:

1. Notification: Both the assigned underwriter and the clearance manager receive an alert identifying the conflict, including the matched submission GUID and the policy system number (if registered).
2. Investigation: The clearance manager reviews both submissions — comparing broker relationships, submission dates, and coverage requests.
3. Designation: The manager designates the broker of record based on company policy (typically first-in-time or existing relationship).
4. Merge or Reject: The duplicate submission is either merged into the primary record or rejected with a documented rationale.
5. Audit Trail: Every step is logged as a Audit Entry with the action type broker conflict resolved.

Cross-Referencing Policy System Numbers

When a matched submission has a registered policy system number (e.g., PAS-SUB-2026-04471 from policy admin system), the duplicate check record includes this reference. This allows the clearance analyst to trace the match back to the policy administration system and verify whether the insured is already in the underwriting pipeline or has an in-force policy.

The rationale text generated by the clearance engine includes the policy system number:

"Fuzzy match detected: 'Bluefin Dining' matches 'Bluefin Dining Group' at 92% similarity (threshold: 85%). Matched submission SUB-GL-2026-0847 is registered in the policy admin system as PAS-SUB-2026-04471 and was submitted by Aon on 2026-04-18. Broker conflict: incoming broker is Marsh. Resolution required before clearance can proceed."

The Scenario

Maria Chen, a GL underwriter at Atlantic Mutual, receives a new submission from Marsh for "Bluefin Dining" — a restaurant chain seeking $2M/$4M GL coverage. InsightUW's clearance engine runs automatically at intake.

What the Clearance Engine Finds

DUP-001 normalizes the name to "bluefin dining" and runs it against 2,400 active submissions and 8,100 in-force policies. It finds a match:

The AI Recommendation

The clearance engine generates a recommendation:

"BROKER CONFLICT DETECTED. Recommend designating Aon as broker of record (first-in-time, 3 days prior). Merge Marsh submission into existing record SUB-GL-2026-0847. Notify Marsh broker that submission is duplicate. All clearance evidence preserved in Duplicate Check record DUPCHK-2026-04-21-0042."

Resolution

The clearance manager reviews and confirms the AI recommendation. Aon is designated as broker of record. Maria Chen's submission is merged into David Park's existing record, and Maria is notified. Marsh is informed through the standard broker communication workflow. The entire process takes 15 minutes instead of the 3 days it would have taken to discover the conflict after both submissions were quoted.

What This Means for Underwriters

1. No more accidental dual quoting. Fuzzy matching at 85% catches the name variations that exact matching misses. The 92% match on "Bluefin Dining" vs. "Bluefin Dining Group" would never have been caught by a string equality check.

2. Broker conflicts are surfaced before damage is done. The conflict between Marsh and Aon is identified at intake — not after both underwriters have spent hours analyzing the risk and issuing competing quotes.

3. Every detection is documented. The Duplicate Check record, the Clearance Rule Result, and the Audit Entry create a complete evidence chain that can be reviewed during DOI examinations or E&O inquiries.

4. Thresholds are tunable. If 85% produces too many false positives for a particular book, the threshold can be raised to 90% from the admin UI — no code changes required.

5. Policy system cross-references add context. Seeing that the matched submission is already registered as PAS-SUB-2026-04471 in the policy admin system gives the clearance analyst immediate confidence that this is a real duplicate, not a false positive.

What's Next

In the next post, we will explore how InsightUW links policy system submission numbers to corporate clearance — the cross-system traceability that ensures every clearance decision references the authoritative record in policy admin systems.

Ready to eliminate duplicate submissions and broker conflicts before they reach underwriting? InsightUW's DUP-001 and BRK-001 rules catch what manual clearance misses — automatically, at intake, with full audit evidence.

Schedule a Corporate Clearance Demo →