Step Types Overview
Common Step Properties
All step types share these base properties:Document Upload Step
Collect and process documents with automatic data extraction.Configuration
Document Requirement Properties
Document Types
Individual Documents
Company Documents
Tax certificate cardinality. A
tax_certificate requirement allows one active upload by default because allow_multiple defaults to false; uploading it again replaces the previous document entry for that requirement. Set allow_multiple: true when the workflow must retain several tax certificates in the same step. A session can also contain more than one tax certificate when different steps request the same type. Consequently, consumers of GET /kyc/sessions/{session_id} should treat matching documents and extraction results as a collection keyed by doc_id, not as a session-wide singleton.Business Documents
Generic
Example: Multiple Document Requirements
Form Fill Step
Collect structured data using custom form fields with semantic validation.Configuration
Form Fill Properties
See the Field Types documentation for complete field type reference including semantic fields like
country, name, wallet, domain, and volume.Selfie Step
Capture a selfie photo for face matching against ID documents.Configuration
Selfie Config Properties
Liveness Step
Perform AWS Rekognition Face Liveness detection to verify the user is a real person and prevent spoofing attacks (printed photos, masks, deep fakes).Configuration
Liveness Config Properties
Challenge Types
Frontend Integration
The frontend must integrate with AWS Rekognition Face Liveness SDK:Example: Complete Liveness Workflow
Subsession Collection Step
Collect verification from related parties (UBOs, submerchants, directors) by creating independent subsessions that can be completed by third parties.Configuration
Subsession Config Properties
How It Works
- User reaches subsession step: The frontend displays the subsession collection UI
- Create subsessions: User creates one or more subsessions (up to
max_subsessions) - Share links: Each subsession has its own public access link to share with third parties
- Third parties complete verification: Each third party completes their subsession independently
- Proceed or wait: Depending on
require_completion_before_proceed, the user can proceed immediately or must wait
Completion Behavior
When require_completion_before_proceed: false
- User can complete the step and proceed immediately after creating subsessions
- Subsessions continue independently
- Parent session can be approved even if subsessions are pending
When require_completion_before_proceed: true
- User cannot proceed until all created subsessions are completed or approved
- Frontend should show subsession status and block the “Continue” button
- Useful for strict UBO verification requirements
Status Impact
Whenimpact_parent_status: true:
- If any subsession is rejected, the parent session may be flagged for manual review
- All subsession results are aggregated in the parent session’s processing results
- Watchlist hits or adverse media from subsessions are included in parent session
Example: UBO Workflow for Subsessions
Create a simple workflow for UBO verification:Example: Company KYC with UBO Subsessions
Frontend Integration
The frontend receives the subsession_collection step configuration and should:- Display the step instructions
- Show a form/button to create new subsessions
- List existing subsessions with their status
- Show copy/share buttons for subsession links
- Allow regenerating links if needed
- Block progression if
require_completion_before_proceedis true and subsessions are pending
Complete Workflow Example
Related Documentation
- Field Types - All available field types
- Automation Rules - Automation configuration
- Sessions - Managing KYC sessions
- Public Sessions - Subsessions - Public API for subsession management