Trussdee security: technical architecture and controls

Prefer a nontechnical explanation? Read How Trussdee protects your family's financial information.

This reference is for family-office technology teams, security reviewers, and advisers evaluating Trussdee. It describes the application's security architecture, implemented controls, and the scope of its current assurance program.

Last updated: September 12, 2026.

Security overview

Architecture and data flows

Trussdee is a web application built with Next.js and React. Server-side application logic handles authorization, provider communication, financial processing, and access to PostgreSQL through Drizzle.

The principal processing boundaries are:

This describes the principal service architecture; it is not a complete contractual subprocessor register. The providers involved depend on the connections and features used.

A typical authenticated request follows this sequence:

1. Clerk establishes the user's application identity.

2. Trussdee resolves the active family and verifies current membership and login status.

3. Server-side logic checks the requested resource and operation.

4. The server reads or changes authorized records and returns the permitted result.

Account ingestion is a separate path: provider callbacks and scheduled or user-requested synchronization retrieve financial data, normalize it, and update records used in reporting. Family documents use private object storage with application authorization around retrieval.

Production and development use separate deployment and environment configuration. Application hosting, database storage, document storage, backups, and provider processing can have different locations. A required data-residency location must be confirmed against the configured services; this article does not establish a single-country or single-region commitment.

Authentication and authorization

Identity and sessions. Clerk handles sign-in and sessions. Protected application routes require authentication, and server-side authorization checks govern access to customer records. Integration endpoints such as webhooks use their own authentication mechanisms.

Family boundaries. Trussdee verifies that the authenticated user belongs to the active family workspace. A family or account identifier supplied by a browser is not sufficient authorization. The application uses scoped queries and resource checks to enforce access.

Resource permissions. Family roles, account access, private-account rules, and document permissions are evaluated separately from financial reporting attribution. An ownership percentage or inclusion in a report does not, by itself, create permission to view the underlying account or document.

Access changes. Application guards check active membership and disabled or pending login states. Revoking application access, disconnecting a financial provider, and deleting retained records are distinct operations.

Platform administration. Operational administration is restricted to specifically authorized platform users. Being an administrator of a family workspace does not grant platform-wide authority.

MFA and session policy. Clerk supports multi-factor authentication and configurable session policies. Enforcement, permitted factors, and session lifetimes are identity-provider settings that require deployment-specific confirmation. This reference does not assert that SMS verification is required for every user. See Clerk's authentication and MFA documentation.

Tenant separation is logical within the application architecture. A family workspace does not imply a dedicated database or dedicated physical infrastructure.

Encryption and key management

There are three distinct layers to consider.

Transport encryption. Browser and service communication use HTTPS/TLS. Vercel documents HTTPS/TLS protection, while Neon documents TLS 1.2 or higher for database transport. Vercel security documentation, Neon security documentation.

Storage encryption. Neon encrypts stored database data with AES-256. Vercel Blob also applies AES-256 encryption at rest to stored objects. This storage-layer protection is separate from application authorization. Neon encryption controls, Vercel Blob security.

Application-level credential encryption. Customer-specific credentials for supported direct integrations, including API keys/secrets and OAuth access or refresh tokens, are encrypted before being persisted to the database. The implementation uses:

• AES-256-GCM authenticated encryption.

• A 256-bit encryption key.

• A fresh random 96-bit initialization vector for each encryption operation.

• A 128-bit authentication tag that detects changes to the encrypted payload.

• A versioned payload containing a key identifier, allowing compatible key transitions.

Encryption and decryption run on the server. Decryption requires the configured key and a valid authentication tag.

Internal service keys and customer connection credentials are different. Service API secrets and the keys used for application encryption are supplied through server environment configuration. Encrypted customer connection payloads are stored in the database. Vercel documents encryption at rest for environment variables; the separate Secret/sensitive setting controls whether saved values remain readable through management interfaces. Encryption at rest alone does not establish that every variable is configured as write-only. Vercel environment-variable documentation.

