Preface and Summary

In transactional internet platforms, fund security is the lifeline. Traditional fund-loss prevention heavily relies on manual experience and post-hoc rules, suffering from chronic issues such as low coverage, delayed response, and rule decay. This article uses the engineering practice of the Huolala AI fund-loss prevention platform as an example to detail how, through a "data flywheel + model distillation + multi-agent collaboration" architecture, annual fund losses were reduced by 99.96%, achieving a systematic leap from "manual defense" to "AI-native prevention." The article focuses on engineering implementation details, covering the construction of automated labeling pipelines, dual-modal (code/text) risk identification, anti-decay Agent design, and transaction middleware architecture upgrades, providing a reusable technical paradigm for similar businesses.

1. Breaking the Deadlock: The "Lifecycle Pain Points" of Traditional Fund-Loss Prevention

A review of the 2024 fiscal year showed that annual fund losses had climbed to the hundreds of thousands, accompanied by several real internal control failures. This was not accidental but a typical dilemma of "business racing ahead while internal controls run naked."

Our approach at the time was the same as most internet companies: business teams identified risks during the requirements phase, testing designed reconciliation rules, and R&D intercepted issues through the reconciliation system before going live. When business volume was small and changes were few, this "manual review + rule engine" system could barely hold up. But as the business iterated at high speed, the situation quickly spiraled out of control:

1. Requirements Phase: Coverage and depth were unguaranteed, relying on manual experience reviews that were highly subjective and difficult to accumulate as knowledge.

2. Development Phase: Problem discovery was severely delayed, manual code reviews were inefficient, and high-frequency changes extended the risk window.

3. Release Phase: Prevention measures were heavily post-positioned, reconciliation rule configuration was cumbersome and error-prone, and strategy adjustments lacked flexibility.

4. Maintenance Phase: Manual identification of fund losses was difficult, rules quickly became ineffective (decayed) with business iterations, and problem scenarios changed dynamically.

Faced with hundreds of thousands of daily code method changes, tens of thousands of commits, and thousands of scattered reconciliation rules, manual review simply couldn't keep up. More fatally, over one-third of reconciliation rules that had been online for more than six months had "factually failed." This was the true source of large-scale fund losses. So what to do? Fund internal controls cannot rely on "throwing more people at it"; they must evolve towards automation, intelligence, and shift-left.

2. Architecture Evolution: From Rule-Driven to AI-Native Prevention System

The platform's evolution did not happen overnight but went through two key stages:

• 1.0 Rule Exploration Phase: Based on policy rules and manual identification, solving the "presence or absence" problem, but with low recall and high maintenance costs.

• 2.0 AI Assistance Phase: Introduced deep pre-trained models to achieve automatic identification of fund-loss requirements and code, with AI beginning to intervene in the core chain.

The current platform has formed four core capability matrices: fund-loss requirement risk warning, fund-loss code risk warning, reconciliation rule validity/completeness diagnosis, and process control.

3. Core Technical Breakthroughs: Deep Integration of Algorithms and Engineering

3.1 Solving the "Labeling Desert": LLM + CoT Builds an Automated Data Flywheel

Fund-loss scenarios are characterized by extreme imbalance between positive and negative samples and highly customized business semantics. Initially, with only 2k manually labeled data points, the model's generalization ability was extremely poor. We designed an offline automated labeling pipeline:

1. Large Model Labeling: Used DeepSeek-R1 and DeepSeek-Coder-Lite, combined with CoT prompts, to perform an initial screening of 1 million unlabeled code/requirement texts.
2. Confidence Filtering: Retained only high-confidence model outputs to construct a pseudo-labeled dataset.
3. Small Model Fine-tuning: Used ModernBERT for PEFT/LoRA fine-tuning, forming a closed loop of "large model labeling → small model learning → online feedback → data backflow."

3.2 Code/Text Risk Identification: The Ultimate Cost-Effectiveness of Feature Engineering and Distillation

In the code identification scenario, we faced four major challenges: context loss (50%), missing business semantics (30%), poor model generalization (10%), and complex chain features (5%). Through 7 iterations, we settled on a high cost-effectiveness solution:

• Feature Engineering: Extracted control flow, data flow, interface links, and textual fund-loss features to construct a dual-modal input.

• Long Sequence Optimization: Introduced ModernBERT to replace traditional BERT, breaking through code length limitations and increasing recall to 83%.

