Check Orchestration
The check framework automatically creates, executes, and tracks verification requirements for each entity in a case. Checks are the system’s way of verifying facts about a person or company through external providers.How checks are created
When a case entity is created (either through the API or as part of case creation), the orchestration service automatically:- Reads the verification type configuration for the entity type and role
- Filters by due diligence level (CDD vs EDD)
- Creates the appropriate records based on execution method
Check types and categories
| Category | Check Types | Execution |
|---|---|---|
Screening | PEP Screening, Sanctions Screening, Adverse Media | API |
Identity | Identity Verification, Biometric Verification | API |
Company | Company Registry, Directors Verification, UBO Check | API |
Financial | Credit Check, Source of Wealth | API/Manual |
EDD | Enhanced Due Diligence checks (added when required) | Manual |
Execution modes
Checks execute in one of three modes depending on the provider configuration:- Individual
- Category Batch
- Async (Awaiting Client)
Individual mode
One API call per check. Used for simple, single-purpose verifications.Example: Twilio phone verification — one call verifies one phone number.Check status lifecycle
| Status | Description |
|---|---|
Pending | Created, awaiting execution or manual action |
Queued | Scheduled for automatic execution |
In Progress | Currently executing against an external provider |
Awaiting Document | Hybrid check waiting for document upload |
Awaiting Client | Waiting for client-side action (e.g., selfie capture) |
Complete | Execution finished with a result |
Failed | Execution error or timeout |
Waived | Manually waived by an analyst with documented reason |
Cancelled | Cancelled (e.g., case closed before execution) |
Reused | Valid check from another case reused |
Retry Scheduled | Failed check scheduled for automatic retry |
Check results
Every completed check produces one of three results:| Result | Meaning | Alert generated? |
|---|---|---|
Pass | Verification passed, no issues | No |
Refer | Potential issue, needs review | Yes |
Fail | Verification failed | Yes |
Check reuse (Verify Once, Reference Many)
When a new case creates checks for an entity that has already been verified, the system evaluates existing checks for reuse:- Look up completed, passing checks for the same entity and check type
- Verify the check has not expired (based on validity period)
- If valid, create a
Reusedcheck referencing the original
| Check Category | Default Validity |
|---|---|
| Identity | 365 days |
| Screening | 90 days |
| Company | 180 days |
| Financial | 365 days |
| EDD | 180 days |
Alert generation
Checks that returnRefer or Fail automatically generate alerts:
| Check Result | Alert Category | Alert Priority |
|---|---|---|
| PEP screening match | PEP Match | High |
| Sanctions match | Sanctions Hit | Critical |
| Adverse media hit | Adverse Media | Medium |
| Company dissolved | API Failure | High |
| Name mismatch (< 70%) | Name Mismatch | High/Medium |
| Identity failure | Name Mismatch | Medium |
Next steps
- Alert Management. How generated alerts are triaged and resolved.
- Entity Lifecycle. How entity roles drive check requirements.
- Checks Data Model. Full field reference for check resources.