Conflicts and Independence Clearance Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does building the rule chain before the entity graph go wrong so often?

Because rules are the visible part and the entity graph is the load bearing part. A specification opens with the conflicts rules the general counsel wants applied, the approval routing, the escalation thresholds and the reviewer workbench, and party resolution appears as a line about improved searching.

Then the system goes live and reviewers see the same noise with better workflow around it. That outcome is guaranteed, because a rule chain running over unresolved names cannot be made precise no matter how well the rules are written. Your own client database holds the same entity four ways because four secretaries opened matters over fifteen years, and intake receives a trading name, a misspelling, or a group name where the actual counterparty is a subsidiary two levels down in another jurisdiction.

Build the resolution layer first. Names normalised with alias storage, parties linked to external references such as company registry numbers and legal entity identifiers where they exist, and joined to corporate family data so a hit against a subsidiary surfaces the parent and the siblings. Every party resolved once and reused, so the fourth matter for the same client does not re enter the same ambiguity. This is unglamorous data engineering and it is where accuracy actually comes from. Rules on top of it are cheap. Rules without it are theatre.

What goes wrong when you reconcile years of client and matter records?

This is the most commonly underestimated line in the whole category and it is the one that determines precision. Fifteen years of client and matter records contain entities recorded inconsistently, party roles captured as free text or not at all, matters closed without a closure date, and former clients whose relationship status nobody can now determine from the record.

The failure is that firms treat reconciliation as a data cleanup and staff it accordingly. It is not. Deciding whether a 2009 engagement created a former client duty under Rule 1.9, or whether a party was adverse or merely named, is a legal judgement that needs a lawyer's time. Assign it to a data team and you get a tidy graph full of confident errors, which is worse than an untidy one because reviewers will believe it.

Two fixes. Scope reconciliation to what the scoring model actually consumes: entity identity, relationship type, role adversity, matter status and recency, fee significance. Everything else can stay as it is. And triage by risk rather than by date, resolving your largest clients and most active practice areas first, so precision improves where volume is. Firms that have already run a cleanup, or that limit release one to one office and one practice line, move noticeably faster than those trying to model the whole partnership at once.

Why do the document and practice management integrations break after launch?

Because they are write integrations into systems that other teams own and change. A wall provisioned into iManage or NetDocuments depends on the security model in that system staying the way it was when you built against it. A matter security policy gets revised, a new workspace template is introduced, or a folder structure changes for an unrelated reason, and your provisioning call still succeeds while protecting less than it did.

Practice management breaks similarly on the finance side. Screened personnel must be excluded from matter reporting and time entry, and if that exclusion is applied at creation rather than enforced continuously, a later change to the matter team quietly reopens access.

Both failures are silent, which is what makes them dangerous. The wall exists in your conflicts database and does not exist where documents and time actually live.

The fixes are verification rather than provisioning. Run periodic attestation checks that read back the actual access state in the document and practice management systems and compare it against every wall you believe is in force, then alert on divergence. Log access attempts by screened individuals as evidence rather than only as prevention. And require any developer to name the specific document management system and version they have provisioned into, because generic integration experience does not transfer here.

What happens when a wall cannot be proven to have been in force?

A wall recorded as a status field is a policy, not a control, and the difference becomes very expensive during a disqualification motion. The question is never whether you declared the screen. It is whether it was operative on a particular date and whether any screened person accessed anything.

Firms discover the gap at the worst moment. The conflicts system shows a wall created on a date. The document management system has no corresponding restriction because provisioning was manual and someone was on leave. Acknowledgements were collected by email and two are missing. There is no access log to demonstrate the negative. Everything about the firm's conduct may have been correct and none of it is provable.

Treat the wall as an executable object. Declaring it triggers provisioning through the document and practice management interfaces, acknowledgements are collected and tracked to completion rather than requested, access attempts by screened individuals are logged, and periodic attestations run automatically. The evidence pack is generated rather than assembled. Build this in the first phase if you have ever been asked to prove a screen was operative and could not, because retrofitting evidence onto a period that has already passed is not possible.

Should you build custom or configure what you already own?

If you are a single office firm under roughly 40 fee earners with one practice area and no audit line, configure. Intapp Conflicts is the established product here and it does the core job properly: structured intake, searching firm records, workflow and approvals. Firms with straightforward practices run it successfully and we would not push anyone off it without a reason. Spend the money on intake discipline instead, which is where most of the benefit actually sits at that size.

Configure first even if you expect to build later, and for a specific reason. Precision is limited by the entity data you attach, not by the product, so improving corporate family data and reconciling your own party records will raise accuracy inside whatever you already run. If it does not, you have learned something valuable and cheaply.

Build when two or more of these are true. Reviewers are reading hundreds of hits per matter and clearance has become the bottleneck on revenue. You run audit and advisory lines under one independence regime, which is effectively two rule models over one entity graph. Rule chains vary by office, jurisdiction and practice line beyond what a packaged configuration model wants to express. You hire laterals regularly and each one is a manual confidential exercise. Or you operate through an alliance or verein structure where imputation genuinely differs across member firms.

How do hidden costs get into the quote?

Five items drive the overrun. Historical data reconciliation, described above, which needs lawyer time rather than developer time and is the line that determines whether the system is trusted. Jurisdiction and regulator count, because rule chains multiply rather than add. Having both audit and advisory lines, which means two rule models sharing one entity graph plus restricted entity list ingestion, holdings declarations and service pre approval workflows. Corporate family data licensing and integration, which is a commercial arrangement with its own cost and refresh cadence. And integration count, since a document management system, a practice or finance system, a client relationship system and an identity provider are four separate pieces of work.

Make them visible by asking for reconciliation as its own line with named lawyer days, each integration as its own line with the target system named by product and version, and corporate family data as a separate commercial item. Then ask what release one covers: one office and one practice line with intake and scoring only, walls in phase two, is a proposal that will ship. Anything broader is a proposal that will slip.

What separates a build that works from one that fails here?

The working ones score rather than search. Hits are ranked with explicit factors, meaning relationship type, matter status and recency, adversity of role, corporate proximity, practice and office overlap and fee significance, and every score is explained in plain language because a reviewer will not trust a number. Reviewers then work in confidence bands under a policy the general counsel has signed, reading the top band in full and sampling the low band. Scoring models are versioned and the system freezes what it knew at the moment of clearance, because in two years someone may ask.

The working ones also keep machine assistance away from the decision. Classifying party roles, spotting that two spellings are the same entity, extracting parties from an engagement letter or term sheet: all sensible and all reduce reviewer load. Deciding whether a conflict exists: never. The output is a ranked, evidenced queue for a human with authority.

The failing ones share one shape. Better search over the same noisy data. Reviewers see the same volume with a nicer interface, stop trusting the tool within a month, and revert to reading everything. The test before signing is to ask how a party is resolved before it is matched, and how a score is explained to a reviewer and reproduced two years later. If normalisation, aliases, external identifiers and corporate family linkage are not in the first answer, and versioned models with a frozen clearance record are not in the second, nothing else in the proposal matters.