Building a Compliance Screening System for New Outbound Investment Restrictions

1. Background: From a proposed rule to a set of engineering problems

On October 24, a new version of proposed outbound investment restriction rules was released by certain countries, aiming to further expand the scope and intensity of restricted investments. In response, the relevant authorities in China stated that such measures represent a typical case of overstretching the concept of national security, discriminatorily broadening restrictions and disrupting normal economic and trade cooperation between enterprises of the two countries. China expressed serious concern and firm opposition, and urged respect for market economy principles to create a favorable environment for normal trade and investment.

For developers and enterprise architects, behind this policy news lies an engineering problem that can be solved systematically. Cross-border investment review rules are showing three clear trends: expanding coverage, increasingly granular provisions, and noticeably faster update cycles. Accordingly, the traditional model of “manually checking against lists and having legal teams review case by case” has hit bottlenecks in response speed, coverage breadth, and decision consistency. Lists are getting longer, name variations are multiplying, and ownership structures are becoming more complex. Manual review can no longer see the full picture, cannot guarantee accuracy, and struggles to prove that due diligence was actually performed.

At an abstract level, any investment review rule can ultimately be decomposed into three technical elements: identifying who is involved (investors and target entities), determining on what basis (provisions and lists), and proving how the decision was made (evidence and audit trails). Around these three elements, the goal of a compliance system is clear: every “approve” or “block” decision must be reviewable, traceable, and explainable. When new rules are issued, the system should be able to switch over in hours rather than months.

2. Why this is hard: Four core technical challenges

2.1 Entity recognition noise far exceeds intuition

The same enterprise may appear under official translated names, phonetic variants, business abbreviations, and historical names across different languages and registration systems. Meanwhile, the same business name in different jurisdictions may refer to entirely unrelated entities. Exact string matching produces massive numbers of false negatives, while simple fuzzy matching generates overwhelming false positives, causing review costs to spiral out of control. Entity recognition must answer two questions simultaneously: “Do these look similar?” and “Are they actually the same entity?”

2.2 Ownership traversal is a graph problem, not a query problem

What review rules care about is often not the direct investment target, but the beneficial owners and actual controllers behind it. Multi-layer nesting, cross-shareholding, circular ownership, and nominee arrangements turn “piercing the corporate veil” from a single database query into traversal and aggregation over a weighted graph. Making matters worse, ownership data is inherently lagging and incomplete. The system must explicitly represent uncertainty — it is better to mark a missing edge as “unknown” and route it for manual completion than to output a seemingly precise but wrong answer.

2.3 Rules are continuously evolving

During the transition from proposed rules to final rules, restricted sectors, filing thresholds, and exception clauses may all change. Already-effective rules can also be amended with transitional arrangements. The system must support rule versioning and select the applicable version based on the transaction date. Otherwise, you risk the compliance failure of “judging yesterday’s transaction with tomorrow’s rules.”

2.4 Decisions must be explainable

After a cross-border investment is blocked or flagged for filing, business teams, regulators, and internal or external auditors will all ask for justification. A “black-box score” without an evidence chain is nearly useless in compliance scenarios. The system needs to fully record the data snapshot, rule version, similarity scores, and manual review comments behind every decision, forming a closed-loop evidence chain.

3. Overall architecture: Four layers

A four-layer architecture of “data layer — algorithm layer — service layer — governance layer” is recommended:

┌─────────────────────────────────────────────────────┐
│ Service layer: synchronous screening API / batch     │
│ due diligence jobs / manual review workflow          │
├─────────────────────────────────────────────────────┤
│ Algorithm layer: entity matching engine / graph      │
│ computation engine / rule engine (versioned)         │
├─────────────────────────────────────────────────────┤
│ Data layer: sanctions lists / corporate master data /│
│ ownership relationship graph                         │
├─────────────────────────────────────────────────────┤
│ Governance layer: version management / audit logs /  │
│ feedback loops / effectiveness metrics               │
└─────────────────────────────────────────────────────┘

The data layer is responsible for collecting and standardizing three types of core data: restricted party lists and control lists, corporate master data (names, registration numbers, countries, industry codes), and ownership relationship graphs (shareholding edges, percentages, effective dates). List data follows the principle of “original sources are read-only; standardized views are built separately.” Every record retains its source and its effective and expiration dates — this is the foundation for all downstream auditability.