The credential implementation supports versioned keys, and a documented rotation procedure covers configuration, re-encryption, validation, and retirement of an old key. This describes rotation capability and procedure; it is not a claim of a verified recurring rotation history.

Trussdee uses service-managed encryption. Authorized server processes can decrypt information required to synchronize accounts and produce reports. This is not an end-to-end encryption model in which only the customer holds the decryption keys.

Financial connections and credential boundaries

Bank and brokerage connections are established through Quiltt and a supported upstream network. Depending on the institution, authentication occurs with the bank itself or through the connection provider. Trussdee does not receive the bank username or password through this connection flow.

Some institutions support OAuth or tokenized access. Others use provider-managed credential flows. A universal claim that every bank issues a read-only token would be inaccurate.

Trussdee uses Quiltt profile sessions to work with the relevant connected data. Quiltt distinguishes environment-level administration from profile-level access. A Quiltt session token should not be confused with a bank password or a bank-issued OAuth token. Quiltt authentication documentation.

Direct exchange connections have a different credential boundary because Trussdee may retain encrypted API credentials or OAuth tokens. Read-only permissions are appropriate for these reporting integrations. For example, the Gemini OAuth integration requests balance-read and history-read scopes.

Reporting connections retrieve account information; they do not authorize Trussdee to initiate payments, withdrawals, or trades. Subscription billing through Stripe is a separate flow.

Private document storage

Family documents are stored using Vercel Blob's private access mode. The application checks the user's family and document access before retrieving a file.

Document controls include:

• PDF-only upload rules and a 25 MB application upload limit.

• File metadata validation and PDF-header checks in the upload validation flow.

• Verification of private storage access during upload completion.

• Authorization for document listing, viewing, downloading, and changes.

• File responses using Cache-Control: private, no-store and X-Content-Type-Options: nosniff.

• Audit events for document lifecycle and access activity.

A storage pathname is not a substitute for application authorization. These upload checks establish file type and size; antivirus scanning and full PDF-content sanitization are outside the controls described here.

Request, webhook, and browser protections

Provider callbacks are authenticated separately from interactive user sessions:

• Quiltt webhook verification uses HMAC-SHA256 over the signed payload, a timestamp check, and constant-time signature comparison.

• Clerk webhooks use Svix signature verification.

• Stripe webhooks use Stripe's signed-event verification.

• Hosted scheduled-job endpoints require a configured bearer secret. Missing credentials are rejected rather than treated as authorization.

Selected sensitive operations, including document uploads, administrative processing, and evidence exports, use Redis-backed rate limits. Rate-limited responses include retry guidance, with policies selected for the operation.

The application also sets browser security headers, including Content Security Policy, framing restrictions, MIME-sniffing protection, Referrer Policy, and Permissions Policy. The CSP permits required integrations and framework behavior, including inline scripts and evaluation allowances.

Audit logging and evidence integrity

Structured audit events can include the family, actor, role, action, target, outcome, timestamp, correlation information, and selected change metadata. Coverage includes privileged administration, identity and security events, document activity, and material financial or configuration changes.

The structured audit helper redacts credential-like fields in metadata. Application runtime logs and provider logs are separate evidence sources.

For supported material local mutations, database changes and their audit event are committed together in an atomic operation. Reads, denied requests, and outcomes controlled by external providers may use best-effort logging. Trussdee does not claim to record every read of every customer record.

Database triggers reject updates, deletes, and truncation of the audit-event table through normal database operations. Evidence-export tooling creates manifests and SHA-256 digests, and limits package contents by the selected review scope.

The triggers protect normal database operations; privileged database administration can still alter database controls. Export hashes support integrity checking when compared with a trusted retained manifest. Recurring completeness reviews and retained operating evidence remain part of the assurance program.

Secure development and change management

Production changes follow the repository's pull-request and release-review process. Continuous integration is configured to run:

• Dependency vulnerability checks that reject high and critical advisories.

• Source checks and a production build.

