Back to Details

sumsub-analyze-regulation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Sumsub — Analyze Regulation

Sumsub — 监管文档分析

Reads a regulation document and produces a structured Sumsub configuration plan — mapping each regulatory requirement to the Sumsub entities that satisfy it, with a clear split between what can be configured now via skills and what requires the Sumsub Dashboard.
This is a planning skill only. It produces a text description, never JSON payloads or API calls.
读取监管文档并生成结构化的Sumsub配置方案——将每项监管要求映射到满足该要求的Sumsub实体，明确区分哪些内容可通过现有技能配置，哪些需要通过Sumsub控制台配置。
本技能仅用于规划，仅生成文本描述，不会生成JSON负载或API调用。

Workflow

工作流程

Step 1 — Gather context

步骤1 — 收集背景信息

Before analyzing, collect:
  • Jurisdiction — if the document covers multiple countries or is ambiguous, ask explicitly: "This regulation covers [list of countries]. Which jurisdiction should the plan focus on?" Do not generate a plan for all jurisdictions simultaneously without a direct request to do so.
  • Business type — crypto exchange, neobank, iGaming, fintech, or other. Ask if not clear from the document.
  • Client types — individuals, companies, or both.
  • Existing Sumsub setup — has the user already configured anything? Avoid suggesting duplicates.
分析前，需收集以下信息：
  • 管辖区域——若文档涉及多个国家或内容模糊，需明确询问： "该监管规则覆盖[国家列表]。配置方案应聚焦哪个管辖区域？" 若无明确要求，请勿同时为所有管辖区域生成配置方案。
  • 业务类型——加密货币交易所、数字银行、在线博彩、金融科技或其他类型。若文档未明确说明，需询问用户。
  • 客户类型——个人、企业，或两者皆有。
  • 现有Sumsub配置——用户是否已完成部分配置？避免重复建议。

Step 2 — Analyze (think before responding)

步骤2 — 分析（思考后再回复）

Use extended thinking before formulating the response. Extract from the document:
  • Customer identification requirements (who must be identified, what data is required)
  • Acceptable identity documents (national ID, passport, tax number, etc.)
  • Address verification requirements (what documents are accepted, maximum age)
  • Enhanced Due Diligence conditions (what triggers EDD)
  • Source of funds / wealth / PEP data collection requirements
  • Transaction monitoring requirements (thresholds, suspicious patterns, crypto Travel Rule)
  • Periodic re-KYC obligations (how often customers must be re-verified)
  • What is out of scope for Sumsub (data retention timelines, regulatory reporting, sanctions list maintenance)
在制定回复前需充分思考，从文档中提取以下信息：
  • 客户身份识别要求（需识别哪些对象，需收集哪些数据）
  • 可接受的身份证明文件（国民身份证、护照、税号等）
  • 地址验证要求（可接受的文件类型、文件最大有效期）
  • 强化尽职调查（EDD）触发条件
  • 资金来源/财富来源/政治公众人物（PEP）数据收集要求
  • 交易监控要求（阈值、可疑模式、加密货币Travel Rule）
  • 定期重新KYC义务（客户需多久重新验证一次）
  • Sumsub不覆盖的范围（数据保留期限、监管报告、制裁名单维护）

Step 3 — Validate understanding first

步骤3 — 先验证理解是否正确

After analysis, present a short "My Understanding" block — bullet points of extracted requirements — and ask: "Have I understood the key requirements correctly? Anything to add or correct?"
Do not generate the full plan until the user confirms. This is mandatory.
分析完成后，展示简短的**"我的理解"**模块——以项目符号列出提取的要求，并询问： "我对核心要求的理解是否正确？是否有需要补充或修正的内容？"
在用户确认前，请勿生成完整配置方案。此步骤为强制要求。

Step 4 — Generate the plan

步骤4 — 生成配置方案

Only after user confirmation, produce the full configuration plan using the output format below.
仅在用户确认后，按照下文的输出格式生成完整配置方案。

Sumsub Capability Map

Sumsub能力映射

A. Verification Levels — 
sumsub-create-level

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

