Checklist · CRM Account Operations
Duplicate Client Records: Merge and Audit Checklist
Review a possible duplicate before merging CRM records, preserving identity evidence, account links, permissions and a traceable recovery plan.
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
A duplicate-client merge should begin with evidence that the records represent the same permitted relationship. Choose a surviving identifier, preserve dependent account and transaction links, and record every change. Matching names or a shared email address alone may be insufficient to justify a merge.
Confirm identity and relationship before deduplication
Two profiles can share contact information while representing different legal entities, household members or authorized relationships. Conversely, one entity can have changed its name or email. Review the approved matching evidence and the purpose of each record. Do not use an automated similarity score as an unexplained authorization to combine financial or identity records. Escalate ambiguous cases according to the operator’s policy.
Map dependencies and choose the survivor
Inventory wallets, trading accounts, documents, consent records, support cases, partner attribution and transaction references attached to each profile. Select the stable survivor ID under an explicit rule and record how the retired ID will resolve. Preserve historical provenance instead of rewriting every past event as if it originated under the survivor. Conflicting fields need a documented decision owner; the most recently edited value is not automatically the correct value.
Protect access and transactional consistency
Combining records can expand what a user or staff role can see. Reevaluate ownership and authorization relationships after the merge, including tenant and brand boundaries. Database transactions can help enforce local consistency, but they do not automatically update external platforms or document stores. PostgreSQL’s isolation guidance illustrates why concurrent changes and retries require deliberate handling. Plan for a new event arriving while the merge is in progress.
Verify the result and retain a recovery record
After the change, check dependent-record counts, identifiers, permissions and financial references. Do not merge wallet balances by simply adding displayed amounts unless the approved ledger process calls for it; the balances may already reflect shared underlying transactions. Keep a before/after mapping, reviewer, reason and validation result. A recovery plan must account for any external effects created after the merge, so reversing a database field alone may not restore the original business state.
A controlled merge worksheet for synthetic profiles
Profiles C-201 and C-309 are flagged as possible duplicates. The review confirms the same approved applicant entity, but only after checking evidence beyond a shared email. C-201 is selected as survivor. The worksheet records dependent objects and conflicting fields; it does not delete transaction history or assume two wallet displays represent separate money.
| Review item | Example decision/evidence |
|---|---|
| Identity | Approved reviewer confirms same applicant entity |
| Survivor | C-201; C-309 retained as historical reference |
| Dependencies | Two trading accounts, one shared wallet reference, three cases |
| Conflict | Different contact address requires verified selection |
| Access | Retest client and staff permissions after remapping |
| Recovery | Keep before/after links and external-effect log |
Implementation checklist
- Confirm identity and relationship with authorized evidence.
- Inventory every dependent record before choosing a survivor.
- Preserve historical provenance and resolve conflicting fields explicitly.
- Retest access, counts and financial references, with a recovery record.
Sources
These documents support the reference. Check the original publication for current requirements and the limits of its scope.
- OWASP authorization guidancecheatsheetseries.owasp.org
- OWASP logging guidancecheatsheetseries.owasp.org
- PostgreSQL transaction isolationwww.postgresql.org
Continue with the broader guides
Connect this reference to platform selection and the wider operating workflow.