Conflicts checks as a data problem, not a form

# Conflicts checks as a data problem, not a form

Eighteen months into a cross-border acquisition, a mid-size law firm discovers it is representing the buyer while a different office, in a different country, had advised the target's founder on a personal estate matter three years earlier. Nobody lied. Nobody cut corners. The founder's name was spelled differently in the two files: one used a maiden name, the other a married name with a hyphen. The firm's conflicts check, run at intake, found nothing. The engagement now faces disqualification risk, and the client relationship is damaged regardless of outcome.

This is not a rare edge case. It is the predictable result of treating conflicts checks as a form-filling exercise instead of what they actually are: an entity-resolution and data-matching problem.

Why intake forms fail

A conflicts check ("conflict of interest check") asks a simple question: does taking on this new client or matter create a duty conflict with someone the firm already represents, has represented, or is adverse to? Professional bodies like the American Bar Association (Model Rule 1.7 and 1.9) and, in the UK, the Solicitors Regulation Authority (SRA) require firms to actively identify these conflicts, not just react when they surface.

The standard workflow: an intake lawyer fills a form with client name, counterparties, and matter description. This gets run against a client database. The problem is structural, not procedural:

• Name variants. Legal entities have subsidiaries, trade names, and prior names post-merger. People have maiden names, transliterations (a Chinese or Arabic name romanized three different ways), and nicknames used in casual correspondence.
• Free-text matter descriptions. "Advised on financing" and "debt restructuring counsel" may describe the same underlying relationship but won't string-match.
• Siloed systems. Many firms, especially post-merger accounting and law firms, run separate practice management systems per office or acquired entity, so a match in London never touches a record in Singapore.
• Human judgment under time pressure. Intake lawyers scan hundreds of matches for a large firm and are incentivized to move fast, not to chase ambiguous partial matches.

None of these are "process discipline" failures. They are data qualitydata qualityThe degree to which data is fit for purpose: accurate, complete, consistent, timely, valid and unique. Poor quality data undermines analytics, reporting and AI.View full definition → and data architecture failures: bad identity resolution, unstructured text, and fragmented systems.

The data model underneath a real conflicts system

Firms that catch conflicts reliably build three linked data structures, not one client list.

1. Entity data. Every party (person or organization) gets a canonical record with a unique identifier, separate from any single matter. Corporate entities are linked to parent and subsidiary structures, often sourced from commercial registries or providers like OpenCorporates, the largest open database of company registration data. Individuals are linked to known aliases and role history (director, beneficial owner, witness).

2. Relationship data. Not just "client" but the nature of the relationship: adverse party, opposing counsel, witness, beneficial owner, guarantor. A conflict can arise from having advised someone's counterparty, not just the party itself.

3. Matter data. Structured metadata per engagement: practice area, jurisdiction, adverse parties, related entities, and a controlled vocabulary for matter type (not free text). This is what makes cross-referencing possible at scale.

The conflicts check is then a graph query, not a keyword search: does any node in the new matter's entity list connect, directly or through a subsidiary or a prior alias, to any node already in the firm's relationship graph?

A simplified matching logic

new_matter.parties = [entity_resolve(name) for name in intake_form.names]

for party in new_matter.parties:
    related = get_linked_entities(party, depth=2)  # subsidiaries, aliases, known roles
    for entity in related:
        if entity in firm_relationship_graph:
            flag_for_review(entity, relationship_type, matter_id)

The critical step is entity_resolve: matching "J. Smith-Warner" to "Jane Smith" requires fuzzy matching (edit distance, phonetic algorithms like Soundex) plus external data (corporate registries, sanctions lists, beneficial ownership registers) rather than exact string comparison. Firms increasingly license identity resolution tools built for this, similar to the "know your customer" (KYC) infrastructure banks use, adapted for legal and advisory conflict screening.

Governance and privacy constraints that shape the design

This is where conflicts data collides with privacy regulation, and professional services firms sit in an unusual spot: they must retain and cross-reference sensitive personal and commercial data specifically to comply with ethics rules, while also complying with data protection law.

• GDPR (General Data Protection Regulation, EU/UK) requires a lawful basis for processing personal data. Conflicts checking is generally justified under "legal obligation" or "legitimate interest," but firms must still document this, limit retention, and honor data subject rights carefully, since a full erasure request could itself destroy conflicts history needed for future ethics compliance. The UK Information Commissioner's Office (ICO) has guidance on this tension for regulated professions (ico.org.uk).
• Cross-border data transfer rules. A global firm running one central conflicts database must ensure client and counterparty personal data moves lawfully between jurisdictions, relevant post-Schrems II for EU-US transfers.
• Confidentiality vs. searchability. Ethical walls ("information barriers") required when a firm represents adverse interests in unrelated matters mean the conflicts system must record enough to flag a match, without exposing confidential matter details to the lawyer running the check. This is usually solved by showing a hit and a contact name for follow-up, not the underlying file.

Firms that get this wrong either over-collect (privacy risk) or under-link (missed conflict risk). The design tension is real and has no shortcut.

Practical checks and audits to run

A conflicts system is never "done." It needs recurring audits, the same way a bank audits its anti-money-laundering (AML) screening.

1. Match rate review. Sample recently closed matters and manually re-check them against the current database. Are known conflicts (deliberately planted test cases) actually surfacing? Firms should run "red team" test names, including intentional spelling variants, quarterly.

2. Entity resolution coverage audit. What percentage of client records have a resolved corporate parent, verified against a registry? Gaps here are gaps in coverage, not edge cases.

3. Latency check. How long between a new matter being opened and the conflicts check completing? A check that takes three weeks defeats its purpose at intake.

4. System silo mapping. After every merger or lateral hire (a partner moving firms, bringing a client book), confirm the acquired client list has been ingested and entity-resolved into the central system, not left in a legacy spreadsheet.

5. False positive rate. Too many low-quality matches cause "alert fatigue," where reviewers start rubber-stamping flags. Track how many flagged matches are cleared without escalation, and tune matching thresholds accordingly.

🎬 [VIDEO: "How Law Firms Use Data to Prevent Conflicts of Interest" - youtube.com - search for recent law firm technology and legal ops channels covering conflicts-check systems and entity resolution in practice]

Key Takeaways

• A missed conflict is usually a data matching failure (name variants, siloed systems, free text), not a lapse in judgment by intake staff.
• Reliable conflicts checking requires three linked data structures: canonical entity records, relationship types, and structured matter metadata, queried as a graph rather than a keyword search.