Privacy · Architecture

The privacy-first finance app — what it actually means when a wealth tool says "no tracking."

~12 min read · Published May 2026

Open the network tab on Empower (formerly Personal Capital) and reload the homepage. You'll count somewhere between 28 and 40 third-party requests — Google Analytics, Meta Pixel, LinkedIn Insight, AppNexus, doubleclick.net, an Adobe stack, Optimizely, Hotjar session-replay, and a handful of advertising re-targeters most visitors have never heard of. That's the surveillance overhead of one homepage load. Now imagine the same architecture is also asking for your brokerage credentials.

This essay is about the architectural choice behind not doing that. Specifically: what it takes for a wealth tool to load zero third-party network requests. Why that's harder than it sounds. And why it matters more for HNW operators than for any other user category.

What "third-party trackers" actually are

A third-party tracker is any script, pixel, or font file your browser fetches from a domain other than the one you typed in. When you load a typical wealth-management dashboard, the page itself comes from the company's domain — but the page tells your browser to also fetch:

Analytics scripts (Google Analytics 4, Adobe Analytics, Mixpanel) that record every page view, click, scroll position, time on page, and referrer.
Advertising pixels (Meta Pixel, LinkedIn Insight, TikTok Pixel, Reddit Pixel) that tell ad networks "this person was on a wealth-tool site" so they can be retargeted across the rest of the web.
Session-replay tools (Hotjar, FullStory, Mouseflow) that record a video of your mouse movements, scrolls, and inputs — including, if not configured carefully, what you typed into form fields.
Heatmap and A/B tools (Optimizely, VWO) that fingerprint your device to bucket you into experiment cohorts.
Tag managers (Google Tag Manager) that orchestrate all the above and can deploy new trackers without a code change.
Third-party fonts (Google Fonts, Adobe Fonts) — not technically tracking, but every font file ping is a logged request that reveals your IP and user-agent to a third party.

Each of these vendors gets to know that somebody at this IP, with this device fingerprint, visited this page, at this time, having been referred from this source. That's the floor. Many also receive the page URL, which on a wealth tool can include things like /portfolio/holdings or /tax/scenario — labels that disclose what the user is doing, not just that they showed up.

Why this is worse for finance than for almost any other category

Most categories of software can argue that the analytics overhead is an acceptable trade for the product getting better over time. A todo app's "homepage → signup → activated" funnel is not particularly sensitive. A blog's "read time" metric is fine.

Finance is different because the metadata leaks the substance. A wealth tool that loads Meta Pixel on a page titled Tax-Loss Harvesting Scan is broadcasting to one of the largest ad networks on earth that this specific user is engaged in tax-loss harvesting at this specific moment. The page URL, the time on page, the referrer chain — all of it becomes input to advertising profiles, lookalike audiences, and (in the most aggressive cases) data-broker resale.

Most users never read the privacy policy footnote that says "we may share aggregate analytics with our partners." But aggregate is doing a lot of work in that sentence. Aggregated cohorts of "active wealth-management users with $1M+ portfolios who used the tax-loss feature in the last 30 days" are exactly the kind of audience signal that gets sold and resold downstream. The user gave consent to "analytics." They did not give consent to this.

"If you are not paying for the product, you are the product." That's the cliché. The less-quoted half is: paying for the product doesn't automatically protect you. A subscription doesn't switch off the surveillance stack.

What "zero third-party calls" actually requires

The phrase sounds simple. In practice it requires turning down a long list of free, easy, default choices that most teams ship without thinking about:

1. Self-hosted fonts.

Almost every modern web design starts with a Google Fonts <link>. It's free, it's fast, it works. It also pings fonts.googleapis.com for the CSS file and fonts.gstatic.com for each individual font weight, on every page load, for every visitor. The pure-self-hosted alternative is to download the WOFF2 files, serve them from your own origin, and write the @font-face declarations yourself. It takes about an hour, costs a few hundred kilobytes of repo size, and eliminates two third-party domains permanently.

2. No Google Analytics. No alternative analytics with cookies either.

The honest replacement isn't a different tracker — it's no client-side tracker at all. Modern hosting platforms (Netlify, Cloudflare, Vercel) ship server-side analytics that parse access logs without putting any JavaScript in the browser. You lose granular event tracking. You gain the ability to truthfully tell a prospect that no analytics script runs in their browser when they visit the site.

3. No ad pixels. Period.

Meta Pixel, LinkedIn Insight, Google Ads Tag — every one of these is justified internally as "we need to measure ad attribution." That justification is real for a B2C app spending $50K/mo on Facebook ads. It's not real for a wealth tool whose customers find them through referral, search, and outbound. The lazy default is to load the pixels anyway, "just in case." The disciplined choice is to skip them and measure attribution server-side from UTM parameters and signup events.

4. No session-replay tools.

