Checklist · CRM Account Operations
Dormant Accounts: Review States and Re-Activation Checks
Separate inactivity, suspension, closure and deletion in an account-review workflow, with checks for obligations, permissions and authorized reactivation.
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
Dormancy is a policy-defined inactivity state, not automatic account closure or deletion. Review open positions, balances, pending requests, communications and record obligations before restricting or reactivating an account. The relevant thresholds, fees and retention rules must come from the actual contract and applicable policy.

Define the signal and the resulting state
A period without login, trading, funding or any account activity can produce different dormancy candidates. State which signal is used and how it is measured. A client with no recent login may still have open positions or an unresolved withdrawal. Treat the initial flag as a review input unless the approved policy expressly defines an automatic transition. Do not invent a universal number of inactive days or a standard dormancy fee.
Separate access restrictions from continuing obligations
Suspending new trading, disabling a login and closing a relationship are different actions. A restriction should not silently erase balances, pending payments, statements or support obligations. Identify which functions remain available and who owns unresolved items. The client-facing message should accurately describe the restriction and the review path. Product documentation can illustrate account-management functions, but the operator’s terms determine how they may be applied.
Review retention and communication deliberately
Inactivity does not alone justify retaining every personal record forever, nor does it require deleting records that must still be kept. The ICO’s principles provide a UK-specific framework for purpose, minimization and storage limitation; other applicable laws and obligations need their own assessment. Maintain an approved retention schedule and communication policy. Do not confuse deletion of an unused login with removal of all financial or identity evidence.
Authorize reactivation against the current state
Before restoring permissions, verify the requester, account ownership, unresolved restrictions and any review required by current policy. A historic approval may not cover changed products, markets or ownership. Record what was checked and exactly which permissions were restored. Test the transition so a reactivated portal does not leave the trading platform, payment workflow or support view in a contradictory state. Keep closure and reactivation decisions traceable.
An inactivity flag that requires review
A synthetic client has not logged in for 180 days, but the account still has a small balance and a pending document request. The 180-day value is an invented review trigger, not a legal threshold. The workflow flags the case, inventories obligations, confirms permitted contact and assigns an owner. It does not delete the account or impose a fee from the inactivity signal alone.
| Review item | Example finding | Required decision |
|---|---|---|
| Inactivity signal | No login for 180 days | Candidate for policy review |
| Financial state | Balance remains | Preserve ledger and withdrawal obligations |
| Open process | Document request unresolved | Assign review owner |
| Access | Current permissions recorded | Decide any scoped restriction |
| Reactivation | Verified request received later | Reassess policy conditions and restore approved scope |
Implementation checklist
- Define the inactivity signal and distinguish it from a final decision.
- Inventory positions, balances, payments and unresolved cases.
- Apply an approved retention and communication policy for the relevant jurisdiction.
- Verify and record the exact scope of any reactivation.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
- ICO data protection principlesico.org.uk
- UpTrader back-office workflowsuptrader.io
- OWASP authorization guidancecheatsheetseries.owasp.org
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.
