Tracking onboarding status
Tracking onboarding status helps platforms monitor participant progress throughout the onboarding and verification lifecycle. Status information provides visibility into outstanding requirements, verification outcomes, remediation activities, and participant readiness for activation. Understanding onboarding status enables platforms to support participants more effectively, streamline operational processes, and identify actions required to complete onboarding.
Status model
Onboarding status has two levels. The participant has an overall status, and underneath it sits a list of the steps still outstanding.
| Status | Description |
|---|---|
| Pending | Application in flight |
| Active | Cleared and able to accept payouts, dated from the day it opened |
| Declined | Not approved, with the reason attached |
| Suspended | Open but stopped |
| Closed | Ended, with fraud closures distinguished from ordinary ones |
Only outstanding steps are reported: phone verification, consent, agreements, business verification, and identity verification. A cleared step drops off the list, so an active participant with no outstanding steps is done. Each outstanding step reads as one of three states.
| Outstanding Step State | Description |
|---|---|
| Awaiting action | Something is needed from the participant |
| Pending | Under evaluation; nothing to do but wait |
| Declined | Not approved; the reason travels with it |
Identity steps are reported per owner, so one beneficial owner can be pending while others are clear. A declined business check ends the application; a cleared one doesn't auto-clear the owners.
Pending actions
An outstanding step names the action: verify the phone, upload a document, or accept an agreement. Each carries an identifier so you can tie a response back to the request, a human-readable message you can surface to the participant, and for document requests the category being asked for. Use the action rather than the participant's last screen to determine what comes next.
Failure and remediation reasons
Failures arrive as field errors or verification shortfalls. Missing or invalid data comes back naming the exact field at fault, so it can be corrected directly. Verification shortfalls come back as a document request, which repeats as verification narrows down what it needs; past the retry limit the application is declined.
A decline is terminal. It carries its reason, but the application itself can't be reopened, corrected, or resubmitted — submitted information is locked at that point. Where the outcome rested on wrong or mistyped information, you can request a new application for that participant with the corrected details. Design for this by validating key fields before submit.
Where status is visible
| Location | Description |
|---|---|
| API | The current step state and pending actions, returned on every save and readable on demand |
| CCC dashboard | Operational view — onboarding performance monitoring and a breakdown of the most common failure reasons |