Defines the sequence of verification steps an applicant must complete. Each step is a 
docSet
.
Available docSet types:
TypePurpose
IDENTITY
Document verification: PASSPORT, ID_CARD, DRIVERS, RESIDENCE_PERMIT, VOTER_ID, etc. Can be restricted by issuing country.
SELFIE
/ 
SELFIE2
Biometrics and liveness.
APPLICANT_DATA
Personal data collection: full name, date of birth, address, nationality, tax number (TIN/CPF/CNPJ/etc.).
PROOF_OF_RESIDENCE
/ 
PROOF_OF_RESIDENCE2
Address document verification. References a PoA preset by 
poaStepSettingsId
.
PHONE_VERIFICATION
/ 
EMAIL_VERIFICATION
Contact verification via OTP.
QUESTIONNAIRE
/ 
QUESTIONNAIRE2–4
Custom form. References a questionnaire definition by 
questionnaireDefId
.
E_KYC
Non-document electronic verification against external databases. See E-KYC section.
DEVICE_CHECK
Device intelligence and fingerprinting. Requires 
DEVICE_INTELLIGENCE
license.
COMPANY
KYB: company info collection.
COMPANY_DATA
KYB: company data fields.
COMPANY_DOCUMENTS
KYB: corporate documents upload.
COMPANY_BENEFICIARIES
KYB: UBOs and representatives verification.
ACCREDITED_INVESTOR
Accredited investor qualification.
E_SIGN
Electronic signature capture.
TR_RECIPIENT_INFORMATION
Travel Rule recipient data collection.
Level properties:
  • applicantType
    : 
    individual
    or 
    company
  • requiredIdDocs
    : the ordered list of docSets + optional 
    includedCountries
    / 
    excludedCountries
  • watchListCheckSettings
    : enables AML/PEP/sanctions screening via watchlists
  • crossCheckPresetId
    : cross-check preset for AML screening
定义申请人需完成的验证步骤序列，每个步骤为一个
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
关联地址证明预设。
PHONE_VERIFICATION
/ 
EMAIL_VERIFICATION
通过OTP验证联系方式。
QUESTIONNAIRE
/ 
QUESTIONNAIRE2–4
自定义表单。通过
questionnaireDefId
关联调查问卷定义。
E_KYC
无文档电子验证，对接外部数据库。详见E-KYC章节。
DEVICE_CHECK
设备智能与指纹识别。需
DEVICE_INTELLIGENCE
授权。
COMPANY
企业KYC（KYB）：企业信息收集。
COMPANY_DATA
KYB：企业数据字段。
COMPANY_DOCUMENTS
KYB：企业文件上传。
COMPANY_BENEFICIARIES
KYB：最终受益所有人（UBO）与代表验证。
ACCREDITED_INVESTOR
合格投资者资质认定。
E_SIGN
电子签名采集。
TR_RECIPIENT_INFORMATION
Travel Rule收件人数据收集。
层级属性：
  • applicantType
    : 
    individual
    或 
    company
  • requiredIdDocs
    : 有序的docSet列表 + 可选的
    includedCountries
    / 
    excludedCountries
  • watchListCheckSettings
    : 启用通过监控名单进行反洗钱（AML）/PEP/制裁筛查
  • crossCheckPresetId
    : AML筛查的交叉验证预设ID

IDENTITY — document type codes

IDENTITY — 文档类型代码

Sumsub uses generic 
IdDocType
values regardless of what the document is locally called. Map the regulation's document names to these types:
Generic document classSumsub 
IdDocType
International / biometric passport
PASSPORT
National identity card (any country)
ID_CARD
Driver's licence
DRIVERS
Residence / immigration permit
RESIDENCE_PERMIT
Voter ID
VOTER_ID
Documents with no dedicated Sumsub type (e.g. tax cards, social security cards)
OTHER_DOCS
includedCountries
/ 
excludedCountries
use ISO-3166 alpha-3 (e.g. 
BRA
, 
USA
, 
DEU
).
Two-sided capture should be specified whenever a mandatory identifier (tax number, national number) appears on the back of the document.
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 — liveness options (
videoRequired
)

SELFIE — 活体检测选项 (
videoRequired
)

ValueDescriptionUse when
passiveLiveness
Default. Advanced passive liveness, no movement required.Standard KYC — no stricter regulatory mandate.
activeLiveness
Active motion challenge (head movement detection).Regulation explicitly requires active/dynamic liveness.
enabled
Short video — applicant pronounces displayed digits.Regulation requires video identity check.
photoRequired
Photo-only selfie, no liveness.Use only when explicitly requested; generally insufficient for AML compliance.
staticLiveness
Single-frame analysis.Use only when explicitly requested.
For most AML/KYC regulations without a specific liveness requirement, default to 
passiveLiveness
.
值描述使用场景
passiveLiveness
默认选项。高级被动活体检测，无需动作。标准KYC——无更严格监管要求时。
activeLiveness
主动动作挑战（头部移动检测）。监管明确要求主动/动态活体检测时。
enabled
短视频——申请人朗读显示的数字。监管要求视频身份核验时。
photoRequired
仅照片自拍，无活体检测。仅在明确要求时使用；通常不足以满足AML合规要求。
staticLiveness
单帧分析。仅在明确要求时使用。
对于大多数无特定活体检测要求的AML/KYC监管规则，默认使用
passiveLiveness
。

APPLICANT_DATA — common field names

APPLICANT_DATA — 通用字段名称

