深度解析风控系统中的“自成交”识别：从算法原理到工程实践

作者： /

在任何高频交易场景，如股票、期货或数字货币交易所中，“自成交”（Wash Trade）或称“刷量”，都是一个必须被正视的幽灵。它通过制造虚假的交易繁荣来扭曲市场信号，误导投资者，甚至成为市场操纵和金融犯罪的温床。本文旨在为中高级工程师和技术负责人提供一个完整的自成交识别系统构建蓝图。我们将从图论、概率数据结构等计算机科学基础原理出发，深入探讨一个集实时流计算、离线图分析和实体识别于一体的工业级风控系统的架构设计、核心实现、性能权衡与演进路径。

现象与问题背景

自成交，其最简单的形式是一个实体同时扮演买方和卖方，与自身达成交易，从而在不产生实际经济损益（除手续费外）的情况下增加交易量。这种行为在早期不受监管的市场中尤为猖獗。其核心动机包括：

  • 制造流动性假象：高交易量能吸引真实的用户和做市商，尤其对于新成立的交易所或新上市的交易对而言，这是冷启动的“灰色”手段。
  • 操纵市场价格：通过连续的、小额的自成交，可以逐步推高或压低价格，形成虚假的趋势，诱导其他交易者跟风，为后续的“收割”做准备。

    • * 获得排名优势：许多行情数据平台以交易量对交易所进行排名，高排名能带来巨大的品牌曝光和流量。

  • 触发特定事件：某些衍生品合约或质押借贷协议的触发条件与交易量或价格有关，自成交可被用于恶意触发这些清算或结算事件。

然而，识别自成交远非检查“买方账户ID是否等于卖方账户ID”这么简单。成熟的操纵者会使用极其复杂的手段来规避检测，这正是技术挑战所在：

  • 账户网络化：操纵者会注册大量账户（俗称“马甲”），通过 A->B, B->C, C->A 这样的环路交易来隐藏自成交的本质。
  • IP 与设备伪装：使用代理IP池、云服务器、以及虚拟设备环境来掩盖所有账户来自同一实体控制的事实。

    • * 时间与金额分散：将大额交易拆分为大量小额交易，并在时间上拉长分布，使其在统计上更接近真实用户的随机行为。

  • 混合真实交易：在大量的自成交行为中，混入与真实用户的交易，进一步增加噪声，干扰检测模型。

因此，一个有效的自成交识别系统，必须能够超越单点、单账户的视角，从账户关联、行为序列和资金网络等多个维度进行综合研判，这本质上是一个结合了大数据处理、图计算和模式识别的复杂工程问题。

关键原理拆解

作为架构师，我们必须将复杂的业务问题映射到稳固的计算机科学基础之上。自成交识别的核心，依赖于以下几个关键的理论基石。

图论：网络关系的数学抽象

交易行为天然可以被抽象成一张图（Graph）。每个交易账户是一个节点（Node），每一笔成功的交易是从买方指向卖方的一条有向边（Directed Edge）。边的权重可以包括交易金额、数量等信息。

  • 自环（Self-loop）：最简单的自成交，即 `A -> A`，在图中表现为一个指向自身的边。这是最容易检测的模式。
  • 短循环（Short Cycles）：如 `A -> B` 和 `B -> A` 构成的 2-cycle，或者 `A -> B -> C -> A` 构成的 3-cycle。这代表资金或资产在少数几个账户之间快速流转，形成了闭环。检测图中的短循环是识别团伙作案的关键。
  • 强连通分量（Strongly Connected Components, SCC）：在一个有向图的子图中，如果任意两个节点都可以相互到达，则这个子图是一个强连通分量。大规模的刷量团伙，其内部账户网络通常会形成一个或多个大型的强连通分量，所有资金在内部频繁流动，但与外部真实世界的交互较少。识别这些“孤岛”或“紧密社区”是高级检测的重点。

时序分析：捕捉行为的节奏

交易不仅是“谁和谁”，更是“在何时”。单纯的图结构是静态的，而操纵行为是有时序特征的。引入时间维度，我们可以分析交易序列的动态模式。

  • 时间窗口（Time Windows）：我们将无限的交易流切分成离散的时间窗口（如1分钟、10分钟）。分析窗口内的交易频率、金额分布、对手方集中度等统计特征。例如，两个账户在多个连续时间窗口内，以高频率、稳定价格、相似金额进行双向交易，这是典型的“对敲”行为。
  • 交易熵（Transaction Entropy）：信息论中的熵可以用来度量一个系统的混乱程度。一个正常用户的交易对手方应该是多样和随机的，其交易对手方分布的熵较高。而一个刷量账户的交易对手方高度集中于其团伙内部，熵值会显著偏低。

实体识别（Entity Resolution）：合并分裂的身份

