sumsub-analyze-regulation

Sumsub — 分析法规

读取法规文档，并生成结构化的 Sumsub 配置计划——将每项法规要求映射到满足该要求的 Sumsub 实体，并明确区分哪些内容可以立即通过技能配置，哪些需要通过 Sumsub Dashboard 配置。

这是一项仅用于规划的技能。它只会生成文本说明，不会生成 JSON 载荷或发起 API 调用。

工作流

第 1 步 — 收集上下文

开始分析前，请收集以下信息：

• 司法管辖区 — 如果文档涉及多个国家或表述不明确，请明确询问： “本法规涵盖 [国家列表]。计划应聚焦于哪个司法管辖区？” 除非用户直接要求，否则不要同时为所有司法管辖区生成计划。
• 业务类型 — 加密货币交易所、新型银行、iGaming、金融科技，或其他类型。如果文档中不明确，请询问。
• 客户类型 — 个人、公司，或两者。
• 现有 Sumsub 配置 — 用户是否已经配置了任何内容？避免建议重复配置。

第 2 步 — 分析（回答前先思考）

在组织回答前进行充分思考。从文档中提取以下信息：

• 客户身份识别要求（必须识别哪些人、需要哪些数据）
• 可接受的身份证明文件（国民身份证、护照、税号等）
• 地址验证要求（接受哪些文件、文件的最长期限）
• 加强尽职调查条件（哪些情况会触发 EDD）
• 资金来源／财富来源／PEP 数据收集要求
• AML 筛查义务（PEP／制裁／负面媒体），以及筛查命中后的处理方式（排除误报、PEP 审核政策、确认匹配后的升级处理）
• 交易监控要求（阈值、可疑模式、加密货币 Travel Rule）
• 定期重新 KYC 义务（客户必须多久重新验证一次）
• Sumsub 服务范围之外的内容（数据保留期限、监管报告、制裁名单维护）

第 3 步 — 首先确认理解

分析后，先简要列出一个 “我的理解” 区块，用项目符号列出提取出的要求，并询问： “我对关键要求的理解是否正确？有没有需要补充或更正的内容？”

在用户确认之前，不要生成完整计划。 这是强制要求。

第 4 步 — 生成计划

仅在用户确认后，按照下方的输出格式生成完整的配置计划。

---

Sumsub 能力映射

A. 验证级别 — sumsub-create-level

定义申请人必须完成的验证步骤序列。每个步骤都是一个 docSet。

可用的 docSet 类型：

类型	用途
IDENTITY	证件验证：PASSPORT、ID_CARD、DRIVERS、RESIDENCE_PERMIT、VOTER_ID 等。可按签发国家限制。
SELFIE / SELFIE2	生物识别和活体检测。
APPLICANT_DATA	收集个人数据：全名、出生日期、地址、国籍、税号（TIN/CPF/CNPJ 等）。
PROOF_OF_RESIDENCE / PROOF_OF_RESIDENCE2	地址证明文件验证。通过 poaStepSettingsId 引用 PoA 预设。
PHONE_VERIFICATION / EMAIL_VERIFICATION	通过 OTP 验证联系方式。
QUESTIONNAIRE / QUESTIONNAIRE2–4	自定义表单。通过 questionnaireDefId 引用问卷定义。
E_KYC	对照外部数据库进行非文件电子验证。参见 E-KYC 部分。
DEVICE_CHECK	设备情报和指纹识别。需要 DEVICE_INTELLIGENCE 许可。
COMPANY	KYB：收集公司信息。
COMPANY_DATA	KYB：公司数据字段。
COMPANY_DOCUMENTS	KYB：上传公司文件。
COMPANY_BENEFICIARIES	KYB：验证 UBO 和代表。
ACCREDITED_INVESTOR	合格投资者资格验证。
E_SIGN	采集电子签名。
TR_RECIPIENT_INFORMATION	收集旅行规则收款人数据。

级别属性：

• applicantType：individual 或 company
• requiredIdDocs：有序的 docSet 列表，以及可选的 includedCountries / excludedCountries
• disableWatchlists：如果租户拥有 WATCHLISTS 权益，但需要为特定级别停用 AML 筛查，则设为 true
• crossCheckPresetId：用于 AML 筛查的交叉核查预设

