KYC Update - Use Cases
KYC Update - Use Cases Overview
The following use cases illustrate how the KYC Update lifecycle behaves across both standard and edge-case scenarios.
They are designed to help you (your platform) understand:
- How the lifecycle evolves over time
- How different events impact account status
- What actions are expected from you and your end-users
🟢 Happy Path — Success
REQUESTED → UNDER_ANALYSIS → ACCEPTED
REQUESTED → UNDER_ANALYSIS → ACCEPTED
- KYC Update is triggered
- User submits updated information
- Compliance validates successfully
- Requirements cleared
- No restrictions applied
- Account remains fully operational
No action needed
Best case
🟠 Scenario A — Resubmission
REJECTED → ACCEPTED
REQUESTED → UNDER_ANALYSIS → REJECTED → UNDER_ANALYSIS → ACCEPTED
- Submission rejected by compliance
- No restriction applied
- You generate a new link
- User corrects and resubmits
- Accepted → requirements cleared
🟠 Scenario B — Overdue
OVERDUE → ACCEPTED
REQUESTED → OVERDUE → UNDER_ANALYSIS → ACCEPTED
- Restriction created → KYC_OUTDATED
- Wallets blocked or restricted
- You generate recertification link
- Restriction remains during review
- Accepted → account unblocked
🟠 Scenario C — Complex Recovery
OVERDUE → REJECTED → ACCEPTED
REQUESTED → OVERDUE → UNDER_ANALYSIS → REJECTED → UNDER_ANALYSIS → ACCEPTED
- Account already restricted
- Submission rejected
- Restriction remains active
- User must resubmit again
- Accepted → restriction removed
🔴 Scenario D — Partial Blocking
Restricted Operations
OVERDUE → isRestricted = true
- No full block but limited operations
- Depends on profile (Investor, Project Holder, etc.)
- You must handle partial UX
- Accepted → full functionality restored
Updated about 4 hours ago