案件管理 - 案件与生命周期

Case Management 是 Didit Console 中的调查中心。每一条 AML 命中记录、被标记的验证或可疑交易，都可以转为案件，供您的合规团队从打开到解决全程跟进，并保留完整的审计日志。

---

​

生命周期

案件只有三种状态： 解决案件时必须填写处理结果： 每个案件都带有优先级（Low、Medium、High，默认为 Medium）以及可选的截止日期，用于 SLA 排序和逾期标记。

​

每个案件只有一个主体

每个案件都只关联一个用户或一家企业。您不能在同一案件中混合多个主体，也不能关联与案件主体不同的会话、企业会话或交易。若尝试这样做，系统会返回明确的错误。 这样可以确保每个案件页面聚焦：主体卡片、风险概览、证件和财务数据，描述的都是该案件所调查的同一个人或企业。若要审查第二个实体，请打开（或创建）另一个案件。

​

Fraud Check 来源上下文

从 Fraud Check 会话创建案件时，会保留其检查 ID、请求 ID，以及审核员打开的部分。 来源卡片还会记录会话在案件创建时的分析师状态。 案件决策与来源决策保持分开。 通过 API 创建案件时，客户端可以在 source_context 中提供 check_id、request_id 和 source_section。 将该请求作为 links 中的一个 session 条目添加。 检查和关联会话必须属于所选应用，并且彼此匹配。 API 会自行读取分析师状态，并拒绝此上下文中由调用方提供的状态、建议或来源类型字段。

​

列表

案件管理在顶部导航中保留 案件、概览和分配。 案件工作区提供 打开、等待用户、已解决和全部等状态视图。 在桌面端打开案件时，案件队列会与其详情并排显示。 在移动端，使用面包屑导航返回队列。 搜索支持匹配主体名称或 ID、标签、案件编号、案件标题、关联会话 ID 和关联交易 ID，因此您可以粘贴会话或交易的 UUID，直接进入对应的案件。 筛选标签：蓝图、创建时间、来源、负责人、标签，以及用于优先级和截止日期的添加筛选条件。 列：创建时间（日期和创建人）、案件详情（标题）、状态、蓝图、主体（名称和 ID）、主体标签、负责人、优先级和截止日期。通过水平滚动和列配置，还可以查看更多列。

​

排序与 SLA

可按创建时间（默认）或截止日期排序。按截止日期排序时，逾期案件会优先显示。只要案件仍处于“打开”或“等待用户”状态且截止日期已过，该案件即为逾期，并显示红色截止日期标签。

​

已保存视图

使用保存视图将当前的筛选条件和列组合保存为命名视图，使用选择视图在视图之间切换，使用清除筛选重置。视图为个人专用，保存方式与控制台其他表格偏好设置相同。

​

批量操作

选择多个案件，可以执行以下操作：

• 分配给某位工作人员。所选案件必须使用相同的蓝图。若不相同，控制台会在提交前发出警告。
• 设置状态为“等待用户”、重新打开或解决（需填写处理结果，并可选填备注）。每个案件会被独立评估。如果某个案件因检查清单未完成或缺少必填备注而被阻止，系统会单独报告该案件，不会导致整批操作失败。

​

导出

列表菜单提供两种 CSV 导出，通过报告页面交付：

• 所有案件报告：每个案件一行，包含状态、处理结果、优先级、标签、关联交易，以及最近一次提交的 FIU 报告。
• SLA 报告：每个案件的时效指标，包括分配耗时（小时）、解决耗时（小时）、逾期标记和 SLA 达成标记。

​

主体操作与重试

主体卡片允许具有权限的审核员更改主体状态、添加标签、添加内部备注，或将主体加入黑名单。 这些操作与解决案件相互独立。 主体操作部分会记录每个请求的操作，并标明其为已执行或失败，同时注明执行的审核员和时间。 在查看当前主体后，使用重试操作重试失败的操作。 已执行的操作在其请求被重试时不会再次执行。 API 客户端应为发送到案件 entity-actions/ endpoint 的每个请求附带唯一的 client_reference。 在连接出错后重试请求时，请保持相同的引用和输入。 若引用相同但输入已更改，将返回 409。 提供引用时，请检查 receipt.status：200 响应中可能包含失败的回执，表示该操作未被执行。 重试失败的请求需要设置 retry: true，或调用其 action-receipts/{receipt_uuid}/retry/ endpoint。 历史记录 endpoint 每页最多返回 20 条回执，并通过 next_offset 提供更多结果。 未提供 client_reference 的现有 API 客户端将保持其原有的响应行为。

​

标签

在案件标题栏中添加标签（添加标签），可将相关调查归为一组；也可以在列表中按标签筛选和搜索。标签变更会记录在案件时间线上。

​

相关页面

​

客户消息

使用 发送消息 为已验证的联系人预览固定的请求或审核更新。 请参阅 客户消息，了解投递状态、安全回复以及 API 工作流。

​

讨论与置顶备注

点击案件状态旁边的讨论按钮，即可在保留调查状态的同时查看备注。 使用备注菜单可以回复或置顶该备注。 置顶备注会显示在最前面，回复会显示其父备注的简短摘录。 置顶变更会记录在案件活动中，且不会更改来源决策。 确认删除后，备注及其在回复中引用的摘录将被永久删除。 回复本身仍然保留。 附件除非仍被其他备注使用，否则将被删除。 API 客户端在添加备注时可以提供 client_reference UUID。 内容未变更的重试会返回已有备注，且不会重复发送通知。 若对内容已变更的备注或已删除的备注重复使用该引用，将返回 409。 提供 reply_to 以引用同一案件中未被删除的备注，并通过备注的 PATCH 端点更新 is_pinned。

​

检查是否已有调查

共享的创建案件对话框会检查所选用户、企业或关联来源是否已有调查。 打开已有案件即可继续审核。 已关闭的案件仍然可见，您可以打开它们并决定是否重新开启。 若要创建单独的调查，请输入将其视为不同事件的原因。 该原因会随新案件一起保存，并显示在其概览中。 在您提交时，控制台会再次检查重复项，包括在对话框打开期间由其他审核员创建的案件。 API 集成可以查看 POST .../cases/duplicates/，并在创建案件时设置 review_duplicates=true。 若发现已有调查，除非提供了 separate_incident_reason，否则创建请求将返回 409。 重复项审核端点每页最多返回 20 个案件，更多结果可通过 next_offset 获取。 省略该选项的现有 API 集成将保持其当前的创建行为。