IDENTITY — 证件类型代码

无论证件在当地如何称呼，Sumsub 都使用通用的 IdDocType 值。将法规中的证件名称映射到以下类型：

通用证件类别	Sumsub IdDocType
国际护照 / 生物识别护照	PASSPORT
国民身份证（任何国家）	ID_CARD
驾驶执照	DRIVERS
居留 / 移民许可	RESIDENCE_PERMIT
选民身份证	VOTER_ID
Sumsub 没有专用类型的证件（如税务卡、社会保障卡）	OTHER_DOCS

includedCountries / excludedCountries 使用 ISO-3166 alpha-3 代码（如 BRA、USA、DEU）。

如果强制要求的标识符（税号、国民身份证号）印在证件背面，则应指定双面采集。

SELFIE — 活体检测选项（videoRequired）

值	描述	适用场景
passiveLiveness	默认。 高级被动活体检测，无需动作。	标准 KYC——无更严格的监管要求。
activeLiveness	主动动作挑战（检测头部动作）。	法规明确要求主动 / 动态活体检测。
enabled	短视频——申请人读出显示的数字。	法规要求视频身份核验。
photoRequired	仅需自拍照片，无活体检测。	仅在明确要求时使用；通常不足以满足 AML 合规要求。
staticLiveness	单帧分析。	仅在明确要求时使用。

对于大多数没有具体活体检测要求的 AML/KYC 法规，默认使用 passiveLiveness。

APPLICANT_DATA — 常用字段名称

标准个人数据字段：

字段名称	含义
firstName	名
lastName	姓
dob	出生日期
country	居住国家/地区（ISO-3166 alpha-3）
town	城市
street	街道地址
postCode	邮政编码
nationality	国籍（ISO-3166 alpha-3）
placeOfBirth	出生地点
tin	纳税人识别号（TIN、CPF、SSN、BSN 等）

如果法规要求收集国家税号或身份号码，请将其映射到 tin，并标记为 required: true。

DEVICE_CHECK — 检测内容

启用 DEVICE_INTELLIGENCE 许可证后，此步骤会标记：模拟器、已 root/越狱的设备、VPN/代理/Tor 连接、远程桌面软件和加密货币混币工具。请务必在计划中注明：如果租户没有相应权限，此步骤会静默回退为禁用状态——添加一个 GET 回查验证步骤。

B. 问卷 — sumsub-create-questionnaire

用于收集申请人数据的自定义表单，这些数据不会通过文档检查获取。

**常见用例：**资金来源、财富来源、就业情况、PEP 自我声明、交易经验、风险状况。

问题类型： text、textArea、date、dateTime、bool、select、selectDropdown、multiSelect、phone、countrySelect、countryMultiSelect、fileAttachment、multiFileAttachments。

**条件逻辑：**可根据之前的回答显示或隐藏章节和条目。

**风险评分：**每个答案选项都可以设置 score（0–100）；分数会自动汇总，并可供下游交易监控规则引用。

每个级别一个问卷。将不同主题（资金来源、PEP 自我声明、风险状况……）分组为单个问卷中的独立章节，而不是创建多个问卷。默认情况下，每个级别配置一个 QUESTIONNAIRE 步骤。独立的级别可以有自己的问卷（例如，包含扩展问卷的 EDD 级别）——这仍然是每个级别一个问卷，并非例外。只有在用户明确提出要求时，才为同一个级别规划多个问卷。

C. 地址证明预设 — sumsub-create-poa-preset

可重复使用的配置，用于指定哪些文档可作为地址证明。

文档类别：

• governmentOrganization — 政府签发的文档（选民登记证明、税单等）
• utilityProvider — 公用事业账单
• bank — 银行对账单和函件
• mobileOperator — 电信账单
• other

关键设置：

• 每个类别的 maxMonths — 文档的最长期限
• **交叉验证：**比较身份证件（POI）和地址证明（POA）上的姓名/地址——可使用模糊或严格模式
• **将 PoI 用作 PoA：**接受身份证件本身作为地址证明
• **新银行机构屏蔽列表：**排除特定机构（Revolut、N26、Wise 等）出具的文档
• **国家/地区特定覆盖规则：**按国家/地区设置不同规则