Standard personal-data fields:
Field nameMeaning
firstName
First / given name
lastName
Last / family name
dob
Date of birth
country
Country of residence (ISO-3166 alpha-3)
town
City / town
street
Street address
postCode
Postal / ZIP code
nationality
Nationality (ISO-3166 alpha-3)
placeOfBirth
Place of birth
tin
Tax identification number (TIN, CPF, SSN, BSN, etc.)
When a regulation mandates collection of a national tax or identity number, map it to 
tin
and mark it 
required: true
.
标准个人数据字段：
字段名含义
firstName
名
lastName
姓
dob
出生日期
country
居住国（ISO-3166 alpha-3代码）
town
城市/城镇
street
街道地址
postCode
邮政编码/ZIP码
nationality
国籍（ISO-3166 alpha-3代码）
placeOfBirth
出生地
tin
税务识别号（TIN、CPF、SSN、BSN等）
当监管要求收集国家税号或身份编号时，将其映射为
tin
并标记
required: true
。

DEVICE_CHECK — what it detects

DEVICE_CHECK — 检测内容

When 
DEVICE_INTELLIGENCE
license is active, this step flags: emulators, rooted/jailbroken devices, VPN/proxy/Tor connections, remote-desktop software, and crypto-mixer tools. Always note in the plan that this step silently falls back to disabled if the tenant lacks the entitlement — add a GET-back verification step.
当
DEVICE_INTELLIGENCE
授权激活时，此步骤会标记：模拟器、Root/越狱设备、VPN/代理/Tor连接、远程桌面软件、加密货币混币工具。需在方案中注明：若租户无此授权，该步骤会自动禁用——需添加后续验证步骤确认是否生效。

B. Questionnaires — 
sumsub-create-questionnaire

B. 调查问卷 — 
sumsub-create-questionnaire

Custom forms for collecting applicant data not captured by document checks.
Common use cases: source of funds, source of wealth, employment, PEP self-declaration, trading experience, risk profile.
Question types: 
text
, 
textArea
, 
date
, 
dateTime
, 
bool
, 
select
, 
selectDropdown
, 
multiSelect
, 
phone
, 
countrySelect
, 
countryMultiSelect
, 
fileAttachment
, 
multiFileAttachments
.
Conditional logic: sections and items can be shown/hidden based on previous answers.
Risk scoring: each answer option can carry a 
score
(0–100); scores sum automatically and can be referenced in downstream transaction monitoring rules.
One questionnaire per level. Group distinct topics (source of funds, PEP self-declaration, risk profile…) as separate sections within a single questionnaire — not as separate questionnaires. Default to one 
QUESTIONNAIRE
step per level. A separate level legitimately gets its own questionnaire (e.g. an EDD level with an extended questionnaire) — that is still one-per-level, not an exception. Only plan multiple questionnaires on the same level if the user explicitly asks for it.
用于收集文档核验未覆盖的申请人数据的自定义表单。
**常见应用场景：**资金来源、财富来源、职业信息、PEP自我申报、交易经验、风险评估。
问题类型：
text
、
textArea
、
date
、
dateTime
、
bool
、
select
、
selectDropdown
、
multiSelect
、
phone
、
countrySelect
、
countryMultiSelect
、
fileAttachment
、
multiFileAttachments
。
**条件逻辑：**可根据之前的答案显示/隐藏章节和问题项。
**风险评分：**每个答案选项可设置
score
（0–100）；分数自动累加，可用于下游交易监控规则。
每个层级对应一份调查问卷。将不同主题（资金来源、PEP自我申报、风险评估…）作为单个调查问卷内的独立章节，而非创建多份调查问卷。默认每个层级设置一个
QUESTIONNAIRE
步骤。不同层级可拥有独立的调查问卷（如EDD层级使用扩展调查问卷）——这仍符合“一层一问卷”的规则，不属于例外情况。仅当用户明确要求时，才为同一层级规划多份调查问卷。

C. Proof of Address Presets — 
sumsub-create-poa-preset

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

Reusable configuration for what documents are accepted as proof of address.
Document categories:
  • governmentOrganization
    — government-issued (voter registration, tax bill, etc.)
  • utilityProvider
    — utility bills
  • bank
    — bank statements and letters
  • mobileOperator
    — telecom bills
  • other
Key settings:
  • maxMonths
    per category — maximum document age
  • Cross-validation: name/address comparison between identity document (POI) and address document (POA) — fuzzy or strict mode
  • PoI-as-PoA: accept the identity document itself as proof of address
  • Neobank blocklist: exclude documents from specific institutions (Revolut, N26, Wise, etc.)
  • Country-specific overrides: different rules per country
可复用的地址证明可接受文档配置。
文档类别：
  • governmentOrganization
    — 政府签发文件（选民登记证、税单等）
  • utilityProvider
    — 公共事业账单
  • bank
    — 银行对账单与信函
  • mobileOperator
    — 电信账单
  • other
核心设置：
  • maxMonths
    （按类别）——文件最大有效期
  • **交叉验证：**身份证明文件（POI）与地址证明文件（POA）的姓名/地址比对——模糊匹配或严格匹配模式
  • **POI作为POA：**接受身份证明文件本身作为地址证明
  • **数字银行黑名单：**排除特定机构的文件（Revolut、N26、Wise等）
  • **国家专属规则：**不同国家适用不同规则

D. E-KYC (Non-Document Electronic Verification)

D. E-KYC（无文档电子验证）

