A Comprehensive Guide to Equity Look-Through: From Data Modeling to Algorithm Implementation

I. The Problem Equity Look-Through Solves

When reviewing a company’s public registration details, the listed shareholders may not be the “true owners.” In practice, shareholders can be multi-layered investment vehicles, limited partnerships, or involve cross-holdings and nominee arrangements. The ultimate rights and interests may eventually belong to a natural person who never appears on the official registry. Equity look-through refers to the analytical process of tracing shareholding relationships layer by layer until reaching terminal nodes—such as natural persons, listed companies, or state-owned entities—to reveal the actual control and beneficial ownership structure of a company.

The engineering requirement for “conducting an equity look-through on a specific natural person” is typically abstracted into two symmetrical problems:

• Forward Look-Through (Person to Enterprise): Given a natural person, identify all directly and indirectly held enterprises and their corresponding穿透 (look-through) shareholding ratios.
• Reverse Look-Through (Enterprise to Person): Given an enterprise, expand through the shareholder layers to find the ultimate natural person shareholders and their respective look-through ratios.

Both problems share the same data foundation and algorithmic core; only the traversal direction differs.

II. Typical Application Scenarios

1. Financial Compliance and AML: KYC (Know Your Customer) and UBO (Ultimate Beneficial Owner) identification are foundational requirements for Anti-Money Laundering (AML) regulations. Most jurisdictions commonly use a threshold (often 25%, subject to local regulations) for a natural person’s shareholding to trigger identification. Institutions must possess automated look-through capabilities to enforce this rule during every customer onboarding process.

2. Investment and Financing Due Diligence: Prior to investment, it is necessary to identify hidden control relationships, nominee suspicions, and conflicts of interest regarding founders’ external investments. Reviewing only the top layer of shareholders can easily miss actual control achieved through multi-tiered structures, leading to inaccuracies in valuation and transaction terms.

3. Group Risk Management: Identifying related-party transactions, guarantee circles, and the transmission paths of capital chain risks requires a look-through equity graph as a foundation. Multiple seemingly independent companies might belong to the same natural person after look-through, bringing associated risks to the surface.

4. Judicial Execution and Asset Investigation: Identifying equity-based property clues of an executed party during enforcement proceedings, or determining whether shareholder capital contribution liabilities can be appended, relies heavily on the results of forward look-through.

III. Data Modeling: Turning Equity Relationships into a Graph

Equity data naturally forms a directed, weighted graph: shareholders point to invested enterprises, and the weight on the edge represents the shareholding ratio. Before modeling, it is essential to define two core entity types and two core relationship types:

• Entities: Natural persons, enterprises (which can be subdivided into companies, partnerships, institutions, etc.).
• Relationships: Shareholding (with ratio, paid-in capital, time, status) and appointments (legal representative, directors, supervisors, senior management).

Using relational storage as an example, the schematic table structure is as follows:

CREATE TABLE entity (
    entity_id    VARCHAR(64)  PRIMARY KEY,  -- Unified Social Credit Code for enterprises; ID hash for natural persons
    entity_type  VARCHAR(16)  NOT NULL,     -- person / company / partnership
    name         VARCHAR(128) NOT NULL,
    status       VARCHAR(16)                -- active / revoked / liquidating
);
CREATE TABLE shareholding (
    shareholder_id VARCHAR(64)  NOT NULL,   -- Shareholder, referencing entity
    company_id     VARCHAR(64)  NOT NULL,   -- Invested enterprise, referencing entity
    ratio          DECIMAL(10,8) NOT NULL,  -- Shareholding ratio, value between 0 and 1
    paid_in_amt    DECIMAL(20,4),           -- Paid-in capital amount
    start_date     DATE,
    end_date     DATE,                    -- Expiration date, NULL for current state
    status         VARCHAR(16)              -- valid / pledged / frozen
);

Three modeling key points deserve emphasis: First, enterprise primary keys should use unified registration codes rather than names—since the same enterprise might have different name spellings across various data sources, anchoring on the code allows for entity resolution. Second, natural persons cannot naturally obtain a globally unique identifier; in engineering, a composite fingerprint using “name + ID hash” is common, ensuring uniqueness while avoiding plaintext storage of sensitive information. Third, equity relationships are time-sensitive, with capital increases, transfers, and cancellations occurring at any time. It is recommended to use dual-track storage for “historical snapshots + current state,” explicitly declaring the point-in-time basis when conducting look-through analysis.

