交易监控规则与评分：速率与条件

提交至 Didit 的每笔交易都会根据您应用中的所有有效规则进行评估。规则定义了条件、速率检查和操作，用于确定交易的最终状态和评分。 本章是 Didit Academy 欺诈规则引擎课程的一部分，从创建规则开始讲起。 规则引擎课程在 7:54 处通过录屏演示创建规则：包括触发器、条件、操作和评分，然后在部署前进行回测。

​

内置规则包

Didit 提供预配置的规则库，涵盖常见的监管类型。您可以从规则库中安装所需的预设（或整个规则包），方式包括：在控制台中操作、通过 安装 API，或使用 MCP 工具，并控制每个已安装预设的模式。如需查看所有预设规则的完整目录（包括阈值和操作），请参阅 规则库。

​

规则来源

每条规则都有一个 source，用于标明由谁管理：

​

规则结构

每条规则包含以下组成部分：

​

操作

当规则匹配某笔交易时，将执行一项或多项操作。每条规则可以包含多项操作，这些操作会一起生效： 大多数预设规则会将添加评分与更改状态组合使用。例如，制裁交易对手规则会增加 90 分，并同时立即拒绝该交易。

​

要求用户验证 (AWAITING_USER)

更改状态 → AWAITING_USER 操作不只是设置状态。规则触发时，Didit 会自动为该交易的主体（即相同的 vendor_data）创建一个托管验证会话。 该会话会出现在交易的 action_required 块中（同时也在 remediation 对象中），包含在创建响应和之后的每次读取中，并且会随两个交易 Webhook 一并发送。这样您可以立即将用户重定向到验证页面，详见所需的用户操作。 自定义规则必须在操作本身中指定工作流（workflow_id），控制台规则构建器和规则 API 都要求如此。 内置规则库中的规则不携带工作流。对于这些规则，验证会话的工作流按以下顺序确定：

1. 在交易设置中配置的补救工作流。
2. 您应用的生物识别认证工作流，前提是该主体已有来自已通过验证且已存储的参考人脸。
3. 您应用的默认工作流。

这意味着 AWAITING_USER 规则库规则开箱即可生成可操作的会话：对于您已验证过的用户，进行生物识别二次验证；其他情况则进行完整验证。 对于 Travel Rule 交易，不适用此自动回退机制，因为其 AWAITING_USER 等待是为了证明钱包所有权，该流程有其专属流程。 对于高风险交易，最佳选择是生物识别认证工作流：该主体就是您已完成 KYC 的用户，因此 Didit 会复用其入驻时已验证的参考人脸（已通过的活体自拍照、护照芯片照片或证件人像）。用户只需拍摄一张实时自拍照，Didit 即可对其进行活体检测，并与开户时的身份进行 1:1 人脸比对。 被盗的凭证、钓鱼获取的一次性验证码和 SIM 卡换绑都无法通过这一关。 完整操作步骤：高价值提现的生物识别二次验证操作指南。 会话作出决策后，交易会自动跟随该结果，并触发 transaction.status.updated Webhook：已通过的会话会使交易通过（decision_reason_code: user_action_approved），已拒绝的会话会使交易被拒绝（user_action_declined），结束于审核中的会话会使交易进入 IN_REVIEW（user_action_in_review）。 已过期或已放弃的会话会使交易保持在 AWAITING_USER 状态。

​

评分

当交易匹配一条或多条规则时，各项评分会被合并：

1. 每次规则匹配都会通过 add_score 操作为交易的总体风险评分贡献分值。
2. 最终评分根据您应用的评分阈值决定交易状态。
3. 如果任何规则包含 change_status 操作，则直接应用该状态，DECLINED 始终优先。

默认评分阈值（可在控制台中配置）：

​

创建自定义规则

可以在 业务控制台 中创建自定义规则，也可以通过 管理 API 创建（也可通过 Didit MCP 以及任何连接 MCP 的 AI 助手访问）。 处于 Active 模式的规则会立即对所有新交易生效。规则标题在每个应用内唯一。

​

回测

激活规则之前，可以使用历史数据进行验证：

