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.