这是整个识别体系中最具挑战性的一环。操纵者控制着成百上千个账户，但这些账户背后是同一个实体。我们的目标就是将这些看似独立的账户“合并同类项”，识别出背后的实际控制实体。这本质上是一个聚类问题，我们依赖多种“信号”（Signals）来判断账户的同源性：

  • 硬特征：如相同的注册设备ID、相同的登录IP地址、相同的充提币地址。这些是强关联信号，但容易被伪装。
  • 软特征：如来自同一 /24 IP段（大概率在同一个机房或区域）、相似的API Key使用模式、接近的注册时间、相似的密码哈希结构（如果内部可获得）等。这些是弱关联信号，需要多个信号叠加才能形成有效判断。

在工程上，这通常通过构建一个“账户关联图”来实现，图中的边表示账户间的关联强度，然后运用社区发现算法（如 Louvain a-lgorithm）或简单的并查集（Union-Find）来对账户进行聚类。

系统架构总览

一个成熟的自成交识别系统是实时性与准确性妥协的产物，通常采用 Lambda 或 Kappa 架构的变体。它包含实时、近线、离线三层处理链路。

数据流描述：

  1. 数据源：核心数据来自撮合引擎的成交日志（Trade Log），以及用户中心的用户注册、登录信息。
  2. 实时摄入：所有数据通过消息队列（如 Kafka）进行汇聚。Trade Log 是高吞吐量数据，一个独立的 Topic；用户行为日志是另一个 Topic。
  3. 实时计算层（Stream Processing）：使用 Flink 或类似框架，订阅 Kafka 的 Trade Log。这一层负责处理最简单、延迟要求最高的场景，如直接的自成交（`A -> A`）或秒级的快速对敲（`A -> B` 后立即 `B -> A`）。检测到的结果直接写入风险事件库（如 HBase 或 TiDB）并触发实时告警。
  4. 近线计算层（Near-line Batch Processing）：同样由 Flink 或 Spark Streaming 实现，但窗口更大（如5-15分钟）。它负责构建小型的、基于时间的图，并进行短循环检测。同时，它会聚合用户的行为特征（如交易频率、对手方数量）并更新到用户画像库（Feature Store，如 Redis 或 Cassandra）。
  5. 离线计算层（Offline Batch Processing）：每小时或每天，由 Spark 批处理任务执行。它会拉取过去一个周期内的全量交易数据和用户关联信息（IP、设备等），构建大规模的交易图和账户关联图。这一层负责复杂的计算，如大型强连通分量分析、全局实体识别聚类。计算结果会更新用户风险等级，并可能触发对历史数据的回溯分析。
  6. 服务与决策层：一个规则引擎/模型服务（Rule/Model Service）对外提供查询接口。当风控系统需要对某个用户或某笔交易进行判断时，它会从用户画像库和风险事件库中拉取特征，执行预设的规则（如“过去1小时内，与超过3个高风险账户发生交易”）或机器学习模型，并给出最终的风险评分或决策。
  7. 数据存储：原始数据存储在数据湖（如 S3/HDFS）中。实时/近线结果存在高性能 KV 存储或数据库中。用户画像和特征使用 Redis/Cassandra。

这个架构实现了分层检测：实时层保证低延迟，处理最明确的信号；近线层平衡了延迟和计算复杂度；离线层则牺牲时效性，追求最广泛和最深入的分析，从而捕捉最狡猾的对手。

核心模块设计与实现

模块一：实时自成交与对敲检测（Flink 实现）

这是系统的第一道防线。我们使用 Flink 的 `KeyedProcessFunction`，以交易对的买卖双方账户ID组合（例如，`{userA, userB}` 排序后的字符串）作为 key。这样，所有 A 和 B 之间的交易都会被同一个 Flink Task 处理。


// -- language:java --
// 伪代码，展示核心逻辑
public class WashTradeDetector extends KeyedProcessFunction<String, Trade, Alert> {

    // 状态中存储最近一次的反向交易时间戳
    private transient ValueState<Long> lastReverseTradeTimestamp;

    @Override
    public void open(Configuration parameters) {
        ValueStateDescriptor<Long> descriptor = new ValueStateDescriptor<>(
                "last-reverse-trade", Long.class);
        lastReverseTradeTimestamp = getRuntimeContext().getState(descriptor);
    }

