What HELM has on you. The complete list.

Here's a thought experiment. If our database is breached tomorrow morning at 3 a.m. — every row of every table copied to an attacker's laptop — what does that attacker walk away with? Pull up your favorite finance app and ask the same question about it. The honest answer for most consumer finance apps is "we'd have to ask the engineers, and the answer is bad." The honest answer for HELM, which we'll spend the rest of this post making concrete, is "a list of things you typed in, plus the analyses you ran on them, and that's it."

That gap isn't a marketing flourish. It is the consequence of an architectural choice we made on day one and have refused to walk back even when it costs us features prospects expect. This post is the audit. We'll publish the full inventory of what HELM stores about you, the inventory of what HELM does not store, the architectural decision that produced both lists, and the price we pay for that decision. By the end of it you'll have a template you can use to interrogate any other finance app you're considering — and a sharp sense of why most of them won't be able to answer.

Why the question is worth asking out loud

Most finance apps cannot publish this kind of inventory. Not because they're hiding something malicious, but because the answer is genuinely sprawling: a primary database, a few read replicas, an analytics warehouse, an event-streaming layer, three observability vendors, two CRM platforms, an attribution stack, a customer-support tool that mirrors transcripts, an email service provider that retains delivery metadata, and a half-dozen ad and growth pixels firing through the user's browser. Each of those holds a different slice of you. Each has its own retention window, its own breach history, its own subprocessor list.

If you ran a fire drill at any large consumer finance company and demanded a complete data inventory by end of week, the engineering, security, legal, and ops teams would all need to be in the same room for several days, and the resulting document would still ship with a footnote about "best-effort scope." This is not a moral failing — it is a structural property of how modern SaaS gets built. Vendors stack until the architecture becomes opaque to its own operators.

HELM is built so that the inventory fits on a page. The reason it fits on a page is the reason we wrote a separate post about why we refused to use Plaid or Yodlee — once you accept aggregator integration, the inventory immediately doubles, and it doesn't fit anymore. So we accepted a different tradeoff, and we'll cover the cost of that tradeoff before the post is over.

The complete list of what HELM stores about you

This is every data class HELM persists. Not "the important ones." Not "the consumer-facing ones." All of them. If we add a new one, this list updates and the changelog reflects it.

Read that list one more time. Notice what's there: things you typed in, and computations we ran on them. Notice the granularity at which the list terminates — we don't even keep your name unless you opt to set a display name. Notice that nothing on this list could be used by an attacker to log in to a brokerage as you, withdraw funds, run an ACH transfer, or impersonate you to a third party. The reason is in the next section.

The complete list of what HELM does not store about you

Just as important as what's there is what isn't. The following classes of data are absent from HELM by design — not by oversight, not pending a future migration. They will never be in HELM as long as the product is built the way it's built today.

Take that list to the finance app you currently use and ask its support team — or its public privacy policy, or its security white paper if it has one — to confirm or deny each item. The answers will be illuminating, in both directions. A lot of consumer finance products store more than this. A few specialized tools store less. The exercise itself is the point.

The architecture decision that made this list short

HELM is manual-first. You enter your holdings yourself, in a structured form. You re-enter them when they materially change — on rollovers, large contributions, or quarterly check-ins for operators who run a tighter cadence. We optimize the entry experience to make this as fast as possible: bulk paste from a brokerage statement, smart defaults for asset classes, a one-click "duplicate last quarter" that brings forward your structure and lets you update only the values that moved.

That choice is what kept the inventory small. Manual entry means we don't need to maintain credentialed integrations, which means we don't need an aggregator vendor, which means we don't have a long-lived access token vault, which means we don't have transaction streams, which means we don't have the "real-time balance" feature most consumer apps lead with — and we don't have its corresponding attack surface.

An honest counter-question: doesn't this make the product worse? It makes the product different. The kind of operator HELM serves — fatFIRE, equity-comp households, multi-account allocators — is not optimizing to refresh a dashboard hourly. They're checking quarterly. They're running scenarios when something material happens. They're producing a document for an estate attorney or accountant. For that workflow, the manual cadence is a feature: you re-engage with the numbers instead of letting them auto-update into the background of your attention. The friction is therapeutic. (We made the same argument in net worth is a lagging indicator — the trailing-twelve-months number you didn't have to enter is the one you didn't have to think about, which is exactly the problem.)

The cost of choosing this architecture

