Core Concepts

Why a new architecture?

The previous architecture was flow-based: each verification was a standalone session with no data persistence between sessions. This made repeat verifications cumbersome, limited extensibility to new verification scenarios (like AML monitoring), and created friction for clients managing multiple verification tiers.

The new platform-centered architecture solves this with four persistent, reusable entities that work together to create a flexible, scalable verification platform.

---

Profile — The user data hub

A Profile is the persistent data record for each end user in your system. Think of it as a long-lived user file that accumulates and retains verified data across multiple verification sessions.

Key characteristics:

• Created once per end user, referenced via your system's externalUserId
• Stores declared information (user-submitted data), verified information (OCR-extracted & confirmed data), identity documents, and risk assessments
• Triggers downstream events to AML Monitor and other compliance modules when data changes
• Enables data re-use: if a user upgrades from Basic KYC to Enhanced KYC, already-verified data is automatically carried forward

Profile states:

---

Application — A single verification session

An Application is a single end-to-end verification run within the context of a specific Level. Each Application is linked to exactly one Profile and one Level, and follows the verification Steps defined by that Level. It has two distinct phases:

• Submit phase — collecting user data (form submissions, document uploads, selfies)
• Check phase — running automated and manual checks against collected data

When an Application reaches a terminal state, it commits its results and data back to the Profile.

Application States:

---

Step — Verification components

A Step is a specific verification capability that users complete as part of the Application workflow. Each Step guides the user through data collection and validation for a particular aspect of identity verification.

Common Steps include:

• Document — User uploads identity documents (passport, ID card, etc.). System performs OCR extraction and forgery detection.
• Face — User captures a selfie and completes a liveness challenge to prove they are a real person. System compares the face against the document photo.
• AML — System screens the user against international sanctions lists, PEP databases, and watchlists. May include ongoing monitoring.

Steps are sequenced in order within a Level, defining the user's verification journey. The system executes each Step in sequence, collecting and validating data as it progresses.

---

Level — A verification template

A Level defines what verification a user must complete. It is a versioned configuration template that specifies which Steps to include, in what order, and how to configure each Step's behavior.

Key characteristics:

• Each Level has a unique identifier (e.g., basic-kyc, enhanced-kyc, aml-only)
• Levels are versioned — changes to a Level do not affect Applications already in progress
• Different Levels represent different compliance requirements, jurisdictions, or product tiers

Each Level specifies:

• Which Steps are required and their execution order
• Configuration for each Step (document types required, liveness mode, screening vendors, manual review triggers, etc.)
  

Example Levels

How they work together