Technical Logic and Data Engineering in Corporate Equity Tracing

I. Core Problems of Equity Tracing

On the surface, equity tracing is about “looking up shareholders.” In essence, it aims to answer three types of questions:

1. Control relationships: Who ultimately controls a company, how long is the control path, and which entities are involved in the middle?
2. Risk transmission: When an anomaly occurs at a certain node, along which equity paths will the risk propagate to other companies?
3. Association identification: Do two seemingly unrelated companies form implicit associations through multiple layers of equity relationships?

The technical implementations for these three types of problems are not entirely the same. Control relationships focus more on “largest shareholder,” “actual controller,” and “voting rights ratio.” Risk transmission focuses on “the product of multi-level ownership ratios” and “the impact radius of anomalous nodes.” Association identification is more akin to “shortest path” and “connected components” problems in graph computing. Understanding these differences is crucial for designing appropriate data structures, rather than forcing all requirements into a single wide table.

II. Basic Approaches to Equity Data Modeling

The raw data for equity tracing typically comes from business registration information. Core fields include the unified entity ID, unified shareholder ID, shareholding ratio, subscribed amount, investment method, and registration date. At the storage layer, there are generally two modeling approaches.

Relational modeling is suitable for scenarios with moderate data volumes and fixed query patterns. An equity relationship table can be designed as follows:

CREATE TABLE equity_relation (
    id              BIGINT PRIMARY KEY,
    subject_id      VARCHAR(32) NOT NULL,  -- Invested entity
    shareholder_id  VARCHAR(32) NOT NULL,  -- Shareholder entity
    ratio           DECIMAL(10, 6),        -- Shareholding ratio, between 0 and 1
    invest_amount   DECIMAL(18, 2),        -- Subscribed amount
    relation_type   TINYINT DEFAULT 1,     -- 1: Direct holding 2: Suspected actual control
    created_at      DATETIME
);

The benefit of this modeling approach is its simplicity and intuitiveness, making it easy to perform single-level queries and statistics. However, when tracing requires five, ten, or more layers, the recursive SQL queries become complex, and computational efficiency drops significantly as the depth increases. Particularly in cases of circular or cross-shareholding, the termination conditions for recursion require special design to prevent infinite loops or path explosions.

Graph modeling is more suitable for multi-level tracing and complex association analysis. Companies and individuals are uniformly abstracted as “nodes,” and shareholding relationships are abstracted as “edges,” with the edges carrying attributes like shareholding ratio. The graph structure natively supports “breadth-first or depth-first traversal from a given starting point” and easily expresses the path semantics of “A indirectly holding C through B.”

In practice, many teams adopt a hybrid approach: raw data resides in a relational database, while an offline task constructs a graph data replica for deep-link queries and association analysis. This retains the convenience of data governance while leveraging the expressive power of graph traversal for complex relationships.

III. Basic Framework of the Tracing Algorithm

A typical implementation of equity tracing is a “depth-limited breadth-first traversal.” The pseudocode is as follows:

Input: starting entity start_id, maximum depth max_depth
Output: set of equity paths originating from start_id
queue = [(start_id, 0)]
visited = set()
result_set = []
while queue is not empty:
    current_id, depth = queue.pop(0)
    if depth >= max_depth:
        continue
    direct_shareholders = query_direct_holdings(current_id)
    for shareholder in direct_shareholders:
        ratio = shareholder.ratio
        record_path: current_id -> shareholder
        result_set.append(current_id, shareholder, depth + 1, ratio)
        if shareholder not in visited:
            visited.add(shareholder)
            queue.append((shareholder, depth + 1))

This framework is simple, but several details must be handled in a production environment.

The calculation of indirect shareholding ratios cannot be done by simple addition. If A holds 60% of B, and B holds 50% of C, then A’s indirect holding ratio in C should be 60% × 50% = 30%. In multi-level paths, the product must be calculated segment by segment. If multiple paths exist—for example, A directly holds C and also indirectly holds C through B—the “calculated ratios” of each path must be aggregated according to business rules. Common aggregation methods in business include taking the maximum value, summing them up, or weighting by actual control relationships. Different regulatory definitions of “actual control” vary, so the aggregation logic should be made configurable during technical implementation, rather than hardcoded into the algorithm.

Circular and cross-shareholding are the scenarios most prone to errors in tracing. For example, A holds B, B holds C, and C holds A. Without access control, the traversal will never end. Common practices include:

• Recording the “set of ancestors on the current path” at each node. If the next-hop node already exists in the current path, it is identified as a cycle, and that branch stops expanding.
• Alternatively, deduplicating in a global visited set, though this may lose some legitimate paths and requires a trade-off based on business needs.

A more refined approach is to use “path-sensitive” traversal, where visited is not global but independent for each path. This preserves multiple visits to the same node via different paths while avoiding infinite recursion caused by cycles. The trade-off is an increase in computation, which must be controlled using maximum depth limits and heuristic pruning.

IV. Hierarchy Determination and Ultimate Beneficial Owner Calculation

A common output of equity tracing is an “equity tree” or “equity hierarchy table.” The calculation of the Ultimate Beneficial Owner (UBO) generally follows these rules:

1. Traverse upwards layer by layer starting from the target company.
2. Individual nodes directly enter the beneficiary candidate pool.
3. Non-individual nodes continue to be traversed upwards until the maximum depth is reached.
4. For each individual, aggregate the shareholding ratios of all their paths.
5. Filter the final beneficial owners based on a predefined threshold (e.g., 25%).

The difficulty here lies in the “aggregation” criteria. If an individual directly holds 20% of the target company and indirectly holds 10% through a holding company, does the total reach 30% and exceed the threshold? This depends on regulatory or compliance definitions. Technically, the “aggregation function” can be abstracted to support strategies like summation, maximum value, or actual-control weighting, determined by parameters passed from the business layer.

Another easily overlooked issue is “shareholder type.” In registration data, shareholders can be corporate entities, individuals, partnerships, public institutions, or social organizations. Different node types have different traversal termination conditions. For example, individuals are typically terminal nodes, while partnerships may need to be further traversed to their partners in certain scenarios. The data model should preserve a node type field, and the traversal logic should decide whether to continue expansion based on this type.

V. Visualization and Interaction Design

Visualizing equity tracing is not simply “drawing a tree.” Real-world equity structures frequently feature multi-layer branching, multi-path convergence, and cross-shareholding. Drawing them directly often results in a tangled “hairball” of crossing lines.

Common optimization methods include:

• Hierarchical layout: Arrange nodes from top to bottom by level to reduce visual clutter.
• Collapsing intermediate nodes: Collapse intermediate entities with shareholding ratios below a threshold into small nodes or aggregated blocks, expanding only the critical paths.
• Path highlighting: When a user selects a UBO, highlight the related paths and dim other unrelated nodes.
• Dynamic expansion: Show only three to five layers by default, and expand deeper layers on demand when the user clicks a node.

At the interaction level, an equity tracing tool should also support “reverse tracing.” Forward tracing answers “who controls this company,” while reverse tracing answers “who does this company invest in.” Combining “forward + reverse” forms a complete association network.

VI. Data Quality and Engineering Challenges

The results of equity tracing rely heavily on the completeness and timeliness of business registration data. Common issues in actual engineering include:

• The same entity having inconsistent names in new and old data, preventing nodes from linking.
• Missing shareholder names or empty unified IDs, requiring fuzzy name matching.
• Untimely synchronization of historical change records, rendering shareholding ratios obsolete.
• Scattered registration locations for overseas entities and intermediate companies in multi-tier structures, making data acquisition varying in difficulty.

Solving these issues requires establishing an entity normalization process. The core idea is to prioritize linking via unified IDs. When IDs are missing, use rule matching based on “name + region + establishment time.” Data that cannot be reliably matched should be flagged as low-confidence and excluded from the final tracing calculations. The data governance pipeline typically involves cleaning, deduplication, entity alignment, version management, and quality validation, with trade-offs made between data scale and accuracy at each step.

Furthermore, equity data and graph computation tasks should be layered between offline and online environments. The offline layer is responsible for constructing the full graph, updating equity relationships, and calculating common actual control paths. The online layer handles only queries and interactive displays, avoiding large-scale graph computation tasks. This keeps response times within acceptable limits and prevents online services from being dragged down by complex tracing requests.

VII. Typical Application Scenarios

Equity tracing is most widely used in risk identification. For example, during supplier onboarding or customer credit approval, a company needs to determine whether a counterparty has implicit associations with high-risk entities. In this case, one can trace upwards from the target company for several layers and match the resulting shareholders and suspected actual controllers against a risk list. The matched paths represent risk transmission chains, which can be further evaluated for risk severity using shareholding ratios and depth.

In corporate group relationship management, equity tracing identifies “the set of entities under the same actual controller.” These entities might be legally independent but belong to the same group from a control perspective. This tracing capability is foundational for related-party transaction identification, audit tracking, and concentration analysis.

Additionally, in data governance and compliance scenarios, companies can use equity tracing results as part of their metadata to build “corporate relationship graph” products. Users can input a company name to view its shareholder hierarchy, outward investments, and actual controller information, combining this with other public data for comprehensive judgment.

VIII. Engineering Implementation Recommendations

For technical teams looking to build equity tracing capabilities in-house, the following steps are recommended:

1. Define business criteria first: Parameters such as maximum depth, aggregation method, whether partnerships are treated as terminal nodes, and UBO thresholds should be finalized before system implementation.
2. Build a graph data model: Abstract companies and shareholders uniformly as nodes, with shareholding relationships as edges carrying attributes like ratio, type, and time.
3. Implement configurable traversal algorithms: Support forward tracing, reverse tracing, and multi-origin association queries, as well as path-sensitive cycle detection.
4. Establish a data update pipeline: Regularly sync business registration changes, update equity relationship versions, and retain historical snapshots.
5. Design front-end interaction around “explainability”: Beyond just displaying the graph, provide path details, ratio calculation processes, and confidence notes so business users can review the results.

The technical barrier to equity tracing lies not in any single algorithm, but in how data, graph computing, business rules, and interactive visualization are organized into a cohesive whole. Only when tracing results are explainable, auditable, and configurable can they truly serve risk identification and association analysis, rather than just remaining a visually appealing diagram.