Exception management in wealth operations: a workflow guide
Wealth firms need more than an alert queue. This guide shows how to assign, escalate, resolve, and review exceptions with clear ownership and closure evidence.
Exception management in wealth operations is the process of identifying work that cannot follow its normal path, assigning a person to resolve it, deciding when to escalate it, and recording why it was closed. An alert is only the start. The case also needs a current owner, an allowed next action, and evidence of the final decision.
A missing identity document, a mismatched client record, a transfer instruction that needs a second review, or an approval that has not arrived can each interrupt a different workflow. Treating them all as generic overdue tasks loses the context that determines who may act. A useful exception process connects the issue to its client or account case and to the firm's written procedures.
Define the exception before routing it
A firm should distinguish three states:
- Routine work: The case meets the conditions to advance through its standard workflow.
- Incomplete work: A required input or document is missing, but the issue has an ordinary remediation path.
- Control exception: A policy check, data conflict, authorization concern, or supervisory requirement prevents the next step until a designated reviewer decides what happens.
These are operating definitions for this guide, not regulatory categories. A missing file might be a routine follow-up in one process and a hard stop in another. The firm's policy, account type, jurisdiction, and risk assessment determine the treatment.
For broker-dealers, FINRA Rule 3110 requires a reasonably designed supervisory system and written procedures, with responsibility for proper supervision remaining with the member. For SEC-registered or required-to-register advisers, Rule 206(4)-7 requires written compliance policies and procedures, an annual review, and a designated chief compliance officer. Neither rule supplies a universal queue design or resolution deadline. Build the workflow around the firm's obligations instead of assuming that an automated alert is compliance.
Give every open case an owner and a next action
An exception record should answer six questions at a glance:
- What triggered it? Record the check, missing item, conflicting field, or user action that raised the case.
- What is affected? Link the relevant client, household, account, transaction, and workflow step using only the access appropriate to each role.
- Who owns resolution? Name the person or assigned team responsible for the next operational action.
- Who may approve? Identify a separate reviewer when a policy or supervisory gate requires sign-off. The operational owner is not automatically the approval authority.
- What can happen now? State whether the case may proceed, is paused, needs client information, or awaits an authorized decision.
- When is review due? Set a firm-defined threshold and escalation path that reflect the risk, not an invented industry-wide service level.
A shared inbox without ownership lets cases move between advisors, operations, and compliance without a clear handoff. OneVest describes its Operations Workspace as a home-office view of workflows, approvals, and exceptions. That is relevant because the owner needs both the exception and the surrounding case status, not a detached notification.
Separate remediation from approval
Consider an account-opening case with a missing identity document. An advisor or operations specialist may be responsible for obtaining the document and checking that it belongs to the correct case. A designated supervisor or compliance reviewer may be responsible for approving the gated step. Those are different jobs.
A practical sequence is:
- The workflow identifies the missing requirement and holds the gated step.
- An owner confirms whether the document is truly absent or merely unmatched.
- The owner requests or attaches the correct item using the firm's approved channel.
- The case returns to the assigned reviewer with the new evidence and relevant history.
- The reviewer approves, rejects, or asks for more information according to the firm's procedure.
- The case records the decision, actor, time, and next state.
OneVest's Supervision product page describes configurable step-level approval rules, reviewer task lists, and cases held until required sign-off. This supports the gated-step example. It does not establish that every exception should be automatically resolved or that a platform can substitute for a firm's judgment.
Escalate by consequence, not by alert volume
An effective escalation rule should specify what changes the case's priority. Examples include a potential unauthorized instruction, a repeated data mismatch across accounts, an approaching firm-defined review threshold, or a blocked client commitment. The decision to pause, communicate, or notify a particular role belongs in the firm's policy.
Build the escalation matrix around a small set of questions:
| Decision | What the firm should define |
|---|---|
| Severity | Which conditions require an immediate hold or specialist review? |
| Ownership | Who can investigate and who can reassign the case? |
| Authority | Which role can approve a change, release a hold, or close the item? |
| Time | When does an unresolved case move to the next reviewer? |
| Communication | Who updates the advisor or client, through which approved channel? |
Do not confuse a notification with an escalation. Sending another message does not help if the recipient cannot make the decision or cannot see the case context. OneVest's Pulse Collaboration describes case-linked messaging and activity, plus task ownership and status tracking. A firm evaluating that layer should test whether its own approval and communication rules are reflected in the actual handoff.
Close the loop with evidence and review
Closure needs more than a green status. For a consequential exception, record the original trigger, the action taken, any changed data or document, the reviewer decision where required, and the final case state. A reopened case should retain the earlier decision rather than silently replacing it.
At intervals set by the firm, review patterns across exception categories. Which checks create avoidable false positives? Which case type sits longest between teams? Are unresolved items concentrated at an integration boundary, a missing field, or a reviewer queue? This is an operating review, not a claim that any particular metric is legally mandated.
The SEC's discussion of adviser annual reviews lists findings, implementation status, documentation, corrective actions, and escalation processes among topics an examiner may consider. It also stresses that the details of an annual review depend on the firm's circumstances (SEC examiner oversight discussion). Use exception history as input to that review where relevant, while keeping the firm's compliance assessment and legal advice with qualified people.
Test the workflow with one real case
Start with one frequent exception, such as a missing identity document during account opening. Run both a routine resolution and a case that must be escalated. Ask the advisor, operations owner, reviewer, and platform administrator to demonstrate what each can see and do. Check that the case cannot advance through a required gate, that reassignment is visible, and that the closure record explains the decision.
If a reviewer needs to consult email threads or a spreadsheet to reconstruct the case, the workflow still has a gap. The aim is not zero exceptions. It is a process in which people know what stopped, who is responsible, and what must happen next.
See the Operations Workspace to examine how OneVest presents firm-wide workflows, approvals, and exception visibility.