⚠️ Requires separate activation per country through a Sumsub Customer Success Manager (CSM). License: 
E_KYC_TARGET
.
Configured via 
sumsub-create-level
once activated.
How it works: the applicant submits unique identifiers (TIN, document number, bank login) which are validated against external databases — no document photo required.
Two configuration modes:
  1. Standalone 
    E_KYC
    docSet     — electronic verification only; applicant cannot upload documents instead
  2. IDENTITY
    with 
    ekycAllowed: true
     — applicant chooses: upload document photo OR complete E-KYC
Available database types: 
GOVERNMENT
(national registries), 
CREDIT
(credit bureaus), 
TELCO
(telecom providers), 
BANKING
, 
COMMERCIAL
(business registries), 
CONSUMER
, 
UTILITY
, 
POSTAL
, 
PROPRIETARY
.
Verification methods: 
ENRICHMENT
, 
ONE_X_ONE_MATCHING
, 
TWO_X_TWO_MATCHING
, 
VALIDITY_CHECK
.
Configuration rules:
  • Country coverage depends entirely on client's license activations — there is no universal list
  • Recommended to pair with a 
    SELFIE
    step for biometric verification against database records
Activation steps: (1) contact CSM to request per-country activation, (2) run 
sumsub-create-level
.
⚠️需通过Sumsub客户成功经理（CSM）按国家单独激活。授权：
E_KYC_TARGET
。
激活后可通过
sumsub-create-level
配置。
**工作原理：**申请人提交唯一标识（税号、文档编号、银行登录信息），系统对接外部数据库进行验证——无需上传文档照片。
两种配置模式：
  1. 独立
    E_KYC
    docSet     — 仅电子验证；申请人无法选择上传文档
  2. 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
    步骤，实现与数据库记录的生物识别比对
激活步骤：(1) 联系CSM申请对应国家的激活权限；(2) 运行
sumsub-create-level
。

E. Transaction Monitoring — 
sumsub-create-kyt-rules

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

⚠️ Requires 
KYT
license (and 
TRAVEL_RULE
for crypto, 
TM_SCHEDULED_EVENTS
for periodic re-KYC, 
KYT_ANTI_FRAUD
for platform events).
Describes what to configure at plan time in plain language. 
sumsub-create-kyt-rules
translates each rule into a 
conditionEl
SumScript expression and POSTs it to the API. New rules always start in test mode (
dryRun: true
) — activating them requires the dashboard.
Transaction types:
  • finance
    — financial transactions (fiat and crypto)
  • travelRule
    — crypto transactions subject to Travel Rule (FATF / VASP)
  • kyc
    — KYC-related events
  • userPlatformEvent
    — login, signup, password reset, 2FA changes
  • scheduledEvent
    — periodic triggers (requires 
    TM_SCHEDULED_EVENTS
    license)
Rule anatomy:
  • Condition — trigger (e.g., "incoming crypto transaction > $10,000")
  • Action: 
    score
    (add risk points), 
    onHold
    (freeze transaction), 
    awaitUser
    (request confirmation), 
    reject
    (block)
  • Risk score (0–100) — cumulative; multiple rules sum their scores
  • Applicant change — move applicant to another level, trigger final rejection, or route to manual review
  • Case creation — auto-create a compliance investigation case on rule match
Automated pre-scoring enrichments (active for licensed tenants):
  • AML watchlists (PEP, sanctions, adverse media)
  • Crypto screening: Chainalysis, Elliptic, TRM Labs, Merkle Science, Crystal
  • Travel Rule processing
  • Device intelligence and fingerprinting
  • BIN lookup and payment method analytics
Periodic Re-KYC (Scheduled Rules):
  • Trigger: applicants on level X for N days → reassign to a new level (triggers re-verification)
  • Requires 
    TM_SCHEDULED_EVENTS
    license
Required licenses for TM features: 
KYT
, 
TRAVEL_RULE
, 
TM_SCHEDULED_EVENTS
, 
KYT_ANTI_FRAUD
, 
DEVICE_INTELLIGENCE
.
⚠️需
KYT
授权（加密货币场景需
TRAVEL_RULE
，定期重新KYC需
TM_SCHEDULED_EVENTS
，平台事件监控需
KYT_ANTI_FRAUD
）。
规划阶段需用自然语言描述配置内容。
sumsub-create-kyt-rules
会将每条规则转换为
conditionEl
SumScript表达式并通过API提交。新规则默认处于测试模式（
dryRun: true
）——需通过控制台激活。
交易类型：
  • 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天 → 重新分配至Y层级（触发重新验证）
  • 需
    TM_SCHEDULED_EVENTS
    授权
交易监控功能所需授权：
KYT
、
TRAVEL_RULE
、
TM_SCHEDULED_EVENTS
、
KYT_ANTI_FRAUD
、
DEVICE_INTELLIGENCE
。

F. Workflows — 
sumsub-create-workflow

F. 工作流 — 
sumsub-create-workflow

