持续 AML 监控：每日重新筛查

持续监控是完整 AML 方案的关键组成部分。它可确保您的客户尽职调查始终保持最新状态，并帮助您发现初始入驻流程之后可能出现的潜在风险。对于所有已执行 AML 检查的会话，此功能均会自动包含，无需执行任何额外的集成步骤。

具有每日重新筛查和 Webhook 警报功能的 Didit 持续 AML 监控仪表板

工作原理

我们的持续监控系统会持续针对各类观察名单、制裁名单和负面新闻源核对您已验证的用户。以下是该流程的详细概览：

每日自动检查：
- 我们的系统会对所有先前已通过的会话运行每日自动检查
- 每次检查都会对照我们全面的观察名单和制裁名单数据库对用户进行重新筛查
- 系统会将任何新发现与您配置的 AML 阈值进行比对
基于阈值的更新：
- 如果发现的新命中项超过了您配置的审核阈值，会话状态将变更为“审核中”（In Review）
- 如果新命中项超过了您的拒绝阈值，会话状态将自动变更为“已拒绝”（Declined）
- 这些阈值与您在工作流中配置的阈值相同
实时通知：
- 发生状态变更时，您的应用将收到一条 Webhook 通知
- Webhook payload 包含更新后的状态以及有关新 AML 命中项的详细信息
- 这些通知遵循我们标准 Webhook 系统的相同格式
Business Console 更新：
- 所有变更都会立即反映在您的 Business Console 中
- 您的合规团队可以检查新的 AML 命中项、审查详细调查结果并采取相应操作
- 控制台维护着所有监控活动和状态变更的完整审计记录

为用户和企业启用监控

您可以在控制台中直接为用户和企业开启或关闭持续监控，包括从未进行过 AML 检查的用户，例如导入的用户。

在 Business Console 中打开用户（或企业），选择您想要监控的档案，然后点击 AML 持续监控。
对话框会在执行任何操作之前显示费用估算：已选择多少个档案、有多少个档案需要新的 AML 筛查、一次性筛查费用以及每年监控费用。
点击启用监控。选择数量较少时会立即完成；选择数量较多时会在后台运行，同时对话框会显示实时进度。
运行结束时，对话框会按档案细分结果：已启用、已筛查并启用、已处于启用状态，或已跳过并说明原因（例如，缺少筛查所需的姓名、出生日期和国家/地区的档案）。

一些值得了解的细节：

未经 AML 筛查的档案会优先进行筛查。 Didit 会为它们创建新的 AML 验证（可在档案的验证标签页中查看），并按常规 AML 筛查计费。随后将对该验证启用监控。
每个档案仅保留一次受监控的筛查。 启用该功能会使每个用户或企业恰好保持一次受监控的 AML 筛查，因此多次验证的人员仅会被监控一次，并且仅计费一次。停用该功能将关闭该档案所有筛查的监控。
列表中可对监控情况一览无余。 用户和企业列表均包含持续监控列；将鼠标悬停在上方即可查看下一个年度计费日期。
全选功能适用于您的过滤器。 选中所有行后，该操作将应用于您当前的筛选视图，而不仅限于已加载的页面。

通过 API 启用监控

您的后端也可以使用 API 密钥执行相同的操作，因此您无需为了更改监控状态而重新筛查档案或打开控制台：

用于用户的 POST /v3/users/aml-monitoring/
用于企业的 POST /v3/businesses/aml-monitoring/
用于轮询任务的 GET /v3/aml-monitoring/jobs/{job_id}/

这两个切换 endpoint 均接受您自己的标识符列表（vendor_data_list）和/或 Didit ID 列表（didit_internal_id_list），每次调用最多支持 1000 个，并且完全遵循控制台的规则：每个档案仅保留一次受监控的筛查、未筛查的档案优先进行筛查，且停用会关闭该档案所有筛查的监控。

# 1. Preview the cost. Nothing is written.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "estimate_only": true, "vendor_data_list": ["user-123", "user-456"]}'

# 2. Enable monitoring. 20 profiles or fewer complete inline (200);
#    larger selections return 202 and a job_id to poll.
curl -X POST https://verification.didit.me/v3/users/aml-monitoring/ \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"is_enabled": true, "vendor_data_list": ["user-123", "user-456"]}'

