Reaching the holdings and tax lots inside a Frec account

A Frec account doesn't hold one S&P 500 position. It holds the individual stocks that make up the index, lot by lot, each with its own cost basis, open date and harvest history. That structure is the whole point of direct indexing — and it is exactly what makes the account worth integrating, because the interesting records aren't a single balance but hundreds of tax lots and a running ledger of harvested losses sitting underneath them.

The bottom line for an integrator: positions and transactions are reachable cleanly, but the records that make Frec distinct — the harvest ledger, the paired long/short legs, the line-of-credit detail — are Frec-side constructs that a generic aggregation feed flattens or drops. The route we actually build around reflects that, and it is described below rather than ranked off a template.

What sits behind a Frec login

Each row below is a real surface the app exposes to its own user, not a generic finance checklist. Granularity matters here more than usual, because the value of a direct-indexing account is in the lot-level detail rather than a rolled-up figure.

Getting at the data

Three routes genuinely apply to an account like this. Each one we set up and run with you during the engagement; access and authorization are arranged as part of the work, not asked of you up front.

User-consented account aggregation

Investment aggregators expose brokerage holdings and transactions through consented endpoints — the kind of /investments/holdings/get and /investments/transactions/get calls documented by providers such as Plaid. Reachable: positions, securities and transaction history. This route is durable across app redesigns because it rides the aggregator's connection, and it is the easiest broad sync to keep alive. What it tends to miss is the Frec-specific texture — the harvest ledger and the credit line don't map onto a standard holdings schema.

Authorized interface integration and protocol analysis

Working from the account holder's authorization, we capture and document the app's own request/response chain — the token flow, the session cookies, the calls that render each screen — and build a typed client against it. Reachable: everything the user can see, including the harvest events, the long/short legs and the line-of-credit detail that aggregation flattens. It needs upkeep when Frec changes its front end, and we plan for that.

Native document export

Statements and year-end tax forms produced with Apex are a reliable fallback for cost-basis and lot history, especially for a one-time backfill where a live connection isn't warranted.

For Frec specifically, the consented-aggregation feed is the cleaner way to keep positions and transactions current, but it won't carry the harvested-loss ledger or the credit line — those are the records most teams come here for. So in practice we build the protocol-analysis client to carry the Frec-side detail and lean on aggregation for the broad, durable position sync, with document export reserved for historical backfill. Which of the three leads depends on whether you mainly need the tax data or a live holdings mirror; we make that call with you on the first scoping pass.

What lands at the end

Deliverables are tied to the surfaces above, not a stock list:

• An OpenAPI/Swagger specification covering the holdings, transactions, harvest-ledger and credit-line objects as a normalized schema.
• A protocol and auth-flow report — the token issue/refresh chain and session handling as they actually behave for this app.
• Runnable source for the key endpoints in Python or Node.js: positions, harvest ledger, treasury and the line-of-credit balance.
• Automated tests, including fixtures for paired long/short legs and wash-sale-flagged lots so regressions surface early.
• Interface documentation that records which fields come from Frec and which from Apex.
• Compliance and data-retention guidance: what is logged, how consent is recorded, and how lot-level data is minimized and aged out.

A positions pull, sketched

Illustrative only — field shapes are confirmed against the live app during the build, and every call runs under the account holder's authorization. Account identifiers are opaque; no login secret is stored in the response.

GET /v1/accounts/{account_id}/positions
Authorization: Bearer <session-derived token>

200 OK
{
  "account_id": "frec_8f2a...",        # opaque handle, not the user login
  "as_of": "2026-06-11T20:00:00Z",
  "strategy": "sp500_direct_index",
  "lots": [
    {"symbol": "AAPL", "qty": 12.4031, "cost_basis": 2105.88,
     "open_date": "2025-09-02", "unrealized": -84.20, "wash_sale": false},
    {"symbol": "NKE",  "qty": 41.0009, "cost_basis": 3990.12,
     "open_date": "2026-01-14", "unrealized": -213.07, "wash_sale": true}
  ],
  "overlay": {"long_legs": 318, "short_legs": 112},   # long/short tilt
  "harvest_ledger": [
    {"date": "2026-06-10", "symbol": "NKE",
     "realized_loss": -213.07, "replacement": "similar-exposure",
     "disallowed": 0.00}
  ]
}

# Auth handling: a 401 triggers a refresh against the token endpoint;
# repeated 401 after refresh means re-consent, surfaced to the caller.
# Requests are paced to the app's observed rate limits, not hammered.

Consent and where US data rights stand

Frec custodies through Apex and reports under FINRA and SIPC; per Frec, securities are protected up to $500,000 by SIPC, with additional Apex coverage cited in the app. No in-force US rule requires a brokerage like Frec to share account data with a third party on demand. The working basis is plain: the account holder authorizes access to their own records, that consent is scoped to the domains the integration needs, and it can be revoked. We log consent grants, keep the access surface narrow, and operate under an NDA where a client needs one.

The CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) could eventually formalize third-party access for accounts like these. As of this writing it is enjoined and back in reconsideration at the Bureau, so we treat it as a forward-looking possibility, not the law a build relies on today. The dependable anchor stays the consumer's own authorization.

What this build has to get right

These are the things the engineering accounts for on a Frec job — judgment calls we handle, not boxes you tick before we start.

Harvest-ledger fidelity

We model the harvest ledger at lot granularity and carry the wash-sale flags Frec applies, so exported losses reconcile against what the app actually shows rather than a number we recompute and hope matches. Getting the disallowed-loss handling wrong is the failure mode that quietly corrupts a downstream tax filing.

The Frec/Apex boundary

Positions, fills and corporate actions sit on Apex's books; index customization, the overlays and the harvest logic are Frec's. We map field-by-field which system owns what, so reconciliation doesn't burn cycles chasing differences that are just two systems describing the same lot.

Keeping long and short legs paired

Long Short Direct Indexing and the Diversify overlays carry matched long and short legs. We keep that pairing intact through the schema so net exposure and harvested losses tie out, instead of collapsing everything into one flat position list. And when Frec ships a front-end change, re-checking the captured flows is part of ongoing upkeep, scheduled rather than reactive.

Where teams put it to work

• A tax-prep backend ingesting the daily harvest ledger to net realized losses against client gains held at other brokerages.
• A wealth dashboard merging Frec lot-level holdings with held-away accounts into one net-worth and exposure view.
• A lending or monitoring tool reading the portfolio line-of-credit balance and borrowing power for loan-to-value alerts.
• A compliance backend reconciling Apex-custodied positions against Frec's customization records on a schedule.

Screens we worked from

Public store screenshots, used to read the app's surfaces. Select any to enlarge.

What was checked, and where it came from

This mapping reads Frec's own description and its public documentation, the App Store and Play listings, and the current state of US data-rights rulemaking, cross-checked in June 2026. Primary sources opened:

• Frec — how customer assets are held (Apex custody, SIPC)
• Frec: Direct Indexing on the App Store
• CFPB — Personal Financial Data Rights reconsideration
• Plaid — Investments API (holdings and transactions)

Mapped by the OpenBanking Studio integration desk, June 2026.

The same lane

Direct indexing and tax-aware robo-investing is a crowded category; a team integrating Frec is usually pulling from several of these into one view. Named here for context, not ranked.

• Wealthfront — direct indexing plus a broad robo portfolio; holds per-user positions and tax-loss-harvesting records behind an account.
• Betterment — goal-based robo portfolios with tax-coordinated allocation; balances, transactions and tax data per user.
• Fidelity (FidFolios) — direct indexing inside a full-service brokerage; holdings, lots and statements.
• Schwab Personalized Indexing — separately managed direct-indexing accounts with automated harvesting and customization.
• Vanguard Personalized Indexing — advisor-facing direct indexing with per-portfolio customization and tax data.
• Parametric Custom Core — institutional-grade direct indexing; lot-level holdings and after-tax reporting.
• SoFi Invest — consumer brokerage on Apex custody; holdings, orders and cash records per account.
• Public — multi-asset brokerage with portfolios, transactions and a treasury offering.

Questions integrators ask about Frec

Can the daily tax-loss harvest ledger be pulled separately from ordinary realized gains?

Yes. The harvest engine records each allowed and disallowed loss at the lot level with its wash-sale flag, and we keep that ledger as its own object so it can be netted against gains from other accounts rather than mixed into a single realized-P&L number.

Frec introduces and Apex Clearing custodies — which side do you integrate against?

Both, deliberately. Positions, fills and corporate actions originate on Apex's books, while index customization, the long/short overlays and the harvest logic are Frec-side. We document which field comes from which system so reconciliation doesn't chase phantom mismatches.

Does the portfolio line of credit balance arrive with the brokerage positions or on its own?

On its own. The line of credit is a separate construct with an outstanding balance, borrowing power and a rate quoted as the Effective Federal Funds Rate plus one percent, per Frec's own description. We carry it as a distinct record next to the investment holdings.

Is there a US rule that forces Frec to share this data with us?

No in-force one. The dependable basis is the account holder's own authorization to reach their own records. The CFPB's Personal Financial Data Rights rule (Part 1033) could formalize third-party access for accounts like these, but it is currently enjoined and back in reconsideration at the Bureau, so we don't treat it as settled law.

Most Frec builds land in one to two weeks. You can take the work as runnable source — the positions and harvest-ledger pull, the auth flow, the OpenAPI spec, tests and interface docs — from $300, paid only after delivery once you're satisfied; or skip the build and call our hosted endpoints instead, paying per call with nothing upfront. Tell us it's Frec and what you need from the data, and we sort access and compliance with you from there: start a project.