Graph-based routing logic: determines which level an applicant goes through next based on conditions.
Node types: 
applicantLevel
(run a level), 
exclusiveChoice
(condition branch), 
manualReview
, 
finalRejection
, 
actions
(tags, notes, source-key changes).
Edge conditions: by applicant country, number of attempts, review decision (approved / rejected / resubmission), custom expressions.
Use when regulation requires risk-based routing (standard KYC for low-risk, EDD for high-risk), re-verification flows, or multi-stage onboarding.
基于图形的路由逻辑：根据条件决定申请人下一步进入哪个层级。
节点类型：
applicantLevel
（运行一个层级）、
exclusiveChoice
（条件分支）、
manualReview
（人工审核）、
finalRejection
（最终拒绝）、
actions
（标签、备注、源密钥变更）。
**分支条件：**根据申请人所在国家、尝试次数、审核结果（通过/拒绝/重新提交）、自定义表达式。
适用于监管要求基于风险的路由（低风险用户走标准KYC，高风险用户走EDD）、重新验证流程、多阶段开户场景。

G. Transaction Submission — 
sumsub-create-transaction

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

Sends transaction data to Sumsub's KYT monitoring system. Distinct from TM Rules:
  • This skill handles data submission (what transaction data to send)
  • TM Rules define what to do with that data (configured in the Dashboard)
Covers: finance transactions, Travel Rule (crypto counterparty data), platform events (login/signup).
将交易数据发送至Sumsub的KYT监控系统。与交易监控规则的区别：
  • 本技能负责数据提交（需发送哪些交易数据）
  • 交易监控规则定义数据处理逻辑（通过控制台配置）
覆盖场景：金融交易、Travel Rule（加密货币交易对手数据）、平台事件（登录/注册）。

Analysis Framework

分析框架

Regulation requirementSumsub entitySkill / action
Identify the customer (name, DOB, nationality)
APPLICANT_DATA
+ 
IDENTITY
sumsub-create-level
Document verification (passport, national ID)
IDENTITY
(types, issuing countries)
sumsub-create-level
Biometrics / liveness check
SELFIE
(passiveLiveness / activeLiveness)
sumsub-create-level
Address verification
PROOF_OF_RESIDENCE
+ PoA preset
sumsub-create-level
+ 
sumsub-create-poa-preset
Tax number collection (TIN, CPF, CNPJ, SSN…)
APPLICANT_DATA
(fields) or E-KYC
sumsub-create-level
Source of funds / source of wealth
QUESTIONNAIRE
(SOF/SOW section)
sumsub-create-questionnaire
PEP self-declaration
QUESTIONNAIRE
+ AML 
watchListCheckSettings
sumsub-create-questionnaire
+ 
sumsub-create-level
Enhanced Due Diligence (EDD)Separate EDD level + extended questionnaire
sumsub-create-level
+ 
sumsub-create-questionnaire
PoA document age limitPoA preset 
maxMonths
per category
sumsub-create-poa-preset
Electronic / non-document verification
E_KYC
docSet
sumsub-create-level
(CSM activation required)
KYB — company verification
COMPANY
/ 
COMPANY_DATA
/ 
COMPANY_BENEFICIARIES
sumsub-create-level
Risk-based routing (standard vs EDD)Workflow with 
exclusiveChoice
sumsub-create-workflow
Transaction monitoring (thresholds, patterns)KYT rules
sumsub-create-kyt-rules
(requires 
KYT
license)
Crypto Travel Rule
travelRule
transaction type + KYT rules
sumsub-create-kyt-rules
(requires 
TRAVEL_RULE
license)
Periodic re-KYC obligationTM Scheduled rule 
byLevelName
sumsub-create-kyt-rules
(requires 
TM_SCHEDULED_EVENTS
license)
Compliance case managementTM rule 
caseAction
sumsub-create-kyt-rules
Transaction data submissionKYT submission
sumsub-create-transaction
Device check / fraud prevention
DEVICE_CHECK
docSet
sumsub-create-level
(requires DEVICE_INTELLIGENCE license)
WebSDK / front-end onboarding flowWebSDK integration
sumsub-integrate-websdk
监管要求Sumsub实体技能/操作
客户身份识别（姓名、出生日期、国籍）
APPLICANT_DATA
+ 
IDENTITY
sumsub-create-level
文档验证（护照、国民身份证）
IDENTITY
（类型、签发国家）
sumsub-create-level
生物识别/活体检测
SELFIE
（passiveLiveness / activeLiveness）
sumsub-create-level
地址验证
PROOF_OF_RESIDENCE
+ 地址证明预设
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
地址证明文件有效期限制地址证明预设
maxMonths
（按类别）
sumsub-create-poa-preset
电子/无文档验证
E_KYC
docSet
sumsub-create-level
（需CSM激活）
KYB——企业验证
COMPANY
/ 
COMPANY_DATA
/ 
COMPANY_BENEFICIARIES
sumsub-create-level
基于风险的路由（标准KYC vs EDD）含
exclusiveChoice
的工作流
sumsub-create-workflow
交易监控（阈值、模式）KYT规则
sumsub-create-kyt-rules
（需
KYT
授权）
加密货币Travel Rule
travelRule
交易类型 + KYT规则
sumsub-create-kyt-rules
（需
TRAVEL_RULE
授权）
定期重新KYC义务定时规则
byLevelName
sumsub-create-kyt-rules
（需
TM_SCHEDULED_EVENTS
授权）
合规案例管理交易监控规则
caseAction
sumsub-create-kyt-rules
交易数据提交KYT数据提交
sumsub-create-transaction
设备检测/欺诈防范
DEVICE_CHECK
docSet
sumsub-create-level
（需DEVICE_INTELLIGENCE授权）
WebSDK/前端开户流程WebSDK集成
sumsub-integrate-websdk

