What it takes to read a Finvest account from outside the app

Three feeds sit behind one Finvest screen. There is Finvest's own brokerage — equities, ETFs, T-bills, bonds, crypto — cleared on Finvest's stack. There is the cash account, marketed at a 3.25% APY (as stated in the current Play Store listing, dated April 1, 2026) and held across program banks under FDIC coverage. And there is the aggregation layer the user can plug their outside Chase, Schwab or American Express into, so Finn can reason over the whole picture. A useful integration usually wants two of those at once, sometimes all three plus the conversation history Finn keeps. The work is consumer-permissioned interface integration against the live mobile-app session, with the Finn surface treated as its own feed.

What lives on the Finvest backend

The table below maps each surface the app exposes to its origin and to what an integrator typically does with it. Names follow how Finvest itself talks about each in the listing and the in-app UI.

How we'd reach it

A. Consumer-permissioned interface integration (recommended)

The user authorizes us to act on their own Finvest account, we capture the mobile session, and we drive the calls the app already makes — login, refresh, holdings query, sweep balance, linked-account list, Finn history. The output is durable: it lives wherever the app lives, and a new app version means a re-validation pass on our side, not a renegotiation with the customer. We arrange the consenting account during onboarding; the build runs against it.

B. Re-aggregation through a third-party aggregator

For the outside accounts a Finvest user has already linked inside the app, an alternative is going around Finvest and hitting Chase or Schwab via Plaid or an equivalent. It is the cleanest route to those specific institutions, with the trade-off that you lose Finvest's normalization (cost basis, asset-class tagging) and you double the consent surface. We mix this in where the customer needs write-back into the source institution, not just reads.

C. Native exports

Finvest, like most US brokerages, has in-app statements and activity exports. Useful for one-shot historical loads and for backfilling cost basis, but not a continuous feed. We wire it in when the customer wants a hands-off catch-up rather than a live sync.

For most briefs we lead with route A and bring in C for historical backfill. Route B enters the design when the customer's reason for the integration is the outside institution, not Finvest itself.

What ends up in your repo

• An OpenAPI 3.1 spec covering the surfaces in scope — at minimum authentication, holdings, cash balance, transactions, and the linked-account list; with Finn endpoints folded in when the brief calls for it.
• A protocol & auth-flow report: how the session is established, how it refreshes, where the token lives, what the app pins, what fails first when something drifts.
• Runnable source for the in-scope endpoints in Python (httpx + pydantic) or Node.js (fetch + zod); a small CLI to do a full pull against a test account; structured JSON outputs that match the spec.
• An integration test pack that runs against a recorded fixture and against a real consenting account in CI; failure modes are surfaced as typed exceptions rather than swallowed.
• Interface documentation: every field has a short note on where it comes from in the app, units, gotchas, and how it maps to the normalized schema.
• Compliance and data-retention guidance specific to a US broker plus an FDIC sweep — log scope, what is safe to store, what should be re-fetched, what gets a DSAR response.

A fragment from the build

The endpoints below are illustrative and the precise paths are pinned during the protocol pass — included here to show the shape, not to publish them.

# Python 3.11+, httpx
import time, httpx

def authenticate(email: str, password: str, device_id: str) -> dict:
    r = httpx.post(
        "https://api.getfinvest.example/v1/auth/session",
        json={"email": email, "password": password, "device_id": device_id},
        headers={"User-Agent": MOBILE_UA},
        timeout=15,
    )
    r.raise_for_status()
    body = r.json()
    return {
        "token": body["access_token"],
        "refresh": body["refresh_token"],
        "expires_at": time.time() + body["expires_in"],
    }

def holdings(token: str) -> list[dict]:
    r = httpx.get(
        "https://api.getfinvest.example/v1/portfolio/positions",
        headers={"Authorization": f"Bearer {token}"},
        timeout=20,
    )
    if r.status_code == 401:
        raise SessionExpired()
    return [
        {
            "symbol":       p["symbol"],
            "asset_class":  p["asset_class"],   # equity | etf | bond | tbill | crypto
            "account_id":   p["account_id"],
            "quantity":     p["quantity"],
            "cost_basis":   p["cost_basis"],
            "market_value": p["market_value"],
        }
        for p in r.json().get("positions", [])
    ]

def cash_sweep(token: str) -> dict:
    r = httpx.get(
        "https://api.getfinvest.example/v1/cash/sweep",
        headers={"Authorization": f"Bearer {token}"},
        timeout=15,
    )
    r.raise_for_status()
    payload = r.json()
    return {
        "balance":      payload["balance"],
        "apy":          payload["apy_current"],
        "partner_banks": payload.get("program_banks", []),
        "fdic_capped":  payload.get("fdic_capped", False),
    }

Where US data rules currently sit

The dependable basis for reading a Finvest account is the user's own authorization — the same consent Finvest itself relies on when it links its users to their outside banks and brokerages, extended to us, logged, and time-bound. CFPB §1033 is the forward-looking piece that could change the shape of that consent posture; it is presently enjoined and back at the Bureau for reconsideration, so we treat it as a watching brief, not the rule we deliver against. The securities side sits under the standard US broker-dealer framework — SEC registration, FINRA membership and SIPC coverage on what the user holds in the Finvest brokerage.