D. E-KYC（非证件电子验证）

⚠️ 需要通过 Sumsub 客户成功经理（CSM）按国家单独激活。许可证：E_KYC_TARGET。

激活后，通过 sumsub-create-level 配置。

**工作原理：**申请人提交唯一标识符（TIN、证件号码、银行登录信息），系统会将其与外部数据库进行比对验证——无需提供证件照片。

两种配置模式：

1. 独立的 E_KYC docSet — 仅进行电子验证；申请人无法改为上传证件
2. 在 IDENTITY docSet 中嵌套数据库来源的 checkSourceSettings — 申请人可选择：上传证件照片，或在同一步骤完成 E-KYC

配置规则：

• 国家和来源的覆盖范围完全取决于客户端激活的许可证——不存在通用列表。sumsub-check-databases 会在构建时确定某个国家实际可用且已启用的来源（由 sumsub-create-level 调用），还会报告每个来源的放置位置（顶层数据库验证，或独立／嵌套的非证件步骤）——请勿在计划中假定覆盖范围或放置位置。
• 建议搭配 SELFIE 步骤，针对数据库记录进行生物特征验证

激活步骤：（1）联系 CSM，申请按国家激活；（2）运行 sumsub-create-level — 它会使用 sumsub-check-databases 确认该国家的来源，并将其放置在相应位置（顶层数据库验证、独立的 E_KYC，或嵌套在 IDENTITY 中）。

E. 交易监控 — sumsub-create-kyt-rules

⚠️ 需要 KYT 许可证（加密货币需要 TRAVEL_RULE，定期重新 KYC 需要 TM_SCHEDULED_EVENTS，平台事件需要 KYT_ANTI_FRAUD）。

在计划阶段用自然语言描述要配置的内容。sumsub-create-kyt-rules 会将每条规则转换为 conditionEl SumScript 表达式，并通过 POST 请求发送到 API。新规则始终以测试模式启动（dryRun: true）——需要通过控制面板激活。

如果规则需要匹配具名集合（clientLists.<name> — 高风险国家、被屏蔽的电子邮件地址、同级允许列表），则需先使用 sumsub-manage-client-lists 创建并填充该列表。计划手动创建副本前，请先查看 Sumsub 维护的列表（fatf_black_flag_countries、eu_high_risk_third_countries 等）。

交易类型：

• finance — 金融交易（法定货币和加密货币）
• travelRule — 受 Travel Rule（FATF / VASP）约束的加密货币交易
• kyc — 与 KYC 相关的事件
• userPlatformEvent — 登录、注册、密码重置、2FA 更改
• scheduledEvent — 定期触发器（需要 TM_SCHEDULED_EVENTS 许可证）

规则构成：

• 条件 — 触发条件（例如，“入账加密货币交易 > $10,000”）
• 操作：score（增加风险分数）、onHold（冻结交易）、awaitUser（请求确认）、reject（阻止）
• 风险分数（0–100）— 累计计算；多条规则的分数会相加
• 申请人变更 — 将申请人转至其他级别、触发最终拒绝，或转交人工审核
• 案件创建 — 规则匹配时自动创建合规调查案件

自动预评分增强项（对已获得相应许可证的租户启用）：

• AML 监控名单（PEP、制裁、不利媒体）
• 加密货币筛查：Chainalysis、Elliptic、TRM Labs、Merkle Science、Crystal
• Travel Rule 处理
• 设备情报和指纹识别
• BIN 查询和支付方式分析

定期重新 KYC（计划规则）：

• 触发条件：处于级别 X 达 N 天的申请人 → 重新分配到新级别（触发重新验证）
• 需要 TM_SCHEDULED_EVENTS 许可证

TM 功能所需的许可证：KYT、TRAVEL_RULE、TM_SCHEDULED_EVENTS、KYT_ANTI_FRAUD、DEVICE_INTELLIGENCE。

F. 工作流 — sumsub-create-workflow

