Trust

Security, privacy, and how we treat your data.

Ironlake holds the most sensitive parts of a household's balance sheet — entities, holdings, beneficiaries, vault contents. We treat that responsibility seriously. This page explains how the product is built, what's in place today, and what's coming as we move toward general availability.

Where we are right now

The product foundation was chosen for a financial product from day one: a managed database with encrypted storage, account-scoped access controls, row-level security policies on customer data tables, type-checked code paths from the API to the database, two-factor authentication encouraged on every account, data-model support for separately encrypted sensitive fields, and a deliberate read-only relationship with your brokerages.

The strongest protection is one we built into the product

Ironlake never moves money. We don't place trades, schedule transfers, or initiate any financial transaction — even if optional brokerage aggregation is added later. If you decide to trade, transfer, or rebalance, you do that outside Ironlake in the financial institution's own interface. A compromise of Ironlake cannot directly move money or place a trade, because there is no transaction path from our system into yours.

How the product is built

Three things matter most for a product that holds financial data — keeping each customer's data fenced off, encrypting it everywhere it sits, and validating every input before it reaches the database.

Tenant isolation

Customer data is separated by account, with access checks in the application and row-level security policies maintained on customer data tables.

Encryption in transit and at rest

Traffic is served over HTTPS, and application data sits in an encrypted managed database. For future vault and tax-identifier workflows, the data model uses encrypted payload fields so those values can be protected separately from ordinary application records.

Validation by construction

User-facing procedure inputs and server actions are checked against strict schemas before they reach business logic. Database access uses parameterized queries rather than hand-built SQL, reducing injection risk by construction.

Edge protection

Traffic is served over HTTPS at our hosting provider's edge, with automatic HTTP-to-HTTPS redirects and platform-level DDoS mitigation. The www subdomain redirects to the apex domain, so visitors land on the same canonical Ironlake URL.

Account access

  • Two-factor authentication is supported and strongly encouraged. Every account can enable two-factor authentication with a standard authenticator app.
  • Passwords are never visible to us. They're hashed and salted at the authentication provider before storage. Even our own database administrators never see them.
  • Sessions expire automatically. Sessions are short-lived and renewed on activity. Logging out invalidates the session immediately.

Data privacy

  • We don't sell your account data. Not to marketers, not to affiliates, not as a side business. The product is funded by subscription, not by data. We use subprocessors to run the service. Anonymous browsing on our marketing pages goes through standard web analytics; authenticated dashboard pages collect Core Web Vitals performance metrics only (no behavioral analytics). See the subprocessors section below.
  • You decide what happens to your data. Export, correct, or delete it at any time — email privacy@ironlake.co to begin. When you close your account, we remove your product data from the active application database, subject to legal, security, and backup retention requirements.

Subprocessors

The third-party services that touch your data. Each one is contractually bound to handle data on our behalf and is not permitted to use your data for any other purpose.

ProviderRoleDataRegion
SupabaseDatabase, authentication, file storageAll application data.US East (AWS us-east-1)
VercelApplication hosting (frontend + API), anonymous pageview analytics on marketing pages, and Core Web Vitals (Speed Insights) on marketing and dashboard pagesRequest and response data in transit. Application logs. Anonymous pageview analytics (path, referrer, device class) on marketing pages only. Core Web Vitals performance metrics (load time, interaction latency, layout shift) on marketing and dashboard pages — performance only, not behavioral analytics; pageview analytics are never loaded on authenticated dashboard pages.Global edge (US-anchored)
CloudflareDNSDNS lookups.Global
InngestBackground job orchestration (scheduled refresh of market reference data)Function execution metadata — step inputs / outputs and retry state. Functions deployed today operate only on public market reference data (ticker lists, ETF holdings); no personally identifiable customer data passes through.US
ResendTransactional email deliveryRecipient email addresses and message contents for outbound mail (sign-up, password reset, security alerts, scheduled report notifications).US
HubSpotMarketing CRM and analyticsMarketing-form submissions (name, email, phone, comments) and anonymous pageview analytics on marketing pages. Not connected to product data; never loaded on authenticated dashboard pages.US (NA2)

Incident response

If something goes wrong, you'll hear from us. We notify affected customers without unreasonable delay after confirming a security incident that involves their data, with a description of what happened, what data was involved, what we've done, and what you may need to consider.

To report a security concern or vulnerability, email security@ironlake.co. We aim to acknowledge reports within three business days. Responsible disclosure is appreciated and protected.

Have a question we haven't answered, or want to talk through a specific control before submitting an access request? Email security@ironlake.co and we'll respond directly.