# 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.
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:
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.Voir la définition complète → and data architecture failures: bad identity resolution, unstructured text, and fragmented systems.
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 metadatametadataDonnées sur les données, informations décrivant le contexte, la structure, la provenance et les caractéristiques d'un asset de données (auteur, date, format, source, définition). 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?
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.
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.
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.
Vérification des acquis
1. In the cross-border acquisition example, why did the firm's conflicts check fail to catch the conflict even though no one acted negligently?
2. What is the core argument for reframing conflicts checks as a 'data problem' rather than a 'form'?
3. Why do free-text matter descriptions like 'advised on financing' versus 'debt restructuring counsel' pose a risk in conflicts checking?
4. Select ALL correct answers about sources of name-variant problems that undermine conflicts checks.
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers about why siloed systems (e.g., post-merger firms with separate practice management systems) increase conflicts risk.
Sélectionnez toutes les réponses correctes.
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]