基于图的路由逻辑：根据条件确定申请人接下来进入哪个级别。

节点类型： applicantLevel（运行一个级别）、exclusiveChoice（条件分支）、manualReview、finalRejection、actions（标签、备注、来源键更改）。

边条件： 根据申请人所在国家、尝试次数、审核决定（通过／拒绝／重新提交）和自定义表达式进行判断。

适用于法规要求基于风险进行路由的情况（低风险走标准 KYC，高风险走 EDD）、重新验证流程或多阶段入驻流程。

G. AML 处置规则 — sumsub-create-aml-resolution-rules

AML 处置规则链：按顺序排列的规则列表，用于自动审核 AML 筛查命中项。每条规则根据条件选择命中项（供应商匹配类型、姓名／出生日期兼容性、风险标签、以往审核），并设置命中项的审核结果——匹配状态（false_positive／potential_match／true_positive）、风险级别、白名单标记、备注——和／或为申请人添加标签。

适用于法规允许或要求系统化处置命中项的情况：自动清除误报、沿用以往审核决定、处理 PEP 不在办公室的情况，或标记需要路由处理的复杂案例。

与其他实体的关系： 当租户具有 WATCHLISTS 权限且级别未设置 disableWatchlists: true 时，筛查会在申请人级别运行；规则链负责管理由此产生的 AML 匹配项。规则标签是通用申请人标签，并会显示在工作流条件 checks.personWatchlist.tags／checks.companyWatchlist.tags 中——例如，规则添加 youngPep 标签，工作流便会将这些申请人路由至人工审核。

需要用于 AI 的 App Token 和租户启用权限（该技能会检测并报告 API 是否不可用）。

H. 交易提交 — sumsub-create-transaction

向 Sumsub 的 KYT 监控系统发送交易数据。与 TM 规则不同：

• 该技能负责数据提交（要发送哪些交易数据）
• TM 规则定义如何处理这些数据（在 Dashboard 中配置）

涵盖：金融交易、旅行规则（加密货币交易对手方数据）、平台事件（登录／注册）。

分析框架

法规要求	Sumsub 实体	技能 / 操作
识别客户（姓名、出生日期、国籍）	APPLICANT_DATA + IDENTITY	sumsub-create-level
文件验证（护照、国民身份证）	IDENTITY（类型、签发国家）	sumsub-create-level
生物识别 / 活体检测	SELFIE（passiveLiveness / activeLiveness）	sumsub-create-level
地址验证	PROOF_OF_RESIDENCE + PoA 预设	sumsub-create-level + sumsub-create-poa-preset
收集税号（TIN、CPF、CNPJ、SSN……）	APPLICANT_DATA（字段）或 E-KYC	sumsub-create-level
资金来源 / 财富来源	QUESTIONNAIRE（SOF/SOW 部分）	sumsub-create-questionnaire
PEP 自我声明	QUESTIONNAIRE + AML watchListCheckSettings	sumsub-create-questionnaire + sumsub-create-level
强化尽职调查（EDD）	单独的 EDD 级别 + 扩展问卷	sumsub-create-level + sumsub-create-questionnaire
PoA 文件时限	按类别设置 PoA 预设 maxMonths	sumsub-create-poa-preset
电子 / 非文件验证	E_KYC docSet，可独立使用或嵌套在 IDENTITY 中	sumsub-create-level + sumsub-check-databases (需 CSM 激活；按国家提供)
KYB — 公司验证	COMPANY / COMPANY_DATA / COMPANY_BENEFICIARIES	sumsub-create-level
基于风险的路由（标准 vs EDD）	使用 exclusiveChoice 的工作流	sumsub-create-workflow
AML 筛查命中的自动审核（清除误报、PEP 规则）	AML Resolution Rule Chain	sumsub-create-aml-resolution-rules
基于筛查结果的路由（例如，标记为 PEP → 人工审核）	AML 规则标签 + 基于 checks.personWatchlist.tags 的工作流条件	sumsub-create-aml-resolution-rules + sumsub-create-workflow
交易监控（阈值、模式）	KYT 规则	sumsub-create-kyt-rules (需要 KYT 许可证)
加密货币 Travel Rule	travelRule 交易类型 + KYT 规则	sumsub-create-kyt-rules (需要 TRAVEL_RULE 许可证)
定期重新进行 KYC 的义务	TM Scheduled 规则 byLevelName	sumsub-create-kyt-rules (需要 TM_SCHEDULED_EVENTS 许可证)
合规案件管理	TM 规则 caseAction	sumsub-create-kyt-rules
提交交易数据	KYT 提交	sumsub-create-transaction
设备检查 / 欺诈防范	DEVICE_CHECK docSet	sumsub-create-level (需要 DEVICE_INTELLIGENCE 许可证)
WebSDK / 前端入驻流程	WebSDK 集成	sumsub-integrate-websdk

