Compliance is architecture, not a feature.

Most platforms build the application first and add compliance later. The audit trail is a reporting layer. The permission system is an afterthought. Data retention is a policy document, not a database constraint.

Advisd inverts this. Compliance requirements shaped the database schema, the API design, the permission model, and the testing infrastructure from the first line of code. The result is a platform where key compliance controls are enforceable, auditable, and difficult to bypass.

This matters when an SEC examiner asks to see your books and records. It matters when a client asks who accessed their personal information. And it matters every day, in the background, when the platform is doing the compliance work your team would otherwise do manually.

SEC Rule 204-2 requires investment advisers to maintain accurate books and records. Advisd enforces this through an immutable audit trail.

Regulated financial workflows — position changes, fee calculations, trade approvals, performance updates — write to an append-only regulatory_audit_log. Ordinary application and administrator workflows cannot update or delete these audit records. The database enforces immutability through triggers that reject UPDATE and DELETE operations on audit records.

Every record carries attribution: who made the change, when, what changed, the old value, the new value, and the reason. The audit trail supports the 7-year minimum retention requirement and is designed for examiner export.

SEC Rule 206(4)-7 requires advisers to adopt and implement written compliance policies and procedures. Advisd supports this through access controls, segregation of duties, and configuration management.

Access controls. The permission system defines 142 granular permission keys across 10 default roles. Permissions are enforced at three layers: the UI hides actions you can't perform, the API rejects unauthorized requests, and the database enforces access through row-level security policies. Contextual permission rules allow further scoping — for example, restricting advisors to only the households assigned to them.

Segregation of duties. Fee billing approval and trade approval enforce that the person who initiated the action cannot be the person who approves it. Fee adjustments require dual-control approval. These aren't workflow suggestions — they are enforced constraints.

Configuration change logging. Every change to business rules, fee schedules, model portfolios, and system configuration requires a documented reason and writes to a dedicated configuration_change_log. This creates a reviewable trail of every operational decision.

Regulation S-P requires safeguarding customer information. Advisd implements data classification, encryption, and access logging.

Data classification. Every table in the database carries a data_classification field. Data is classified as Public, Internal, Confidential, or Restricted. PII fields — Social Security numbers, Tax IDs, dates of birth, bank and custodian account numbers — are classified as Restricted.

Encryption. Restricted PII is encrypted at the column level using AES-256-GCM with application-managed keys. Encrypted fields are stored alongside masked display columns (e.g., "***-**-1234") so that the application never needs to decrypt just to show a partial value.

Access logging. Every decryption operation — every time someone views a full SSN or Tax ID — writes to the data_access_log with the user's identity, the record accessed, and a timestamp. This creates an auditable trail of who accessed what sensitive information and when.

Client portal isolation. The client portal never exposes Restricted PII. SSN, Tax ID, and other restricted fields are absent from client views entirely — not masked, not hidden behind a click, but structurally absent from the data sent to the client's browser.

Advisd's infrastructure aligns with SOC 2 trust principles through technical controls.

Least privilege. The permission system defaults to no access. Roles grant specific permissions. The two-tier seat model (Full and Staff) provides an additional layer of access control. Permission changes on compliance-sensitive keys trigger CCO notifications.

Change management (CC9). Configuration changes require documented reasons. The change log captures who changed what, when, why, and the before/after values. Changes to compliance-relevant settings trigger additional audit entries.

Financial records in Advisd carry a 7-year minimum retention policy, enforced at the database level. Soft-deleted records are retention-protected — the database rejects any attempt to soft-delete a record that falls within its retention window.

Hard deletes are prevented entirely on regulated tables through database triggers. There is no "permanently delete" button or administrator workflow that bypasses the protection. Records can be soft-deleted (hidden from active views) when retention allows, but the data remains in the database for the required retention period.

Advisd's permission model provides granular, auditable access control.

142 permission keys cover every action in the platform — from viewing household data to approving trades to accessing PII. Permissions are grouped by module: household management, portfolio operations, billing, trading, compliance, and administration.

10 default roles provide out-of-the-box configurations: Firm Admin, Lead Advisor, Operations Manager, Advisor, Staff, Compliance Officer, Billing Manager, Client Service Associate, and Staff Member. Two roles (Firm Admin and Staff Member) are locked to prevent misconfiguration. The other seven are fully customizable.

Contextual permission rules add conditional logic. A rule like "advisors can only view households where they are the assigned advisor" is enforced at the database level, not just the UI. This enables firms to implement Chinese wall restrictions, team-based access, and role-based data scoping.

Advisd runs 4251 automated compliance checks across 0 categories: audit triggers, hard-delete prevention, retention enforcement, PII encryption, permission enforcement, RLS policies, configuration change logging, and segregation of duties.

These checks are not manual — they are executed programmatically and produce a machine-readable result: 4176 passed, 0 failed, 42 exempt (with documented exemptions). The verification script is designed for CI/CD integration, ensuring that no code change can degrade compliance infrastructure without being caught immediately.