Equity Tracing: From Business Registration Data to Knowledge Graphs

1. What is Equity Tracing: From a Single Entity to a Control Chain

Equity tracing essentially involves tracing layer by layer along an equity relationship graph to answer two classic questions: Who ultimately controls an enterprise (tracing upwards to natural persons or ultimate controllers), and what enterprises does a natural person or institution ultimately hold indirectly, and what is the total aggregated equity (tracing downwards to the ultimate beneficiary enterprises).

In modern business societies, corporate structures are highly nested, and direct shareholders are often just the “tip of the iceberg.” Therefore, equity tracing is a rigid requirement in multiple scenarios:

• Account Opening Review and Anti-Money Laundering (AML): Identifying the actual controllers and beneficial owners behind accounts.
• Credit and Investment Due Diligence: Assessing whether hidden high-risk affiliated parties exist behind counterparties.
• Tender Qualification Review: Verifying whether implicit associations exist among multiple bidding enterprises.
• Group Management: Sorting out the scope of consolidated financial statements and related transaction lists.
• Risk Transmission Analysis: Evaluating the impact scope along the shareholding network after a subject encounters risks.

The difficulties are equally obvious: deep hierarchies, cross-holdings and circular shareholdings, hidden arrangements such as proxy holdings and concerted actions that cannot be directly observed from registration data, scattered data with delayed updates, and severe interference from entities with identical names. This determines that equity tracing is not a simple “table lookup” problem, but a complete data engineering pipeline.

2. Data Foundation: Structured Registration Data + Unstructured Text

Equity tracing is fundamentally a data problem; the “graph” is merely the computational form. Data quality determines the reliability of conclusions.

1. Structured Data: Shareholder and investment information in business registrations (shareholder name, type, subscribed ratio), key personnel appointments, branch institutions, and historical change records form the backbone of the knowledge graph.
2. Unstructured Data: Announcements, annual reports, legal documents, and news reports often contain key signals such as proxy holding arrangements, concerted action agreements, and voting rights delegation. These must undergo information extraction before being stored in the database.
3. Entity Alignment: Enterprises use unified social credit codes as primary keys, but normalization of former names and historical names must be handled. The issue of identical names for natural persons is more challenging, requiring cross-validation using auxiliary signals such as employment relationships, geographic locations, and masked ID numbers; otherwise, two separate companies might be incorrectly “merged” into one entity.
4. Time Series and Versioning: Equity changes have effective timestamps, and different sources may conflict at the same point in time. Conflict detection and timeline-based version management are required to support audit needs for “tracing back to a specific date.”

In practice, Natural Language Processing (NLP) and even Large Language Models (LLMs) can be introduced to assist with extraction and normalization. However, extraction results must undergo rule validation and manual review to prevent dirty data from entering the graph and being amplified layer by layer.

3. Graph Modeling: Turning Equity Relationships into Computable Structures

The mainstream approach adopts the property graph model:

• Nodes: Enterprises, natural persons. Properties include name, unified social credit code, entity type, operating status, etc.
• Edges: Holding shares (core property is the shareholding ratio, supplemented by investment method, direct/indirect indicator, data source, and timestamp), serving as a director/executive (legal representative, director, executive), branching (headquarters and branches).

For storage selection, a tiered approach can be considered: in small to medium-scale scenarios, relational databases combined with recursive queries are sufficient and have low maintenance costs; in large-scale, multi-hop, high-concurrency scenarios, graph databases or graph computing engines are more suitable. These capabilities are mostly offered as general product categories by mainstream cloud vendors (such as graph databases, object storage, message queues, logging services, monitoring and alerting, etc.) and can be combined as needed without building a full infrastructure from scratch.

An illustrative graph structure is as follows (pseudocode):

Node: Company{uscc, name, status}
Node: Person{id, name, masked_cert_no}
Edge: HoldShare{src, dst, ratio, since, source}
Edge: ServeAs{src, dst, position}

4. Core Algorithms: Multi-Layer Tracing, Weighted Equity, and Cycle Handling

1. Traversal Strategy. Breadth-First Search (BFS) is suitable for visualization scenarios that expand layer by layer; Depth-First Search (DFS) is suitable for enumerating all paths between two entities. Both must set maximum depths and pruning rules to prevent loss of control on giant group structures.

2. Weighted Equity Calculation. Multiply the shareholding ratios along a single path, and sum the ratios across multiple paths to obtain the effective shareholding ratio of A to B. This aligns with the financial concept of “direct shareholding + indirect shareholding.”