响应中包含控制台对话框显示的相同明细，外加每个档案一个 results 条目及其结果：enabled、screened_and_enabled、already_enabled、disabled 或跳过原因（例如 skipped_no_identity_data）。未匹配任何内容的标识符将在 unmatched 下返回。切换监控本身不会发出 Webhook；一旦监控开启，重新筛查将照常触发 status.updated 和 data.updated 事件。

证明监控已运行

上述警报、活动条目和 Webhook 均在发生变更时触发。如果一个主体在一年内每天接受筛查但均未产生新命中项，则不会触发上述任何内容，因此“没有消息”和“从未运行过”看起来完全相同，而这在审计中是站不住脚的。有三个地方会记录实际的运行情况。 1. AML 报告上的上次筛查日期。 无论是否有变更，在 /v2/ 和 /v3/ 会话决策以及独立的 AML 报告上，每次运行完成时 last_ongoing_screening_at 都会更新。与其并列的 last_ongoing_screening_datasets_updated_at 是提供商为该次运行报告的最新 AML 数据集更新时间。这两项均绝非估算值：null 分别表示“从未重新筛查”和“未报告数据集日期”，而不是“未知，因此提供一个合理的近似值”。请勿将 next_ongoing_monitoring_bill_date 视为筛查日期，它是计费日期。 2. 每个主体的筛查历史记录。 GET /v1/session/{session_id}/aml-screening-history/ 返回该会话 AML 检查的每次已完成运行，按最新优先排序，包括结果为 NO_CHANGE 的运行。当图谱工作流包含多个 AML 节点时，请添加 ?node_id=。

curl https://verification.didit.me/v1/session/SESSION_ID/aml-screening-history/ \
  -H "x-api-key: YOUR_API_KEY"

{
  "count": 2,
  "results": [
    {
      "uuid": "0d1c...",
      "completed_at": "2026-09-12T04:03:11Z",
      "started_at": "2026-09-12T04:00:02Z",
      "outcome": "NO_CHANGE",
      "trigger": "ONGOING_MONITORING",
      "status": "Approved",
      "score": 0,
      "total_hits": 0,
      "dataset_freshness": null
    }
  ]
}

字段	含义
`outcome`	`NO_CHANGE`：运行完成且结果未发生变化。`CHANGED`：运行完成且评分、状态或命中项发生了变化。`FAILED`：提供商未返回针对该主体的可用回答，因此未筛查任何内容且未进行任何更改。覆盖范围的缺失会被记录下来，而不是被隐瞒。
`completed_at` / `started_at`	该主体的筛查完成时间，以及其所属批次的开始时间。
`status` / `score` / `total_hits`	该次运行后检查所处的状态。
`dataset_freshness`	该次运行时提供商名单的时效性；若无可用的数据集日期，则为 `null`。

3. 可导出的证据。 GET /v1/session/{session_id}/aml-screening-history/export/ 以 CSV 文件流的形式导出相同的历史记录：每次已完成的筛查对应一行，若提供商报告了对应来源类别的数据集更新日期则包含该日期，未报告则显示为空单元格。该文件正是合规团队向审计人员提交的材料。Business Console 在 AML 结果旁提供了相同的列表和相同的导出功能，因此审核员无需 API 访问权限即可生成该文件。

可用性限制（明确说明）。 历史记录从该功能上线之时起开始记录；较早的筛查记录不会被重新构建，而是直接缺失。运行记录将保留在所配置的数据保留周期内（默认为两年）。数据集时效性取决于提供商是否为您所处的环境发布了数据集日期；若未发布，则每个数据集字段均显示为 null，且 GET /v1/aml/dataset-freshness/ 将报告 availability: "not_configured"。缺失的日期绝不会使用替代值填补。

持续监控的优势

持续合规：无需额外设置，确保始终符合 AML/KYC 法规要求。
风险缓解：通过自动监控快速识别并应对新出现的风险。
运营效率：自动化耗时的人工重新筛查流程，无需额外的集成工作。
强化尽职调查：自动保持最新的客户档案。
监管支持：轻松向监管机构证明持续的合规工作。
零接触集成：无需任何额外开发工作即可受益于持续监控。

身份认证

验证

监控

平台

持续 AML 监控：每日重新筛查

工作原理

为用户和企业启用监控

通过 API 启用监控

证明监控已运行

持续监控的优势

​工作原理

​为用户和企业启用监控

​通过 API 启用监控

​证明监控已运行

​持续监控的优势

工作原理

为用户和企业启用监控

通过 API 启用监控

证明监控已运行

持续监控的优势