To be fair to the alternatives: aggregator-based tools have real strengths. Here's what we give up by being manual-first, written without varnish:

If your dominant need is daily cash-flow visibility, an aggregator tool may serve you better than HELM, and we'll say that on a sales call without hesitation. If your dominant need is multi-decade modeling on a quarterly cadence with a clean handoff to your CPA or attorney, HELM is in its element. Operators in the latter group are who we built the product for.

Case study: the monthly digest

Here's a small concrete consequence of the architecture, and the thing that originally pulled this post out of an internal architecture memo and onto the public blog. HELM ships a Monday-morning email digest — a brief summary of the prior week's activity, your leading indicators, and any flags from Tax Brain or the scenario engine. It lands in your inbox; it does not require you to log in to read.

That last property surprises some operators when they think about it. Most finance dashboards can't send you a usable email summary, because the moment they pre-render numeric values into an email, they've made copies of those values outside the app's auth perimeter. So the typical digest you get from a finance app is a vague nudge ("you have new insights — open the app to view"), which exists to drive engagement metrics rather than to tell you anything. HELM's digest contains actual numbers, because the actual numbers are your numbers, that you entered, summarized and computed and sent back to you. There is no aggregator-side privacy concern about pre-rendering them, because there is no aggregator side. There is no risk of them being out of date relative to your "real" balances at the brokerage, because we never claimed to be polling those.

The digest is a small feature. But the property it has — useful without requiring a re-auth — is downstream of the architectural decision. Once you stop chasing real-time aggregation, a long list of small features become quietly cheaper and more useful, because the data is yours, the computations are deterministic, and the surface area to defend is narrow.

What every finance app should be willing to publish

If we accomplished only one thing with this post, we'd want it to be this: a template every reader can take to any other finance app they use, and ask the same questions of it.

1. The complete inventory of data classes you hold about me. Not "the important ones." All of them, including analytics warehouse and CRM and email service provider and customer-support transcripts. If the company can't produce this in 24 hours, that is itself information.
2. The list of subprocessors who receive any of those classes. Aggregator, hosting, observability, email, support, analytics, ads. Each subprocessor has its own retention, breach history, and contractual posture.
3. The retention windows, by class. Login records for 90 days; identity for the lifetime of the account; transactions for seven years; et cetera. Vague answers ("we keep things as long as needed") are non-answers.
4. The path to deletion. Clicking "delete account" should produce, within a defined window, removal across all listed classes and all listed subprocessors. The right number to expect is days, not "best-effort indefinite."
5. The export equivalent. Anything you've entered should be exportable in a structured format — CSV at minimum, JSON ideally. If the data is yours, you should be able to leave with it.

If the company can answer (1) through (5) in plain language without reaching for a privacy lawyer first, you have a serious operator. If they can't, you have information about the kind of operator you have. Neither outcome is a moral verdict on the company; it's a description of the tools they've chosen and the tradeoffs they've made. But the difference will matter on the day a breach lands in the news.

Closing the loop on the thought experiment

Back to the prompt at the top of the post. If HELM is breached tomorrow morning at 3 a.m., the attacker walks away with: a list of email addresses, a list of values that you typed and called "holdings," some saved scenarios you ran, some tax events you logged for harvesting analysis, some chat threads you exchanged with an in-app advisor, and any documents you explicitly chose to upload to the vault (which are encrypted at rest with a per-account key, so the practical attack against vault contents would also require the encryption infrastructure, not just database read).

The attacker does not walk away with brokerage credentials, OAuth tokens, account numbers, real-time balances, transaction streams, or anything that lets them pretend to be you to a financial institution. None of that is in HELM, because we never collected it.

That property of "you cannot lose what you never collected" is older than software. It's the reason ATMs don't store the cash they dispense; the reason airline ticket counters don't hold passenger luggage in the lobby; the reason a good safe-deposit-box facility doesn't make a master copy of every deposit. The boring discipline of not collecting is a security control, possibly the strongest one a software product can adopt, and it's one of the few that actually scales linearly with the number of users — the more people you serve, the more carefully you have to defend what you have, but if you have less, you have less to defend.

It costs us features. We are clear-eyed about that. But it lets us write a post like this one — and back it up with a live audit page that proves zero third-party origins, an enforced Content Security Policy, scanner badges from independent third parties, and an architecture you can hold a finger on the structure of in fewer than fifteen minutes. We think that's a fair trade for the operator we built for.