The algorithm layer consists of three engines: entity matching, graph computation, and rules. The three are decoupled and deployed independently so that each can iterate on its own schedule. List updates don’t require algorithm changes, rule adjustments don’t require data changes, and evolution in any one layer doesn’t drag down the others.

The service layer wraps algorithm capabilities into a synchronous screening API, batch due diligence jobs, and a manual review workflow. It integrates with investment management systems, finance middle platforms, and business frontends, exposing only unified semantics while hiding internal implementation changes.

The governance layer covers rule and model version management, audit logs, feedback loops for matched samples, and effectiveness metrics. The governance layer determines whether the system is a one-time deliverable or an asset that gets more accurate over time. It is the most easily overlooked layer in practice, yet the one that should never be omitted.

4. Key technical implementation

4.1 Entity matching: Coarse recall + multi-path precision ranking + tiered disposition

The workflow is: normalization (unify full-width/half-width characters, remove punctuation, convert between traditional and simplified Chinese, normalize case) → inverted index coarse recall → multi-path similarity precision ranking (character-level edit distance, token-level overlap, transliteration alignment) → tiered disposition by threshold.

// Illustrative pseudocode: name matching with tiered disposition
function screen(inputName):
    n = normalize(inputName)
    candidates = coarseRecall(n, invertedIndex)   // coarse recall
    best = null
    for c in candidates:
        s = max(editSimilarity(n, c.name),
                tokenJaccard(n, c.name),
                transliterationScore(n, c.name))   // transliteration/pinyin alignment
        if best == null or s > best.score:
            best = {entity: c, score: s}
    if best.score >= HIGH_THRESHOLD:
        return {action: AUTO_BLOCK,    evidence: best}
    if best.score >= MID_THRESHOLD:
        return {action: MANUAL_REVIEW, evidence: best}
    return {action: AUTO_PASS,         evidence: best}

Two key practices: First, thresholds must be set separately by list risk tier — high-risk lists should lean toward false positives rather than false negatives, while regular lists should tighten thresholds to control review volume. Second, all intermediate scores must be persisted. They serve both as input for human reviewers and as evidence for post-hoc audits.

4.2 Ownership traversal: Modeling relationships as a weighted directed graph

Nodes are entities, edges are “who holds whom” shareholding relationships, and edge weights are percentages. The computation of aggregate beneficial ownership is essentially multiplying proportions along paths, then aggregating across paths:

// Illustrative pseudocode: indirect ownership calculation
// with pruning and cycle handling
function indirectOwnership(from, to, maxDepth, minRatio):
    total = 0
    stack = [{node: from, acc: 1.0, path: []}]
    while stack not empty:
        cur = stack.pop()
        if cur.node == to:
            total = total + cur.acc        // hit target, accumulate path interest
            continue
        if length(cur.path) >= maxDepth: continue
        for e in outgoing(cur.node):
            if e.ratio < minRatio: continue     // pruning: filter low-ratio edges
            if e.to in cur.path:   continue     // cycle handling: avoid infinite loops
            stack.push({node: e.to,
                        acc:  cur.acc * e.ratio,
                        path: cur.path + [e.to]})
    return min(total, 1.0)

Three engineering considerations are essential: Set maximum traversal depth and minimum shareholding threshold for pruning, otherwise traversal costs on large graphs become uncontrollable. Use deduplication approximations for shared paths to avoid redundant computation inflating results. For control determination, beyond percentages, layer in structured fields such as voting rights arrangements and acting-in-concert agreements — these fields often come from extraction results on due diligence documents rather than public registration data.

4.3 Rule engine: Law as code

Design a declarative rule specification that expresses each rule as a quadruple of “applicable subject + triggering behavior + judgment conditions + disposition conclusion,” attached with an effective date and version number. The decision service selects the rule version by transaction date, evaluates rules sequentially, and outputs matched details.

