Before replacing a form pack, decide what “complete” is allowed to mean. Information supplied, evidence checked, internal approval and custodian confirmation should each have their own recorded outcome. A single completion flag should not stand in for all four.
Build the wealth management onboarding workflow around those distinctions. Give approved rules responsibility for requirements and routing, while people remain accountable for verification, risk assessment and approval. Start with one client and account path, and make its decisions and handoffs traceable before extending it.
Start with the operating workflow
Before designing screens, map who supplies information, who owns each fact, who reviews evidence and who can authorize the next step. For each handoff, specify the receiving owner, the entry conditions and the route back when something is missing. Use forms to collect information without making each form a competing record of the case.
Model the client legal entity separately from related people and their roles. Distinguish authorized persons from beneficial owners where those relationships are relevant to the selected path; do not infer one role from the other. Connect the client to accounts, each with its custodian and relevant jurisdiction and product context. Treat this as a proposed information structure, not a universal regulatory data model.
Choose an authoritative source for each fact and status, and specify who may correct it. Do not let the most recently uploaded form win by default. When submissions disagree, preserve their sources and route the discrepancy to an owner rather than overwriting the earlier value.
Separate facts, evidence, checks and approval
Map form answers to typed facts with defined meanings, sources and change histories. Link documents to the facts or relationships they are intended to support. Record checks separately from both: supplied evidence should remain identifiable even when a reviewer disputes what it establishes.
Typed values, relationships and sources.
Linked material, provenance and relevant dates.
Method, result, reviewer or service, and time.
Pending work, owners and approval scope.
Proposed design: assess how a change to one record affects the others.
Keep assertions, supporting material, checks and permission to proceed distinct.Some evidence checks have a technical basis for automation. The National Institute of Standards and Technology (NIST), in its digital identity-proofing guidance, lists automated document validation and cryptographic verification among acceptable evidence-validation methods. These are validation mechanisms, not an end-to-end wealth-management onboarding design or a determination that a client is approved.
Authority warrants a separate record too. For Financial Industry Regulatory Authority (FINRA) members, Rule 2090 requires reasonable diligence when opening and maintaining accounts to know and retain essential customer facts and the authority of each person acting for the customer. Rule 4512 requires members to maintain the names of persons authorized to transact business for a corporation, partnership or other legal-entity customer. These provisions do not establish beneficial-ownership verification or a global wealth-management data model.
In the workflow, give completeness, identity verification, evidence validation, risk assessment and human approval separate outcomes. Define what each means and who can record it. Use questionnaire answers as assessment inputs; do not label questionnaire completion as suitability assessment or compliance approval.
Govern requirements and routing through versioned rules
Give the rules engine a bounded job: apply approved decisions about information, documents, requested checks and routing. Each output should identify the requirement or route and the context that triggered it. Keep legal interpretation and accountable approval outside that output; avoid an undifferentiated “compliant” result.
Assign each rule version an accountable owner, source, approver and effective date. Decide how changes apply to cases already in progress. For every evaluation, retain the applied version, input facts, evidence references and result. Record any override with its reason and author, so the decision can be understood without reconstructing it from today’s rules.
Use recorded client, relationship and account facts.
Apply the approved effective-date policy.
Return information, evidence and routing needs.
Send unknown, conflicting or expired evidence to review.
Store version, inputs, outputs and linked review outcomes.
This proposed sequence governs collection and routing, not legal judgment or approval.
Select the approved rule version, determine requirements and route unresolved inputs to review.Treat unknown as a distinct value, not as “no” or an empty field that passes a check. Assign unresolved cases to a named queue and owner. For exceptions, record who authorized the departure, its scope, any expiry or review date, and the action required when it ends.
A hypothetical path: common core, contextual requirements
Consider a hypothetical legal-entity client requesting an account. Its common-core submission identifies the entity and a representative, records that the representative is not a director, and asserts that they may instruct alone. Keep those person and relationship facts separate from the account’s custodian, jurisdiction and product context.
For this illustration only, assume an internal policy requires a signed entity mandate when a non-director is named as an authorized person on an entity account. The rule requests a mandate identifying the representative, their authority and whether they must act jointly with someone else. The non-director relationship triggers this additional collection. This policy is invented for the example, not a jurisdictional, product or custodian requirement.
Entity names a non-director representative.
Non-director authority on an entity account triggers collection.
Mandate names another required signatory, contradicting the answer.
Assigned operations reviewer owns clarification; approval is blocked.
Illustrative internal policy and case facts, not external requirements. Receiving the mandate does not resolve authority.
The representative’s recorded role triggers collection; a reviewer’s finding leaves authority unresolved.Suppose the operations reviewer finds that the uploaded mandate requires joint instructions with another named signatory, contradicting the submitted answer. Preserve both records and set the authority relationship to “Authority unresolved.” Under the assumed policy, assign clarification to that reviewer and block internal approval until they resolve the discrepancy with the client and record the supporting evidence and outcome. Collection can be complete while authority remains unresolved. The rules engine should not choose which assertion is legally valid.
After internal approval, record custodian submission separately. Show the client a status such as “Submitted to custodian,” without implying that the account is open. Reserve an opening status for the relevant custodian confirmation and reconcile it to the account record.
Design for interruption, correction and parallel work
Present questions progressively as context becomes known. Save progress, explain additional requests and distinguish invalid input from information awaiting review. Make correction accessible: identify the affected field in text, preserve unaffected answers and let the client resolve an inconsistency without starting again. Flag possible duplicate people or entities for resolution rather than merging them because names match.
For parallel reviewers, give each task its own status, decision scope and dependencies. Define which reviews must finish before submission and who resolves disagreement. Tie each approval to a recorded version of the case, rather than automatically carrying it forward to changed information.
- Changes after approval: preserve the approved snapshot, identify affected checks and reopen the necessary review before further action.
- Expired evidence or exceptions: assign refresh or reassessment under the approved policy; do not silently extend validity.
- Custodian rejection: retain the reason, assign correction and link the revised submission to the original case.
- Retries and duplicates: use stable submission identifiers, reconcile acknowledgements and resolve uncertain outcomes before creating another request.
Apply the same discipline to evidence refresh after opening. Link new evidence to the existing client and account, preserve the prior decision record and specify which changes require reassessment. Keep client-facing progress clear about what is waiting and who must act next.
Roll out one path and test control over change
Choose one bounded client and account path with named operational, policy and technical owners. Agree its facts, evidence, states and handoffs before migration. Reconcile authoritative identifiers and statuses across the client record, workflow and custodian integration. Specify which system may update each value and who resolves mismatches.
- Establish the baseline: test the complete path through review, approval, submission and custodian confirmation.
- Challenge the inputs: test missing and conflicting facts, unknown relationships, expired evidence and adverse changes after approval.
- Challenge rule changes: test effective-date boundaries, in-progress cases, reviewer overrides and exception expiry.
- Challenge integrations: test rejection, retries, duplicate submissions and delayed acknowledgements. Check that identifiers and statuses reconcile.
- Set the release boundary: require accountable owners to resolve unexplained decisions and state mismatches before extending the workflow.
Include privacy in the rollout decisions. NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk through enterprise risk management. That framing does not establish universal access, masking, minimisation or retention requirements.
For the selected path, document why personal data is collected, which roles need it and where it moves, including documents, logs and test environments. Determine minimisation, access, masking and retention controls with the accountable privacy and legal owners for that context. Preserve necessary decision evidence without assuming every reviewer needs every document.
Make expansion conditional on a traceable decision record: what was known, which rule version applied, who decided and what the custodian confirmed. Test that record after a correction or rejection, not only after a clean submission. Which onboarding path will you put through that test first?