IV. Core Algorithms: Traversal, Ratio Calculation, and Cycle Detection

4.1 Path Discovery

Whether for forward or reverse look-through, the first step is graph traversal. Depth-First Search (DFS) is suitable for collecting all paths completely; Breadth-First Search (BFS) expands layer by layer, better aligning with manual, tier-by-tier verification habits. Real equity structures usually do not exceed five or six layers, but financial holding groups occasionally feature a dozen layers of nesting. Therefore, the depth limit is generally relaxed to 10 layers as a safeguard.

4.2 Indirect Shareholding Ratio: Multiply then Sum

The industry-standard calculation formula is: the look-through ratio on a single path equals the product of the shareholding ratios of each edge on that path; the total indirect shareholding ratio equals the sum of the products across all acyclic paths. For example: if Natural Person A holds 70% of Company M, and M holds 40% of Company N, A’s look-through ratio for N is 0.7×0.4=28%. If A also indirectly holds N via another Company P (A holds 50% of P, P holds 10% of N), the total look-through ratio is 28%+5%=33%.

Two points require clarification: First, “full-path summation” may double-count equity in certain cross-holding structures. A rigorous approach pairs this with an “acyclic path” constraint and annotates the calculation methodology in the results. Second, “equity look-through” and “control look-through” are distinct chains—the general partner of a partnership might secure control with a very low capital contribution. Control relies on voting rights and contractual arrangements, while equity relies on capital contribution shares. Freezing the definition of these methodologies (subscribed vs. paid-in, full-path vs. optimal-path, equity vs. control) with business and legal teams before launch is critical to avoiding subsequent disputes.

4.3 Cycle Detection: Preventing Traversal Runaway

Cross-holdings create cycles in the graph, which, if unhandled, lead to infinite recursion. A combination of three constraints provides a safety net:

• Path-level Acyclic: No duplicate nodes are allowed on a single path (using a visited set for deduplication).
• Depth Limit: Default cap at 10 layers.
• Ratio Pruning: The product of shareholding ratios decays rapidly (0.5 to the 10th power is roughly one-thousandth). Traversal stops when dropping below a threshold—this pruning often compresses the search space by several orders of magnitude.

4.4 Recursive SQL Implementation

This can be implemented in mainstream relational databases supporting recursive CTEs (schematic SQL; array-related syntax varies by database dialect):

WITH RECURSIVE equity_path AS (
    -- Base case: Target natural person's direct shareholding
    SELECT s.shareholder_id,
           s.company_id,
           s.ratio AS cum_ratio,
           ARRAY[s.shareholder_id, s.company_id] AS path_nodes,
           1 AS depth
    FROM shareholding s
    WHERE s.shareholder_id = :person_id AND s.status = 'valid'
    UNION ALL
    -- Recursive step: Continue look-through along shareholding relationships
    SELECT p.shareholder_id,
           s.company_id,
           p.cum_ratio * s.ratio,
           p.path_nodes || s.company_id,
           p.depth + 1
    FROM equity_path p
    JOIN shareholding s
      ON s.shareholder_id = p.company_id AND s.status = 'valid'
    WHERE p.depth < 10                          -- Depth limit
      AND p.cum_ratio * s.ratio >= 0.0001       -- Ratio pruning
      AND NOT s.company_id = ANY(p.path_nodes)  -- Path acyclicity
)
SELECT e.name,
       p.path_nodes AS equity_chain,
       p.cum_ratio  AS look_through_ratio
FROM equity_path p
JOIN entity e ON e.entity_id = p.company_id
WHERE e.entity_type = 'person'                 -- Keep only paths reaching a natural person
ORDER BY p.cum_ratio DESC;

4.5 Python Implementation

from collections import defaultdict
def build_graph(rows):
    """rows: [(shareholder_id, company_id, ratio), ...]"""
    g = defaultdict(list)
    for sh, co, ratio in rows:
        g[sh].append((co, ratio))
    return g
def penetrate(graph, start, is_terminal,
              max_depth=10, min_ratio=1e-4):
    """
    Returns the look-through ratio of `start` to each terminal node (sum of products across all paths).
    is_terminal: Business-defined terminal node judging function,
                 e.g., natural person / listed company / state-owned entity.
    """
    result = defaultdict(float)
    def dfs(node, ratio, depth, visited):
        if is_terminal(node):
            result[node] += ratio
            return                      # Terminal node stops further traversal
        if depth >= max_depth or ratio < min_ratio:
            return                      # Dual pruning on depth and ratio
        for nxt, r in graph.get(node, ()):
            if nxt in visited:          # Cycle detection
                continue
            dfs(nxt, ratio * r, depth + 1, visited | {nxt})
    dfs(start, 1.0, 0, {start})
    return dict(result)

