How SideDrawer Solves Rep Code–Based Access in Wealth Management

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.

Reality of Servicing Wealth Management Relationships

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.

The Legacy Permission Model Problem

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:

1. Operational overhead - When advisors join or leave a team, permissions must be manually updated across many locations.

2. Inconsistent access - Permissions often diverge over time, creating access gaps or unintended exposure.

3. 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 Relationship-Driven Vault Model

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:

1. Teams - Teams represent servicing groups within the firm. Advisors and assistants belong to those teams. 

2. Vaults - Vaults represent client information spaces. 

3. 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.

Aligning Access with Enterprise Systems

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.

Policy-Based Access Simplifies Governance

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.

Operational Changes Become Relationship Updates

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.

Designing a Vault for the Way Firms Actually Operate

The most mature vault architectures operate as part of a broader enterprise platform model.

In this model:

1. Enterprise systems define servicing relationships.

2. Those relationships become entitlement policies.

3. 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.

Why This Architecture Matters

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.

The Practical Starting Point

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.

Final Thought

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.