Orchestration use cases
Real-world flows you can build by combining Trust Platform capabilities
Trust Platform is built around four capabilities that you combine into flows to address your specific compliance, fraud prevention, and onboarding requirements:
- Identify
- Authenticate
- Protect
- Trust
The sections below describe each capability and illustrate how they come together in concrete use cases.
Capabilities
Identify
Identify covers all forms of identity verification — establishing who the end-user actually is by collecting and verifying their identity attributes.
| What you can verify | Relevant steps |
|---|---|
| Identity document + liveness | Document-based IDV (v3), Document-based IDV (v4) (Preview), Sphinx (v2), Sphinx (v3) (Preview), Document-based IDV (v2) (Deprecated), Sphinx (v1) (Deprecated) |
| Identity document — API only | Document-based IDV headless (v1), Document-based IDV headless (v2) (Preview) |
| Electronic identity (eID) | eID (v2), German eID, France Identité, EUDI Wallet (v2), eKYC UK (v1) (Preview), eID (v1) (Deprecated), EUDI Wallet (v1) (Deprecated) |
| Phone number | Phone verification (v1) |
| Residential address | Proof of address (v1) |
| Bank account (IBAN) | IBAN verification (v1) |
Authenticate
Authenticate lets you confirm that a returning user is the same person who was originally verified, without asking them to repeat the full identity verification process.
This requires two flows working in sequence: an enrolment flow that captures a biometric reference during initial onboarding, and an authentication flow that compares a new biometric sample against that reference on each subsequent session.
| What you can do | Relevant steps |
|---|---|
| Enrol a biometric reference | Biometric enrolment |
| Verify identity via biometric match | Biometric authentication (v2) (Preview), Biometric authentication (v1) |
Protect
Protect surfaces fraud signals and screens individuals against financial crime watchlists. It is used both to make real-time onboarding decisions and to run recurring background checks on an existing customer base.
| What you can do | Relevant steps |
|---|---|
| Screen against PEP and sanctions lists | AML screening, PEP and sanctions (Deprecated) |
| Detect device-level fraud signals | Device intelligence |
| Verify email and phone as fraud signals | Email and phone verification |
| Cross-check identity against a stored record | Identity comparison (v2) (Preview), Identity comparison (v1) |
Trust
Trust enables the collection of legally binding digital signatures on documents as part of a flow. A signature can be issued immediately after identity verification completes, or collected on a pre-existing document without requiring a full IDV step.
| What you can do | Relevant steps |
|---|---|
| Issue a signature immediately after IDV | Instant signature issuance, Document-based IDV with instant signature issuance (Deprecated) |
| Sign a document without a user-facing IDV step | Headless signing |
| Collect a signature alongside full IDV | Doc ID signing (v3) (Preview), Doc ID signing (v2) |
Usecases
KYC: enduser onboarding
From interestee to customer — regulated onboarding for financial services, fintechs, and payment institutions where an individual must be identified and screened before becoming a customer.
Capabilities used: Identify + Protect
How a flow is typically structured:
-
Offer the right verification method for the market. Use a Method selector step so users in eID-capable markets (Germany, France, EU wallet) can complete verification electronically, while users in other markets proceed via camera-based document capture. Alternatively, use a Conditional routing step to branch on a country value supplied at session creation and route directly to the appropriate step without presenting a choice.
-
Verify identity. On the eID path, the step authenticates the user cryptographically against the chip in their identity document. On the document capture path, the step checks document authenticity, extracts the holder's personal data, and performs a liveness check.
-
Screen against PEP and sanctions lists. Connect an AML screening step after the IDV result. The verified name and date of birth from step 2 are carried automatically as data blocks — no duplicate data entry.
-
Apply risk-based routing for additional checks (optional). Use a Conditional routing step to inspect AML results or risk signals supplied at session creation. Route elevated-risk users to additional steps — proof of address, IBAN verification, or device intelligence — before they reach the final outcome.
-
Decide. Route clean results to an accepted End step and matches or failures to a rejected End step.
Daily AML checks for PSPs
Recurring sanctions and PEP screening — Payment Service Providers are required by AML regulations to continuously monitor their customer base, not just at onboarding. This use case describes a headless, API-triggered flow with no Player UI.
Capabilities used: Protect
How a flow is typically structured:
-
Pre-supply identity data at session creation. The flow's Start step is configured to accept identity data blocks (name, date of birth, nationality) provided by your system when the session is created via the API. No user interaction is needed — the individual does not participate in this session.
-
Screen against watchlists. The AML screening step receives the pre-supplied identity data and runs it against current PEP, sanctions, and adverse-media sources.
-
Route on the result. A Conditional routing step evaluates the screening outcome:
no_match→ accepted End step. The result is available via webhook and the sessions API for your compliance records.match→ rejected End step (or a separate path that triggers a case management workflow in your system via webhook).
-
Trigger from your scheduler. Your system calls the Create Session API once per customer per screening cycle (daily, weekly, or event-triggered). Each call produces an independent session with its own audit trail, timestamped result, and webhook delivery.
Because the flow has no user-facing steps, sessions complete immediately without waiting for Player input. The screening latency is determined by the watchlist provider response time.
Newcomer employee verification
From successful applicant to employee — onboarding a new hire from the point of offer acceptance, covering identity verification, contract signing, and biometric enrolment for future authentication.
Capabilities used: Identify + Protect + Trust + Authenticate
How a flow is typically structured:
-
Verify the employee's identity. Use a Document-based IDV step or an eID step to confirm the applicant's identity and extract their verified personal data. For roles with enhanced vetting requirements, follow this with an AML screening step to check against PEP and sanctions lists.
-
Verify supporting contact details (optional). Add a Phone verification step to confirm the employee's registered mobile number, and/or a Proof of address step for roles that require documented residency.
-
Collect the employment contract signature. Use an Instant signature issuance step or a Doc ID signing step to have the employee sign the employment contract and any required onboarding documents within the same session. The verified identity from step 1 backs the signature, providing a complete and auditable chain of evidence.
-
Enrol a biometric reference for future authentication. End the onboarding flow with a Biometric enrolment step. This stores a biometric reference tied to the verified identity, which can then be used in subsequent Biometric authentication flows — for example, to authenticate the employee before they access sensitive systems or approve internal documents.