---

输出格式

将计划整理为结构清晰的 Markdown 文档，并分为两个明确独立的部分。

**重要：**全文使用实际的 Sumsub 枚举值和字段名，而非文字描述。每个步骤都必须展示将传入 API 调用的具体参数。

# Sumsub Configuration Plan: [Regulation Name] — [Jurisdiction]

## My Understanding
- [Bullet: key requirement 1 from regulation]
- [Bullet: key requirement 2]
- …
[Ask for confirmation here before generating the rest]

---

## ✅ Configure via Skills (available now)

### 1. Verification Level(s)
#### Level: [name] — [purpose, e.g. "standard KYC"]
- `applicantType`: individual | company
- Steps (in order):
  1. `APPLICANT_DATA`
     - `fields`: `[firstName, lastName, dob, country, town, street, postCode]`
     - Tax identifier: `tin` — `required: true` _(Art. N — CPF mandatory for identification)_
  2. `IDENTITY`
     - `docTypes`: `[PASSPORT, ID_CARD, DRIVERS]`
     - `includedCountries`: `[BRA]` _(ISO-3166 alpha-3, or omit for all countries)_
     - Two-sided capture: yes — `ID_CARD` and `DRIVERS` carry CPF on the reverse _(Art. N)_
     - Regulation reference: Art. N
  3. `SELFIE`
     - `videoRequired`: `passiveLiveness` _(default; change to `activeLiveness` if regulation requires motion challenge)_
     - Regulation reference: Art. N
  4. `QUESTIONNAIRE` — `questionnaireDefId`: `[questionnaire-slug]` _(defined in section 2 below)_
  5. `PROOF_OF_RESIDENCE` — `poaPresetId`: `[preset-id]` _(defined in section 3 below)_
  6. `DEVICE_CHECK` — ⚠️ requires `DEVICE_INTELLIGENCE` license _(Art. N — emulators, VPN/Tor, rooted devices)_
- AML watchlist screening: requires the **`WATCHLISTS` tenant entitlement**; when present it is **on by default** — nothing to set _(Art. N — PEP/sanctions screening mandatory)_. If the tenant lacks `WATCHLISTS`, flag it as a blocking entitlement (CSM must enable it). Only note `disableWatchlists: false` if you want to be explicit; pick a provider with `watchListCheckSettings.amlCaseType` only if the regulation/tenant demands a specific one (tenant-gated).
- Countries in scope: `includedCountries: [XXX]` | all countries
→ Next: `sumsub-create-level`

#### Level: [name] — [e.g. "enhanced due diligence"]
- (same structure — add extra steps or stricter liveness as required)
→ Next: `sumsub-create-level`

### 2. Questionnaire(s)
#### Questionnaire: `[id-slug]` — [purpose, e.g. "Risk Profile & Compliance"]
- Sections:
  - `[section-id]` — [Section name, e.g. "Virtual Asset Experience"]
    - `[item-id]`: "[Question text]" — `type: select` — `required: true`
      Options: `[["novice","No experience"],["intermediate","Some experience"],["expert","Expert"]]`
    - `[item-id]`: "[Question text, e.g. risk acknowledgement]" — `type: bool` — `required: true`
      _(Art. N — client must confirm trades outside risk profile)_
  - `[section-id]` — [Section name, e.g. "Source of Funds"]
    - `[item-id]`: "[Question text]" — `type: select` — `required: true`
      Options: `[["employment","Employment/Salary"],["business","Business income"],["savings","Savings"],["investment","Investment returns"],["other","Other"]]`
    - `[item-id]`: "Specify other source" — `type: text` — condition: `[section-id].[item-id] = other`