The cash side is the part that most often catches integrators out. The 3.25% APY the app advertises is not a single bank account; it is a sweep across FDIC-insured program banks, which is why an integration that needs to map to FDIC coverage limits has to ask for the partner-bank split, not just the rolled-up balance. Treating the cash account as one row will work for net-worth dashboards and will misbehave the first time a customer drifts above $250k in cash.

Quirks we plan around

A handful of things about Finvest specifically that we account for during the build, so the consuming platform does not have to learn them the hard way.

• Three feeds, one screen. The brokerage, the sweep and the linked-account aggregator land in the same UI but live behind different services. We normalize them into one schema and tag each row with its origin, so a downstream system can trust totals and still split by source.
• Finn is stateful. The copilot keeps prompt history, fired alerts and scheduled actions. We treat it as a first-class feed with its own pagination cursors, not a derivative of the holdings data, and we expose a way to replay only the events that postdate the last sync.
• Program-bank sweep, not a single bank. The cash balance is one number to the user and a tuple of partner balances underneath. We expose both shapes and let the consuming platform choose; the FDIC-cap view is the one that matters when the customer wants to alert on concentration.
• App-version drift. Mobile-broker apps ship frequently. We hand over a small regression-check script alongside the source, so a new Finvest release shows up as a failing test on your CI rather than as silently stale data downstream.
• Aggregator-of-aggregators. If the customer's user has already linked outside accounts inside Finvest, we read those through Finvest first and only set up a parallel aggregator link when there is a reason — write-back, richer transaction enrichment, or a refresh cadence Finvest does not match.

What was checked, and against what

This brief was put together against the current public footprint of the app — the Play Store and App Store listings, the operator's own site and the Y Combinator launch page — and against the current state of the relevant US regulation. The brokerage-side claims (SEC/FINRA/SIPC) and the 3.25% APY figure are reproduced as Finvest states them in its consumer-facing material; the CFPB §1033 status reflects the federal-court injunction and the Bureau's reconsideration notice. Specific endpoint paths and authentication mechanics are confirmed during the protocol pass on the consenting account.

• Finvest: AI Money Manager on Google Play (package com.bondgrid.bondgrid)
• Finvest on the US App Store
• YC launch page: Finvest, the first AI-powered wealth manager
• CFPB — Personal Financial Data Rights Reconsideration

OpenBanking Studio · integration desk notes, 2026-05-24.

Other apps people stack near Finvest

If you are planning a unified integration that touches Finvest, you are usually touching at least one of the following in the same build. Names below are independent products and are listed for orientation, not ranked.

• Empower (formerly Personal Capital) — long-standing US net-worth and brokerage aggregator with a deep set of linked-institution coverage.
• Wealthfront — robo-advisor with its own cash account and brokerage; useful comparison when a customer wants both a planner and a sweep balance.
• Monarch Money — household-level budgeting that pulls in investments alongside cash and credit, paid-subscription model.
• Kubera — asset-aggregation tool with strong support for alternative assets (real estate, private holdings) on top of standard brokerage feeds.
• Mezzi — AI tax-aware portfolio insights, designed to sit beside, not replace, the underlying broker.
• PortfolioPilot — AI-driven portfolio analysis and risk monitoring, again on top of consented brokerage data.
• Robinhood — US mobile broker with cash sweep and crypto, often the other side of a Finvest comparison.
• Public — multi-asset broker with T-bills and bonds prominent in the consumer experience.
• AllInvestView — multi-asset portfolio tracker that emphasises international holdings and analytics.

Things integrators ask first

Does the FDIC program-bank cash sweep show up as one balance, or one row per partner bank?

In the user-facing app the cash account presents as a single APY-bearing balance, but underneath it is a sweep across program banks. For an integration that has to reconcile to FDIC coverage limits, we model it both ways: a rolled-up account number for normal balance sync, and an exploded view that exposes the partner-bank allocation when Finvest reveals it. Which one the consuming platform reads is a wiring choice we make per project.

Can Finn's conversation history come down the same pipeline as the brokerage holdings, or is that a separate surface?

Finn is the AI copilot layer, and its state (prompts, alerts it has fired, scheduled actions, reminder workflows) sits on a different endpoint from the positions list. We treat it as its own feed with its own pagination and freshness rules, then expose it under one normalized schema so downstream code does not care that two backends are involved. If a customer only wants the holdings and ignores Finn, we ship just that path; if they want both, the auth and rate-limit handling get shared.

If a Finvest user has already linked an outside Chase or Schwab account inside the app, do we re-aggregate that or read what Finvest already holds?

Reading the cached aggregation Finvest already maintains is faster, cheaper and avoids asking the user to re-consent to a second aggregator. We do this where the customer prefers a single point of consent. Where the customer needs a direct line into the outside institution — say, for posting beyond read-only — we wire a parallel link through Plaid or the institution itself, and we keep the two views reconciled so net worth does not double-count.

We're ready to start, what does the actual handoff look like?

A scoping call to decide whether you want runnable source or a hosted endpoint, then we work with you on the consenting account or sandbox we'll build against, the data domains you actually need, and the format you want it in. Compliance paperwork and any NDA are handled during that same setup. Plan on one to two weeks. Start the thread at /contact.html.

$300 buys runnable source against a live Finvest session — bearer-token login, positions query, cash-sweep balance, linked-account list, Finn history if it is in scope — handed over after you have run it and signed off, not before. If you would rather not host code, the same surfaces are available as a hosted endpoint you call and pay for per request, with no upfront fee. Either shape, one Finvest brief runs one to two weeks. Reach the integration desk at /contact.html.