Ownership Lens: Using a Graph Database to Uncover Offshore Shell Company Networks

Title

Ownership Lens: Using a Graph Database to Uncover Offshore Shell Company Networks

Meta Description

Ownership Lens is a FalkorDB hackathon project that uses multi-hop graph traversal to penetrate offshore shell company networks, combining typed MCP tools, a deterministic rules engine, and an anti-hallucination verification layer to deliver an auditable compliance investigation agent.

Article Content

Investigating offshore shell companies has always been tricky: a company registered in Samoa or Panama, with complete-looking paperwork and a clear director address, appears flawless in isolation. But if you treat companies, directors, intermediaries, and addresses as a network of relationships, risk signals often hide in the connections—a seemingly clean company may be only four hops away from an entity on a compliance watchlist. This is exactly the problem the hackathon project Ownership Lens tries to solve.

The Problem: Clean Records Don't Equal Safety

Ownership Lens was built by a developer and entered the Graph Hacks hackathon co-hosted by WeMakeDevs and FalkorDB. The project uses a concrete case to illustrate the limits of shallow queries: the target company GLAISDALE LIMITED, in an investigation at depth 1, showed no direct connection to the watchlist entity DOM Limited, and the system returned "clear."

But when the investigation depth was extended to 4 hops, a hidden chain emerged: GLAISDALE LIMITED → Rachel Erickson → NEWCOMBE LIMITED → ANDREW MORAY STUART → DOM Limited. This chain links a shared director network through OFFICER_OF relationships, triggering the WATCHLIST_PATH rule, with a path cost of 4.0, below the threshold of 8.0, ultimately escalating the verdict to "escalate."

The company record itself did not change—what changed was the scope of the investigation. This confirms the project's core insight: risk indicators live in the relationships between entities, not in the entities themselves.

Data and Graph Architecture: Real Offshore Records

To avoid theorizing on toy data, Ownership Lens uses a real subset of the ICIJ Offshore Leaks database, covering the Samoa and Seychelles jurisdictions from the Panama Papers. The dataset contains 51,940 nodes (entities, officers, intermediaries, addresses) and 58,891 relationships, occupying 40.91 MiB of memory in FalkorDB—within its cloud service's free-tier limit of 100 MiB.

The graph model defines relationship types such as REGISTERED_ADDRESS, OFFICER_OF, and INTERMEDIARY_OF. The project particularly emphasizes: being included in the ICIJ database does not constitute evidence of wrongdoing, so the system only reports exposure indicators requiring human review, rather than automatic accusations.

Why FalkorDB Is the Architectural Core

The project does not treat the graph database as a decorative layer—graph traversal and graph algorithms directly participate in the investigation itself. Beyond pathfinding, Ownership Lens also builds an isolated in-memory temporary graph for each investigation, running multiple algorithms on a local k-hop subgraph:

• Label propagation and weakly connected components: determine whether the target belongs to the same structural community as a watchlist entity, corresponding to the COMMUNITY_WATCHLIST rule. Community membership is only an investigative lead, not proof of shared ownership or wrongdoing.
• Betweenness centrality: identify potential "gatekeeper" intermediaries lying on multiple shortest paths, corresponding to the CENTRALITY_SPIKE rule.
• PageRank: discover company hubs with prominent structural influence in the network, corresponding to the PAGERANK_ANOMALY rule.

These algorithms supplement network-structural signals that simple path queries tend to miss. The project also ran a degree-matched control test on 30 randomly sampled shell companies, none of which were connected to DOM Limited, providing a reference for the observed topology.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024 to standardize how large language models interact with external tools and data sources. Under the MCP framework, the application layer wraps callable capabilities as "tools," each declaring a name, parameter structure, and return type; the model can only select from the registered tool list and fill in parameters, rather than freely constructing arbitrary queries or calls. This design decouples "what the model can do" from "what the model wants to do": database connections, query syntax, and permission control are all managed by the application layer, with the model acting only as a decision and orchestration layer. For compliance scenarios requiring auditability, the value of MCP lies in the fact that every tool call can be logged, replayed, and verified, thereby avoiding the unpredictable traversals and prompt injection risks brought by freely generated queries.

Betweenness Centrality measures how frequently a node appears on the shortest paths between other pairs of nodes in the network. The higher the value, the more the node serves as a "bridge" or "bottleneck" in the network—many connections must pass through it. In offshore company investigations, intermediaries or officers with high betweenness centrality may be key nodes connecting multiple seemingly unrelated entities—potential "gatekeepers." Complementary to this, PageRank evaluates node importance through iterative propagation: the more important nodes point to a node, the higher its own score. In ownership graphs, companies with high PageRank are often structural hubs, potentially concentrating large numbers of equity or director relationships. Both reflect only topology and do not directly equate to risk, so the project treats them as investigative leads rather than grounds for judgment.

Three Architectural Decisions Ensure Agent Reliability

