Fraud Detection Through Entity Chain Reasoning

A wire transfer from your client to Alpha Corp for $50,000. Your compliance system checks Alpha Corp against the sanctions list, finds nothing, and clears the transaction. Six months later, you're in front of a regulator explaining why you processed a payment to an entity that was four hops away from a sanctioned person. The fine is seven figures. The enforcement action is public. And the worst part: the information was sitting in your own data the whole time. Corporate registries, ownership filings, KYC records, all spread across databases that nobody had connected.

Alpha Corp is a subsidiary of Beta LLC. Beta LLC is 60% owned by Gamma Holding. And Gamma Holding is 80% controlled by someone on a sanctions list. No single record in that chain looks suspicious. The risk only becomes visible when you follow the ownership path end to end, computing effective control at every hop.

A simple sanctions-list lookup checks the direct counterparty against a list. That catches the obvious cases. It completely misses the layered structures that sophisticated actors actually use.

Why per-transaction rules miss this

Standard fraud detection checks fields on individual transactions: amount thresholds, jurisdiction flags, direct sanctions matches. These catch the obvious cases. But the layered ownership structures that sophisticated actors use are invisible at the single-transaction level.

The problem is structural. The risk isn't in any single record. It's in the path through a network of entity relationships. And that path might span multiple registries and databases.

The information exists across separate registries: corporate records, ownership filings, sanctions lists. No single database contains the complete picture. You have to follow the chain.

How InputLayer traces these chains

In InputLayer, you model entity relationships as facts: "Person X owns 80% of Company Y." "Company A is a subsidiary of Company B." These facts come from corporate registries, ownership databases, and KYC records, data you probably already collect.

Then you define the compliance logic as a rule: "An entity has sanctions exposure if it's directly sanctioned, or if it's owned (above a threshold) by an entity that has sanctions exposure."

That second clause is recursive, meaning it keeps repeating itself, following the chain as deep as it goes. At every level, it checks whether the owner has sanctions exposure. If the owner does, whether directly or through its own ownership chain, the exposure flows down.

Here's what the engine does when it evaluates this rule against our example:

The engine didn't just check the direct counterparty. It walked the full ownership and control chain, evaluated the sanctions exposure rule at every level, and passed the result back down. All automatically, from a single rule definition.

And this works for chains of any depth. Five layers of shell companies? No problem. Ten intermediaries? The engine follows the chain until there's nowhere left to go.

Beneficial ownership: the same pattern, different question

Regulators worldwide are tightening beneficial ownership requirements. The core question is: who are the natural persons that ultimately own or control this entity?

The computation is surprisingly similar to sanctions screening, with one twist: you need to multiply ownership percentages through the layers.

Effective beneficial ownership of Person X in Company B: 80% x 60% = 48%. If your regulatory threshold is 25%, Person X is a beneficial owner of Company B even though they don't own it directly.

Add more layers, and the math compounds:

Effective ownership: 80% x 60% x 70% = 33.6%. Still above 25%. Person X is a beneficial owner of Company C.

InputLayer handles the multiplication and passes ownership percentages through any number of layers. Define a threshold, and the engine identifies every natural person who qualifies as a beneficial owner for every entity in your graph.

Structuring detection: connecting related entities

Beyond direct sanctions, you need to detect structuring, where large transactions are split into smaller ones to avoid reporting thresholds. The standard approach checks individual transactions against the $10,000 threshold. Sophisticated actors split transactions across related entities to stay below it.

Each individual transaction is below $10,000. But the entities are related through common ownership, and their combined transactions to the same target exceed the threshold.

InputLayer identifies these relationships automatically by following chains of ownership. It determines which entities are connected, aggregates their transactions within a time window, and fires an alert when the combined total exceeds the threshold. The "related entity" determination is itself a chain walk. Entity A and Entity C might be connected through multiple intermediate layers.

What happens when facts change

This is where the knowledge graph approach becomes especially valuable for compliance. Entity relationships change constantly. Companies are acquired. Ownership stakes are transferred. New sanctions designations are published. Old ones are lifted.

When you add a new sanctions designation, say Gamma Holding's owner gets added to the list, InputLayer picks up the change instantly. It identifies every entity in that person's ownership chain, evaluates whether the ownership thresholds are met, and flags the affected transactions. On a graph with thousands of entities, this takes milliseconds.

The reverse is equally important. When someone is removed from a sanctions list, all the downstream flags that were derived through their ownership chain clear automatically. No manual cleanup, no stale alerts clogging up your queue. And if an entity had sanctions exposure through multiple paths (e.g., owned by two sanctioned individuals), removing one designation correctly preserves the remaining exposure.

Getting started

If you're working on compliance, sanctions screening, or transaction monitoring, this approach to entity chain reasoning is worth exploring.

docker run -p 8080:8080 ghcr.io/inputlayer/inputlayer

The quickstart guide gets you running in about 5 minutes. The recursion documentation covers the chain-following reasoning that powers entity chain traversal.