拿到监管法规文档时，如何把它拆解成一份可落地的合规配置方案（…

当你手上有一份监管法规/合规要求文档，需要把它翻译成具体的身份验证、问卷、地址证明、交易监控等配置项时使用。

适用场景

解决思路

1. 先收集上下文：确认司法管辖区（若文档覆盖多国必须明确问用户聚焦哪一个，不要擅自做多辖区方案）、业务类型（加密交易所/数字银行/iGaming/金融科技等）、客户类型（个人/企业/两者）、以及用户已有的配置（避免重复建议）。
2. 逐条从文档中抽取要求：客户身份识别要求（谁必须被识别、需要哪些数据）、可接受的身份文件（身份证/护照/税号等）、地址验证要求（接受哪些文件、最大时效）、加强尽职调查（EDD）触发条件、资金来源/财富/PEP 数据收集要求、AML 筛查义务（PEP/制裁/负面新闻）及命中处理方式（误报清除、PEP 复核策略、确认命中升级）、交易监控要求（阈值、可疑模式、加密 Travel Rule）、定期重新 KYC 义务、以及 Sumsub 无法覆盖的部分（数据留存期限、监管报送、制裁名单维护）。
3. 先验证理解再产出：分析后先给出简短的『我的理解』要点清单，并问用户『我是否理解正确？有需要补充或修正的吗？』，必须等用户确认后才能生成完整方案。
4. 生成方案时按能力映射逐项落地：验证等级（Level）用 docSet 序列定义，包括 IDENTITY（文件类型如 PASSPORT/ID_CARD/DRIVERS/RESIDENCE_PERMIT/VOTER_ID，可用 includedCountries/excludedCountries 按 ISO-3166 alpha-3 限制签发国）、SELFIE（liveness 选项：默认 passiveLiveness；法规明确要求主动活体用 activeLiveness；要求视频用 enabled；仅照片用 photoRequired；单帧用 staticLiveness）、APPLICANT_DATA（字段如 firstName/lastName/dob/country/town/street/postCode/nationality/placeOfBirth/tin，税号映射到 tin 并设 required: true）、PROOF_OF_RESIDENCE（引用 PoA preset）、PHONE/EMAIL_VERIFICATION、QUESTIONNAIRE、E_KYC、DEVICE_CHECK、COMPANY 系列（KYB）、ACCREDITED_INVESTOR、E_SIGN、TR_RECIPIENT_INFORMATION。
5. 把法规里的本地文件名称映射到通用 IdDocType：国际/生物识别护照→PASSPORT，任何国家的国民身份证→ID_CARD，驾照→DRIVERS，居留/移民许可→RESIDENCE_PERMIT，选民证→VOTER_ID，没有专用类型的（税卡、社保卡）→OTHER_DOCS；当强制标识（税号、国民号）出现在证件背面时，要注明需要双面采集。
6. 问卷配置：一个 level 只配一份问卷，把资金来源、PEP 自声明、风险画像等不同主题作为同一问卷里的不同 section，而不是拆成多份问卷；题型支持 text/textArea/date/dateTime/bool/select/selectDropdown/multiSelect/phone/countrySelect/countryMultiSelect/fileAttachment/multiFileAttachments；支持基于前序答案的条件显示；每个选项可带 0–100 的 score 用于风险评分并供下游交易监控规则引用。
7. 地址证明预设（PoA preset）：按类别（governmentOrganization/utilityProvider/bank/mobileOperator/other）设置 maxMonths 最大文件时效；配置 POI 与 POA 之间的姓名/地址交叉校验（模糊或严格）；可开启『身份文件本身作为地址证明』；可设置 neobank 黑名单（Revolut、N26、Wise 等）；支持按国家覆盖规则。
8. E-KYC（非文件电子验证）：需按国家通过 Sumsub CSM 单独开通（license: E_KYC_TARGET），开通后用 sumsub-create-level 配置；两种模式——独立 E_KYC docSet（只能电子验证）或 IDENTITY 加 ekycAllowed: true（用户可选上传证件或走 E-KYC）；数据库类型有 GOVERNMENT/CREDIT/TELCO/BANKING/COMMERCIAL/CONSUMER/UTILITY/POSTAL/PROPRIETARY；验证方法有 ENRICHMENT/ONE_X_ONE_MATCHING/TWO_X_TWO_MATCHING/VALIDITY_CHECK；建议搭配 SELFIE 做生物识别比对；覆盖国家完全取决于已开通的 license，没有通用清单。
9. 交易监控规则（KYT）：需 KYT license（加密 Travel Rule 需 TRAVEL_RULE，定期 re-KYC 需 TM_SCHEDULED_EVENTS，平台事件需 KYT_ANTI_FRAUD）；交易类型分 finance/travelRule/kyc/userPlatformEvent/scheduledEvent；规则结构包含条件（触发）、动作（score 加分/onHold 冻结/awaitUser 请求确认/reject 拦截）、风险分 0–100 累加、申请人变更（转 level、最终拒绝、转人工复核）、案件创建；新规则一律先以 dryRun: true 测试模式创建，上线需在 Dashboard 激活；定期 re-KYC 用 scheduledEvent 规则（在 level X 停留 N 天后重新分配到新 level 触发重验）。
10. 工作流（Workflow）：用图结构做路由，节点类型有 applicantLevel（跑某个 level）、exclusiveChoice（条件分支）、manualReview、finalRejection、actions（打标签、备注、改 source-key）；边条件可按申请人国家、尝试次数、审核决定（通过/拒绝/重提交）、自定义表达式；用于风险分级路由（低风险走标准 KYC、高风险走 EDD）、重验流程、多阶段入驻。
11. AML 命中处置规则链（AML Resolution Rules）：用有序规则列表自动复核 AML 筛查命中，每条规则按条件（供应商匹配类型、姓名/出生日期兼容性、风险标签、历史复核结果）选中命中，并设置其复核结果（match status: false_positive/potential_match/true_positive、风险等级、白名单标记、备注）和/或给申请人打标签；规则标签是通用申请人标签，可在工作流条件里以 checks.personWatchlist.tags / checks.companyWatchlist.tags 引用（例如规则打 youngPep 标签，工作流把这些申请人转人工复核）；需要 AI 用途的 App Token 和租户开通。
12. 交易数据提交（sumsub-create-transaction）：负责把交易数据发给 Sumsub 的 KYT 监控系统，与 TM 规则分工不同——前者管『发什么数据』，后者管『拿到数据做什么』；覆盖 finance 交易、Travel Rule（加密对手方数据）、平台事件（登录/注册）。
13. 输出方案时用结构化 markdown，分成两个明确区块：✅ 现在可通过技能配置（含具体参数）和 ⚠️ 需在 Sumsub Dashboard 配置（如激活 TM 规则、维护 KYT Client Lists）；每个条目必须用真实的 Sumsub 枚举值和字段名，不能写散文式描述（写 docTypes: [PASSPORT, ID_CARD, DRIVERS] 而不是『护照和身份证』；写 videoRequired: passiveLiveness 而不是『高级活体』；国家码用 ISO-3166 alpha-3 如 BRA）。
14. 方案末尾附上：Sumsub 无法覆盖的法规要求清单（数据留存、向监管机构报送等）、建议执行顺序（先建问卷和 PoA 预设→再建 level→再建工作流→再建 AML 处置规则（若工作流依赖规则标签，规则要先建）→再建 KYT 规则→再接入交易提交→最后在 Dashboard 激活 TM 规则）。
15. 全程只产出文字描述，绝不生成 JSON payload、API 调用或配置代码；TM 规则和 AML 处置规则只用业务语言描述触发条件和动作（如『拦截超过 5 万美元的交易』『姓名和出生日期都不匹配的命中→误报』），不写 SumScript 表达式或条件 AST。
16. 标注 license 要求：DEVICE_INTELLIGENCE、E_KYC_TARGET、KYT、TRAVEL_RULE、TM_SCHEDULED_EVENTS 都需先核实是否已开通；DEVICE_CHECK 在无权限时会静默降级为禁用，需加一步 GET 回查验证。
17. 只在法规明确要求交易监控时才在方案里加入 TM 规则；E-KYC 永远标注为需 CSM 开通并列出开通步骤，不能当作默认选项。

适用边界 · 注意事项

• 用户只是想直接创建某个 Sumsub 实体（没有监管背景）时——应直接调用对应的创建技能，不要走法规分析流程。
• 用户要的是直接调用 Sumsub API 或生成 JSON payload 时——本流程只做规划，不产出 API 调用。
• 文档覆盖多个司法管辖区且用户未指明聚焦哪一个时——不要擅自生成多辖区方案，必须先问清楚。