• 将规则设置为 测试 模式：规则会对每笔新交易进行评估，但结果不影响交易的状态或分数。执行统计（匹配数、受影响实体）会持续累积，便于在正式上线前评估影响。
• 使用 回测 功能（在控制台中，或通过 POST /v3/transactions/rules/backtest/）对指定时间段内的交易，追溯评估规则的条件和聚合。回测会返回已评估的交易数、已匹配的交易数以及受影响实体，且不会修改任何历史数据。请发送与计划激活的规则相同的 conditions、aggregation、evaluation_mode 并且 scope：省略适用范围表示不做限制，这样回测会统计已保存规则会跳过的交易。

​

速率窗口（聚合）

速率规则会在一段时间内聚合历史交易数据，以发现单笔交易检查可能漏掉的模式： 每个聚合需指定：

• 时间窗口：<N>m（分钟）、<N>h（小时）或 <N>d（天），例如 30m、6h、7d、30d。注意：m 表示分钟，而不是月。
• 过滤器：用于缩小纳入的历史交易范围。键为字段目录中的字段路径；特殊值 "__current__" 会解析为正在评估的交易中同一字段的值（例如 "subject_vendor_data": "__current__" 将窗口限定为同一主体）；列表值表示匹配列表中的值。过滤器仅支持等值或成员匹配，没有 lt/gte 过滤器，因此无法表达类似金额低于 10,000 的交易这样的范围。请将范围放在指标上（例如下方的 max 低于 10,000、min 高于 1,000），并谨记：条件约束的是正在评估的交易，而不是时间窗口。
• 运算符和阈值：eq、ne、gt、gte、lt、lte 与 value 比较，例如计数 >= 20。

​

示例模式

​

字段目录

条件和聚合过滤器通过路径引用交易字段：

​

条件运算符

规则支持以下条件比较运算符： 其他所有运算符都需要非空的 value，否则 API 返回 400。 contains、not_contains 和 regex 接受单个字符串，不接受列表或对象；contains_any 接受字符串列表。

​

条件值类型

条件上可选的 value_type 用于改变 value 的解释方式：

​

分组条件

平铺的条件列表会按规则的 evaluation_mode（ALL/ANY）组合。如需混合逻辑，可为条件设置 group_index：具有相同索引的条件构成一组，group_logic（AND/OR，默认 AND）组合组内的条件，第一个条件上的 groups_logic（AND/OR，默认 OR）组合各组的结果。只要有任一条件带有 group_index，分组评估就会取代 evaluation_mode。

​

引用自定义属性

通过 POST /v3/transactions/ 的 custom_properties 对象提交的每个键，都会以 custom_values 的形式存储在交易上，并可在条件中使用字段路径 custom_values.<key> 引用。例如，提交的交易带有 "custom_properties": {"channel": "mobile_app"}，则会匹配条件 custom_values.channel eq "mobile_app"。上述所有运算符都适用于自定义属性，它们也可以与其他字段进行比较，或用于交易频率过滤器。 在控制台规则构建器中，近期接收的交易中出现过的键会自动显示在条件字段选择器的 自定义属性 下。您也可以在任何交易携带该键之前先引用它：在同一分组中选择 输入自定义属性，并按集成发送的方式准确输入该键（键区分大小写）。在携带该键的交易到达之前，规则会直接判定为不匹配。

​

黑名单自动拒绝

在评估任何规则之前，Didit 会将交易的实体与您应用的黑名单进行核对。如果发现 任何 匹配，交易将被 立即拒绝，不再评估规则。 系统会检查以下实体： 发生黑名单匹配时：

• 交易状态被设置为 DECLINED
• 决策原因被设置为 blocklisted
• 会创建一条活动记录，用于审计追踪

​

交易筛查

Didit 与外部 AML 和区块链分析服务商集成，为交易补充风险情报。提交交易时，系统可以：

• 筛查交易对手，比对全球制裁和观察名单数据库
• 评估钱包地址（适用于加密交易），比对区块链情报数据，包括与混币器的关联、与受制裁实体的关联以及与高风险服务的交互
• 检查申请人的 AML 状态，将交易关联的用户与其最新的 AML 筛查结果进行交叉比对

筛查结果会附加到交易上，并纳入规则引擎的评分。如果交易对手或钱包与制裁名单匹配，相应规则会自动标记或拒绝该交易。

​

后续步骤