    @Override
    public void processElement(Trade trade, Context ctx, Collector<Alert> out) throws Exception {
        // 1. 直接自成交检测
        if (trade.getBuyerId().equals(trade.getSellerId())) {
            out.collect(new Alert(trade, "DIRECT_SELF_TRADE"));
            return;
        }

        // 2. 快速对敲检测
        // 当前 key 是 {buyerId, sellerId}
        String currentKey = ctx.getCurrentKey();
        
        // 构造反向交易的 key
        String reverseKey = trade.getSellerId() + ":" + trade.getBuyerId();

        // 这是一个技巧：我们实际上应该在同一个 keyed stream 中处理
        // 这里简化为查询一个共享状态，但更好的方式是把 A->B 和 B->A 都路由到同一个 key
        
        // 假设我们已经把 A-B 和 B-A 路由到同一个 key
        // 那么我们可以维护一个状态，记录上一次交易的方向和时间
        // MapState
        
        // 简化的逻辑：检查反向交易是否在短时间内发生
        Long lastTimestamp = lastReverseTradeTimestamp.value();
        if (lastTimestamp != null && (trade.getTimestamp() - lastTimestamp) < 5000) { // 5秒内
            out.collect(new Alert(trade, "QUICK_REVERSAL_TRADE"));
        }
        
        // 更新当前方向交易的时间戳
        // 注意：为简化，这里没有展示如何处理两个方向的状态
        // 在实际项目中，state 可以是一个包含 (direction, timestamp) 的对象
        lastReverseTradeTimestamp.update(trade.getTimestamp());
        
        // 设置一个定时器，在一段时间后清理状态，防止 state 无限增长
        ctx.timerService().registerProcessingTimeTimer(ctx.timestamp() + 60_000L); 
    }
    
    @Override
    public void onTimer(...) {
        // 定时器触发时，清理过期的状态
        lastReverseTradeTimestamp.clear();
    }
}

极客坑点：Flink 的状态管理是这里的核心。`ValueState` 对于存储单个值很有效，但对于对敲这种需要记录对手方最后交易时间的状态，可能需要 `MapState`。此外，必须设置状态的 TTL (Time-To-Live) 或使用定时器清理，否则对于活跃的交易对，状态会无限增长，最终导致内存溢出。数据倾斜也是个大问题，少数做市商账户的交易量极大，需要对 Key 进行加盐（salting）等预聚合操作来打散负载。

模块二：离线实体识别（Union-Find 算法）

离线任务的核心是根据各种关联信号，将马甲账户聚类成实体。并查集（Union-Find）是实现这个逻辑的经典数据结构，它的时间复杂度近乎 O(1) 用于 `find` 和 `union` 操作，非常高效。

我们首先从数据库中提取所有账户的关联信息，如 `(accountId, deviceId)`, `(accountId, ipAddress)`。然后遍历这些关联对。


# -- language:python --
# 伪代码，展示 Union-Find 在实体识别中的应用

class UnionFind:
    def __init__(self, accounts):
        self.parent = {acc_id: acc_id for acc_id in accounts}
        self.rank = {acc_id: 0 for acc_id in accounts}

    def find(self, i):
        if self.parent[i] == i:
            return i
        self.parent[i] = self.find(self.parent[i]) # 路径压缩
        return self.parent[i]

    def union(self, i, j):
        root_i = self.find(i)
        root_j = self.find(j)
        if root_i != root_j:
            # 按秩合并
            if self.rank[root_i] > self.rank[root_j]:
                self.parent[root_j] = root_i
            else:
                self.parent[root_i] = root_j
                if self.rank[root_i] == self.rank[root_j]:
                    self.rank[root_j] += 1

# 1. 初始化
all_accounts = get_all_account_ids()
uf = UnionFind(all_accounts)

# 2. 根据强关联（如设备ID）进行合并
device_to_accounts = get_device_to_accounts_map() # e.g., {'dev1': ['acc1', 'acc2']}
for device_id, accounts in device_to_accounts.items():
    if len(accounts) > 1:
        first_acc = accounts[0]
        for i in range(1, len(accounts)):
            uf.union(first_acc, accounts[i])

# 3. 根据弱关联（如 /24 IP段）进行合并
ip_subnet_to_accounts = get_ip_subnet_to_accounts_map()
for subnet, accounts in ip_subnet_to_accounts.items():
    if len(accounts) > 1:
        first_acc = accounts[0]
        for i in range(1, len(accounts)):
            uf.union(first_acc, accounts[i])

# 4. 输出聚类结果
clusters = {}
for acc_id in all_accounts:
    root = uf.find(acc_id)
    if root not in clusters:
        clusters[root] = []
    clusters[root].append(acc_id)

# clusters 的 value 就是识别出的实体账户集群
# e.g., {'acc1': ['acc1', 'acc2', 'acc10'], 'acc3': ['acc3', 'acc5']}

极客坑点：这里的挑战在于“关联”的定义。仅使用单一强特征（如设备ID）会漏掉使用虚拟设备的对手；仅使用弱特征（如IP段）则可能将同一栋办公楼里不相关的用户错误地关联起来。实践中，我们会给不同的关联边赋予权重，并使用更复杂的图社区发现算法（如 Louvain）来代替简单的并查集。此外，处理海量账户时，这个过程必须在分布式环境（如 Spark）中执行，需要将并查集算法并行化，这并非易事。

