无需独立案例工具构建可疑活动报告（SAR）工作流程
Didit 的交易监控内置了警报、案例、分析师分配和可疑活动报告（SAR）归档功能，而非从独立的案例管理供应商处拼凑。本文将详细介绍端到端的工作流程。.
规则触发是容易的部分。之后发生的事情——警报、调查、升级、决定提交可疑活动报告——才是大多数合规操作实际存在的地方，也是大部分成本隐藏的地方。典型的设置是将三件事拼接在一起：一个产生警报的监控供应商，一个用于保存调查的独立案例管理工具，以及一个通常以电子表格和 PDF 结束的手动 SAR 流程。数据在系统之间重复录入，审计跟踪碎片化，分析师整天都在切换标签页。
Didit 的交易监控 API 在一个产品中提供了整个工作流程。当规则触发时，警报打开；警报分组到案例中；分析师被分配；SAR 从与警报发起相同的控制台提交。没有独立的案例工具需要许可、集成或协调——并且为其提供数据输入的交易成本为每笔 $0.02。
本指南将介绍从触发规则到提交 SAR 的整个工作流程。
主要收获
- 当规则触发时，警报自动打开，并经历一个定义的生命周期：
OPEN（开放）、INVESTIGATING（调查中）、AWAITING_USER（等待用户）、PENDING_SAR（待定 SAR）、SAR_FILED（SAR 已提交）、RESOLVED（已解决）、DISMISSED（已驳回）。 - 案例将相关警报分组，具有优先级和严重性，并跟踪调查过程，包括
OPEN（开放）、UNDER_REVIEW（审核中）、AWAITING_USER（等待用户）、ON_HOLD（暂停）和RESOLVED（已解决）状态。 - 分析师被分配到警报和案例，因此所有权和绩效是可衡量的。
- SAR 归档与警报位于同一控制台——无需导出到单独的工具，无需重复录入数据。
AWAITING_USER路径允许分析师将警报推回给用户进行补救，而不是手动解决。- 每笔交易 $0.02，无最低消费。对被标记方的反洗钱（AML）筛选单独计费，每笔 $0.20。
案例管理工作流程的作用
交易监控产生信号；案例管理将其转化为可辩护的决策。Didit 中的每个警报都带有一个来源——规则触发、提供商触发或分析师创建——以及一个反映其在调查中位置的状态。分析师打开警报，审查交易和触发的规则，然后决定：将其驳回为误报、解决它、升级到案例、推回给用户，或者将其推向 SAR。
案例是比单个警报更大的容器。同一用户的几个警报——周一的速度飙升，周三的受制裁交易对手命中——会分组到一个案例中，其中包含完整的情况，并有自己的优先级和严重性。案例是调查员处理的对象，也是记录公司决策的对象。
为什么这很重要
监管机构不仅期望您检测可疑活动，还期望您调查并报告它，并展示从警报到决策的清晰审计跟踪。碎片化的系统在每个方面都对您不利。在监控供应商和案例工具之间重复录入数据会引入错误。电子表格 SAR 流程难以审计且难以辩护。每个集成缝隙都是警报可能遗漏的地方。
将堆栈整合到一个产品中，同时解决了操作和监管问题。警报、调查、拥有它的分析师和 SAR 都存在于同一记录中。审计跟踪是连续的，因为没有任何东西离开系统。成本随交易量而非案例工具的按席位许可（您还需要维护）而扩展。
技术细节
当规则在交易上触发时，响应会带有状态和 alert_id：
{
"transaction_id": "txn_3c81f0",
"status": "IN_REVIEW",
"risk_score": 64,
"triggered_rules": [
{ "name": "Sanctioned counterparty", "bundle": "AML/CTF", "action": "CHANGE_STATUS" }
],
"alert_id": "alrt_77a920"
}交易本身是根据统一的 /v3/ API 创建的，在您控制的 transaction_id 上是幂等的：
curl -X POST https://verification.didit.me/v3/transactions/ \
-H "x-api-key: $DIDIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"transaction_id": "txn_3c81f0",
"category": "finance",
"amount": 24000,
"currency": "EUR",
"currency_kind": "fiat",
"txn_date": "2026-05-21T14:50:00Z",
"subject": { "vendor_data": "user_6610", "role": "SENDER", "entity_type": "INDIVIDUAL" },
"counterparty": { "role": "RECEIVER", "entity_type": "INDIVIDUAL" }
}'警报状态。 OPEN（开放）→ INVESTIGATING（调查中）→ (AWAITING_USER（等待用户）) → PENDING_SAR（待定 SAR）→ SAR_FILED（SAR 已提交），或终止于 RESOLVED（已解决）或 DISMISSED（已驳回）。
案例状态。 OPEN（开放）、UNDER_REVIEW（审核中）、AWAITING_USER（等待用户）、ON_HOLD（暂停）、RESOLVED（已解决）。
Webhooks。 订阅 transaction.created 和 transaction.status.updated，以便您的系统在分析师将警报推入工作流程时保持同步。
价格。 每笔交易 $0.02。在调查期间对被标记方进行的反洗钱（AML）筛选单独计费，每笔 $0.20。
从警报到提交 SAR
- 警报打开。 规则触发，交易变为
IN_REVIEW状态，警报以OPEN状态打开，并附带触发规则。 - 分析师处理。 警报变为
INVESTIGATING状态并分配给分析师，分析师审查交易历史、速度上下文以及任何反洗钱筛选。 - 升级或补救。 分析师将相关警报分组到一个案例中，或将警报推到
AWAITING_USER状态，以便客户可以通过资金证明或重新验证来清除它。 - 决定提交 SAR。 如果活动需要报告，警报将变为
PENDING_SAR状态，SAR 在同一控制台中准备，提交后警报将变为SAR_FILED状态。 - 结案。 不需要采取行动的警报会作为
DISMISSED（误报）或RESOLVED（已解决）处理。整个跟踪记录——谁在何时决定了什么——都保留在记录中。
由于警报可以变为 AWAITING_USER 状态，调查和自动补救循环共享同一界面：分析师可以将边缘警报交还给用户，而不是浪费时间，一旦用户响应，警报会自动恢复。
用例
- 金融科技 — 在决定提交 SAR 之前，将单个账户上的速度、结构和制裁警报分组到一个案例中。
- 加密货币 — 在同一案例文件中调查由钱包筛选暴露引发的警报以及链上速度。
- 借贷 — 将欺诈模式警报（骡子账户、合成身份）处理到有记录的决策，而无需第二个工具。
- 市场平台 — 将卖家退款滥用和退单警报整合到一个案例中，然后提交或驳回。
- iGaming — 在一个工作流程中管理负责任博彩和反洗钱警报，具有分析师所有权和审计跟踪。
如何与 Didit 集成
- 开启您的捆绑包。 在业务控制台中，启用适合您业务的规则捆绑包，以便警报根据正确的类型学打开。
- 发送交易。 随着资金的流动，
POST /v3/transactions/，使用稳定的transaction_id和vendor_data将每笔交易链接到其用户或实体。 - 在控制台中处理警报。 调查、分配分析师、将警报分组到案例中并提交 SAR——所有这些都通过同一界面完成。
- 与 Webhooks 同步。 监听
transaction.status.updated，以便您的系统反映警报和案例状态的变化。
由于这一切都基于统一的 /v3/ API，一个 KYB 会话可以为它的 UBO 启动 KYC 会话，这些用户流入交易监控，一个被标记的交易可以启动一个补救 KYC——一个端到端的身份和欺诈平台。
常见问题
我需要一个单独的案例管理工具吗？
不需要。警报、案例、分析师分配、调查状态和 SAR 归档都内置在同一个产品和控制台中。
警报会经历哪些状态？
OPEN（开放）、INVESTIGATING（调查中）、AWAITING_USER（等待用户）、PENDING_SAR（待定 SAR）、SAR_FILED（SAR 已提交）、RESOLVED（已解决）和 DISMISSED（已驳回）。案例会经历 OPEN（开放）、UNDER_REVIEW（审核中）、AWAITING_USER（等待用户）、ON_HOLD（暂停）和 RESOLVED（已解决）状态。
我可以将警报分配给特定的分析师吗？
是的。警报和案例都分配给分析师，因此所有权清晰，绩效可衡量。
SAR 在哪里归档？
在发起警报的同一控制台中。无需导出到单独的工具，也无需重复录入数据，这使得审计跟踪保持连续性。
费用是多少？
每笔交易 $0.02，按每次调用计费，无最低消费。在调查期间对被标记方进行的反洗钱（AML）筛选单独计费，每笔 $0.20。
准备好开始了吗？
阅读文档中的交易监控概述，查看它如何与交易监控产品页面上的其他平台配合使用，并在定价页面上查看透明的按次调用定价。准备好后，免费开始——每月 500 次免费 KYC 检查，交易监控每次调用 $0.02。