What sits behind Autopilot's automated trade-mirroring

About $2.4 billion in customer assets and more than 90,000 investors ride on Autopilot, per the app's own Play Store listing; InvestmentNews reported the advisory arm crossing roughly $750 million in assets under management as users copy Pelosi and Buffett trades. None of that money lives inside Autopilot. The app sits on top of a user's existing brokerage and fires proportional orders when a chosen “pilot” moves. That architecture is the whole integration story here: the interesting data is a thin, real-time layer of subscriptions, mirrored-trade events and aggregated positions stretched between Autopilot's backend and a connected broker.

The bottom line for anyone wanting Autopilot's data programmatically: split it in two. The signals that drive the trackers are public records you can pull cleanly and independently; the user-specific layer — what someone follows, what got mirrored into their account, how each pilot has performed for them — is read through the authenticated app interface with the account holder's consent. We build both halves and normalize them into one feed.

The data Autopilot actually holds

Autopilot names its catalog the Pilot Marketplace, spanning Expert Pilots, AI Portfolios, Thematic Portfolios, Hedge Fund Trackers and Politician Trackers. Mapped to where each surface originates, that becomes:

Authorized routes in

Public-disclosure sourcing for the signal layer

The trackers rest on filings anyone may read: congressional periodic transaction reports mandated by the 2012 STOCK Act, and the quarterly 13F holdings funds file with the SEC. Reachable in full, durable, and the cleanest part of the job — the formats are stable and the data is public domain. We set up the ingest and parsing; nothing about a user account is needed for this half.

User-consented interface integration for the account layer

Positions, subscriptions, mirrored-trade history and per-pilot performance are account-bound. We reach them by analyzing the authenticated traffic between the app and its backend under the account holder's authorization, then reimplementing the relevant calls. Effort is moderate; durability depends on how often the app's front end changes, which we plan maintenance around. Access to a consenting account is arranged with you during onboarding.

Aggregation-boundary pull for true holdings

Because positions are themselves aggregated from the broker, the most authoritative portfolio read is at that boundary rather than from Autopilot's mirror of it. Where a project needs ground-truth holdings, we integrate at the brokerage-connectivity layer directly, under the same user consent.

For most briefs we recommend running the public-disclosure ingest as the dependable core and layering the consented account interface on top of it — the filings give you a stable, license-clean spine that keeps working regardless of app changes, while the account calls add the per-user picture that filings alone cannot show. The aggregation-boundary route comes in only when a customer needs reconciled holdings rather than Autopilot's view of them.

What we build for this app

Deliverables are scoped to the surfaces above:

• An OpenAPI specification covering the account-interface calls we reimplement — subscriptions, mirrored-trade history, per-pilot performance — plus the disclosure-ingest endpoints.
• A protocol and auth-flow report documenting the token exchange and session handling observed during the build for the authenticated interface.
• Runnable source in Python or Node.js for the key reads: a positions pull, a trade-event stream, and a STOCK Act / 13F ingest with a normalized output schema.
• Automated tests, including idempotency checks on the trade-event sync and a re-validation suite that flags front-end drift early.
• Interface documentation and data-retention guidance fitted to an SEC-adviser context.

A sketch of the positions sync

Illustrative only — field names and the auth header are confirmed during the build against a consenting account, not asserted here:

# Pull a consenting user's mirrored portfolio, normalize, attach disclosure lineage
GET /v1/accounts/{account_id}/positions
Authorization: Bearer <session_token>      # short-lived; refreshed via token endpoint

200 OK
{
  "account_id": "acct_...",
  "as_of": "2026-06-07T14:02:11Z",
  "positions": [
    { "symbol": "NVDA", "qty": 4.0, "source_pilot": "politician:pelosi",
      "mirrored_from_disclosure": "2026-05-22", "observed": "2026-06-05" }
  ]
}

# Reconciliation rule we ship:
#   each position carries BOTH filing date and observed date.
#   sync is idempotent on (account_id, order_id) so a late STOCK Act
#   filing re-surfacing the same trade never double-fires an order.
def upsert_event(store, ev):
    if store.has(ev.account_id, ev.order_id):   # already applied
        return "skip"
    store.put(ev); return "applied"

Three integrations this enables

• Compliance mirror. An RIA wanting an independent audit trail of every order Autopilot fired into client accounts, joined to the source disclosure, for its own books.
• Strategy research feed. A quant desk pulling per-pilot performance history alongside raw 13F and STOCK Act data to test whether the mirrored version tracks the filing.
• Unified portfolio view. A wealth dashboard folding a user's Autopilot-driven positions into a household balance sheet that already aggregates other accounts.

Consent and US data rights

The dependable legal basis for the account layer is the account holder's own authorization — explicit, scoped, revocable consent to read their Autopilot data, recorded and logged. That is what every consented pull rides on. Because Autopilot Advisers, LLC operates as an SEC-registered adviser, we treat the integration as touching regulated client data: data minimization, retention limits and an NDA where the engagement calls for one.

