SumsubUser action with decisionBeta

Verify identity (Sumsub)

Starts a Sumsub identity verification for a natural-person contact, displays the verification experience, then routes the process on the provider decision.

Business object

Vérifier l’identité (Sumsub)

Approuvé

Rejeté

Relance

Revue requise

Applicant Sumsub

Identity check Sumsub

Vue d’ensemble

Objectif

This node encapsulates the Sumsub identity journey without requiring the process designer to manipulate an applicant, SDK token, or provider event directly.

It creates or reuses the Sumsub applicant linked to the Ormuz subject, opens a verification user action, then resumes the process when Sumsub returns the applicantReviewed decision.

identity_check is the main business output: it carries result, decision, review_answer, review_reject_type, and Sumsub rejection labels.

The node routes directly on identity_check.decision with approved, rejected, retry, and review_required branches. It therefore replaces the user-action + router pair in standard processes.

When the subject is a persisted contact and review reaches a terminal decision, the node directly materializes the corresponding platform.compliance_check under its write permission.

When the Sumsub review contains AML, PEP, or sanctions signals, the node may materialize a second distinct aml_compliance_check with check_type: aml.

When the subject is a contact draft, the check cannot be materialized until the canonical contact exists; correlation remains carried by the onboarding_case.

scope is an Ormuz business scope for the compliance check. It is neither a Sumsub parameter nor an API authorization scope.

Quand l’utiliser

You need to verify the identity of a contact or contact_draft during customer onboarding.
You want to use an existing Sumsub level, for example ID only, ID + liveness, or ID + phone, without changing the process graph.
The process must route on the KYC result before approving, rejecting, or retrying a case.

Parameters 8

extension_config_idRequisref(extension_config:sumsub)

Active Sumsub provider configuration. It carries the Sumsub credentials and webhook secret used for this journey.

subjectRequisContact

Business subject to verify. The node accepts a persisted platform.contact or a contact draft from onboarding.

level_nameRequisstring

Name of the Sumsub level to apply. The level carries the Sumsub-side business scenario, for example ID only, ID + liveness, or ID + phone.

onboarding_caseOptionnelOnboarding case

Onboarding case associated with the check. Required when subject is a contact draft because its identifier then serves as the Sumsub correlation key.

scopeOptionnelstring

Business scope written to compliance_check.scope when the check is materialized. Keep identity_verification unless you need to distinguish several compliance checks for the same subject.

check_typeOptionnelstring

Check type to write to the materialized compliance_check. Default: kyc.

titleOptionnelstring

Title displayed in the user action. Default: Verify your identity.

descriptionOptionnelstring

Supporting text shown in the user action.

Outputs 5

sumsub_applicantSumsub applicant

Sumsub provider object exposing the verified applicant. It carries the applicant identifier and correlation used by the provider decision.

identity_checkSumsub identity check

Provider-native business result of the identity check. identity_check.decision is the source of node routes.

selected_routeenum

Route selected by the node, derived from identity_check.decision.

compliance_checkOptionnelCompliance check

Persisted Compliance Check created or reused after a terminal Sumsub decision when the subject is a persisted contact.

aml_compliance_checkOptionnelCompliance check

Additional persisted AML check when the review contains an AML, PEP, sanctions, or watchlist signal. Provider granularity remains in raw_response.

Behavior

Prepare the applicant

The node associates the Ormuz subject with an existing Sumsub applicant or creates one. For a contact, externalUserId is the contact identifier. For a contact draft, externalUserId is the onboarding_case identifier.

Display verification

A user action opens with the context required by the Sumsub component. The process remains waiting while the user completes verification.

Wait for the provider decision

After submission, the process waits for the extension.sumsub.applicant_reviewed event matching the applicant. Intermediate events may be observed, but the business decision comes from the review.

Route the journey

identity_check.decision becomes selected_route. approved continues the nominal journey, rejected branches to final rejection, retry restarts user correction, and review_required branches to manual review.

Materialize the compliance check

When Sumsub responds for a persisted contact with a terminal decision, the node creates or reuses the canonical compliance_check with provider provenance. A green result becomes passed and a final rejection becomes failed; retry outcomes remain routing decisions and do not materialize a terminal fact.

Process example