Built to withstand scrutiny.

Advisd is built on a modern, proven stack.

Next.js provides the application framework — server-side rendering, API routes, and a React-based UI. The application runs on Vercel's edge network for fast global delivery and instant deployments.

Supabase provides the database (PostgreSQL), authentication, and row-level security. PostgreSQL's maturity — decades of production hardening, ACID compliance, and a robust extension ecosystem — is exactly what financial data requires. Supabase adds real-time subscriptions, server-side auth helpers, and managed infrastructure.

Row-level security (RLS) enforces multi-tenant isolation at the database level. Every table has RLS policies that automatically scope queries to the requesting user's organization. This is not application-level filtering — it's database-enforced isolation that applies to every query, whether it comes from the UI, the API, or a background process. 373 RLS policies cover all database tables.

Every financial calculation in Advisd — portfolio valuation, performance returns, fee computation, drift analysis, tax-lot optimization — follows a documented specification.

29 approved financial specifications cover every calculation the platform performs. Each spec defines inputs, outputs, formulas, edge cases, rounding rules, and test cases. The specs are written in plain language with mathematical notation, reviewed before implementation, and versioned alongside the codebase.

1,000+ test cases across these specifications ensure correctness. Test cases cover normal operations, boundary conditions, edge cases (division by zero, negative values, empty portfolios), and regulatory requirements (IRS holding period rules, SEC Marketing Rule disclosures).

Decimal arithmetic is mandatory. JavaScript's floating-point numbers produce rounding errors that are unacceptable in financial calculations. All monetary computations use the decimal.js library, which provides arbitrary-precision decimal arithmetic. The number 0.1 + 0.2 = 0.30000000000000004 is not a rounding error we tolerate — it's an error we've eliminated.

Compliance is implemented as database-level constraints and triggers, not application-level checks that can be bypassed.

106 audit triggers on regulated tables ensure that every financial data mutation writes to the immutable audit trail automatically. The application doesn't need to remember to log — the database does it.

Dozens of hard-delete prevention triggers reject DELETE operations on regulated tables. These triggers fire at the database level, before the row is removed. No application code, no admin tool, no direct SQL command can bypass them.

Dozens of retention soft-delete prevention triggers reject soft-delete attempts on records within their retention window. A financial record with a 7-year retention policy cannot be soft-deleted until the retention period has elapsed.

4 immutable audit tables — regulatory_audit_log, configuration_change_log, data_access_log, and incident_log — are append-only. Insert is permitted. Update and delete are rejected by triggers. These tables are designed for regulatory examination.

PII encryption uses AES-256-GCM with application-managed keys. Encrypted fields include SSN, Tax ID, date of birth, and bank/custodian account numbers. Masked display columns (e.g., "***-**-1234") allow the application to show partial values without decrypting. Every decryption operation is logged to the data access log.

Advisd is a multi-tenant platform where every organization's data is strictly isolated.

Every table includes an organization_id column. Every RLS policy scopes queries to the requesting user's organization using a get_user_organization_id() function that reads from the authenticated session. There is no way to query another organization's data — the database won't return it.

This isolation extends to every layer: the API verifies organization membership before processing requests, the UI only renders data that passes through the API, and background jobs run within organizational context. But the ultimate enforcement is at the database level — even if every other layer failed, the RLS policies would still prevent cross-tenant data access.

Advisd maintains a three-layer testing strategy with 7,000+ automated tests.

Unit tests verify individual functions and calculations — financial formulas, permission checks, data transformations, encryption/decryption operations. These tests run fast and cover edge cases exhaustively. Financial calculation tests verify exact decimal precision.

Component integration tests verify that UI components render correctly with real data, handle loading and error states, and enforce permission gates. These tests use React Testing Library to simulate user interactions.

End-to-end tests use Playwright to exercise complete user workflows — logging in, navigating to a household, creating a position, running a billing cycle, approving a trade. End-to-end tests run against a real database with real authentication, not mocked services.

Compliance verification runs 1532 automated checks across 17 categories. The verification script is designed for CI/CD integration: it exits with code 0 if all checks pass (with documented exemptions) and code 1 if any check fails. No code change can degrade compliance infrastructure without the verification script catching it.

Advisd's data model handles the full spectrum of RIA data — from household contacts to alternative fund commitments — in a unified schema.

Database tables cover households, contacts, accounts, positions, transactions, tax lots, fund commitments, capital calls, distributions, NAV history, fee schedules, billing runs, model portfolios, drift snapshots, trades, activities, and compliance audit tables.

Positions and fund commitments share a unified portfolio view. Traditional positions carry market values from daily price updates. Alternative fund commitments carry NAV values from GP statements or manual entry. Both feed into the same allocation analysis, the same drift calculation, and the same performance engine (using appropriate methodology — TWR for traditional, IRR for alternatives).

17 security types in the security master span equities, fixed income, mutual funds, ETFs, money market, options, and alternatives (private equity, venture capital, private credit, private real estate, hedge funds, and more).

Every action in the Advisd UI goes through a documented API layer. The UI never queries the database directly — it makes requests to Next.js API routes, which validate permissions, process business logic, and return structured responses.

API routes enforce permissions server-side using a requirePermission() utility that checks the user's role against the required permission key. If the permission check fails, the API returns a 403 before any business logic executes.

This API-first design means that every action is auditable, every access point is permission-gated, and the system behaves identically whether the action originates from the web UI, the client portal, or a future mobile application.