Building Ownership Lens: How Connected Data Solves the Offshore Shell Company Puzzle

_

Track 1: Agents That Act on Connected Data — WeMakeDevs × FalkorDB Graph Hacks Hackathon

What if a company that looks completely legitimate in a database is only four connections away from an entity on a compliance watchlist?

That’s the problem we set out to solve with Ownership Lens.

Offshore corporate structures can be incredibly difficult to investigate. A company registered in Samoa, Panama, or the British Virgin Islands might have a registered agent, a mailing address, and a corporate director. Look at that company in isolation, and nothing might seem suspicious.

But the bigger picture can tell a very different story.

A director might be associated with multiple companies. Those companies might share intermediaries or ownership connections. Follow those relationships far enough, and an apparently ordinary company could be connected to an entity that warrants further compliance investigation.

Traditional SQL queries often struggle to make these multi-hop relationships intuitive to investigate.

Ownership Lens is an autonomous graph investigation agent that uses FalkorDB, MCP tool calling, deterministic compliance rules, and evidence verification to uncover these hidden connections.

In this post, I'll walk through the dataset, the graph architecture, the decisions that make the agent reliable, and how you can run it locally.

🚀 The Problem: A Clean Record Doesn't Tell the Whole Story
Imagine investigating an offshore company called GLAISDALE LIMITED.

At the first level of investigation, you find five standard corporate filings and no direct connection to a company on your compliance watchlist.

The result looks clean.

Now expand the investigation to four relationship hops.

Suddenly, a chain of shared directorships connects the company to DOM Limited, an entity included in our demo watchlist.

Nothing about the original company record necessarily changed. What changed was the scope of the investigation.

This is the fundamental insight behind Ownership Lens:

Risk indicators often live in the relationships between entities, not in the entities themselves.

Instead of treating every company as an isolated database row, we model the corporate ecosystem as a graph and investigate how entities connect.

📊 The Dataset: Real-World Offshore Records
We didn't want to build a graph agent that only works on a synthetic toy dataset.

Ownership Lens uses an empirical subset of the ICIJ Offshore Leaks Database, covering the Panama Papers records for the Samoa and Seychelles jurisdictions.

The dataset contains:

51,940 nodes representing entities, officers, intermediaries, and addresses.
58,891 relationships connecting those records.
40.91 MiB RAM footprint in FalkorDB, within the 100 MiB free-tier limit of FalkorDB Cloud used for this deployment.
The graph models relationships such as:

REGISTERED_ADDRESS — connections between entities and registered addresses.
OFFICER_OF — relationships between officers and companies.
INTERMEDIARY_OF — relationships involving intermediaries.
These connections allow us to investigate corporate structures that would otherwise require multiple queries and considerable manual analysis.

A crucial caveat: inclusion in the ICIJ database is not evidence of wrongdoing or illegal activity. Ownership Lens therefore reports exposure indicators requiring human review, rather than automatically accusing entities of misconduct.

🕸️ Why FalkorDB Is at the Center of the Architecture
A graph database shouldn't just be a decorative layer around an application that could run equally well on a relational database.

In Ownership Lens, graph traversal and graph algorithms are core to the investigation itself.

1. The Depth 1 vs. Depth 4 Experiment Let's return to our example.

The target company is GLAISDALE LIMITED (Node ID: 10024477), and the demo watchlist includes DOM Limited (Node ID: 10189122).

At depth 1

The investigation finds no direct connection between the two companies.

The agent returns:

clear

The explanation is straightforward: no exposure indicators were found within the configured one-hop investigation depth.

At depth 4

The investigation expands across four relationship hops and discovers this chain:

GLAISDALE LIMITED → Rachel Erickson → NEWCOMBE LIMITED → ANDREW MORAY STUART → DOM Limited

The actual traversal follows the OFFICER_OF relationships encoded in the graph, exposing a chain of shared corporate directorships.

The deterministic rules engine detects the watchlist connection and triggers:

WATCHLIST_PATH

The path cost is 4.0, below the configured threshold of 8.0, so the verdict escalates to:

escalate

The important difference is not that the company suddenly became suspicious. It's that the deeper investigation uncovered additional evidence.

We also ran degree-matched control tests on 30 randomly selected shell companies. None connected to DOM Limited in those tests. This provides a useful comparison for the observed topology, although it does not establish the absence of risk in other companies or prove wrongdoing.

Why This Matters
A shallow query can tell you whether two entities have a direct relationship.

A graph traversal can reveal whether they are connected through a chain of officers, companies, and intermediaries.

That distinction matters in anti-money laundering (AML), know-your-customer (KYC), and corporate due diligence workflows, where indirect relationships can be just as important to investigate as direct ones.

1. Graph Algorithms on an Isolated Scratch Graph Ownership Lens doesn't stop at finding paths.

