This post summarizes Arthur Keen’s technical deep-dive on the Sentries risk-intelligence system. Read the full article on Medium →
Sanctions screening is a solved problem — until it isn’t.
Every bank, defense contractor, and fintech operating in the United States runs counterparty data against the OFAC Specially Designated Nationals (SDN) list: roughly 18,500 individuals, organizations, and entities that U.S. persons are prohibited from transacting with. Compliance teams have spent years tuning these pipelines. They work well for the entities that appear on the list.
The failure mode is everything else.
The gap sanctions lists can’t close
Consider a vendor you’re about to onboard. The vendor isn’t sanctioned. Neither is its parent company, its parent’s sister company, or any of the intermediaries above them. But the owner sitting three layers up — behind a stack of clean shells — is on the SDN list, and beneficial ownership flows straight back down to your counterparty.
Your screening tool scores the vendor clean and you sign.
This is what Keen calls the Shell Game: the entire risk signal lives in the path between entities, not in any single node. A keyword screen will never find it. A graph traversal will.
What Sentries does
Sentries is a working risk-intelligence system built on ArangoDB. Rather than screening entity names against a flat list, it models the ownership, control, and family relationships between entities as a graph — then computes how risk propagates along those relationships, hop by hop.
ArangoDB is a multi-model database that stores documents, a property graph, and a semantic schema (ontology) in a single system, all queryable together. That matters here because the three ingredients of a transitive-risk calculation — entity records, relationship edges, and the rules governing how risk travels across them — normally live in three separate systems. Sentries keeps them in one query context, which means a single traversal can join all three without external application code holding the pieces together.
The result is a five-step analyst toolset: search → trace → vet → concentrate → visualize. An analyst, an auditor, and an AI agent all call the same stored queries against the same data — there is no divergence between what the human sees and what the system decided.
Why the math works
Risk propagation is path arithmetic. Each relationship type carries a propagation weight stored directly on the graph edge — 1.0 for direct ownership, 0.8 for leadership, 0.5 for family ties. The traversal walks up to three hops from a seed entity, multiplies the weights along each path it finds (think of it like multiplying probabilities along a chain of custody), and sums the contributions from any sanctioned terminals it reaches.
The output is three numbers: directRisk (is the entity itself on the SDN list?), inferredRisk (what risk flows in through connections?), and totalExposure (the sum).
For the Shell Game scenario: three ownership hops, each carrying weight 1.0, terminating on a sanctioned entity with a risk score of 1.0. The traversal returns totalExposure: 1.0. The screening tool returns zero. Both answers are arithmetically valid. Only one reflects the actual risk.
If policy changes next quarter — say, family ties should propagate 0.4 instead of 0.5 — that’s a one-line update to the edge data. No Python scoring service to redeploy. No hardcoded constant buried in application logic. The query is the engine.
Where this applies in the enterprise
The same engine, with the same five-step toolset, covers three distinct lines of business:
Defense and government vendor vetting. Whether a prime contractor’s tier-three supply chain reaches a foreign-influence concern — a connection an analyst would only find today by noticing an address overlap and pulling the thread manually. Sentries makes that thread the default output.
Financial services KYC and AML. The regulatory question in know-your-customer and anti-money laundering programs is the ultimate beneficial owner (UBO): the natural person at the end of a chain that may run through holding companies, trusts, and transliterated aliases. UBO roll-up and transitive risk are the same query with different weights on the edges. When a suspicious activity report (SAR) is filed, the traversal returns the exact path that drove the decision — the auditable chain of evidence regulators will ask for.
Counterparty and supply-chain risk. Modeling the second-order effect of a geopolitical event requires the same multi-hop traversal, with a country code as the seed rather than a sanctioned entity. The engine is identical; only the weights and seed types change.
What’s coming next
Three capabilities are on the roadmap. A propagation-weighted PageRank via ArangoDB’s Graph Analytics Engine will run continuous whole-graph risk computation in the background, keeping inferredRisk fresh across all entities rather than computing it per query. A temporal layer will enable “as of” queries — reconstructing the exact graph state that produced a vetting decision on a specific historical date, a non-negotiable requirement for audit and regulatory response. And entity resolution as a first-class ingest step will handle the OFAC list’s transliterated aliases and multi-jurisdiction duplicates, turning the synthetic demo into a production-ready system.
A sanctions list tells you who is on it. A graph tells you who is one degree removed — and underwriting decisions live in that gap.
The full technical walkthrough — including the AQL traversal query, worked examples with path arithmetic, and the architectural comparison between a multi-model approach and a split stack — is on Medium.
“Tracing Hidden Risk”
by Arthur Keen
The working system, including synthetic data and saved queries, is also available on GitHub.
