Wealth management firms manage sensitive client information across complex servicing relationships.
Advisors, assistants, operations staff, and client households all interact around shared documents. Those relationships frequently change as teams evolve, books move, and coverage assignments shift.
Yet many firms still control document access using file-level permissions inside legacy document systems.
That approach becomes fragile at scale. Every servicing change requires manual permission updates across folders or files, creating operational overhead, inconsistent access, and difficult audits.
The underlying issue is architectural:
Document access should follow servicing relationships — not individual files.
A vault architecture solves this by aligning access with the relationships that already exist in the business.
Most wealth platforms rely on rep codes to represent advisor servicing relationships. Rep codes identify which advisors are responsible for which client accounts and often determine compensation, reporting, and operational workflows.
However, rep codes do not represent a simple one-to-one relationship between advisor and client.
In practice, servicing structures are many-to-many. Multiple advisors may service the same household, and each advisor typically works with assistants and operational staff who also require access to client information.
The resulting servicing graph is complex.
Figure 1 — Rep Codes Create Many-to-Many Servicing Relationships
Understanding this structure is critical because document access must ultimately align with these servicing relationships.
Traditional document systems manage access through explicit permissions assigned to files or folders.
Administrators grant or revoke access directly on document containers.
This approach creates several problems:
Operational overhead - When advisors join or leave a team, permissions must be manually updated across many locations.
Inconsistent access - Permissions often diverge over time, creating access gaps or unintended exposure.
Poor auditability - It becomes difficult to answer a simple governance question: “Why does this person have access to this document?”
Figure 2 — Manual Permissions vs Policy-Based Access
The key insight is that relationships should define access, not manual permission assignments.
A modern vault architecture approaches the problem differently. Instead of attaching permissions to files, the system models the relationships that govern collaboration.
In SideDrawer, this is accomplished through three core concepts:
Teams - Teams represent servicing groups within the firm. Advisors and assistants belong to those teams.
Vaults - Vaults represent client information spaces.
Collaborator relationships - Access occurs when a team is connected to a vault through a collaborator relationship.
Figure 3 — SideDrawer Rep Code Mapping Model
In this model, document access emerges from structural relationships, not manual permission assignments.
In mature implementations, the relationships that determine access are defined outside the vault platform.
Systems exist that already track the servicing relationships that determine who should access client information, such as:
CRM platforms,
portfolio management systems,
identity providers, and,
advisor compensation systems.
A vault platform can leverage these upstream systems as sources of policy
Figure 4 — Upstream Entitlements, SideDrawer Enforcement
This pattern can be summarized simply: Policy defined upstream, enforcement handled by the vault platform. The result is a system where access reflects authoritative business relationships rather than manually configured permissions.
One of the strongest advantages of a relationship-driven model is explainable access. When access is derived from structured relationships, organizations can trace the exact reason why/how a user obtained access.
For example:
an advisor belongs to a servicing team
the team collaborates on a client vault
vault access allows document access
Figure 5 — Explainable Access Trace
For governance and compliance teams, this creates a clear answer to the audit question: “Why does this person have access?” The explanation becomes structural rather than historical.
Another benefit of a vault architecture is operational simplicity. When organizational events occur, the system updates relationships rather than permissions.
Examples include:
advisor transitions between teams
book transfers between advisors
temporary coverage assignments
operational staff changes
Instead of editing permissions across hundreds of files, administrators update team membership or vault relationships.
Figure 6 — Operational Events Update Relationships, Not File Permissions
This dramatically reduces operational complexity.
The most mature vault architectures operate as part of a broader enterprise platform model.
In this model:
Enterprise systems define servicing relationships.
Those relationships become entitlement policies.
The vault platform enforces those policies as access control.
Figure 7 — Policy In, Enforcement Out
The vault becomes a secure collaboration layer aligned with enterprise policy. This “policy-in, enforcement-out” pattern allows the vault to act as a secure collaboration layer aligned with enterprise servicing relationships.
Modern wealth firms operate through complex collaboration between advisors, teams, clients, and external professionals.
Managing access through file-level permissions does not scale to this environment.
A relationship-driven vault architecture replaces manual permissions with a simpler model:
relationships determine access
enterprise systems define policy
the vault platform enforces access
This approach improves:
governance and auditability
operational efficiency
consistency of access control
Instead of continuously repairing permissions, firms maintain the servicing relationships that define collaboration.
Organizations do not need to redesign their architecture all at once.
A common starting point is simply aligning vault access with rep-code-driven servicing relationships. From there, firms can gradually integrate additional upstream systems and operational workflows. Over time, the vault becomes a structured collaboration environment aligned with the organization’s servicing model.
That shift moves document access from a fragile configuration problem to a stable architectural foundation.
This playbook outlines a practical path toward a relationship-driven vault architecture.
For organizations managing complex client servicing models, the key shift is simple:
Stop managing permissions on files.
Start managing relationships.