The aggregator problem: why we refuse to ask for your brokerage password.

Every popular wealth-tracking app you can name — Mint, Personal Capital (now Empower), Monarch Money, Copilot, Tiller, Quicken Simplifi — works the same way under the hood. You hand it your brokerage username and password. It logs in as you, scrapes your positions and transactions, and stores them in its own database. The convenience is real. So is the architecture, and so is its failure mode.

This post explains what the aggregator architecture actually is, what breaks when it fails, why we built HELM the other way, and the tradeoffs we accept by doing so. The goal is not to scare anyone off Mint or Empower — they remain useful tools for plenty of operators. The goal is to give you enough information to choose with intent, instead of choosing by default.

What an aggregator actually is

The companies whose names you'd recognize on the dashboard side — Mint, Empower, Monarch — don't actually do the credential-handling themselves. They route the work to an aggregator: Plaid, Yodlee, MX, or Finicity. These are middleware companies that maintain integrations with several thousand US financial institutions. Their job is to take your username and password, log in to your bank or brokerage, fetch the data, and return a normalized JSON object the consumer app can render.

Two things happen the moment you "connect" an account:

• Your credentials (or in the OAuth-supported subset of institutions, a long-lived access token equivalent) flow to the aggregator's servers, where they're stored encrypted.
• A persistent connection is established. Most aggregators refresh data several times a day, automatically logging back in to your account.

The aggregator now has both an attack surface and a high-value target. Anyone who breaches the aggregator's vault has access not to one set of brokerage credentials, but to tens of millions. Plaid alone reports handling data for 100M+ consumers across 12,000+ institutions. The economics for an attacker are obvious.

What has actually happened

This is not a theoretical concern. Aggregators and aggregator-dependent apps have been involved in repeated incidents over the past decade.

• Plaid · 2022 class-action settlement. Plaid agreed to a $58 million settlement in a class-action lawsuit alleging it had collected and retained more financial data than users authorized — including credentials and transaction history beyond what was needed to power the apps users had connected. The settlement did not establish wrongdoing as a legal matter, but it did establish that the data flowing through aggregators is voluminous, durable, and not under the consumer's direct control.
• Equifax · 2017. Not an aggregator per se, but a useful baseline: 147 million Americans' financial data was exposed. The lesson — that consumer-financial-data centralizers are high-value targets — applies equally to aggregators.
• Mint deprecation · 2024. When Intuit shut down Mint and migrated users to Credit Karma, the friction was high precisely because all account connections had to be re-established at the new aggregator endpoint. Many users simply gave up on automated tracking. The credentials, however, remained in the old system until the deprecation timeline played out.

None of this means aggregators are negligent or that Plaid's engineers do not take security seriously. They demonstrably do — Plaid is SOC 2 Type II compliant, ISO 27001-certified, and operates a public bug bounty program. What it means is that the architecture itself creates the centralized target, and no amount of internal diligence makes it disappear.

Why this matters more for HNW operators

The risk is asymmetric. A typical retail user connecting Plaid to track a checking account and an IRA is exposing maybe $50K of liquid wealth. A solo HNW operator connecting eight accounts — taxable brokerage, IRA, Roth IRA, HSA, joint checking, two business accounts, and a private vault — is exposing single-digit millions. The cost of an aggregator breach scales linearly with the operator's net worth, but the aggregator charges a flat fee (or, in the consumer apps' case, $0).

This is why most wealth managers, family offices, and CFP/CPA professionals refuse to use consumer aggregator tools for their clients' tracked positions. The risk-adjusted economics don't work above a certain net-worth threshold. The professionals, instead, ask the operator to download statements monthly and reconcile manually — which is exactly the workflow we standardized in HELM.

The two architectures, side by side

The "manual is too much work" objection

Fair. Two pieces of context.