V. Key Challenges in Engineering Implementation

5.1 Data Quality is the First Hurdle

• Entity Resolution: The same enterprise often has varying name spellings across registrations, annual reports, and announcements, requiring resolution via unified codes. Homonym issues for natural persons are trickier, requiring composite fingerprints plus contextual features (registration location, industry, timeline) to assist disambiguation.
• Timeliness: Equity changes frequently; the further data is from the current point in time, the lower its reliability. Retain effective and expiration dates upon data ingestion, enabling point-in-time retrospective look-through results.
• Source Grading: The credibility of public registration data is higher than that of listed company announcements and annual reports, which in turn is higher than news and public opinion. Tag different sources with confidence levels so downstream processes can filter as needed.

5.2 Performance Optimization

When entity scales reach tens of millions and shareholding relationships reach hundreds of millions of edges, multi-hop self-joins in relational databases become a bottleneck. Common optimization methods include: the pruning trio (depth, ratio, acyclicity) to compress the search space; offline materialization and caching for high-frequency query targets, with incremental refreshing of affected chains upon equity changes; a more thorough solution is migrating to a graph database, utilizing adjacency storage to accelerate multi-hop traversal. Cloud providers generally offer graph database, knowledge graph, and large model platform capabilities (such as Baidu AI Cloud). During technology selection, evaluate based on data scale and the team’s tech stack to avoid over-engineering.

5.3 Consistency of Calculation Methodologies

The same “look-through ratio” can vary drastically across different systems, often due not to the algorithm but to the calculation methodology: subscribed vs. paid-in, how direct and indirect are merged, full-path summation vs. optimal path, and how GP/LP partnerships are converted. It is recommended to document these definitions and include them in the data dictionary, routing any methodology changes through a review process.

5.4 Privacy and Compliance

Natural person equity information falls under the category of personal data and should adhere to the principle of minimum necessity when processed: queries should only be made for compliance purposes (customer due diligence, risk control reviews, etc.); sensitive fields like ID numbers should be hashed or desensitized, with display layers masked according to permissions; data sources must be legitimate, utilizing public channels and authorized data, as data from unknown origins poses legal risks.

VI. Intelligent Enhancements: Letting Machines Read Clues Beyond Structured Data

Structured registration data is merely the skeleton of an equity graph; a massive amount of clues are hidden in unstructured text like announcements, prospectuses, court documents, and news reports. This is why Large Language Model (LLM) technology has rapidly penetrated this field in recent years:

1. Unstructured Extraction: Using LLMs to extract “entity—shareholding ratio—target” triplets from text and fuse them into the graph, turning “a sentence in an announcement” into “an edge in the graph.” Extraction accuracy directly determines data quality, and LLM versions iterate quickly, with different versions showing significant performance differences on extraction tasks—it is recommended to conduct small-scale blind tests on your own equity corpus before finalizing a model, rather than relying solely on public benchmark scores.
2. Entity Disambiguation: Distinguishing between enterprises or natural persons with the same name can be achieved by combining contextual semantic features for matching scores. The model handles semantic similarity, while rules handle hard constraints (code consistency, regional consistency).
3. Event-Driven Updates: Automatically triggering local graph updates and risk warnings after events like equity freezes, auctions, or changes, upgrading static look-through into dynamic monitoring.

A more robust engineering architecture consists of three lines of defense: LLMs handle extraction, rule engines handle format and logic validation (ratio ranges, entity legitimacy), and manual proportional sampling acts as a safety net, keeping model uncertainty within business-acceptable limits.

VII. Conclusion

On the surface, equity look-through is simply “checking down the shareholder list.” Once engineered, however, it is a comprehensive system encompassing data modeling, graph algorithms, data governance, methodology management, and privacy compliance. Solidifying entity resolution, implementing pruning and caching correctly, and clearly defining methodologies and compliance are what transform look-through results from “reference information” into “reliable decision-making evidence.” For most teams, a pragmatic and risk-controlled evolution path is to first run the business using recursive queries on a relational database, and then evolve to graph databases and intelligent extraction as data scale dictates.