What ships today, what doesn't yet.
The architecture, controls, and disclosures we can defend right now — plus an honest list of what's still on the roadmap.
- Read-only architectureNo keys, no signing, no custody — Stride cannot move funds
- RBACAdmin / editor / viewer enforced server-side
- Append-only audit logEvery mutation captured · exportable for auditors
- Singapore data residencySupabase ap-southeast-1
- Encryption at rest + TLS in transitPostgres native + managed storage
- Tenant isolationworkspace_id filter on every query · RLS policies in place
- SOC 2 Type 1On v1.0 roadmap, not attested today
- SSO (SAML / OIDC)On v1.0 roadmap, Enterprise tier
- ISO 27001Not yet
- Third-party penetration testInternal review only today
If your security team needs one of these before piloting, write to hello@vypeconsulting.com — we prioritise on real demand.
Read-only by design
Stride is a view-only treasury workspace. We never hold private keys. We never sign transactions. We never custody assets. The only thing moving on the network is data about your wallets — addresses are public, balances and transactions are public, and the snapshots we store are a derived index of that public state.
This is a deliberate architectural choice. Even if Stride were fully compromised, an attacker could not move customer funds, redirect deposits, or sign transactions on a customer's behalf. The blast radius of any Stride incident is limited to read-side disclosure: snapshot records, address lists, and email/audit metadata.
Access controls (RBAC)
Workspaces have three roles, enforced server-side via the workspace context on every API request:
- Admin — invite/remove members, change roles, all wallet actions, change cost basis method, change display currency, generate audit packs, manage alert destinations.
- Editor — add/remove/edit wallets, run refreshes, export CSVs/PDFs, block tokens, edit per-wallet alert overrides.
- Viewer — read-only across all data. No mutations.
Role enforcement happens at the API layer (not just the UI), so direct API calls cannot bypass it.
Audit trail
Every workspace mutation writes an append-only row to the audit log. Captured events include: wallet add/remove/reassign, member invite/role change/removal, blocked-token additions, alert preference changes, bulk wallet imports, workspace renames, PDF audit pack generation, ERP CSV exports, P&L recomputes and method changes, off-chain position changes, monthly report sends, and snapshot-failure alert dispatches.
The activity log is visible to all workspace members and is exportable for external auditor review. Rows include actor user ID + email snapshot at the time of the event, target object, and a structured metadata payload.
Data handling
- Storage region: Singapore (Supabase ap-southeast-1).
- Encryption at rest: Postgres native + Supabase storage encryption. TLS in transit.
- Tenant isolation:every workspace-scoped table has a workspace_id column; server-side queries always filter on the current user's workspace context. RLS policies are in place; production data access is via service-role with explicit workspace filtering.
- Personally identifiable data: we hold workspace member emails (for invites + alert routing) and Supabase Auth records. We do not hold government IDs, wallet keys, or signing material.
- Retention: snapshots, transactions, and audit log are retained for the lifetime of the workspace. Workspace deletion cascades (data is removed on workspace removal).
Operational practices
- CI/CD: typecheck on every commit; deploys go through Vercel preview environments before production.
- Monitoring: per-wallet snapshot health tracked daily; admin email alerts on 3+ consecutive failures (24h cooldown).
- Cron jobs: daily snapshots (00:05 UTC), daily digest + floor breach checks (00:00 UTC), monthly PDF reports (1st of month, 02:00 UTC). All cron endpoints require a shared secret.
- Backups: Supabase managed point-in-time recovery (7-day window on the current plan).
Regulatory posture
Stride does not custody assets, does not move money, does not provide execution, and does not handle client funds. On that basis we believe the product does not currently fall within the scope of payment-services licensing in Singapore (MAS Payment Services Act). We do not provide AML services or transaction monitoring as a regulated activity — those are customer-side responsibilities.
These statements are our product-level framing, not legal advice. If you operate in a regulated context (PI / EMI / VASP), you should obtain independent counsel on whether using Stride affects your licence obligations. We are happy to share architecture documentation with your compliance and legal teams.
What our team can — and cannot — see
Stride's ops team has service-role database access for incident response and support. We deliberately constrain what our back-office surfaces to minimise exposure of customer-confidential information, even from staff who have legitimate database access.
What staff sees in the back-office:
- Workspace metadata (name, owner email, member emails — needed for support routing)
- Usage counts (number of wallets, transactions, snapshots, audit events, address book entries)
- Health flags (failing snapshots, stale snapshots)
- Audit event timeline — event types, timestamps, actor emails
What staff does NOT see in the back-office:
- Wallet labels (your naming choices)
- Counterparty labels (your business graph — merchants, partners, LPs)
- Address book entries (your settlement counterparties)
- Off-chain custody position notes
- Audit log metadata payloads (which often contain customer values)
- Free-text notes anywhere in the workspace
For genuine support cases requiring deeper inspection, the workflow is: customer-initiated screen-share OR explicit consent OR formal legal process. Direct database access via Supabase Studio is logged at the infra layer with a documented reason.
Stride is observability software for your finance team — not surveillance software, including for our own customers.
Contact for security review
For security questions, vulnerability disclosure, or a procurement-style questionnaire, write to hello@vypeconsulting.com. For pilot terms, see pricing.