First, the actual time cost. A monthly upload of statements from five institutions — assuming the operator is not making 200 trades a month, which most are not — takes about 12 minutes. Schwab, Fidelity, Vanguard, E*TRADE, and Interactive Brokers all expose CSV exports through their account-history pages. Coinbase and most major crypto exchanges expose them too. The CSV format is stable across years; we maintain parsers for the common ones and the parser library is public on GitHub.

Second, the strategic distinction between data and decision. Aggregators sell real-time data. Manual-first tools sell better thinking. For most HNW operators, the bottleneck is not "I didn't know my exact net worth at 9:14am Tuesday." The bottleneck is "I don't have time to scan all my positions for wash-sale risk" or "I forgot to track the QSBS clock on that 2021 angel check" or "I haven't run the FI Monte Carlo with my updated assumptions in two years." Those are problems aggregator-based apps don't actually solve well, because the moment you've fetched the data you've used 90% of the product's value. Real analysis happens after.

What we never store, and what that buys you

Because we never log in to your accounts, the entire class of credential-related risk vanishes from our threat model. We have nowhere to store a brokerage password, because there is no field for one. We have nowhere to store a routing number, because nothing in HELM ever needs to initiate a transfer.

What we do store: the data you bring us, encrypted at rest in a per-tenant Postgres database. Your CSV file is parsed in memory by a serverless function and discarded; only the normalized rows make it to the database. The full list of what we never collect — brokerage logins · full account numbers · routing numbers · SSN · government IDs · plaintext passwords · tracking pixels · reverse-enrichment cookies — is published at atthelm.com/security#never-store.

Honest tradeoffs, both directions

Manual-first is not strictly better. There are real tradeoffs.

What you give up

• Real-time refresh. If your dividend hits today and you want to see the cash balance update by 5pm, manual-first can't do that without you uploading.
• Auto-categorization. Aggregators can label "Whole Foods" as Groceries automatically. We don't, because the categorization is your taxonomy and we'd rather not guess.
• Bill-tracking integration. If your goal is monthly cashflow management, an aggregator-based budgeting tool may genuinely fit better. HELM is a wealth-OS, not a budgeting app.

What you get

• No aggregator-breach exposure. The architectural risk class is not present.
• No vendor lock-in to refresh cycles. If Plaid changes its pricing, your tool keeps working.
• Cross-institution analysis. Wash-sale detection across all your accounts in one query — not just inside the aggregator's coverage list.
• Compliance comfort. Many fiduciary advisors, family-office staff, and operators with compliance constraints simply cannot use aggregator-based tools. Manual-first removes that friction.
• Privacy clarity. When the answer to "where does my data go" is "into one Postgres database, encrypted, scoped to your operator ID, with one named sub-processor list of seven companies," it is a defensible technical claim, not marketing language.

If you stay on an aggregator-based tool

Three operational rules to reduce risk if you do.

1. Use OAuth where the institution offers it. Schwab, Fidelity, and a growing list of brokerages support OAuth-style consented connections that don't require giving up your password. Use that path when available — even your aggregator dashboard usually flags it.
2. Disconnect when not in use. If you're a once-a-quarter checker, the aggregator does not need a persistent connection. Sever the connection at every audit cycle and re-authenticate when you actually need fresh data.
3. Audit the sub-processor list. Every aggregator-dependent app has one. Look for the page; if you can't find it, that's a signal. Plaid, Yodlee, and MX all publish their security postures and certification status — read them once.

The architectural choice is the moat

Most wealth tools competing in 2026 are arguing about features — "we have AI, they don't" or "our charting is prettier" or "our pricing is lower." The architectural choice underneath the features is rarely surfaced because most of the tools share it. We have built HELM the other way deliberately. Aggregator-credential breaches are impossible for HELM by design, not by policy.

That's not a marketing claim. It's a structural one. The choice has tradeoffs, listed above. If you accept those tradeoffs, HELM is built for you. If you don't, an aggregator-based tool may genuinely fit better, and we've tried to give you the framework to choose with intent.