3. Cycle Handling. Cross-holdings create cycles. A “visited set for the current path” must be used for deduplication; otherwise, the recursion will never terminate.

4. Super Nodes. Subsidiaries of large groups can number in the thousands, making full expansion highly costly. Techniques such as subgraph pruning, on-demand drill-down, and hot subgraph caching are required.

Illustrative code (Python-style pseudocode with cycle detection):

def effective_ratio(graph, start, target, visited=None):
    """Calculate the weighted shareholding ratio from start to target: sum of path products with cycle protection"""
    if visited is None:
        visited = {start}
    if start == target:
        return 1.0
    total = 0.0
    for child, ratio in graph.get(start, []):
        if child in visited:          # Cycle protection: do not re-enter a node in the same path
            continue
        total += ratio * effective_ratio(graph, child, target, visited | {child})
    return total

Equivalent semantics can also be implemented in relational databases using recursive CTEs (illustrative):

WITH RECURSIVE path AS (
    SELECT parent_id, ratio, 1 AS depth
    FROM equity_edge WHERE company_id = :start
  UNION ALL
    SELECT e.parent_id, p.ratio * e.ratio, p.depth + 1
    FROM equity_edge e
    JOIN path p ON e.company_id = p.parent_id
    WHERE p.depth < :max_depth
)
SELECT parent_id, SUM(ratio) AS effective_ratio
FROM path GROUP BY parent_id;

Note that recursive CTEs do not inherently provide cycle protection. You must additionally exclude visited nodes in the join condition or strictly limit the maximum depth.

5. Ultimate Controller Determination: Ratio is Just the Starting Point, Control is the Conclusion

• Threshold Rules: An aggregated voting right or shareholding ratio exceeding a certain threshold (e.g., 50%) is typically considered absolute control.
• Qualitative Rules: The largest shareholder combined with board seats, concerted action agreements, voting rights delegation, or actual dominance can also constitute control.
• Configurable Criteria: Regulatory identification (such as beneficial owner identification) and business analysis metrics differ. The rule engine should support flexible configuration and parallel output of multiple metrics.
• Explainability: Any “ultimate controller” conclusion must be accompanied by a path evidence chain, supporting step-by-step review. Unexplainable conclusions are unusable in compliance scenarios.

6. Engineering Challenges: Performance, Updates, and Presentation

1. Performance: Deep tracing is a typical multi-hop query. Common strategies include limiting depth, extracting subgraphs before calculation, pre-calculating common metrics for hot entities, and using asynchronous tasks with progress feedback.
2. Incremental Updates: Use business registration change events as triggers for incremental graph updates to avoid frequent full rebuilds.
3. Visualization: Hierarchical layout, key path highlighting, and layer-by-layer drill-down interactions. The frontend should only present the “conclusion + evidence path” rather than throwing a full graph of tens of thousands of nodes at the user.
4. Compliance and Security: Use only legally public data, desensitize natural person shareholder information, classify query permissions, and maintain a complete audit trail of operations.

7. When LLMs Meet Equity Tracing: New Trends and Clear Boundaries

LLMs bring two practical benefits to this field: first, unstructured information extraction, identifying signals like equity changes, proxy holding clues, and concerted action arrangements from announcements, annual reports, and legal documents to compensate for the lag in structured registration data; second, natural language interaction, using the knowledge graph as a factual foundation to allow users to query “Who is the actual controller of this company?” in a single sentence and automatically generate analysis summaries—this is the Graph-Augmented Generation paradigm currently discussed in the industry.

However, the boundaries are equally clear: shareholding ratio calculation and ultimate controller determination are strong factual reasoning tasks that must be completed by deterministic algorithms. LLMs are only responsible for extraction, translation, and summarization, and their outputs must trace back to specific nodes and edges in the graph. Otherwise, a single hallucination could allow an incorrect equity conclusion to flow into risk control decisions, resulting in an extremely high cost.

8. Implementation Recommendations

Define criteria before writing algorithms: tracing depth, control thresholds, and time baselines must be aligned with business and compliance teams in advance. Data quality takes priority over algorithmic sophistication; entity alignment errors will distort all downstream conclusions. Conclusions must be explainable, traceable, and auditable. It is recommended to start with a single high-value scenario (such as account opening review) and expand horizontally after closing the loop. The value of equity tracing lies not in “how many layers are traced,” but in providing an evidence chain for every trace that can withstand scrutiny.