Output Format

输出格式

Produce the plan as a structured markdown document with two clearly separated sections.
Critical: use actual Sumsub enum values and field names throughout — not prose descriptions. Every step must show the concrete parameters that will go into the API call.
undefined
以结构化Markdown文档形式生成配置方案，明确分为两个部分。
**关键要求：**全程使用实际Sumsub枚举值和字段名，而非自然语言描述。每个步骤需展示将用于API调用的具体参数。
undefined

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

Sumsub配置方案：[监管规则名称] — [管辖区域]

My Understanding

我的理解

  • [Bullet: key requirement 1 from regulation]
  • [Bullet: key requirement 2]
  • … [Ask for confirmation here before generating the rest]
  • [项目符号：从监管规则提取的核心要求1]
  • [项目符号：核心要求2]
  • … [在此处请求用户确认后再生成剩余内容]

✅ Configure via Skills (available now)

✅ 可通过现有技能配置

1. Verification Level(s)

1. 验证层级

Level: [name] — [purpose, e.g. "standard KYC"]

层级：[名称] — [用途，如“标准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)
  • watchListCheckSettings.enabled
    : true 
    • categories
      : 
      [sanctions, pep, adverseMedia]
      (Art. N — PEP/sanctions screening mandatory)
  • Countries in scope: 
    includedCountries: [XXX]
    | all countries → Next: 
    sumsub-create-level
  • applicantType
    : individual | company
  • 步骤（按顺序）： 
    1. APPLICANT_DATA
      • fields
        : 
        [firstName, lastName, dob, country, town, street, postCode]
      • 税务标识：
        tin
        — 
        required: true
        (第N条——CPF为必填识别项)
    2. IDENTITY
      • docTypes
        : 
        [PASSPORT, ID_CARD, DRIVERS]
      • includedCountries
        : 
        [BRA]
        (ISO-3166 alpha-3代码，若适用于所有国家则省略)
      • 双面采集：是 — 
        ID_CARD
        和
        DRIVERS
        背面含CPF (第N条)
      • 监管规则参考：第N条
    3. SELFIE
      • videoRequired
        : 
        passiveLiveness
        (默认值；若监管要求动作挑战则改为
        activeLiveness
        )
      • 监管规则参考：第N条
    4. QUESTIONNAIRE
      — 
      questionnaireDefId
      : 
      [调查问卷标识]
      (下文第2节定义)
    5. PROOF_OF_RESIDENCE
      — 
      poaPresetId
      : 
      [预设ID]
      (下文第3节定义)
    6. DEVICE_CHECK
      — ⚠️需
      DEVICE_INTELLIGENCE
      授权 (第N条——检测模拟器、VPN/Tor、Root设备)
  • watchListCheckSettings.enabled
    : true 
    • categories
      : 
      [sanctions, pep, adverseMedia]
      (第N条——强制PEP/制裁筛查)
  • 适用国家：
    includedCountries: [XXX]
    | 所有国家 → 下一步：
    sumsub-create-level

Level: [name] — [e.g. "enhanced due diligence"]

层级：[名称] — [用途，如“强化尽职调查”]

  • (same structure — add extra steps or stricter liveness as required) → Next: 
    sumsub-create-level
-（结构同上——根据要求添加额外步骤或更严格的活体检测） → 下一步：
sumsub-create-level

2. Questionnaire(s)

2. 调查问卷

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
  • 章节： 
    • [章节ID]
      — [章节名称，如“虚拟资产交易经验”] 
      • [问题ID]
        : "[问题文本]" — 
        type: select
        — 
        required: true
        选项：
        [["novice","无经验"],["intermediate","有一定经验"],["expert","专家级"]]
      • [问题ID]
        : "[问题文本，如风险确认]" — 
        type: bool
        — 
        required: true
        (第N条——客户需确认超出风险范围的交易)
    • [章节ID]
      — [章节名称，如“资金来源”] 
      • [问题ID]
        : "[问题文本]" — 
        type: select
        — 
        required: true
        选项：
        [["employment","工资/薪金"],["business","经营收入"],["savings","储蓄"],["investment","投资收益"],["other","其他"]]
      • [问题ID]
        : "请说明其他资金来源" — 
        type: text
        — 条件：
        [章节ID].[问题ID] = other
        → 下一步：
        sumsub-create-questionnaire