Hotjar, FullStory, and Mouseflow record everything a user does. The vendors all promise to mask sensitive form fields, but the masking is opt-in and frequently misconfigured. For a wealth tool, the realistic risk is recording an account number being typed, a tax-scenario projection being viewed, or a beneficiary's name being edited. The honest move is to never load the script.

5. Lock the choice with a Content Security Policy.

This is the part most teams skip even when they want to be private. A CSP is a response header that tells the browser exactly which origins are allowed to be contacted. With a strict CSP, even if a developer accidentally adds a tracking script, the browser refuses to load it. The promise stops being a policy and becomes an enforcement.

HELM's CSP, for example, allows the browser to fetch from atthelm.com, Stripe (only on the checkout page), and Supabase (only when authenticated). Everything else is blocked at the browser level. "No third-party calls" stops being a marketing claim and starts being something the user's browser actively enforces.

Live verification

Open atthelm.com/network-audit — that page runs a count in your own browser and shows you the receipt. No screenshots. No marketing voice. Just the number.

What it costs the operator

The fair question is: what does a no-tracker product give up?

Granular product analytics. Without client-side trackers, you don't get a fine-grained funnel of "user opened the dashboard, hovered over the donut chart, scrolled to the holdings table, clicked the export button." You get the coarse signals: signups, subscription events, server-side feature usage. For a tool whose pricing is flat-fee and whose retention is built on quality rather than engagement-bait, that's enough. For a freemium app that needs to optimize a signup funnel against a 3% conversion target, it's probably not.

Ad retargeting. You can't run a Facebook lookalike audience based on people who visited /pricing. For a wealth tool whose buyers find it through search and direct, the loss is small. For a wealth tool growing through paid social, the loss is large.

Embedded marketing tools. Intercom, Drift, and the rest of the chat-widget category load substantial third-party scripts. A no-trackers posture means choosing email and a contact form over a chat widget that follows the user around the site. That's a real tradeoff and a different style of customer support.

The honest read: zero-tracker is the right architecture for a low-volume, high-trust, premium-priced tool serving a sophisticated audience that responds badly to ad retargeting. It is the wrong architecture for a high-volume, low-margin, top-of-funnel-driven product.

Why HNW operators in particular care

Most users tolerate trackers because the personal cost feels theoretical. For an HNW operator, the cost is more concrete:

The same data-broker pipelines that aggregate "active wealth-management user" cohorts also feed the data brokers who sell physical-address lookups to scammers. The metadata trail from a wealth-tool visit is one input in those datasets.
Discovery in legal proceedings (contested estates, divorces, business disputes) can subpoena third-party analytics records. A logged-out, anonymized visit to /tax/scenario-builder with a recognizable device fingerprint can become a deposition exhibit. The fewer logs that exist, the less of that surface there is.
Aggregation risk compounds. An HNW operator's financial life touches dozens of vendors — broker, trust company, CPA, insurance, real estate, private equity. Every one of those vendors that loads trackers is one more link in a profile that can be reassembled by a determined party.

The architectural argument: a wealth tool that doesn't connect to your brokerage (manual-first) and doesn't broadcast your visits to third parties (no-tracker) eliminates two attack surfaces by design, not by policy. There is no place in the codebase to put a brokerage password, and no place in the network plan to put a tracker. You can't fail a control that doesn't exist.

How to verify any wealth tool's tracker posture in 30 seconds

You don't have to take any vendor's privacy policy at their word. Three-step audit, works on every site:

Open the page in a private/incognito window. This bypasses your local cookies and gives you a clean baseline.
Open DevTools → Network tab. Reload the page.
Filter by domain. Anything that isn't the site's own domain is a third-party request. Count them. Read the hostnames.

For the average wealth tool, you'll see 20–40 third-party requests on the homepage alone — and more on logged-in pages. For a privacy-first wealth tool, you'll see zero (or only Stripe on the billing page, only Anthropic when an AI feature runs, etc.). That count is the receipt. Marketing copy doesn't change it.

What we built and what it means

HELM, the wealth OS we ship, is built on three architectural choices that compound:

One: manual-first data entry. No Plaid, no Yodlee, no MX. There is no place in our system to store your brokerage password because the system never asks for it. (Read more: The Aggregator Problem →)

Two: zero third-party network calls. The site, the app, and every transactional email load only from our own origin and the bare-minimum payment/auth/AI vendors required to actually run the product. (Verify: atthelm.com/network-audit)

Three: browser-enforced via CSP. The promise is a response header your browser refuses to violate. Any future regression — a developer adding an analytics script, a vendor's library trying to phone home — gets blocked at the browser level before any data leaves your tab.

None of this is a feature. It's a posture. Features are easy to ship; postures are easy to break, and breaking one would be a deliberate decision rather than an oversight. That asymmetry is the point.