• Database schema/migration consistency checks.

• Tenant-isolation checks and focused security-relevant tests.

• Static application security testing with Semgrep.

• Repository secret scanning with Gitleaks.

The written vulnerability-management process includes risk assessment, remediation, and documented exceptions. Automated results are evaluated within the scope and date of each check.

Independent penetration testing and external review are part of the remaining SOC 2 readiness work. Automated development checks are not a substitute for those activities.

AI use, data processing, and retention

Trussdee does not use customer financial information to train AI models.

AI tools help write, review, and analyze software code. Source code describes how the application operates; family balances, transactions, holdings, and documents are stored in the application's data services.

Access to source code alone does not authorize access to the live database. Database credentials, connected tools, file permissions, and authorized operational access determine whether a development tool can reach customer information. Separate storage should not be interpreted as a guarantee that a tool could never be granted such access.

Model training, processing a prompt, and retaining a conversation are different activities. The no-training commitment does not mean that every AI service retains no prompts or that anything deliberately submitted to a third-party tool bypasses that provider's processing and retention rules.

Support is another distinct data flow. Trussdee's Productlane integration supplies identity and application context such as email, page, role, subscription plan, and access status. The explicit context fields are not an account-balance, transaction, or document export. Information a user includes in a support message or attachment is nevertheless shared with the support service.

Avoid including passwords, access tokens, or unnecessary financial records in support messages. If troubleshooting requires sensitive material, contact Trussdee to arrange an appropriate exchange.

Monitoring, recovery, and data lifecycle

Operational monitoring. Runtime monitoring records service health, background-job outcomes, and provider failures. Background processing uses bounded work, progress state, and retries to support diagnosis and recovery.

Incident response. Documented procedures cover triage, evidence preservation, containment, credential revocation or rotation, impact assessment, recovery, communications, and corrective action. Notification obligations follow the applicable agreement and law; this overview does not introduce a separate notification deadline.

Backup and recovery. Recovery planning uses provider backup and point-in-time recovery capabilities together with documented restoration procedures. An isolated database point-in-time recovery exercise was completed on July 10, 2026. That exercise was an engineering test, not a guarantee of full-service recovery time or an independently witnessed continuity audit.

A recovery point objective specifies acceptable data loss; a recovery time objective specifies acceptable restoration time. No fixed RPO, RTO, backup-retention period, or availability SLA is established by this article.

Export and deletion. Deletion requires review of request authority, affected records, legal holds, provider connections, private objects, caches, queued work, and retained evidence. Removing a user's access or disconnecting a provider does not itself erase historical information.

The deletion implementation supports tracked workflow steps and completion evidence. Production execution is subject to validation and approval of the applicable workflow. Active-system removal, provider-side deletion, retained exports, and backup expiration have separate completion conditions. Deletion timing depends on those conditions and the applicable agreement.

SOC 2 and independent assurance

Trussdee is developing a security program mapped to the AICPA Trust Services Criteria, initially covering Security, Availability, and Confidentiality. The program defines control owners, review schedules, evidence requirements, and exception handling.

Trussdee has not completed a SOC 2 Type 2 examination. Implemented controls, documented procedures, dated operating evidence, and an independent auditor's opinion are separate stages. Remaining readiness work includes recurring operating evidence, access and vendor reviews, independent review, and external testing.

Quiltt reports two consecutive SOC 2 Type 2 audits. That assurance concerns Quiltt and the scope of its reports; it does not establish a Trussdee audit opinion. Quiltt's audit announcement.

Provider reports must be evaluated for the relevant service, audit period, exceptions, and customer responsibilities. A provider's compliance badge does not automatically establish that a customer's application meets the same framework.

Additional review evidence

For requirements that depend on live configuration or contract terms—such as MFA enforcement, session duration, processing regions, retention settings, or available independent reports—contact Trussdee through this help portal or [email protected]. We will identify the relevant evidence and any limits on sharing it. Customer records, secrets, and detailed operational access instructions are excluded from public documentation.