→ Next: `sumsub-create-questionnaire`

### 3. Proof of Address Preset
- Accepted categories and max document age:
  - `governmentOrganization` — [N] months _(Art. N)_
  - `bank` — [N] months
  - `utilityProvider` — [N] months
  - `mobileOperator` — [N] months
- Cross-validation: enabled | disabled — _(name/address match between POI and POA)_
- POI-as-POA: yes | no
- Country overrides: [ISO-3 code — category/maxMonths changes, if any]
→ Next: `sumsub-create-poa-preset`

### 4. Workflow
- [Description of routing: standard KYC → if high-risk → EDD → manual review]
- Conditions: [by country / by questionnaire score / etc.]
→ Next: `sumsub-create-workflow`

### 5. AML Resolution Rules (AML Resolution Rule Chain)
[Include only if the regulation addresses AML hit handling]
- Rule: [name] — [plain language: which hits → what review/tag]
  e.g. "Hits whose name and date of birth both mismatch the applicant → false positive"
  e.g. "PEP hits under age 30 → tag `youngPep`" _(routed by the workflow in section 4)_
- Rule order: [decisive rules first, broad clean-up rules last]
- Regulation reference: Art. N
→ Next: `sumsub-create-aml-resolution-rules`

### 6. Transaction Data Submission (KYT)
- Transaction types to instrument: `finance` | `travelRule` | `userPlatformEvent`
- Required fields per transaction: [counterparty name, wallet address, etc.] — _(Art. N)_
→ Next: `sumsub-create-transaction`

### 6. Transaction Monitoring Rules
[Only include if regulation requires transaction monitoring. Requires `KYT` license.]

#### Rule: [name]
- `types`: `finance` | `travelRule` | `kyc` | `userPlatformEvent` | `scheduledEvent`
- Trigger: [plain language, e.g. "incoming transaction above $10,000"]
- `action`: `score [N]` | `onHold` | `awaitUser` | `reject`
- Case creation: yes | no — [group by applicant / by rule]
- Regulation reference: Art. N
- Client lists referenced: [`clientLists.<name>` — contents, or the Sumsub-maintained list it points at] _(omit if none)_
→ Next: `sumsub-manage-client-lists` (for each list to build) → `sumsub-create-kyt-rules`

#### Periodic Re-KYC rule [if applicable — requires `TM_SCHEDULED_EVENTS` license]
- Trigger: customers at level [X] after [N] days
- Action: reassign to level [Y] for re-verification
- Regulation reference: Art. N
→ Next: `sumsub-create-kyt-rules`

---

## ⚠️ Configure in Sumsub Dashboard

### Activate TM rules
New rules are created in test mode (`dryRun: true`). To make them live: open each rule in the dashboard (KYT → Rules Manager) and set it to **Active**.

### Bulk client-list import
Client lists referenced in rule conditions are created and populated with `sumsub-manage-client-lists`, but values are added one at a time (300 per hour). A list of more than a few dozen entries is loaded as a CSV import in the dashboard.

---

## 🔒 E-KYC (electronic non-document verification)
[Include only if applicable to the jurisdiction]

- Jurisdiction: [country]
- Configuration path: `sumsub-create-level` — after CSM activation
- Availability check: `sumsub-check-databases` resolves which sources [country] actually offers, whether they're enabled, and each source's placement (top-level validation vs. standalone/nested non-doc step)
- Activation steps:
  1. Contact your Sumsub CSM to request activation for [country]
  2. Run `sumsub-create-level` with the `E_KYC` docSet (standalone, or nested inside `IDENTITY`) — per-country sources and placement confirmed via `sumsub-check-databases`

---

## Out of Scope for Sumsub
[List requirements from the regulation that Sumsub does not handle]
- [e.g. 5-year data retention — handle in your own infrastructure]
- [e.g. Reporting to [authority] — handle via your compliance team]

---