3. Proof of Address Preset

3. 地址证明预设

  • 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
  • 可接受的文档类别与最大有效期： 
    • governmentOrganization
      — [N]个月 (第N条)
    • bank
      — [N]个月
    • utilityProvider
      — [N]个月
    • mobileOperator
      — [N]个月
  • 交叉验证：启用 | 禁用 — (身份证明文件与地址证明文件的姓名/地址匹配)
  • POI作为POA：是 | 否
  • 国家专属规则：[ISO-3代码——类别/有效期变更（若有）] → 下一步：
    sumsub-create-poa-preset

4. Workflow

4. 工作流

  • [Description of routing: standard KYC → if high-risk → EDD → manual review]
  • Conditions: [by country / by questionnaire score / etc.] → Next: 
    sumsub-create-workflow
  • [路由描述：标准KYC → 若高风险 → EDD → 人工审核]
  • 条件：[按国家 / 按调查问卷分数 / 其他] → 下一步：
    sumsub-create-workflow

5. Transaction Data Submission (KYT)

5. 交易数据提交（KYT）

  • Transaction types to instrument: 
    finance
    | 
    travelRule
    | 
    userPlatformEvent
  • Required fields per transaction: [counterparty name, wallet address, etc.] — (Art. N) → Next: 
    sumsub-create-transaction
  • 需监控的交易类型：
    finance
    | 
    travelRule
    | 
    userPlatformEvent
  • 每份交易需提交的字段：[交易对手名称、钱包地址等] — (第N条) → 下一步：
    sumsub-create-transaction

6. Transaction Monitoring Rules

6. 交易监控规则

[Only include if regulation requires transaction monitoring. Requires 
KYT
license.]
[仅当监管要求交易监控时包含。需
KYT
授权。]

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 → Next: 
    sumsub-create-kyt-rules
  • types
    : 
    finance
    | 
    travelRule
    | 
    kyc
    | 
    userPlatformEvent
    | 
    scheduledEvent
  • 触发条件：[自然语言描述，如“入账金额超过10,000美元”]
  • action
    : 
    score [N]
    | 
    onHold
    | 
    awaitUser
    | 
    reject
  • 案例创建：是 | 否 — [按申请人分组 / 按规则分组]
  • 监管规则参考：第N条 → 下一步：
    sumsub-create-kyt-rules

Periodic Re-KYC rule [if applicable — requires 
TM_SCHEDULED_EVENTS
license]

定期重新KYC规则（若适用——需
TM_SCHEDULED_EVENTS
授权）

  • 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
  • 触发条件：处于[X]层级达[N]天的客户
  • 动作：重新分配至[Y]层级进行重新验证
  • 监管规则参考：第N条 → 下一步：
    sumsub-create-kyt-rules

⚠️ Configure in Sumsub Dashboard

⚠️ 需在Sumsub控制台配置

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.
新规则默认处于测试模式（
dryRun: true
）。如需启用，需在控制台（KYT → 规则管理器）中打开每条规则并设置为激活状态。

KYT Client Lists

KYT客户名单

Adding values to client lists referenced in rule conditions (e.g., country blocklists, peer allowlists) is a dashboard-only operation: KYT → Client Lists.
向规则条件引用的客户名单添加值（如国家黑名单、同行白名单）仅可通过控制台操作：KYT → 客户名单。

🔒 E-KYC (electronic non-document verification)

🔒 E-KYC（电子无文档验证）

[Include only if applicable to the jurisdiction]
  • Jurisdiction: [country]
  • Potentially available databases: GOVERNMENT | CREDIT | BANKING
  • Configuration path: 
    sumsub-create-level
    — after CSM activation
  • Activation steps:
    1. Contact your Sumsub CSM to request activation for [country]
    2. Run 
      sumsub-create-level
      with the 
      E_KYC
      docSet
[仅当适用于该管辖区域时包含]
  • 管辖区域：[国家]
  • 可用数据库：GOVERNMENT | CREDIT | BANKING
  • 配置路径：
    sumsub-create-level
    — CSM激活后
  • 激活步骤：
    1. 联系Sumsub CSM申请[国家]的激活权限
    2. 运行
      sumsub-create-level
      并配置
      E_KYC
      docSet

Out of Scope for Sumsub

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]
[列出监管规则中Sumsub无法满足的要求]
  • [示例：5年数据保留——需自行在内部系统处理]
  • [示例：向[监管机构]提交报告——需由合规团队处理]

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-kyt-rules
    (TM rules, if regulation requires transaction monitoring)
  7. sumsub-create-transaction
    (instrument transaction submission)
  8. Dashboard — activate TM rules (move from test mode to live)

---
  1. sumsub-create-questionnaire
    （层级创建前需完成）
  2. sumsub-create-poa-preset
    （层级创建前需完成）
  3. sumsub-create-level
    （标准KYC层级）
  4. sumsub-create-level
    （EDD层级，若需）
  5. sumsub-create-workflow
    （若需基于风险的路由）
  6. sumsub-create-kyt-rules
    （交易监控规则，若监管要求）
  7. sumsub-create-transaction
    （配置交易数据提交）
  8. 控制台——激活交易监控规则（从测试模式切换至正式模式）

