Skip to main content

Core concept

Flows, steps, verdicts and data blocks​

This page explains the core building blocks of the IDnow Trust Platform and how they work together to form end-to-end flows:

  • Flow: A sequence of steps that produces a final outcome of a flow
  • Start & End Steps: Every flow has a Start step and one or more End steps. End steps define the final outcome
  • Operational Steps: Execute logic such as reading inputs, writing data blocks, and producing verdicts
  • Verdicts: Step results that determine output data blocks and the next route
  • Data Blocks: Typed inputs or outputs of a step, based on the verdict
  • Routes: Named paths that lead to another step or an End step

Flows​

A flow defines how input data moves through a series of steps until a final outcome is produced.

Minimal flow with Start, a single processing Step, and an End Step.

Start and end step​

Every flow must contain exactly one Start step as its entry point and at least one End step representing a final outcome. Each session of a flow always ends in an End step, and therefore always results in a outcome that can be either accepted or rejected.

Between the Start step and the End step, you can add any combination of operational steps to perform actions, transform data and control the routing of the flow.

Operational steps​

Operational Steps are modular building blocks within a flow, each representing a single operational step. Typical examples include Document-based IDV, Biometric authentication or Trust Services.

Each step session results in exactly one verdict, which in turn determines:

  • which data blocks are produced or updated, and
  • how the flow continues via Routes to either another Step or an End step.

Verdicts​

Each step can produce verdicts, which describe the result of a step operation. For example, the verdicts of an Document-based IDV step are:

  • verified
  • fraud
  • failure

In the flow, the verdict is used to select the next route: it either routes to a follow-up step or to an End step, which sets the final outcome shown in the API response (for example, accepted or rejected).

IDV Step with three outcomes: verified, fraud, and failure, each leading to a dedicated End Step. Example of an IDV Step with multiple verdicts, each mapped to a dedicated End Step.

Data blocks​

Each step consumes and produces typed data blocks.

Examples of such data blocks could be ExtendedIdentity, DocumentVerification and DocumentData.

Data blocks keep data consistent as it moves through the flow. The platform determines which data blocks are available at each step, verifies that all required inputs are present, and ensures data dependencies are satisfied before executing a step.

The data block structure is preserved in the API response after a flow session, making it easy to trace data from the initial input to the final outcome.

As step output​

The verdict of a step determines which data blocks it produces.

As an example, in an identity verification flow, a capture failure produces no DocumentData or ExtendedIdentity, while a capture failure or a fraud verdict always includes DocumentVerification results.

Many data blocks also carry the step’s verdict to indicate the outcome of the check that generated them.

IDV Step producing different data blocks for different verdicts (verified, fraud, failure).

An Identity verification step generates different data blocks depending on whether the verdict is verified, fraud, or failure.

As step input​

Some steps, such as AML screening

  • produces a PepAndSanctionsResults data block as output.
  • but require a BasicIdentity data block as input.

Each step defines which data blocks it requires and which it produces for each verdict.

Data blocks flow from each step’s outputs to the inputs of the next steps. These definitions allow the system to validate the flow, ensuring all required inputs are available before a step executes. The data block can be included in the initial API request when a flow is executed as shown in the example below.

Missing data blocks​

If a required data block is missing, the step cannot execute. As an example, an AML screening step requires a BasicIdentity data block, which can be provided either

  • in the initial API request or
  • produced by an upstream step

All outputs from a step are added to the flow context, making them accessible to all of its descendant steps. As a result, any Step that generates a BasicIdentity, such as an Identity verification step, can satisfy the AML screening step’s input requirement.

Duplications​

In more complex flows, a step may require multiple instances of the same data block type as input (for example, two BasicIdentity data blocks for comparison). In such cases, the steps input array contains the same data block type multiple times, with each occurrence representing a separate instance.

When multiple upstream steps generate data blocks of the same type as output, the platform currently uses the last produced instance.

Routes​

Routes define how flows choose their next step. Routes are named exits on a step and determine which path the flow follows. Routes effectively turn step verdicts into transitions:

  • If a step ends in the verified scenario, the transition with route "verified" is taken.
  • If a transition has no route, it maps to the default scenario.

A simplified transition object looks like this:

{
  "id": "next_Step_id", // Identifier of the target step
  "route": "verified" // Named route for conditional transitions (e.g., "verified", "failure")
}

When a step is configured with multiple output scenarios, the scenario keys act as route names (for example, verified, fraud_detected, capture_failed, default).

Putting it together​

A flow is composed of steps, verdicts, data blocks, and routes. When designing a flow:

  1. Define the initial process steps
    For example, start with an ID verification step that outputs multiple verdicts (success, fraud, capture_failed) through corresponding routes, each connected to the appropriate next step or end step.

  2. Reuse outputs between Steps
    Data blocks produced by one step can be used as inputs to downstream steps. For instance, a BasicIdentity data block created during ID verification can be passed to an AML screening step, which then produces its own verdict and PepAndSanctionsResults data blocks.

  3. Extend the flow as needed
    Add additional steps for risk checks, digital signals, signatures, or evidence collection. Each step follows the same pattern of verdicts, data blocks, and routes.

By combining steps, verdicts, data blocks, and routes, you can build complex trust flows.

By understanding these building blocks, you can compose complex trust flows simply by wiring steps together. The platform handles session, data propagation, and audit trails automatically.