// Illustrative pseudocode: structured rule expression and version scheduling
ruleSet v2025Q4 {
    effectiveFrom: "2025-10-24"
    rules: [
        {
            subject:  investor.profile.region in RESTRICTED_REGIONS
            behavior: outboundInvestment(target, stakeRatio, sector)
            when:     sector in SENSITIVE_SECTORS
                      and stakeRatio >= STAKE_THRESHOLD   // threshold is configurable
            then:     DECISION.REPORTABLE
            evidence: [subject, behavior, sector, stakeRatio]
        }
    ]
}
// At decision time, select the version effective on the transaction date
function decide(txn):
    version = pickRuleSet(txn.date)
    hits = [r for r in version.rules if match(r, txn)]
    return highestSeverity(hits)

Versioning is the core design decision: rules moving from “proposed” to “final and effective” should be represented as new versions rather than in-place modifications, which guarantees the reproducibility of historical decisions. All thresholds should be parameterized so that provision adjustments only require publishing a new configuration, not deploying new code.

4.4 Audit trails and effectiveness metrics

The input snapshot, rule version, similarity scores from each path, final decision, and review comments for every determination should be uniformly written to audit logs and archived in object storage, forming a tamper-evident evidence chain. At the same time, establish a feedback loop for matched and false-positive samples, and periodically measure four metrics: recall rate on high-risk lists (the floor metric — should approach 100%), overall false positive rate (determines manual review cost), average handling time per case (determines business experience), and rule-change-to-production turnaround (determines responsiveness to new regulations). The acceptance criterion for a compliance system is never “how many transactions were blocked,” but “every decision has a defensible reason.”

5. Cloud deployment: Building the foundation with general-purpose platform capabilities

A compliance screening system is fundamentally a data-intensive application and is well suited to being built directly on cloud platforms. Using Baidu AI Cloud as an example, enterprises can combine general-purpose capabilities to quickly assemble the foundation: object storage holds list snapshots and audit archives, container platforms host the matching and rule engines with elastic scaling based on business volume, message queues make batch due diligence jobs asynchronous to smooth peak loads, and log services with monitoring and alerting ensure full-path observability of the screening pipeline. For unstructured inputs such as multilingual registration documents and complex ownership agreements, general-purpose extraction and comprehension capabilities of large language models can be used to generate candidate structured fields, which are then confirmed by human reviewers before entering the system. The semi-automated “model generates, human confirms” pattern is often more reliable than full automation in compliance scenarios because it preserves a clear point of human accountability.

6. Methodological transfer: The common core of rule-driven platforms

Another piece of news from the same day offers an interesting reference point: the Southern Regional Electricity Market officially began operation, marking a new stage in the construction of China’s unified national electricity market. The electricity market and cross-border investment review may seem like entirely different domains, but their platform cores are highly consistent. Both require “identity standardization” (unique identifiers for market participants), “rule centralization” (unified expression and execution of trading and settlement rules), and “data trustworthiness” (consistent and traceable metering, filing, and settlement data). In other words, the combination of “rule engine + master data + relationship graph + audit trail” is a universal foundation for nearly all rule-driven market platforms. Once teams understand this commonality, they can support multiple types of compliance and trading businesses on the same technical stack, gaining architectural-level reuse capability.

7. Phased implementation roadmap

Phase 1 (approximately 0–3 months): Minimum viable list screening loop. Prioritize high-risk lists, connect the “submission — matching — tiering — review” chain, and solve the problem of “does screening exist at all.”

Phase 2 (approximately 3–9 months): Introduce the ownership graph and rule engine to cover new rule formats with expanded scope and granular provisions, solving the problem of “is the system accurate enough.”

Phase 3 (9 months and beyond): Platformize the system. Expose APIs and batch job capabilities externally, establish false-positive feedback loops and threshold tuning mechanisms, and solve the problem of “is the system fast enough.” Each phase should be validated against metrics to avoid building a system whose effectiveness cannot be evaluated.

8. Conclusion

The authorities emphasized in their response that overstretched security restrictions not only disrupt normal economic and trade cooperation but ultimately harm the interests of the rule-making side’s own enterprises. The consumption and investment potential of a super-large-scale market remains the bedrock of cross-border cooperation. For technical teams, the right posture is not retreat but turning compliance into infrastructure: use standardized data, versioned rules, and explainable decisions to drive down the marginal cost of compliance, allowing legitimate cross-border business to proceed smoothly through the shortest possible chain. Rules will continue to change, but the technical core of “identify entities, execute rules, preserve evidence” will not. If these three things are done solidly, the system will be ready whenever the next version of the rules arrives.