## Suggested Execution Order
1. `sumsub-create-questionnaire` (needed before level creation)
2. `sumsub-create-poa-preset` (needed before level creation)
3. `sumsub-create-level` (standard KYC level)
4. `sumsub-create-level` (EDD level, if needed)
5. `sumsub-create-workflow` (if risk-based routing needed)
6. `sumsub-create-aml-resolution-rules` (if AML hit auto-review needed; before the workflow when it routes on rule tags — the tag must exist first)
7. `sumsub-create-kyt-rules` (TM rules, if regulation requires transaction monitoring)
8. `sumsub-create-transaction` (instrument transaction submission)
9. Dashboard — activate TM rules (move from test mode to live)

---

规则

1. 语言： 使用与用户请求相同的语言作答。
2. 先思考： 在组织回复前进行深入思考——法规文本内容繁杂，要求往往隐含其中。
3. 一次处理一个司法管辖区： 如果文档涉及多个司法管辖区，请先询问要为哪个司法管辖区制定方案。不要主动提供涵盖多个司法管辖区的方案。
4. 生成前先确认： 分析后，先提供「我的理解」摘要，并等待用户确认，再生成完整方案。
5. 不要使用 JSON： 此技能仅生成文本描述。绝不生成 API 负载、JSON 对象或配置代码。
6. 具体明确： 方案必须使用实际的 Sumsub 参数名称和枚举值，而非文字描述。写 docTypes: [PASSPORT, ID_CARD, DRIVERS]，不要写“护照和国民身份证”。写 videoRequired: passiveLiveness，不要写“高级活体检测”。写 fields: [firstName, lastName, dob, tin]，不要写“姓名和税号”。使用 ISO-3166 alpha-3 国家代码（例如 BRA，而不是“巴西”）。指定问卷项目类型（bool、select、text）。使用 Capability Map 中按国家划分的证件映射表，将本地证件名称转换为 IdDocType 代码。
7. 明确标注边界： 方案中的每一项都必须标为 ✅（当前技能可实现）或 ⚠️（需通过 Dashboard 实现／技能仍在开发中）。不得模糊处理边界。
8. E-KYC 始终为可选项： 始终标明 E-KYC 需要 CSM 激活。列出激活步骤，不得将其作为默认选项。
9. 仅以通俗语言说明 TM 和 AML 处理规则： 用业务语言描述触发条件和操作（例如，“拦截超过 $50,000 的交易”“姓名和出生日期不匹配的命中结果 → 误报”）。不要编写 SumScript 表达式、条件 AST 或技术规则语法——这些转换由 sumsub-create-kyt-rules 和 sumsub-create-aml-resolution-rules 处理。
10. 未经明确要求，不制定 TM 规则： 仅当法规明确要求交易监控时，才在方案中加入 TM 规则。
11. 许可证： 标明 DEVICE_INTELLIGENCE、E_KYC_TARGET、KYT、TRAVEL_RULE、TM_SCHEDULED_EVENTS 需要核实许可证。
12. 超出范围： 明确列出法规包含但 Sumsub 无法满足的要求（例如数据保留、向主管机关报告等）。

---

相关技能

技能	调用时机
sumsub-create-level	始终调用——这是每次法规分析的核心输出
sumsub-check-databases	法规要求进行非证件／数据库验证时调用——在构建时核实各国数据源是否可用（由 sumsub-create-level 调用）
sumsub-create-questionnaire	法规要求收集 SOF、PEP、财富、就业或风险概况信息时调用
sumsub-create-poa-preset	法规要求验证地址时调用
sumsub-create-workflow	法规要求基于风险的路由、EDD 流程或多阶段开户流程时调用
sumsub-create-aml-resolution-rules	法规涉及 AML 命中处理时调用——误报清除、PEP 审核政策或由筛查触发的升级处理
sumsub-create-kyt-rules	法规要求制定交易监控规则时调用（阈值、可疑模式、定期重新 KYC、Travel Rule）
sumsub-create-transaction	法规要求提交交易监控数据时调用
sumsub-integrate-websdk	法规包含用户体验或前端开户要求时调用
sumsub-api-generic	创建新实体前检查现有配置