• Knowledge Distillation: Using DeepSeek-Coder-Lite as Teacher and ModernBERT as Student, through joint distillation of soft and hard labels, recall exceeded 95% while maintaining extremely low inference costs.

Engineering Conclusions:

• When training data is fixed, through distillation, the effect of a small model can approach that of a large model.
• The BERT series models offer the best cost-effectiveness ratio.
• Constructing hard samples and more unlabeled data can improve model accuracy.

3.3 The Anti-Decay Challenge: Multi-Agent Adversarial and Rule Self-Maintenance

Identification 1.0 solved the problem of "can we block new requirements/new code before they go live," but it couldn't solve a bigger problem:

Are the reconciliation rules already online still effective after three months?

The answer is: Most of them have already failed.

Business chains change, database table structures change, and the semantics of counterparty interfaces change, but reconciliation rules do not automatically follow suit. This is the true source of large-scale fund losses.

We made a rough estimate: over one-third of reconciliation rules that had been online for more than six months had already "factually failed."

What to do? We built a multi-agent collaboration anti-decay system.

Overall Approach

Instead of relying on a single "omniscient" model, we let several specialized agents divide the work and cooperate:

• Surveyor (Code Analysis Agent): Understands what a piece of code does, identifying which fields, tables, interfaces, and enumeration values it involves.
• Inspector (Rule Analysis Agent): Understands what a reconciliation rule checks, comparing it against the code facts.
• Communicator (Feature Relationship Agent): Integrates code facts and rule facts into a "feature relationship graph," identifying places where "the code says one thing, the rule says another."
• Scout (Adversarial Check Agent): Performs adversarial checks on the "graph," finding areas not covered by new rules or where old rules are outdated.

These four Agents work in series, automatically discovering which rules need to be added, which need to be deleted, and which need to be modified.

Conclusions:

• Improved the efficiency of writing reconciliation rules (by 90%).
• Automatically kept online rules fresh.
• Improved the efficiency of maintaining reconciliation rule validity.
• Further expanded the guarantee scope of reconciliation rules.

4. Outlook: Towards Fully Automated Intelligent Prevention 3.0

In 2026, we will move towards "Intelligent Closed-Loop, Full-Chain Internal Control." If the 2.0 era achieved "human-machine co-defense," the goal of the 3.0 era is "autonomous driving-level" fund internal control—equipping AI with the capabilities for autonomous planning, autonomous execution, and autonomous adversarial action.

Multi-Agent Platformization

4.1 Multi-Agent Platformization: Building a "Red-Blue Adversarial" Internal Control Matrix

We will no longer rely on a single linear workflow but will build a networked collaborative matrix composed of five core Agents, achieving a closed loop from "problem discovery" to "problem resolution":

• 🔍 Identification Agent (Sentinel): Based on a multimodal large model, perceives fund risk characteristics in requirement documents and code changes in real-time, achieving millisecond-level warnings.
• 🧠 Deduction Agent (Advisor): Deeply understands the upstream and downstream dependencies of the fund chain, automatically deduces potential fund-loss paths, and generates a risk propagation graph.
• 🛡️ Maintenance Agent (Doctor): Automatically diagnoses and repairs decayed rules, comparing code semantics with rule logic to automatically output rule update suggestions.
• 🚫 Control Agent (Gendarme): Takes over the CI/CD pipeline, implementing automatic circuit breaking or interception for high-risk changes, ensuring that "sick" fund logic cannot go live.
• ⚔️ Adversarial Agent (Blue Team): Simulates hacker or abnormal user behavior, conducts red-blue adversarial drills against existing internal control rules, and proactively uncovers rule blind spots.

5. Conclusion

Fund internal control is not a pure algorithm competition but a systematic engineering effort involving data governance, model engineering, architecture design, and business understanding. Our practice shows:

• Don't blindly chase large models: Distillation + small models often offer a higher ROI in fund internal control scenarios.
• The data flywheel is the core: Automated labeling and closed-loop feedback determine the upper limit of the model.
• Anti-decay is a protracted war: Multi-agent adversarial verification is the key to maintaining the vitality of fund rules.
• Shift-left is the defense line: Embedding internal control nodes into the CI/CD pipeline is a dual engine for fund security and R&D efficiency.

AI is reshaping the boundaries of fund internal control, but the true moat is always built on solid engineering practice and reverence for fund security.