Sumsub Create Kyt Rules

Sumsub — KYT Rules, Applicant Scoring & Risk Levels

Configures the full KYT transaction monitoring stack:

• Rules — translates user intent into KytTxnRule payloads and POSTs them one at a time. Supports creating new rules and modifying existing ones (by posting a new revision). New rules always start in testMode (dryRun: true) — they appear in dryScore but do not affect the live outcome until activated in the dashboard.
• Tags & applicant scoring — creates and configures tags (named risk markers) and the assessment that maps tag weights into a composite applicant risk score.
• Risk levels — configures the score thresholds that translate a numeric risk score into a human-readable label (e.g. Low / Med / High).

Rules, tags, and risk levels form a single pipeline: a rule fires → applies tags → tags accumulate a weighted score → score maps to a risk level.

Endpoints

See `references/kyt-rule-schema.md` for the full rule SumScript expression field reference and type system.

Auth — App Token + secret (sandbox only)

This skill talks to the public Sumsub API and signs each request per the authentication reference. The full how-it-works writeup lives in the `sumsub-api-auth` skill — read it if you hit 401 Invalid signature.

⚠️ Sandbox tokens only. Do not accept or use a production App Token here. If the user offers one, refuse and ask them to generate a sandbox pair at <https://cockpit.sumsub.com/checkus/home?sbx=true> (Connect Sumsub to your AI agent -> Build & configure -> Generate token). Token + secret are shown once — copy both before closing the dialog. The helper script enforces this — it rejects tokens that don't start with sbx:.

If the user has already supplied credentials in conversation, reuse them; otherwise ask once before running. Never echo the secret back.

Tenant Entitlements

Entitlements are gated per transaction type, not globally. Each types value needs any one of the keys listed for it — not all of them. There is no baseline entitlement that every rule requires: KYT is the entitlement for the finance type, nothing more.

A tenant that has only TRAVEL_RULE can create travelRule rules. A tenant that has only DEVICE_INTELLIGENCE can create kyc rules. Neither needs KYT. Do not require KYT for a type whose row does not list it.

Before creating or modifying a rule, run bash scripts/check_permissions.sh from the `sumsub-check-permissions` skill directory. The response body is {"allowedChecks": {"<KEY>": "<description>", ...}} — the keys of allowedChecks are the enabled entitlements. There is no allowed array.

Stop only when the requested type is not enabled — i.e. none of the keys on that type's row appear in allowedChecks. Do not build or POST that rule. Name the type as the user sees it (see Transaction Types — kyc is "Verification session events", never "kyc"), list the keys that would enable it joined by "or", and tell the user to contact their CSM or Sumsub support. Do not offer a different transaction type as a workaround — if the user wants a travelRule rule, a finance rule is not a substitute.

If the entitlement request itself fails (non-200, timeout), warn the user that entitlements could not be verified and proceed anyway. The backend is the authority and enforces the same gate on POST — see the No allowed transaction types found row in step 6.

Note on scheduled rules. The scheduled trigger mode is licensed by TM_SCHEDULED_EVENTS specifically, while the scheduledEvent type is also enabled by KYT. A tenant with only KYT may therefore pass this gate and still be refused by the backend on noEventTrigger. Build the rule as usual and surface the backend error verbatim if that happens.

Procedure

1. Fetch tenant entitlements — only when creating or modifying a rule. Run sumsub-check-permissions and keep the keys of allowedChecks. Once you know the rule's types, check that row in Tenant Entitlements and abort if none of its keys are present.

Skip this step entirely for work that is not a rule: tags, applicant assessment, risk levels, and client lists need no entitlement. Do not look for an entitlements endpoint other than the one sumsub-check-permissions calls — there is no other one.

1. Determine mode — create or modify.