sumsub-analyze-regulation

Sumsub — 規制の分析

規制文書を読み込み、構造化された Sumsub の設定計画を作成します。各規制要件を、それを満たす Sumsub のエンティティに対応付け、スキルを通じて今すぐ設定できる項目と、Sumsub Dashboardでの設定が必要な項目を明確に区別します。

これは計画立案専用のスキルです。テキストによる説明のみを作成し、JSON ペイロードや API 呼び出しは生成しません。

ワークフロー

Step 1 — コンテキストの収集

分析の前に、以下の情報を収集します。

• 管轄区域 — 文書が複数の国を対象としている場合や、対象が曖昧な場合は、明確に確認してください。 「この規制は［国のリスト］を対象としています。計画の対象とする管轄区域を指定してください。」 直接の依頼がない限り、すべての管轄区域を対象とした計画を同時に作成しないでください。
• 事業種別 — 暗号資産取引所、ネオバンク、iGaming、フィンテック、またはその他。文書から明確でない場合は確認してください。
• クライアントの種類 — 個人、法人、またはその両方。
• 既存の Sumsub 設定 — ユーザーがすでに何かを設定しているか確認してください。重複する提案は避けてください。

Step 2 — 分析（回答する前に考える）

回答をまとめる前に、拡張思考を使用してください。文書から以下の内容を抽出します。

• 顧客の本人確認要件（本人確認が必要な対象者、必要なデータ）
• 受け入れ可能な本人確認書類（国民 ID、パスポート、納税者番号など）
• 住所確認要件（受け入れ可能な書類、有効期限の上限）
• 強化されたデューデリジェンスの条件（EDD の実施が必要となる条件）
• 資金源／財産／PEP に関するデータ収集要件
• AML スクリーニング義務（PEP／制裁／ネガティブメディア）と、スクリーニングで該当があった場合の対応（誤検知の解消、PEP 審査ポリシー、確認済みの一致のエスカレーション）
• 取引モニタリング要件（しきい値、不審なパターン、暗号資産のトラベルルール）
• 定期的な再 KYC 義務（顧客の再確認頻度）
• Sumsub の対象外となるもの（データ保持期間、規制当局への報告、制裁リストの保守）

Step 3 — まず理解を確認する

分析後、抽出した要件を箇条書きにした簡潔な**「理解した内容」**ブロックを提示し、次のように確認してください。 「主要な要件を正しく理解できていますか？ 追加または修正する点はありますか？」

ユーザーの確認を得るまでは、完全な計画を作成しないでください。 これは必須です。

Step 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 カード（国を問わず）	ID_CARD
運転免許証	DRIVERS
居住許可証／移民許可証	RESIDENCE_PERMIT
有権者 ID	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 ライセンスが有効な場合、このステップではエミュレーター、ルート化／ジェイルブレイクされたデバイス、VPN／プロキシ／Tor 接続、リモートデスクトップソフトウェア、暗号資産ミキサーツールを検出します。テナントに権限がない場合、このステップは通知なく無効に切り替わることを必ず計画に記載し、GET による検証ステップを追加してください。

B. アンケート — sumsub-create-questionnaire

書類チェックでは取得できない申請者データを収集するためのカスタムフォームです。

一般的なユースケース： 資金源、資産形成の経緯、雇用、PEP に関する自己申告、取引経験、リスクプロファイル。

質問タイプ： text、textArea、date、dateTime、bool、select、selectDropdown、multiSelect、phone、countrySelect、countryMultiSelect、fileAttachment、multiFileAttachments。

条件ロジック： セクションや項目は、以前の回答に応じて表示／非表示にできます。

リスクスコアリング： 各回答の選択肢に score（0～100）を設定できます。スコアは自動的に合算され、後続の取引モニタリングルールで参照できます。

レベルごとにアンケートは1つです。 資金源、PEP に関する自己申告、リスクプロファイルなどの異なるトピックは、個別のアンケートではなく、1つのアンケート内の別々のセクションとしてまとめてください。各レベルにつき QUESTIONNAIRE ステップは1つをデフォルトとします。別のレベルには、そのレベル専用のアンケートを設定できます（例：拡張アンケートを含む EDD レベル）。これは例外ではなく、あくまでレベルごとに1つというルールの範囲内です。同じレベルに複数のアンケートを計画するのは、ユーザーが明示的に要求した場合に限ります。

C. 住所証明のプリセット — sumsub-create-poa-preset

住所証明として受け付ける書類の再利用可能な設定です。

書類カテゴリ：