性能优化与高可用设计

一个金融级的风控系统，其性能与稳定性甚至比功能本身更重要。误判可能导致正常用户资产被冻结，漏判则让平台声誉受损。

  • 对抗数据倾斜：在交易数据中，少数做市商或交易所内部账户会产生海量交易，形成数据热点。在 Flink/Spark 中，这会导致部分 Task 负载极高。解决方案包括：
    • Key Salting: 对热点 Key（如某做市商账户ID）增加一个随机后缀，将其打散到多个 Task 中，进行局部预聚合，最后再合并结果。
    • 白名单机制: 对已知的、合规的做市商账户，可以在某些简单规则检测中直接跳过，避免不必要的计算资源浪费。
  • 内存管理与 GC 优化：图计算是内存密集型操作。在 Spark 中执行大规模图分析时，需要仔细配置 Executor 的内存、`spark.memory.fraction` 等参数。使用堆外内存（Off-Heap Memory）可以有效减少 JVM GC 的压力和停顿时间。序列化格式的选择（如 Kryo 替换 Java 原生序列化）也能大幅提升性能。
  • 高可用设计：
    • 数据链路：Kafka 本身通过多副本保证高可用。Flink/Spark Streaming 需开启 Checkpoint 机制，将状态快照持久化到 HDFS 或 S3，当任务失败时可以从上一个 Checkpoint 恢复，保证 exactly-once 或 at-least-once 的处理语义。
    • 服务层：规则引擎和用户画像服务必须是无状态的，可以水平扩展，并通过负载均衡器（如 Nginx）对外提供服务。其依赖的 Redis 或 Cassandra 等存储也必须是集群化部署。

      • – 降级预案：当离线计算集群出现故障时，系统应能优雅降级，至少保证实时的、基于简单规则的检测链路仍然可用。可以设置一个“熔断器”，当离线特征超过一定时间未更新时，规则引擎自动切换到更保守的策略。

架构演进与落地路径

构建如此复杂的系统不可能一蹴而就。一个务实的演进路径至关重要，它能帮助团队在不同阶段用最小的成本解决最核心的问题。

第一阶段：MVP（最小可行产品）- 规则化与手工化

  • 目标：快速上线，遏制最猖獗、最简单的刷量行为。
  • 实现：不引入复杂的流计算或图计算框架。在业务后端的交易后处理逻辑中，同步或异步地增加一个检查模块。该模块只实现最简单的规则，如 `buyerId == sellerId`。对于团伙作案，依赖运维和数据分析人员通过 SQL 查询手工捞取可疑账户，定期封禁。
  • 优势：开发成本极低，能快速响应业务需求。
  • 劣势：覆盖场景有限，无法应对有组织的对手，且高度依赖人力。

第二阶段：平台化 – 引入流计算与离线分析

  • 目标：将检测能力平台化、自动化，覆盖中等复杂度的作弊模式。
  • 实现：引入 Kafka + Flink 的实时计算链路，实现对自成交、快速对敲等模式的自动化实时检测和告警。同时，搭建基于 Spark 的离线批处理平台，每日执行 T+1 的账户关联分析和交易环路检测。建立初步的用户画像库，存储用户的风险等级。
  • 优势：检测能力和自动化程度大幅提升，解放人力。
  • 劣势：实时与离线数据存在割裂，对新出现的复杂模式响应仍然较慢。

第三阶段：智能化 – 融合图计算与机器学习

  • 目标：构建统一、智能的检测体系，能主动发现未知模式。
  • 实现：落地本文所描述的完整架构。引入图数据库（如 Neo4j）或 Spark GraphFrames 进行更专业的图分析。在离线平台之上，构建机器学习管道，利用聚类、异常检测、图神经网络（GNN）等模型来识别高度隐藏的、非显式的操纵行为。风控规则引擎与模型服务深度融合，实现动态、自适应的风险决策。
  • 优势：检测的深度和广度达到业界领先水平，具备发现未知威胁的能力。
  • 劣势：技术栈复杂，对团队的工程和算法能力要求极高，建设和维护成本巨大。

通过这样的分阶段演进，团队可以在每个阶段都产生明确的业务价值，同时逐步积累数据、沉淀技术，最终构建起一个既强大又稳固的自成交识别风控系统，为市场的公平和健康运行提供坚实的技术保障。

延伸阅读与相关资源

  • 想系统性规划股票、期货、外汇或数字币等多资产的交易系统建设，可以参考我们的
    交易系统整体解决方案。
  • 如果你正在评估撮合引擎、风控系统、清结算、账户体系等模块的落地方式，可以浏览
    产品与服务
    中关于交易系统搭建与定制开发的介绍。
  • 需要针对现有架构做评估、重构或从零规划，可以通过
    联系我们
    和架构顾问沟通细节，获取定制化的技术方案建议。
滚动至顶部