sumsub-analyze-regulation

Sumsub — Analyze Regulation

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.

Workflow

Step 1 — Gather context

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.

Step 2 — Analyze (think before responding)

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
• AML screening obligations (PEP / sanctions / adverse media) and how screening hits must be handled (false-positive clearing, PEP review policy, escalation of confirmed matches)
• 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)

Step 3 — Validate understanding first

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

Only after user confirmation, produce the full configuration plan using the output format below.

Sumsub Capability Map

A. Verification Levels — sumsub-create-level

Defines the sequence of verification steps an applicant must complete. Each step is a docSet.

Available docSet types:

Level properties:

• applicantType: individual or company
• requiredIdDocs: the ordered list of docSets + optional includedCountries / excludedCountries
• disableWatchlists: set to true if tenant has WATCHLISTS entitlement but needs to disable AML Screening for a particular level
• crossCheckPresetId: cross-check preset for AML screening

IDENTITY — document type codes

Sumsub uses generic IdDocType values regardless of what the document is locally called. Map the regulation's document names to these types:

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.

SELFIE — liveness options (videoRequired)

For most AML/KYC regulations without a specific liveness requirement, default to passiveLiveness.

APPLICANT_DATA — common field names

Standard personal-data fields:

When a regulation mandates collection of a national tax or identity number, map it to tin and mark it required: true.

DEVICE_CHECK — what it detects

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.

B. Questionnaires — 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.

C. Proof of Address Presets — 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

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

⚠️ 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.

E. Transaction Monitoring — 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.

F. Workflows — 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.

G. AML Resolution Rules — sumsub-create-aml-resolution-rules

The AML Resolution Rule Chain: an ordered list of rules that auto-review AML screening hits. Each rule selects hits by condition (vendor match types, name/DoB compatibility, risk labels, previous reviews) and sets the hit's review — match status (false_positive / potential_match / true_positive), risk level, whitelisted flag, note — and/or tags the applicant.

Use when the regulation permits or requires systematic hit disposition: auto-clearing false positives, carrying over prior review decisions, PEP out-of-office handling, or flagging nuanced cases for routing.

Relationship to other entities: the screening runs on an applicant level when the tenant has WATCHLISTS entitlement and the level doesn't set disableWatchlists: true; the rule chain governs what happens to the AML matches it produces. Rule tags are common applicant tags and surface in workflow conditions as checks.personWatchlist.tags / checks.companyWatchlist.tags — e.g. a rule tags youngPep, a workflow routes those applicants to manual review.

Requires an AI-purpose App Token and tenant enablement (the skill detects and reports if the API is unavailable).

H. Transaction Submission — 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).

Analysis Framework

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.

# 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
→ Next: `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**.

### KYT Client Lists
Adding values to client lists referenced in rule conditions (e.g., country blocklists, peer allowlists) is a dashboard-only operation: KYT → Client Lists.

---

## 🔒 E-KYC (electronic non-document verification)
[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

---

## 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)

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 and AML resolution rules in plain language only: describe trigger conditions and actions in business language (e.g., "block transactions over $50,000", "hits with mismatching name and date of birth → false positive"). Do not write SumScript expressions, condition ASTs, or technical rule syntax — sumsub-create-kyt-rules and sumsub-create-aml-resolution-rules handle 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.).

Related Skills