The signal layer is different: STOCK Act transaction reports and SEC 13F filings are public records, so sourcing them carries no consent requirement, only attribution and format discipline. On the broader question of consumer-permissioned financial data access, the CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is where US policy may eventually settle, but as of this writing it is not in force — enforcement has been enjoined and the rule is back in agency reconsideration — so we do not build against it as current law. Consent remains the basis we rely on today.

Field notes from scoping this one

Two things shape how we'd build it.

First, the disclosure delay is real and we design for it rather than around it. Autopilot's founder has said publicly that politician trades surface on average about two weeks after the fact under STOCK Act timing. We stamp every signal with both its filing date and the date we observed it, so a downstream system reasons about staleness instead of assuming a live edge — and the trade-event sync is idempotent, so a disclosure that re-appears in a later filing window never re-fires an order.

Second, positions are an aggregation, not a primary record. Autopilot shows holdings it pulled from the linked broker through its Plaid-based connector, so the same symbol can read differently depending on whether you trust Autopilot's mirror or the broker's own ledger. We map that split explicitly and let the project pick the authoritative source per use case; where reconciliation matters, we pull at the brokerage boundary. We also wire front-end drift detection into maintenance, since the authenticated interface is the part most likely to shift under us.

Interface evidence

Screens from the app's store listing, useful for mapping visible surfaces to the calls behind them. Select to enlarge.

Similar apps in this space

These share data shapes with Autopilot — copy-trading mechanics, congressional and 13F signal feeds, or both — and a unified integration usually wants more than one of them. Named for ecosystem context, not ranking.

• dub — copy-trading app mirroring portfolios of investors, influencers and politicians; holds per-user subscriptions and mirrored-trade events much like Autopilot.
• Surmount — broker-agnostic automation that sits atop existing accounts; holds strategy definitions and connected-account state.
• Quiver Quantitative — congressional and alternative-data platform with a documented API; holds normalized disclosure datasets.
• Unusual Whales — political trading plus options-flow data; holds disclosure feeds and derived signals.
• Capitol Trades — free congressional-trade tracker; holds structured STOCK Act disclosure records.
• InsiderFinance — real-time congressional-trade alerts; holds event streams over disclosure data.
• StockCircle — political and investor portfolio tracking across legislatures; holds portfolio time series.
• Composer — automated strategy builder; holds user-defined symphonies and execution history.
• TraderCongress — multi-source congressional trade aggregation; holds merged disclosure datasets.

Sources and how this was checked

Compiled on 7 June 2026 from the app's store listings, the SEC adviser record, trade press and primary disclosure sources, cross-checked against the app's own feature descriptions. Where a number is the app's marketing claim rather than a filing, it is flagged as such above.

• Google Play listing — finance.iris.autopilot
• SEC IAPD — Autopilot Advisers, LLC firm summary
• InvestmentNews — Autopilot AUM and RIA growth
• SEC — registered investment adviser data

Mapping reviewed June 2026 by the OpenBanking Studio integration desk.

Questions an integrator asks

Where does the holdings data Autopilot shows actually come from?

Positions and balances are not Autopilot's own records; they are aggregated from the linked brokerage (Robinhood, Schwab, Fidelity, E*TRADE, Public and others) through a third-party connectivity layer the app describes as Plaid-based. So an integration that wants true portfolio state pulls it at the aggregation boundary, while pilot subscriptions, mirrored-trade events and performance history are read from Autopilot's own backend.

Can the politician and hedge-fund tracker feeds be integrated separately from a user account?

Partly. The underlying signals Autopilot's Politician Trackers and Hedge Fund Trackers are built on are public-domain disclosures: STOCK Act periodic transaction reports and SEC 13F filings. Those can be sourced independently and legally. What is account-bound is Autopilot's own curation, the per-pilot performance history and which pilots a given user follows, and that part is read through the authenticated app interface under the account holder's consent.

How do you handle the roughly two-week STOCK Act disclosure delay in a sync?

We treat disclosure lag as a data property, not a defect. The app's founder has said publicly that politician trades surface on average around two weeks after the fact under STOCK Act timing. We timestamp each signal with both its filing date and its observed date so downstream systems can reason about staleness rather than assume real-time alpha, and we design the trade-event sync to be idempotent so a late-arriving disclosure does not double-fire.

One practical close: tell us the app name and what you want out of its data, and we handle the access, consent and compliance setup with you from there. Two delivery shapes, priced plainly — we build the runnable source, OpenAPI spec, tests and interface docs and hand them over for a flat fee from $300, payable only after delivery once you are satisfied; or we host the integration as an endpoint you call and pay per call, with nothing upfront. Either way the cycle runs one to two weeks. Start the conversation at /contact.html.