For an investigation, it constructs an isolated in-memory scratch graph representing the relevant local k-hop subnetwork. It then applies graph algorithms to identify additional structural signals.

Here's how we use them:

algo.labelPropagation and algo.WCC

These algorithms help analyze community structure and connectivity. Ownership Lens uses the resulting evidence to evaluate whether a target belongs to the same connected component or structural community as a watchlisted entity.

The corresponding rule is:

COMMUNITY_WATCHLIST

Community membership is a lead for investigation, not proof of common ownership or wrongdoing.

algo.betweenness

Betweenness centrality helps identify nodes that sit on many shortest paths through a network.

In a corporate graph, this can reveal potential gatekeeper intermediaries whose position makes them important to understanding how different parts of the network connect.

The corresponding rule is:

CENTRALITY_SPIKE

algo.pageRank

PageRank helps identify structurally influential nodes in the network.

Ownership Lens uses these scores to investigate potentially significant corporate hubs and intermediary networks.

The corresponding rule is:

PAGERANK_ANOMALY

These algorithms complement path-based investigation by highlighting network structures that a simple direct-relationship query might miss.

1. Persistent Graph Memory Through Case Nodes An investigation shouldn't disappear as soon as the user closes the browser.

Every completed investigation creates a (:Case) node in FalkorDB, connected to relevant entities and evidence through [:ABOUT] and [:CITED] relationships.

When a future investigation involves related entities, the recall_cases(entity_id) tool can retrieve earlier findings and evidence ledgers.

This gives Ownership Lens a form of persistent graph memory.

Instead of treating every investigation as an entirely new problem, the agent can reuse previously recorded evidence and case context.

🏗️ Three Architectural Decisions That Make the Agent Reliable
Building an agent that can explore a graph is one challenge.

Building one that produces verifiable, auditable results is another.

We made three key architectural decisions to address the second challenge.

1. Typed MCP Tools Instead of Free-Form Cypher A common approach to building graph agents is to let an LLM generate Cypher queries dynamically.

That can be flexible, but it introduces several risks:

The model may invent relationship types or properties that don't exist.
Poorly constructed queries may cause expensive traversals or timeouts.
Unrestricted query generation increases the attack surface for prompt injection.
Debugging and reproducing investigations becomes harder.
Ownership Lens takes a different approach.

The LLM never writes raw Cypher.

Instead, it selects from six typed, parameterized, read-only tools implemented using the Python MCP SDK:

resolve_entity(query) — resolves a user-provided name or query to an entity.
ownership_chain(entity_id, max_depth) — explores corporate and officer relationships.
shared_links(entity_id, max_depth) — identifies shared connections.
path_between(source_id, target_id, max_depth) — searches for connections between two entities.
cluster_view(entity_id, max_depth) — examines the surrounding graph structure.
recall_cases(entity_id) — retrieves previously recorded investigations.
The application owns the database queries. The model chooses which approved tool to call and interprets the structured results.

This separation improves control over query behavior and makes the investigation process easier to audit.

It also means tool selection can be benchmarked independently of the compliance rules.

1. A Deterministic Rules Engine Makes the Final Decision We didn't want a language model to make an unauditable compliance decision based on a free-form explanation.

Instead, the verdict comes exclusively from a deterministic Python rules layer in core/rules.py.

The process looks like this:

MCP tools retrieve evidence from FalkorDB.
Tool outputs are normalized into a structured evidence ledger.
The rules engine evaluates the evidence against configured thresholds.
The application assigns a verdict.
The LLM generates an explanatory memo grounded in the investigation results.
The rules use signals such as:

Officer degree greater than or equal to 5.
Community co-membership with a watchlisted entity.
Watchlist path cost less than or equal to 8.0.
Structural anomalies identified by graph algorithms.
The thresholds are calibrated against empirical dataset percentiles and configured rule criteria.

The rules engine produces one of four verdicts:

Verdict Meaning
clear No configured exposure indicators were found within the investigation scope.
review Evidence warrants additional human examination.
escalate A configured high-priority indicator, such as a qualifying watchlist path, was detected.
insufficient_evidence Available evidence is inadequate to support a reliable determination.
These verdicts are produced by the rules layer, not selected by the LLM.

This distinction is important: a clear result means no qualifying indicator was found under the configured rules and search scope. It does not guarantee that an entity is risk-free.

1. An Anti-Hallucination Verification Layer Even when an LLM is only asked to write an explanatory memo, it can introduce details that weren't present in the evidence.

A fabricated officer name or address could undermine an otherwise correct investigation.

To address this, we implemented a verifier in core/verifier.py.

The verifier checks every named entity, officer, and address in the generated memo against the raw tool output from that exact investigation.

If the memo includes an unverified name, the system discards it and generates a deterministic template memo directly from the evidence ledger.

