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, and we keep an anonymous count of how many people complete each public calculator (no name or email, and no IP on the record itself - only a hashed, non-reversible IP key for rate-limiting) so we can see which tools are useful; authenticated dashboard pages collect Core Web Vitals performance metrics only (no behavioral analytics). If you arrive from one of our links or shared exports, we store a single first-party cookie (“il_from”) that remembers which page sent you, so we can see which of our own tools lead to signups. It holds only that source label (no name, email, or browsing history), and it clears when you create an account. While we're in early access, when a signup is turned away by the beta gate we keep a hashed, non-reversible record of the attempt by source (the email is stored only as an irreversible hash, never in plain text) so we can gauge how much demand the waitlist is holding back. If you submit the request-access form, the name and contact details you enter are sent to our CRM subprocessor (HubSpot), as described on that form, and we also keep the same hashed, by-source record. 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.
| Provider | Role | Data | Region |
|---|---|---|---|
| Supabase | Database, authentication, file storage | All application data. | US East (AWS us-east-1) |
| Vercel | Application hosting (frontend + API), anonymous pageview analytics on marketing pages, and Core Web Vitals (Speed Insights) on marketing and dashboard pages | Request 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) |
| Cloudflare | DNS | DNS lookups. | Global |
| Inngest | Background 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 |
| Resend | Transactional email delivery | Recipient email addresses and message contents for outbound mail (sign-up, password reset, security alerts, scheduled report notifications). | US |
| HubSpot | Marketing CRM and analytics | Marketing-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.
Legal documents
The versioned agreements and notices that govern the service: Terms of Service, Privacy Policy, and Disclosures. Each page shows the version and effective date of the text in force; your account records which versions you accepted.
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.