---

Rules

规则

  1. Language: respond in the same language as the user's request.
  2. Think first: use extended thinking before formulating the response — regulation texts are dense and requirements are often implicit.
  3. One jurisdiction at a time: if the document covers multiple jurisdictions, ask which one to plan for before proceeding. Do not produce multi-jurisdiction plans unprompted.
  4. Validate before generating: after analysis, present the "My Understanding" summary and wait for user confirmation before producing the full plan.
  5. No JSON: this skill produces text descriptions only. Never generate API payloads, JSON objects, or configuration code.
  6. Be concrete: the plan must use actual Sumsub parameter names and enum values, not prose descriptions. Write 
    docTypes: [PASSPORT, ID_CARD, DRIVERS]
    , not "Passport and national ID". Write 
    videoRequired: passiveLiveness
    , not "advanced liveness". Write 
    fields: [firstName, lastName, dob, tin]
    , not "name and tax number". Include country codes in ISO-3166 alpha-3 (
    BRA
    , not "Brazil"). Name questionnaire item types (
    bool
    , 
    select
    , 
    text
    ). Use the country-specific document mapping table in the Capability Map to translate local document names to IdDocType codes.
  7. Mark the boundary clearly: every item in the plan must be in either ✅ (skills available now) or ⚠️ (Dashboard / skill in development). Never leave the boundary ambiguous.
  8. E-KYC is always opt-in: always mark E-KYC as requiring CSM activation. List the activation steps. Do not present it as a default option.
  9. TM rules in plain language only: describe trigger conditions and actions in business language (e.g., "block transactions over $50,000"). Do not write SumScript expressions or technical rule syntax — 
    sumsub-create-kyt-rules
    handles that translation.
  10. No TM rules without explicit requirement: only include TM rules in the plan if the regulation explicitly requires transaction monitoring.
  11. Licenses: flag 
    DEVICE_INTELLIGENCE
    , 
    E_KYC_TARGET
    , 
    KYT
    , 
    TRAVEL_RULE
    , 
    TM_SCHEDULED_EVENTS
    as requiring license verification.
  12. Out of scope: explicitly list requirements the regulation contains that Sumsub cannot fulfill (data retention, authority reporting, etc.).
  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
    ）。使用能力映射中的国家专属文档映射表，将本地文档名称转换为IdDocType代码。
  7. 明确边界： 方案中的每项内容需明确归类到✅（现有技能可配置）或⚠️（控制台/开发中技能）。边界不可模糊。
  8. E-KYC需主动申请： 需明确标记E-KYC需CSM激活，并列出激活步骤。请勿将其作为默认选项。
  9. 交易监控规则仅用自然语言： 用业务语言描述触发条件和动作（如“拦截超过50,000美元的交易”）。请勿编写SumScript表达式或技术规则语法——
    sumsub-create-kyt-rules
    会负责转换。
  10. 无明确要求则不配置交易监控规则： 仅当监管明确要求交易监控时，才在方案中包含交易监控规则。
  11. 授权提示： 标记
    DEVICE_INTELLIGENCE
    、
    E_KYC_TARGET
    、
    KYT
    、
    TRAVEL_RULE
    、
    TM_SCHEDULED_EVENTS
    需验证授权状态。
  12. 明确不覆盖范围： 列出监管规则中Sumsub无法满足的要求（数据保留、监管报告等）。

Related Skills

相关技能

SkillWhen to invoke
sumsub-create-level
Always — core output of every regulation analysis
sumsub-create-questionnaire
Regulation requires SOF, PEP, wealth, employment, or risk profile collection
sumsub-create-poa-preset
Regulation requires address verification
sumsub-create-workflow
Regulation requires risk-based routing, EDD flow, or multi-stage onboarding
sumsub-create-kyt-rules
Regulation requires transaction monitoring rules (thresholds, suspicious patterns, periodic re-KYC, Travel Rule)
sumsub-create-transaction
Regulation requires transaction monitoring data submission
sumsub-integrate-websdk
Regulation has UX or front-end onboarding requirements
sumsub-api-generic
Check existing configuration before creating new entities
技能调用时机
sumsub-create-level
必选——所有监管分析的核心输出
sumsub-create-questionnaire
监管要求收集资金来源、PEP、财富、职业或风险评估信息时
sumsub-create-poa-preset
监管要求地址验证时
sumsub-create-workflow
监管要求基于风险的路由、EDD流程或多阶段开户时
sumsub-create-kyt-rules
监管要求交易监控规则（阈值、可疑模式、定期重新KYC、Travel Rule）时
sumsub-create-transaction
监管要求提交交易监控数据时
sumsub-integrate-websdk
监管有UX或前端开户流程要求时
sumsub-api-generic
创建新实体前检查现有配置时