Beneficial Ownership Data After CTA: Building a Reusable KYC/UBO Graph Regardless of the Federal Rule

The Corporate Transparency Act’s domestic exemption did not delete beneficial ownership from your obligations. It moved one filing off one desk and left the harder problem — knowing who actually controls the entities you bank — exactly where it was.

A lot of firms read the March 2025 news as a reprieve. FinCEN’s interim final rule, issued on 21 March 2025, exempted entities created in the United States and their US beneficial owners from reporting beneficial ownership information, and narrowed the definition of a “reporting company” to foreign entities registered to do business in a US State or tribal jurisdiction. Then, on 13 February 2026, FinCEN granted exceptive relief loosening the Customer Due Diligence rule’s requirement to re-verify beneficial owners at every new account opening. Two swings of the pendulum in under a year. If you built your ownership data around either the filing regime or the old verification cadence, you built on sand.

The durable point is this: whatever the CTA does or does not require you to file, you still have to know who owns and controls your customers. That obligation lives in the CDD rule, in sanctions law, and in your own onboarding risk appetite — none of which the CTA exemption touched. The right response is not a compliance project tied to one rule. It is an architecture: model ownership once, resolve it properly, and serve every downstream consumer from the same resolved structure.

Why a table cannot hold this

Most KYC systems store beneficial ownership as a flat attribute on the customer record: a list of names, a percentage, a copied passport. That model works until ownership passes through another company, which is to say it works for sole traders and nothing else. Real ownership is a directed graph. An individual owns a holding company, which owns two intermediate entities, which between them own the operating company you are onboarding. The individual’s effective stake is the sum, across every path, of the products of the percentages along each path. You cannot express that in a column.

The 25% ownership prong under 31 CFR 1010.230 — the individuals who own or control 25% or more of a legal entity customer, plus one individual with significant control — is trivial to check when ownership is direct and genuinely hard when it is layered. A shareholder holding 15% directly and another 15% through a subsidiary crosses the threshold, but only if your system multiplies down the layers and adds across the branches. A flat model silently misses that person. That is not a data-quality nuisance; it is an undetected beneficial owner, which is the exact failure the rule exists to prevent.

Model the graph once

The model is small and it is the same for every use case. Two node types: a party that is a natural person, and a party that is a legal entity. One weighted edge: ownership, carrying a percentage. Control relationships that are not equity — a director, a trustee, a person with a power of attorney — are a second, unweighted edge type on the same nodes. That is the whole schema. Everything else is a query.

Because ownership is stored as a graph, resolving ultimate beneficial owners becomes a traversal that multiplies stakes along each path and aggregates across paths. In a property graph the query is short and, importantly, the threshold is a parameter rather than a hard-coded assumption — which matters when the same firm has to answer the FinCEN 25% question and, for an EU affiliate, the threshold under AMLD6 from the same data.

// Neo4j / Cypher — resolve ultimate beneficial owners of a target entity.
// Nodes: (:Party {id, kind})  where kind IN ['individual','entity']
// Edges: (:Party)-[:OWNS {pct}]->(:Party)   pct is a fraction, e.g. 0.15

MATCH path = (owner:Party {kind:'individual'})-[:OWNS*1..12]->(target:Party {id:$targetId})
WITH owner, target,
     // multiply the percentages down each ownership layer
     reduce(share = 1.0, r IN relationships(path) | share * r.pct) AS pathShare
// add the person's stake across every distinct path to the target
WITH owner, sum(pathShare) AS effectiveOwnership
WHERE effectiveOwnership >= $threshold          // 0.25 for the CDD rule
RETURN owner.id                AS beneficialOwner,
       round(effectiveOwnership * 100, 2) AS ownershipPct
ORDER BY ownershipPct DESC;

Bound the path depth (here, twelve layers) so a circular holding structure cannot loop forever, and log any target where a cycle is detected — circularity is itself a risk signal worth surfacing to an analyst.

One graph, three consumers

The reason to build this as a capability rather than a KYC feature is that three different obligations read the same structure differently, and each is cheap once the graph exists.

CDD and onboarding ask the 25%-plus-control question above and want the answer at account opening. Sanctions screening asks a different question of the same edges: OFAC’s 50 Percent Rule treats an entity as blocked when one or more blocked persons own it in aggregate at 50% or more, directly or indirectly. That is the identical path-product-and-sum traversal with the threshold set to 0.50 and the leaf nodes matched against the SDN list rather than returned as owners. Ongoing AML monitoring asks the graph what changed: a new intermediate owner, a stake crossing a threshold, a director added. If ownership lived in three separate systems, you would reconcile three answers and defend the differences to an examiner. If it lives in one graph, there is one answer and three lenses over it.

Reconciling the sources

The graph is only as trustworthy as what feeds it, and the feeds disagree. A customer’s self-certification, a corporate registry extract, a commercial data provider and — where accessible — a public beneficial ownership register will each assert ownership facts, and they will not always match. The discipline is to store the source, the date and the confidence on every edge, never to overwrite one source with another. When the registry says 30% and the customer says 20%, you want both edges present, flagged as conflicting, and a rule that surfaces the discrepancy rather than quietly picking a winner. The mechanics of pulling from official registers — access models, APIs, interconnection — are a project in themselves; I have written separately on beneficial ownership registers after the CJEU ruling, and the access picture there is still moving.

This provenance layer is where the data-lineage discipline earns its place. An examiner asking how you concluded that a particular individual is a 26% beneficial owner wants to see the paths, the source of each edge and the date it was verified — not a percentage in a box with no history behind it.

Who should build this now

Banks and money services businesses already carry the CDD obligation and gain the most immediate return. Fintechs onboarding business customers, and investment advisers now inside the BSA/AML perimeter under the FinCEN investment adviser AML rule, are building their programmes from a cleaner sheet and should model ownership as a graph from day one rather than inherit the flat-table debt everyone else is unwinding.

The CTA will keep moving — exemptions, reinstatements, litigation, state-level registers filling the federal gap. None of that changes what you owe your risk function, which is a defensible answer to who controls this customer. Build the answer as a capability, and the next rule change is a parameter you tune, not a system you rebuild.