A global bank’s compliance team was responsible for tracking regulatory obligations across forty jurisdictions. Each jurisdiction produced regulations, guidance documents, enforcement actions, and consultation papers. The team maintained a library of three million documents that had accumulated over fifteen years. When a new regulation was published, the compliance team needed to answer: which existing obligations does this affect, which business units are impacted, and what controls need to change?

The answer required reading the new regulation, identifying the obligations it imposed, tracing those obligations to existing obligations in other jurisdictions that covered similar ground, and mapping the obligations to the bank’s internal control framework. For a straightforward regulation, this took two to four analyst-weeks. For a complex cross-jurisdictional regulation, it took two to three months.

The delay was not in reading the regulation. The delay was in finding the connections. A new EU directive on anti-money laundering might impose obligations that were similar to, but not identical to, existing obligations under the US Bank Secrecy Act, the UK Money Laundering Regulations, and the Singapore Payment Services Act. The connections were implicit in the text but explicit in no system. Analysts found them through experience, memory, and manual search.

Why Search Was Not Enough

The team had a document management system with full-text search. Analysts could search for “anti-money laundering” and get thousands of results. The problem was not finding documents. The problem was understanding relationships between documents.

Search returns documents that contain matching terms. It does not return the relationship between documents. An analyst searching for the impact of a new EU directive needed to know not just which documents mentioned anti-money laundering, but which documents imposed conflicting requirements, which documents were superseded by the new directive, and which documents referenced the same underlying obligation.

A document that says “report suspicious transactions within 24 hours” and another document that says “report suspicious transactions within 48 hours” are both about suspicious transaction reporting. Full-text search returns both. But the relationship between them (which jurisdiction requires 24 hours, which requires 48 hours, and whether the bank must comply with both) is not captured by search. An analyst must read both documents, understand the jurisdictions, and determine the relationship manually.

This relational gap was the bottleneck. The compliance team did not need better search. They needed a map of how obligations related to each other.

The Graph Model

A knowledge graph represents entities and the relationships between them. For regulatory compliance, the entities were obligations, documents, jurisdictions, business units, and controls. The relationships were: an obligation appears in a document, a document is issued by a jurisdiction, an obligation applies to a business unit, and a control addresses an obligation.

The graph was built in three phases. The first phase extracted obligations from documents. An obligation is a statement that requires or prohibits an action: “firms must report transactions above $10,000” or “firms must not process payments to sanctioned entities.” The extraction used a combination of rule-based parsing (identifying modal verbs like “must,” “shall,” and “required”) and a fine-tuned language model that classified sentences as obligations, definitions, guidance, or background. The model was trained on a labelled set of twelve thousand sentences that compliance analysts had annotated.

The second phase linked obligations across documents. Two obligations that imposed similar requirements were connected with a “related obligation” edge. Two obligations that imposed conflicting requirements were connected with a “conflicts with” edge. An obligation that superseded an earlier one was connected with a “supersedes” edge. The linking was performed by a semantic similarity model that compared obligation embeddings and classified the relationship type based on a training set of five thousand labelled obligation pairs.

The third phase mapped obligations to the bank’s internal control framework. Each control in the framework was linked to the obligations it addressed. A control that required suspicious transaction reporting was linked to all obligations across all jurisdictions that imposed suspicious transaction reporting requirements. This mapping revealed gaps, obligations that no control addressed, and redundancies: multiple controls addressing the same obligation.

The Impact Analysis Workflow

The graph changed the analyst workflow from search-and-read to query-and-navigate.

When a new regulation was published, the analyst uploaded the document to the extraction pipeline. The pipeline identified the obligations in the document and matched them against the graph. Within minutes, the analyst had a preliminary impact assessment: which existing obligations were related, which controls were affected, which business units were impacted, and where conflicts existed.

The preliminary assessment was never complete. The extraction system missed obligations that were expressed in unusual language. The linking system produced false positives: obligations that were superficially similar but substantively different. The control mapping had gaps because the bank’s control framework was itself incomplete. The analyst used the preliminary assessment as a starting point and refined it through manual review.

The value was in the starting point. Before the graph, an analyst started from zero and spent weeks finding connections through manual search. After the graph, an analyst started with a connected map and spent days verifying and refining it. The two-to-four analyst-weeks for a straightforward regulation dropped to three-to-five analyst-days. The two-to-three months for a cross-jurisdictional regulation dropped to two-to-three weeks.

What the Graph Could Not Do

The knowledge graph had three limitations that the compliance team learned to work around.

First, obligation extraction was noisy. The rule-based parser flagged too many sentences as obligations because regulatory text uses “must” and “shall” in contexts that are not obligations, but definitions, cross-references, and transitional provisions. The fine-tuned model reduced the noise but did not eliminate it. The extraction precision was approximately seventy-four percent, meaning roughly one in four extracted obligations was not actually an obligation. Analysts had to review and prune the extracted set, which added time but was still faster than manual extraction from scratch.

Second, relationship classification was unreliable for nuanced conflicts. The semantic similarity model could identify that two obligations were related with seventy-eight percent accuracy. It could identify that one obligation superseded another with seventy-one percent accuracy. But conflict detection was only sixty-two percent accurate because regulatory conflicts are often subtle: two obligations that appear to conflict may be reconcilable through interpretation, and two obligations that appear harmonised may conflict at the implementation level. Analysts had to verify every conflict edge manually. The graph was useful for surfacing potential conflicts that the analyst might have missed, not for confirming conflicts that the analyst already suspected.

Third, the graph required continuous maintenance. New documents were published weekly. Obligations changed as regulations were amended. Controls were updated as the bank’s risk posture evolved. The graph was only useful if it was current. The maintenance team, two full-time analysts, processed new documents on a rolling basis, with a target lag of no more than two weeks between document publication and graph update. During periods of regulatory activity (consultation periods, enforcement waves) the maintenance lag extended to four weeks, which reduced the graph’s value for those documents.

The Outcome

After twelve months, the compliance team had processed ninety-four new regulations using the graph-based workflow. The average time for impact assessment dropped from sixteen analyst-days to four analyst-days. The team identified one hundred and twelve previously unknown obligation conflicts, fourteen of which required immediate remediation because the bank was non-compliant in at least one jurisdiction without realising it.

The most valuable finding was not a specific conflict. It was a structural gap. The graph revealed that the bank’s control framework had no coverage for obligations related to digital asset custody in three jurisdictions. The compliance team had assumed that existing custody controls covered digital assets because the control descriptions did not exclude them. But the obligations in the three jurisdictions had specific requirements for digital assets (cryptographic key management, proof-of-reserves reporting, and segregation of client digital assets) that the existing controls did not address. This gap had been invisible in a search-based workflow because the relevant obligations used terminology that did not match the control descriptions.

When Knowledge Graphs Pay Off

Knowledge graphs pay off when the value is in the relationships, not the entities. If your problem is finding documents, search is sufficient. If your problem is understanding how documents relate to each other (what conflicts, what depends on what, what supersedes what) then a graph structure captures what search cannot.

The build cost is high. Obligation extraction, relationship classification, and entity mapping require labelled training data that does not exist off the shelf. The labelled data must come from domain experts, which means compliance analysts spending weeks annotating sentences instead of doing compliance work. Budget twelve to sixteen weeks for the initial build and two full-time roles for ongoing maintenance.

The payoff is proportional to the complexity of the relationship network. A firm with one jurisdiction and a hundred documents does not need a graph. A firm with forty jurisdictions and three million documents cannot function without one.