• governmentOrganization — 政府発行書類（有権者登録証、納税通知書など）
• utilityProvider — 公共料金の請求書
• bank — 銀行の取引明細書およびレター
• mobileOperator — 通信料金の請求書
• other

主な設定：

• カテゴリごとの maxMonths — 書類の最大経過月数
• クロスバリデーション： 身分証明書（POI）と住所証明書類（POA）の氏名／住所を照合 — あいまい一致または厳密一致モード
• PoI-as-PoA： 身分証明書そのものを住所証明として受け付ける
• ネオバンクのブロックリスト： 特定の金融機関（Revolut、N26、Wise など）の書類を除外する
• 国別のオーバーライド： 国ごとに異なるルールを設定する

D. E-KYC（書類不要の電子本人確認）

⚠️ Sumsub カスタマーサクセスマネージャー（CSM）を通じて、国ごとに個別の有効化が必要です。ライセンス：E_KYC_TARGET。

有効化後、sumsub-create-level で設定します。

仕組み： 申請者が一意の識別情報（TIN、書類番号、銀行ログイン情報）を提出し、外部データベースと照合して検証します。書類写真は不要です。

設定モードは2種類です：

1. スタンドアロンの E_KYC docSet — 電子本人確認のみです。申請者は代わりに書類をアップロードできません
2. データベースソースの checkSourceSettings を内包した IDENTITY docSet — 申請者は同じステップで、書類写真をアップロードするか、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 式に変換し、API に POST します。新しいルールは常にテストモード（dryRun: true）で開始され、有効化にはダッシュボードでの操作が必要です。

名前付きセット（clientLists.<name> — 高リスク国、ブロック対象のメールアドレス、ピア許可リストなど）と照合するルールでは、まず sumsub-manage-client-lists でリストを作成し、データを登録する必要があります。独自にリストを作成する計画を立てる前に、Sumsub が管理するリスト（fatf_black_flag_countries、eu_high_risk_third_countries、…）を確認してください。

取引タイプ：

• finance — 金融取引（法定通貨と暗号資産）
• travelRule — トラベルルール（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
• トラベルルール処理
• デバイスインテリジェンスとフィンガープリンティング
• 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（タグ、メモ、source-key の変更）。

エッジ条件： 申請者の国、試行回数、審査結果（承認／却下／再提出）、カスタム式。

規制によりリスクベースのルーティング（低リスクには標準的な 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 Rules とは異なります。

• このスキルはデータの送信（送信する取引データ）を扱います。
• TM Rules は、そのデータに対して何を行うかを定義します（Dashboard で設定）。

対象：金融取引、トラベルルール（暗号資産の取引相手データ）、プラットフォームイベント（ログイン／登録）。

分析フレームワーク

規制要件	Sumsub のエンティティ	スキル／アクション
顧客の特定（氏名、生年月日、国籍）	APPLICANT_DATA + IDENTITY	sumsub-create-level
書類確認（パスポート、国民ID）	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
リスクベースの振り分け（標準と 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 ライセンスが必要です)
暗号資産のトラベルルール	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

---

出力形式

2 つのセクションを明確に分けた、構造化された Markdown ドキュメントとして計画を作成してください。

重要： 説明文ではなく、実際の Sumsub の enum 値とフィールド名を全体で使用してください。各ステップには、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. 一度に扱う法域は1つ： 文書が複数の法域を対象としている場合は、作業を進める前に、どの法域を対象とするかを確認してください。求められていない複数法域の計画を作成しないでください。
4. 作成前に確認する： 分析の後、「理解した内容」の要約を提示し、ユーザーの確認を待ってから、完全な計画を作成してください。
5. JSON は使用しない： このスキルで作成するのはテキストによる説明のみです。API ペイロード、JSON オブジェクト、設定コードは決して生成しないでください。
6. 具体的に記述する： 計画では、文章による説明ではなく、実際の Sumsub のパラメーター名と列挙値を使用してください。「パスポートと国民 ID」ではなく、docTypes: [PASSPORT, ID_CARD, DRIVERS] と記述してください。「高度なライブネス」ではなく、videoRequired: passiveLiveness と記述してください。「氏名と納税者番号」ではなく、fields: [firstName, lastName, dob, tin] と記述してください。国コードは ISO-3166 alpha-3（「ブラジル」ではなく BRA）を使用してください。質問項目の種類（bool、select、text）を明記してください。ローカルの文書名を IdDocType コードに変換するには、Capability Map の国別文書マッピング表を使用してください。
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	規制で UX またはフロントエンドのオンボーディング要件が定められている場合に呼び出します。
sumsub-api-generic	新しいエンティティを作成する前に、既存の設定を確認します。