The principle is simple:

If the evidence doesn't support the statement, the statement doesn't make it into the final memo.

This creates a useful separation between evidence collection, decision-making, and natural-language explanation.

The graph provides the evidence. The rules engine determines the verdict. The verifier checks the explanation.

🧪 Model Benchmarking and Reliability
A constrained tool interface is only useful if the model can select the right tools reliably.

We benchmarked multiple models through a hosted NVIDIA endpoint using 10 standardized tool-calling scenarios.

We deployed:

nvidia/llama-3.3-nemotron-super-49b-v1.5

In our live evaluation, the system achieved 15/15 verdict-fidelity checks across three multi-turn investigation runs.

We also implemented a deterministic fallback loop to keep the investigation workflow from depending entirely on successful model calls, including situations involving rate limits.

These are results from our own evaluation setup, not a claim of universal model accuracy. Broader testing across more entities, edge cases, and adversarial inputs would be needed before using the system in a production compliance workflow.

🔄 Putting It All Together
Here's the high-level investigation flow:

A user enters a company name in the Ownership Lens interface.
The agent resolves the entity using a typed MCP tool.
It traverses the FalkorDB graph to investigate ownership relationships, shared connections, and potential watchlist paths.
Graph algorithms analyze the relevant local subnetwork.
The evidence is collected in a structured ledger.
The deterministic rules engine assigns the verdict.
The LLM produces an explanatory memo.
The verifier checks the memo against the retrieved evidence.
The application stores the completed case in FalkorDB for future investigations.
The result is an agent that can explore connected data without giving up control over how evidence is evaluated.

💻 Run Ownership Lens Locally
Want to explore the graph yourself?

You can launch the full stack, including FalkorDB, the browser interface, and the FastAPI application, using Docker Compose.

Prerequisites
Git
Docker
Docker Compose
Installation
Clone the repository:

git clone https://github.com/GoDxVictoryRR/ACD-Agent.git
cd ACD-Agent
Create your environment configuration:

cp .env.example .env
Configure the required environment variables according to the project's setup instructions.

Start the application:

docker compose up -d
Open the application in your browser:

http://localhost:8000

You can then investigate offshore entities, compare depth 1 and depth 4 results, and explore the relationships in the interactive Cytoscape graph canvas.

For the latest setup requirements and configuration details, check the repository's README.

🔗 GitHub repository: https://github.com/GoDxVictoryRR/ACD-Agent

💡 What We Learned
Building Ownership Lens reinforced a few lessons about developing agents that act on connected data.

1. Graph traversal changes the investigation.

An entity that looks isolated in a shallow query can have meaningful connections several hops away. The depth 1 vs. depth 4 experiment makes that difference concrete.

1. An LLM doesn't need unrestricted database access to be useful.

Typed MCP tools let the model plan an investigation while keeping database access within controlled boundaries.

1. Compliance decisions should be reproducible.

Separating the deterministic rules engine from the LLM makes it easier to explain why a verdict was assigned and which evidence triggered it.

1. Explanations need their own verification.

A correct verdict can still be undermined by a fabricated detail in the accompanying memo. Checking generated claims against retrieved evidence is therefore an essential part of the system.

1. Graph memory makes investigations reusable.

Persisting case nodes allows future investigations to retrieve relevant historical evidence rather than starting from scratch every time.

🔮 What's Next?
Ownership Lens is a demonstration of how graph-native agents can help investigate complex corporate networks.

The next steps include expanding the evaluation dataset, testing more adversarial and ambiguous cases, improving the calibration of graph-based indicators, and strengthening the audit trail around individual rule decisions.

Most importantly, any real-world deployment would need human oversight, independent validation, and appropriate governance before its outputs could be used to support consequential compliance decisions.

The goal isn't to automatically label companies as suspicious.

It's to help investigators discover connections, understand the evidence behind them, and decide what deserves a closer look.

🙌 Final Thoughts
Ownership Lens was built for Track 1: Agents That Act on Connected Data at the WeMakeDevs × FalkorDB Graph Hacks Hackathon.

The project combines graph-native investigation, constrained tool calling, deterministic decision-making, and evidence verification into a single workflow.

For us, the most important takeaway is this:

The real power of a graph agent isn't just finding connections. It's finding them in a way that people can inspect, verify, and trust.

If you're working on graph databases, AI agents, fraud detection, AML, or connected-data applications, we'd love for you to check out the project.

⭐ Explore the code: https://github.com/GoDxVictoryRR/ACD-Agent

Let us know what you'd build with a graph-native investigation agent!

Disclaimer: Ownership Lens is an investigative prototype. Its outputs are exposure indicators for human review, not determinations of wrongdoing. Inclusion in the ICIJ Offshore Leaks Database does not, by itself, imply illegal conduct.
_