Skip to main content

Workflow Model

A workflow is the recipe a verification follows — an ordered sequence of steps that collect data, evaluate it, and decide an outcome. The Company picks a workflow when starting a session; the platform runs it to completion and returns the result.

Steps​

A workflow is an ordered list of steps. Steps come in two kinds:

KindRunsExamples
Capture stepsOn the User's device (mobile SDK or web component)Document capture, face capture, liveness, NFC chip reading, mobile handoff
Evaluation stepsServer-side, after data is capturedTrust evaluation, face duplicity check, document duplicity check, 1:1 face matching

Capture steps​

These ask the client app/web to produce data (an image, a chip read)

  • Mobile redirect - a handoff to mobile phone in case the onboarding originated on a desktop
  • Document capture
  • Face capture
  • Smile capture
  • Multirange capture
  • NFC capture - triggers reading of the document chip, the Document capture needs to precede this step
  • External capture - gives a signal to client to trigger a additional capture not covered by IDV Platform

Evaluation steps​

These produce results (a score, a match, a duplicity check outcome). Later steps can read the results of earlier ones.

  • Trust factor eval - evaluates the trust factors of the captured Digital Identity
  • Face duplicity check - performs the 1:N facial identification against the watchlists and updates the duplicity check status
  • Document duplicity check - performs the 1:N search for a person with the same personal details on ID document and updates the duplicity check status
  • Matching - performs the 1:1 face comparison of the captured Digital Identity against a the customer record whose ID was defined at the beginning of the workflow
  • Decision - perform the decision, return the outcome result and trigger the outcome actions

Decisions and outcomes​

A workflow reaches a verdict through decision points. A decision evaluates the results gathered so far against a set of rules and either:

  • ends the workflow with a terminal state (Accept / Review / Reject / Incomplete), or
  • continues to the next step (for example, an age check that passes on the selfie estimate, or otherwise falls through to a document check).

Each rule produces a named outcome. Named outcomes map to actions — the side effects that run when that outcome fires.

Actions​

When an outcome fires, its actions apply the result to the Company's records :

  • create_new_customer - create a new Customer from the attempt and add the person to the Customer watchlist
  • add_new_DI_to_customer - link the Digital Identity record of the attempt to an existing Customer (merge);
  • repoint_primary_DI - set the Digital Identity record of the attempt as the Customer's primary identity (repoint);
  • 1N_add_current_to_blocklist - add the person to the Blocklist;
  • 1N_move_to_review - keep the person in review watchlist for the period of manual review
  • emit_event - emit a custom event to the Company's backend (see Webhooks).

Which actions run for which outcome is part of the workflow definition, so the same verification can behave differently per Company policy.

Sessions and versioning​

  • A session is one run of a workflow for one User. The client holds a session identifier and drives it step by step.
  • When a session starts, it is pinned to the workflow version active at that moment and runs that version to completion — later edits never disrupt an in-flight session.
  • Sessions have an idle timeout; an abandoned session expires and ends as Incomplete.

See also​