Letting an agent explore a graph is one thing; making the results verifiable and auditable is another. The project addresses the latter through three design decisions.

Typed MCP Tools Instead of Freely Generated Cypher

A common approach is to let the LLM dynamically generate Cypher queries, but the project deliberately does not. The LLM never writes raw Cypher; instead, it selects from six typed, parameterized, read-only MCP tools: resolve_entity, ownership_chain, shared_links, path_between, cluster_view, and recall_cases. The application layer owns database queries, and the model is only responsible for selecting an approved tool and interpreting structured results. This reduces the risk of the model inventing relationship types, triggering expensive traversals, or expanding the prompt injection attack surface, and it also makes the investigation process more auditable.

Deterministic Rules Engine for Final Verdicts

Compliance verdicts should not be made by a language model based on free-text interpretation. In Ownership Lens, conclusions come entirely from the deterministic Python rules layer in core/rules.py. The flow is: MCP tools retrieve evidence, which is normalized into a structured evidence ledger; the rules engine evaluates it against thresholds; and the application layer assigns one of four verdicts—clear, review, escalate, or insufficient_evidence. The LLM is only responsible for generating an explanatory memo based on the investigation results.

Rule signals include officer degree ≥5, same community as a watchlist entity, watchlist path cost ≤8.0, and structural anomalies identified by graph algorithms, with thresholds calibrated based on empirical percentiles of the dataset. The project explicitly states: clear only means no qualifying indicators were found within the configured rules and search scope; it does not guarantee the entity is risk-free.

Evidence ledger is the data structure used in the project to record all structured evidence retrieved in each investigation. Entities, relationships, paths, and algorithm results returned by MCP tools are normalized into a unified format and written to the ledger; both the rules engine and the verification layer read only the ledger contents. This design separates "data retrieval" from "judgment": the rules engine's input is deterministic structured data rather than model-generated text; and the verification layer can compare, item by item, whether every name in the memo actually appears in the ledger. The evidence ledger also serves as an audit trail, allowing every verdict to be traced back to specific tool calls and return results.

Anti-Hallucination Verification Layer

Even if the LLM is only asked to write a memo, it may introduce details not present in the evidence—a single fabricated officer name or address is enough to ruin a correct investigation. core/verifier.py compares every named entity, officer, and address in the memo against the original tool output for that investigation. If unverified names are found, the system discards the memo and instead generates a deterministic template directly from the evidence ledger. The principle is simple: claims unsupported by evidence do not make it into the final memo.

Model Benchmarking and Reliability

A restricted tool interface is only valuable if the model can reliably select tools. The project benchmarked multiple models using hosted NVIDIA endpoints across 10 standardized tool-calling scenarios, deploying nvidia/llama-3.3-nemotron-super-49b-v1.5. Across three multi-turn investigation runs, the system passed 15/15 verdict fidelity checks. The project also implements a deterministic fallback loop so the investigation flow does not depend entirely on successful model calls, including handling rate limits. The team also candidly acknowledges that these are results from its own evaluation environment, not a claim of universal model accuracy, and that testing covering more entities, edge cases, and adversarial inputs is needed before production deployment.

Running Locally and Next Steps

The project can launch its full stack via Docker Compose, including FalkorDB, a browser UI, and a FastAPI application. After cloning the repository and configuring .env, run docker compose up -d to access an interactive Cytoscape graph canvas at localhost:8000 and compare results at depth 1 and depth 4.

Next steps include expanding the evaluation dataset, testing more adversarial and ambiguous cases, improving graph metric calibration, and strengthening the audit trail for individual rule decisions. The team emphasizes that any real deployment requires human oversight, independent verification, and appropriate governance before it can support consequential compliance decisions. The goal is not to automatically label companies as suspicious, but to help investigators discover connections, understand evidence, and decide what warrants further scrutiny.

Developers interested in graph databases, AI agents, fraud detection, and anti-money laundering can view the full code on GitHub and reproduce it locally.

One-line Summary

Ownership Lens uses a graph database and a constrained AI agent to uncover hidden risk chains among offshore shell companies within four-hop relationships.

Paragraph Summary

Ownership Lens is a Graph Hacks hackathon project aimed at solving the problem that "clean records don't equal safety" in offshore shell company investigations. The project uses a real subset of the ICIJ Offshore Leaks data (about 52,000 nodes and 59,000 relationships) to build an ownership graph on FalkorDB, using multi-hop traversal and graph algorithms such as label propagation, betweenness centrality, and PageRank to uncover watchlist connections missed by single-hop queries. Architecturally, the LLM does not generate raw Cypher but instead selects from six typed, read-only MCP tools; a deterministic Python rules engine makes clear/review/escalate/insufficient_evidence verdicts; and the LLM only generates memos that must pass item-by-item evidence verification, otherwise falling back to a template. The project is positioned as an investigative-assistance prototype, outputting exposure indicators that require human review.