Skip to main content

Core concept

Flows, steps, routes 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.

Routes​

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

  • verified
  • not_verified
  • fraud_detected

In the flow, the route taken determines the next step: it either leads 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, not_verified, and fraud_detected, each leading to a dedicated End Step. Example of an IDV Step with multiple routes, 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, not_verified, fraud_detected).

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

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.

Input source selection​

When multiple upstream steps produce data blocks of the same type, the platform uses the last produced instance by default. You can override this by configuring a step to read from a specific upstream source, ensuring the correct instance is consumed.

For example, if both the Start step and an Identity verification step produce a BasicIdentity, an AML screening step downstream can be configured to always use the verified identity from the IDV step, regardless of what else may be available in the flow context.

This configuration is optional. Steps that do not specify a source continue to use the default behavior (last produced instance).

Controlling the API response​

End steps use the same mechanism to define which data blocks are included in the final API response. Without explicit configuration, the response contains all data blocks accumulated during the flow. With it, only the selected data blocks are returned alongside the OutcomeStatus.

Each End step can be configured independently. For example, an "accepted" End step may return verified identity data and document results, while a "rejected" End step may return only the outcome status.

Multiple instances of the same type​

Some steps require multiple instances of the same data block type as input (for example, two BasicIdentity data blocks for comparison). These steps reference two distinct upstream sources explicitly. See Identity comparison for details.

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 port "verified" is taken.

A simplified transition object looks like this:

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

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

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 (verified, not_verified, fraud_detected) 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.