Checklist · CRM Account Operations
Client Onboarding States: A Transition Checklist
Define onboarding states, allowed transitions and decision owners using an illustrative workflow with rejection, resubmission and authorization checks.
Published Updated
Published by FxTrusts, a supplier of brokerage and prop firm technology. Prepared with AI-assisted research and drafting; reviewed against the cited public sources. Examples are illustrative. Product links describe our services.
Quick answer
An onboarding state machine defines the allowed stages of a client application and the actions that move it between them. Each transition needs conditions, an authorized actor and an audit record. A status label alone does not establish that identity, legal eligibility or account permissions have been approved.
Model the decision being represented
Draft, submitted, under review, approved and rejected can be useful application states, but their meaning must be defined by the operating policy. Approval for one purpose does not automatically approve every product or market. A CRM may coordinate the workflow while a separate provider or responsible team supplies evidence. UpTrader’s documentation illustrates onboarding and document-review functions; it does not define a universal approval policy for every broker.
Describe each transition in three parts
First state the precondition, such as a complete submission or resolved review request. Then identify who can authorize the action. Finally state the resulting record and permitted next actions. A resubmission after rejection may create a new review version rather than erasing the original decision. An expiry or material change may return an approved case to review. Keep those paths explicit so the implementation does not rely on unrestricted manual status edits.
Enforce rules at the service boundary
Hiding an approval button is not enough if the same action remains available through an API or background process. OWASP transaction-authorization guidance emphasizes server-side checks and valid state transitions. Bind an approval to the significant case details so that a later ownership or product change does not reuse an authorization for a different application. The appropriate review design is a business-policy decision; the software must enforce that chosen design consistently.
Keep rejection and suspension understandable
A rejected application and a suspended existing relationship are different states. One concerns an approval decision; the other may restrict previously available actions while preserving obligations and records. Record the reason, effective time, responsible reviewer and permitted communication. Avoid exposing sensitive screening details unnecessarily. A client-facing explanation should accurately describe what is pending and what information is needed without promising approval or making an unsupported allegation.
A fictional transition record
This example concerns an application workflow only. It does not establish legal eligibility or require the same roles in every business. The important property is that each transition is authorized and linked to evidence, and that a material change invalidates the earlier approval where the declared policy requires a fresh review.
| From | Action and condition | To | Example owner |
|---|---|---|---|
| Draft | Submit complete application | Under review | Applicant |
| Under review | Request missing evidence | Awaiting information | Authorized reviewer |
| Awaiting information | Submit new evidence version | Under review | Applicant |
| Under review | Approve documented scope | Approved | Authorized reviewer |
| Approved | Material scope change requires review | Under review | Policy-designated owner |
Implementation checklist
- Define what each status approves and what it does not approve.
- Specify preconditions, actor and evidence for every transition.
- Enforce the same rules through UI, API and background processes.
- Preserve prior decisions and require review after relevant material changes.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
- UpTrader back-office workflowsuptrader.io
- OWASP transaction authorization guidancecheatsheetseries.owasp.org
- OWASP authorization guidancecheatsheetseries.owasp.org
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.